rfc9667.original   rfc9667.txt 
Internet Engineering Task Force T. Li, Ed. Internet Engineering Task Force (IETF) T. Li, Ed.
Internet-Draft Juniper Networks Request for Comments: 9667 Juniper Networks
Intended status: Experimental P. Psenak, Ed. Category: Experimental P. Psenak, Ed.
Expires: 7 October 2024 Cisco Systems, Inc. ISSN: 2070-1721 Cisco Systems, Inc.
H. Chen H. Chen
Futurewei Futurewei
L. Jalil L. Jalil
Verizon Verizon
S. Dontula S. Dontula
ATT AT&T
5 April 2024 October 2024
Dynamic Flooding on Dense Graphs Dynamic Flooding on Dense Graphs
draft-ietf-lsr-dynamic-flooding-18
Abstract Abstract
Routing with link state protocols in dense network topologies can Routing with link-state protocols in dense network topologies can
result in sub-optimal convergence times due to the overhead result in suboptimal convergence times due to the overhead associated
associated with flooding. This can be addressed by decreasing the with flooding. This can be addressed by decreasing the flooding
flooding topology so that it is less dense. topology so that it is less dense.
This document discusses the problem in some depth and an This document discusses the problem in some depth and an
architectural solution. Specific protocol changes for IS-IS, OSPFv2, architectural solution. Specific protocol changes for IS-IS, OSPFv2,
and OSPFv3 are described in this document. and OSPFv3 are described in this document.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This document is not an Internet Standards Track specification; it is
provisions of BCP 78 and BCP 79. published for examination, experimental implementation, and
evaluation.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document defines an Experimental Protocol for the Internet
and may be updated, replaced, or obsoleted by other documents at any community. This document is a product of the Internet Engineering
time. It is inappropriate to use Internet-Drafts as reference Task Force (IETF). It represents the consensus of the IETF
material or to cite them other than as "work in progress." community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are candidates for any level of
Internet Standard; see Section 2 of RFC 7841.
This Internet-Draft will expire on 7 October 2024. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9667.
Copyright Notice Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.1. Requirements Language
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2. Problem Statement
3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 5 3. Solution Requirements
4. Dynamic Flooding . . . . . . . . . . . . . . . . . . . . . . 6 4. Dynamic Flooding
4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Applicability
4.2. Leader election . . . . . . . . . . . . . . . . . . . . . 8 4.2. Leader Election
4.3. Computing the Flooding Topology . . . . . . . . . . . . . 9 4.3. Computing the Flooding Topology
4.4. Topologies on Complete Bipartite Graphs . . . . . . . . . 10 4.4. Topologies on Complete Bipartite Graphs
4.4.1. A Minimal Flooding Topology . . . . . . . . . . . . . 10 4.4.1. A Minimal Flooding Topology
4.4.2. Xia Topologies . . . . . . . . . . . . . . . . . . . 10 4.4.2. Xia Topologies
4.4.3. Optimization . . . . . . . . . . . . . . . . . . . . 11 4.4.3. Optimization
4.5. Encoding the Flooding Topology . . . . . . . . . . . . . 11 4.5. Encoding the Flooding Topology
4.6. Advertising the Local Edges Enabled for Flooding . . . . 12 4.6. Advertising the Local Edges Enabled for Flooding
5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 12 5. Protocol Elements
5.1. IS-IS TLVs . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. IS-IS TLVs
5.1.1. IS-IS Area Leader Sub-TLV . . . . . . . . . . . . . . 13 5.1.1. IS-IS Area Leader Sub-TLV
5.1.2. IS-IS Dynamic Flooding Sub-TLV . . . . . . . . . . . 14 5.1.2. IS-IS Dynamic Flooding Sub-TLV
5.1.3. IS-IS Area Node IDs TLV . . . . . . . . . . . . . . . 15 5.1.3. IS-IS Area Node IDs TLV
5.1.4. IS-IS Flooding Path TLV . . . . . . . . . . . . . . . 16 5.1.4. IS-IS Flooding Path TLV
5.1.5. IS-IS Flooding Request TLV . . . . . . . . . . . . . 17 5.1.5. IS-IS Flooding Request TLV
5.1.6. IS-IS LEEF Advertisement . . . . . . . . . . . . . . 18 5.1.6. IS-IS LEEF Advertisement
5.2. OSPF LSAs and TLVs . . . . . . . . . . . . . . . . . . . 18 5.2. OSPF LSAs and TLVs
5.2.1. OSPF Area Leader Sub-TLV . . . . . . . . . . . . . . 19 5.2.1. OSPF Area Leader Sub-TLV
5.2.2. OSPF Dynamic Flooding Sub-TLV . . . . . . . . . . . . 20 5.2.2. OSPF Dynamic Flooding Sub-TLV
5.2.3. OSPFv2 Dynamic Flooding Opaque LSA . . . . . . . . . 20 5.2.3. OSPFv2 Dynamic Flooding Opaque LSA
5.2.4. OSPFv3 Dynamic Flooding LSA . . . . . . . . . . . . . 22 5.2.4. OSPFv3 Dynamic Flooding LSA
5.2.5. OSPF Area Router ID TLVs . . . . . . . . . . . . . . 22 5.2.5. OSPF Area Router ID TLVs
5.2.5.1. OSPFv2 Area Router ID TLV . . . . . . . . . . . . 23 5.2.5.1. OSPFv2 Area Router ID TLV
5.2.5.2. OSPFv3 Area Router ID TLV . . . . . . . . . . . . 24 5.2.5.2. OSPFv3 Area Router ID TLV
5.2.6. OSPF Flooding Path TLV . . . . . . . . . . . . . . . 26 5.2.6. OSPF Flooding Path TLV
5.2.7. OSPF Flooding Request Bit . . . . . . . . . . . . . . 27 5.2.7. OSPF Flooding Request Bit
5.2.8. OSPF LEEF Advertisement . . . . . . . . . . . . . . . 28 5.2.8. OSPF LEEF Advertisement
6. Behavioral Specification . . . . . . . . . . . . . . . . . . 29 6. Behavioral Specification
6.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 29 6.1. Terminology
6.2. Flooding Topology . . . . . . . . . . . . . . . . . . . . 29 6.2. Flooding Topology
6.3. Leader Election . . . . . . . . . . . . . . . . . . . . . 30 6.3. Leader Election
6.4. Area Leader Responsibilities . . . . . . . . . . . . . . 30 6.4. Area Leader Responsibilities
6.5. Distributed Flooding Topology Calculation . . . . . . . . 30 6.5. Distributed Flooding Topology Calculation
6.6. Use of LANs in the Flooding Topology . . . . . . . . . . 31 6.6. Use of LANs in the Flooding Topology
6.6.1. Use of LANs in Centralized mode . . . . . . . . . . . 31 6.6.1. Use of LANs in Centralized Mode
6.6.2. Use of LANs in Distributed Mode . . . . . . . . . . . 31 6.6.2. Use of LANs in Distributed Mode
6.6.2.1. Partial flooding on a LAN in IS-IS . . . . . . . 31 6.6.2.1. Partial Flooding on a LAN in IS-IS
6.6.2.2. Partial Flooding on a LAN in OSPF . . . . . . . . 32 6.6.2.2. Partial Flooding on a LAN in OSPF
6.7. Flooding Behavior . . . . . . . . . . . . . . . . . . . . 33 6.7. Flooding Behavior
6.8. Treatment of Topology Events . . . . . . . . . . . . . . 33 6.8. Treatment of Topology Events
6.8.1. Temporary Addition of Links to the Flooding 6.8.1. Temporary Addition of Links to the Flooding Topology
Topology . . . . . . . . . . . . . . . . . . . . . . 34 6.8.2. Local Link Addition
6.8.2. Local Link Addition . . . . . . . . . . . . . . . . . 34 6.8.3. Node Addition
6.8.3. Node Addition . . . . . . . . . . . . . . . . . . . . 35 6.8.4. Failures of Links Not on the Flooding Topology
6.8.4. Failures of Links Not on the Flooding Topology . . . 35 6.8.5. Failures of Links On the Flooding Topology
6.8.5. Failures of Links On the Flooding Topology . . . . . 36 6.8.6. Node Deletion
6.8.6. Node Deletion . . . . . . . . . . . . . . . . . . . . 36 6.8.7. Local Link Addition to the Flooding Topology
6.8.7. Local Link Addition to the Flooding Topology . . . . 36 6.8.8. Local Link Deletion from the Flooding Topology
6.8.8. Local Link Deletion from the Flooding Topology . . . 37 6.8.9. Treatment of Disconnected Adjacent Nodes
6.8.9. Treatment of Disconnected Adjacent Nodes . . . . . . 37 6.8.10. Failure of the Area Leader
6.8.10. Failure of the Area Leader . . . . . . . . . . . . . 37 6.8.11. Recovery from Multiple Failures
6.8.11. Recovery from Multiple Failures . . . . . . . . . . . 38 6.8.12. Rate-Limiting Temporary Flooding
6.8.12. Rate-Limiting Temporary Flooding . . . . . . . . . . 38 7. IANA Considerations
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 7.1. IS-IS
7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 39 7.2. OSPF
7.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.2.1. OSPF Dynamic Flooding LSA TLVs Registry
7.2.1. OSPF Dynamic Flooding LSA TLVs Registry . . . . . . . 42 7.2.2. OSPF Link Attributes Sub-TLV Bit Values Registry
7.2.2. OSPF Link Attributes Sub-TLV Bit Values Registry . . 42 7.3. IGP
7.3. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Security Considerations
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 9. References
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 9.1. Normative References
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44 9.2. Informative References
10.1. Normative References . . . . . . . . . . . . . . . . . . 44 Acknowledgements
10.2. Informative References . . . . . . . . . . . . . . . . . 46 Authors' Addresses
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47
1. Introduction 1. Introduction
In recent years, there has been increased focus on how to address the In recent years, there has been increased focus on how to address the
dynamic routing of networks that have a bipartite (a.k.a., spine-leaf dynamic routing of networks that have a bipartite (also known as
or leaf-spine), Clos [Clos], or Fat Tree [Leiserson] topology. spine-leaf or leaf-spine), Clos [Clos], or Fat-tree [Leiserson]
Conventional Interior Gateway Protocols (IGPs, i.e., IS-IS topology. Conventional Interior Gateway Protocols (IGPs; i.e., IS-IS
[ISO10589], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) under-perform, [ISO10589], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) underperform,
redundantly flooding information throughout the dense topology, redundantly flooding information throughout the dense topology. This
leading to overloaded control plane inputs and thereby creating leads to overloaded control plane inputs and thereby create
operational issues. For practical considerations, network architects operational issues. For practical considerations, network architects
have resorted to applying unconventional techniques to address the have resorted to applying unconventional techniques to address the
problem, e.g., applying BGP in the data center [RFC7938]. However problem, e.g., applying BGP in the data center [RFC7938]. However,
some feel that using an Exterior Gateway Protocol as an IGP is sub- some network architects feel that using an Exterior Gateway Protocol
optimal, if only due to the configuration overhead. (EGP) as an IGP is suboptimal, perhaps only because of the
configuration overhead.
The primary issue that is demonstrated when conventional IGPs are The primary issue that is demonstrated when conventional IGPs are
applied is the poor reaction of the network to topology changes. applied is the poor reaction of the network to topology changes.
Normal link state routing protocols rely on a flooding algorithm for Normal link-state routing protocols rely on a flooding algorithm for
state distribution within an area. In a dense topology, this state distribution within an area. In a dense topology, this
flooding algorithm is highly redundant, resulting in unnecessary flooding algorithm is highly redundant and results in unnecessary
overhead. Each node in the topology receives each link state update overhead. Each node in the topology receives each link state update
multiple times. Ultimately, all of the redundant copies will be multiple times. Ultimately, all of the redundant copies will be
discarded, but only after they have reached the control plane and discarded, but only after they have reached the control plane and
been processed. This creates issues because significant link state have been processed. This creates issues because significant Link
database updates can become queued behind many redundant copies of State Database (LSDB) updates can become queued behind many redundant
another update. This delays convergence as the link state database copies of another update. This delays convergence as the LSDB does
does not stabilize promptly. not stabilize promptly.
In a real-world implementation, the packet queues leading to the In a real-world implementation, the packet queues leading to the
control-plane are necessarily of finite size, so if the flooding rate control plane are necessarily of finite size, so if the flooding rate
exceeds the update processing rate for long enough, then the control exceeds the update processing rate for long enough, then the control
plane will be obligated to drop incoming updates. If these lost plane will be obligated to drop incoming updates. If these lost
updates are of significance, this will further delay the updates are of significance, this will further delay the
stabilization of the link state database and the convergence of the stabilization of the LSDB and the convergence of the network.
network.
This is not a new problem. Historically, when routing protocols have This is not a new problem. Historically, when routing protocols have
been deployed in networks where the underlying topology is a complete been deployed in networks where the underlying topology is a complete
graph, there have been similar issues. This was more common when the graph, there have been similar issues. This was more common when the
underlying link-layer fabric presented the network layer with a full underlying link-layer fabric presented the network layer with a full
mesh of virtual connections. This was addressed by reducing the mesh of virtual connections. This was addressed by reducing the
flooding topology through IS-IS Mesh Groups [RFC2973], but this flooding topology through IS-IS Mesh Groups [RFC2973], but this
approach requires careful configuration of the flooding topology. approach requires careful configuration of the flooding topology.
Thus, the root problem is not limited to massively scalable data Thus, the root problem is not limited to massively scalable data
centers. It exists with any dense topology at scale. centers. It exists with any dense topology at scale.
Link state routing protocols were conceived when links were very Link-state routing protocols were conceived when links were very
expensive and topologies were sparse. The fact that those same expensive and topologies were sparse. The fact that those same
designs are sub-optimal in a dense topology should not come as a huge designs are suboptimal in a dense topology should not come as a huge
surprise. Technology has progressed to the point where links are surprise. Technology has progressed to the point where links are
cheap and common. This represents a complete reversal in the cheap and common. This represents a complete reversal in the
economic fundamentals of network engineering. The original designs economic fundamentals of network engineering. The original designs
are to be commended for continuing to provide correct operation to are to be commended for continuing to provide correct operation to
this point, and optimizations for operation in today's environment this point and optimizations for operation in today's environment are
are to be expected. to be expected.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. These words may also appear in this capitals, as shown here.
document in lower case as plain English words, absent their normative
meanings. These words may also appear in this document in lower case as plain
English words without their normative meanings.
2. Problem Statement 2. Problem Statement
In a dense topology, the flooding algorithm that is the heart of In a dense topology, the flooding algorithm that is the heart of
conventional link state routing protocols causes a great deal of conventional link-state routing protocols causes a great deal of
redundant messaging. This is exacerbated by scale. While the redundant messaging. This is exacerbated by scale. While the
protocol can survive this combination, the redundant messaging is protocol can survive this combination, the redundant messaging is
unnecessary overhead and delays convergence. Thus, the problem is to unnecessary overhead and delays convergence. Thus, the problem is
provide routing in dense, scalable topologies with rapid convergence. how to provide routing in dense, scalable topologies with rapid
convergence.
3. Solution Requirements 3. Solution Requirements
A solution to this problem must then meet the following requirements: A solution to this problem must meet the following requirements:
Requirement 1: Provide a dynamic routing solution. Reachability Requirement 1: Provide a dynamic routing solution. Reachability
must be restored after any topology change. must be restored after any topology change.
Requirement 2: Provide a significant improvement in convergence. Requirement 2: Provide a significant improvement in convergence.
Requirement 3: The solution should address a variety of dense Requirement 3: The solution should address a variety of dense
topologies. Just addressing a complete bipartite topologies. Just addressing a complete bipartite
topology such as K5,8 is insufficient. [Bondy] topology such as K5,8 is insufficient (see [Bondy]).
Multi-stage Clos topologies must also be addressed, Multi-stage Clos topologies must also be addressed,
as well as topologies that are slight variants. as well as topologies that are slight variants.
Addressing complete graphs is a good demonstration of Addressing complete graphs is a good demonstration of
generality. generality.
Requirement 4: There must be no single point of failure. The loss Requirement 4: There must be no single point of failure. The loss
of any link or node should not unduly hinder of any link or node should not unduly hinder
convergence. convergence.
Requirement 5: The workload for flooding should be evenly Requirement 5: The workload for flooding should be evenly
skipping to change at page 6, line 13 skipping to change at line 249
dense subgraph not operate in a radically different dense subgraph not operate in a radically different
manner than the remainder of the topology. While manner than the remainder of the topology. While
some operational differences are permissible, they some operational differences are permissible, they
should be minimized. Any change to any node outside should be minimized. Any change to any node outside
of the dense subgraph is not acceptable. These of the dense subgraph is not acceptable. These
situations occur when massively scaled data centers situations occur when massively scaled data centers
are part of an overall larger wide-area network. are part of an overall larger wide-area network.
Having a second protocol operating just on this Having a second protocol operating just on this
subgraph would add much more complexity at the edge subgraph would add much more complexity at the edge
of the subgraph where the two protocols would have to of the subgraph where the two protocols would have to
inter-operate. interoperate.
4. Dynamic Flooding 4. Dynamic Flooding
The combination of a dense topology and flooding on the physical The combination of a dense topology and flooding on the physical
topology is sub-optimal for network scaling. However, if the topology is suboptimal for network scaling. However, if the flooding
flooding topology is decoupled from the physical topology and topology is decoupled from the physical topology and restricted to a
restricted to a greatly reduced portion of that topology, the result greatly reduced portion of that topology, the result can be efficient
can be efficient flooding and all of the resilience of existing flooding and the resilience of existing protocols. A node that
protocols. A node that supports flooding on the decoupled flooding supports flooding on the decoupled flooding topology is said to
topology is said to support dynamic flooding. support dynamic flooding.
With dynamic flooding, the flooding topology is computed within an With dynamic flooding, the flooding topology is computed within an
IGP area with the dense topology either centrally on an elected node, IGP area with the dense topology either centrally on an elected node,
termed the Area Leader, or in a distributed manner on all nodes that termed the Area Leader, or in a distributed manner on all nodes that
are supporting Dynamic Flooding. If the flooding topology is are supporting dynamic flooding. If the flooding topology is
computed centrally, it is encoded into and distributed as part of the computed centrally, it is encoded into and distributed as part of the
normal link state database. This is the centralized mode of normal LSDB. This is the centralized mode of operation. If the
operation. If the flooding topology is computed in a distributed flooding topology is computed in a distributed fashion, this is the
fashion, this is the distributed mode of operation. Nodes within distributed mode of operation. Nodes within such an IGP area would
such an IGP area would only flood on the flooding topology. On links only flood on the flooding topology. On links outside of the
outside of the flooding topology, normal database synchronization flooding topology, normal database synchronization mechanisms, i.e.,
mechanisms (i.e., OSPF database exchange, IS-IS Complete Sequence OSPF database exchange and IS-IS Complete Sequence Number PDUs
Number Protocol Data Units (CSNPs)) would apply, but flooding may (CSNPs), would apply, but flooding may not. The detailed behavior of
not. Details are described in Section 6. New link state information the nodes participating in IGP is described in Section 6. New link-
that arrives from outside of the flooding topology suggests that the state information that arrives from outside of the flooding topology
sender has no flooding topology information or that it is operating suggests that the sender has no flooding topology information or that
on old information about the flooding topology. In these cases, the it is operating on old information about the flooding topology. In
new link state information should be flooded on the flooding topology these cases, the new link-state information should be flooded on the
as well. flooding topology as well.
The flooding topology covers the full set of nodes within the area, The flooding topology covers the full set of nodes within the area,
but excludes some of the links that standard flooding would employ. but excludes some of the links that standard flooding would employ.
Since the flooding topology is computed before topology changes, the Since the flooding topology is computed before topology changes, the
effort required to compute it does not factor into the convergence effort required to compute it does not factor into the convergence
time and can be done when the topology is stable. The speed of the time and can be done when the topology is stable. In the case of
computation and its distribution, in the case of centralized mode, is centralized mode, the speed of the computation and its distribution
not a significant issue. is not a significant issue.
Graph theory defines the 'degree' of a node to be the number of edges Graph theory defines the "degree" of a node to be the number of edges
that are attached to the node. To keep the flooding workload that are attached to the node. To keep the flooding workload
scalable and distributed, there should be no nodes in the flooding scalable and distributed, there should be no nodes in the flooding
topology that have a much higher degree than other nodes. topology that have a much higher degree than other nodes.
If a node does not have any flooding topology information when it If a node does not have any flooding topology information when it
receives new link state information, it should flood according to receives new link-state information, it should flood according to
standard flooding rules. This situation will occur when the dense standard flooding rules. This situation will occur when the dense
topology is first established but is unlikely to recur. topology is first established but is unlikely to recur.
Link state protocols are intentionally designed to be asynchronous, Link-state protocols are intentionally designed to be asynchronous
with nodes acting independently. During the flooding process, with nodes acting independently. During the flooding process,
different nodes will have different information, resulting in different nodes will have different information, resulting in
transient conditions that can temporarily produce suboptimal transient conditions that can temporarily produce suboptimal
forwarding. These periods of transient conditions are known as forwarding. These periods of transient conditions are known as
'transients.' "transients."
When centralized mode is used and if, during a transient, there are When centralized mode is used and if there are multiple flooding
multiple flooding topologies being advertised, then nodes should topologies being advertised during a transient, then nodes should
flood link state updates on all of the flooding topologies. Each flood link-state updates on all of the flooding topologies. Each
node should locally evaluate the election of the Area Leader for the node should locally evaluate the election of the Area Leader for the
IGP area and first flood on its flooding topology. The rationale IGP area and first flood on its flooding topology. The rationale
behind this is straightforward: if there is a transient and there has behind this is straightforward: if there is a transient and there has
been a recent change in Area Leader, then propagating topology been a recent change in Area Leader, then propagating topology
information promptly along the most likely flooding topology should information promptly along the most likely flooding topology should
be the priority. be the priority.
During transients, loops may form in the flooding topology. This is During transients, loops may form in the flooding topology. This is
not problematic, as the standard flooding rules would cause duplicate not problematic, as the standard flooding rules would cause duplicate
updates to be ignored. Similarly, during transients, the flooding updates to be ignored. Similarly, during transients, the flooding
skipping to change at page 7, line 47 skipping to change at line 331
4.1. Applicability 4.1. Applicability
In a complete graph, this approach is appealing because it In a complete graph, this approach is appealing because it
drastically decreases the flooding topology without the manual drastically decreases the flooding topology without the manual
configuration of mesh groups. By controlling the diameter of the configuration of mesh groups. By controlling the diameter of the
flooding topology, as well as the maximum node degree in the flooding flooding topology, as well as the maximum node degree in the flooding
topology, convergence time goals can be met, and the stability of the topology, convergence time goals can be met, and the stability of the
control plane can be assured. control plane can be assured.
Similarly, in a massively scaled data center, where there are many Similarly, in a massively scaled data center (where there are many
opportunities for redundant flooding, this mechanism ensures that opportunities for redundant flooding), this mechanism guarantees that
flooding is redundant, with each leaf and spine well connected, while flooding is redundant, with each leaf and spine well connected, while
ensuring that no update takes too many hops and that no node shares ensuring that no update takes too many hops and that no node shares
an undue portion of the flooding effort. an undue portion of the flooding effort.
In a network where only a portion of the nodes support Dynamic In a network where only a portion of the nodes support dynamic
Flooding, the remaining nodes will continue to perform standard flooding, the remaining nodes will continue to perform standard
flooding. This is not an issue for correctness, as no node can flooding. This is not an issue for correctness, as no node can
become isolated. become isolated.
Flooding that is initiated by nodes that support Dynamic Flooding Flooding that is initiated by nodes that support dynamic flooding
will remain within the flooding topology until it reaches a legacy will remain within the flooding topology until it reaches a legacy
node, where standard flooding is resumed. Standard flooding will be node, where standard flooding is resumed. Standard flooding will be
bounded by nodes supporting Dynamic Flooding, which can help limit bounded by nodes supporting dynamic flooding, which can help limit
the propagation of unnecessary flooding. Whether or not the network the propagation of unnecessary flooding. Whether or not the network
can remain stable in this condition is very dependent on the number can remain stable in this condition is very dependent on the number
and location of the nodes that support Dynamic Flooding. and location of the nodes that support dynamic flooding.
During incremental deployment of dynamic flooding, an area will During incremental deployment of dynamic flooding, an area will
consist of one or more sets of connected nodes that support dynamic consist of one or more sets of connected nodes that support dynamic
flooding and one or more sets of connected nodes that do not, i.e., flooding and one or more sets of connected nodes that do not, i.e.,
nodes that support standard flooding. The flooding topology is the nodes that support standard flooding. The flooding topology is the
union of these sets of nodes. Each set of nodes that does not union of these sets of nodes. Each set of nodes that does not
support dynamic flooding needs to be part of the flooding topology support dynamic flooding needs to be part of the flooding topology
and such a set of nodes may provide connectivity between two or more and such a set of nodes may provide connectivity between two or more
sets of nodes that support dynamic flooding. sets of nodes that support dynamic flooding.
4.2. Leader election 4.2. Leader Election
A single node within the dense topology is elected as an Area Leader. A single node within the dense topology is elected as an Area Leader.
A generalization of the mechanisms used in existing Designated Router A generalization of the mechanisms used in existing Designated Router
(OSPF) or Designated Intermediate-System (IS-IS) elections is used (OSPF) or Designated Intermediate-System (IS-IS) elections is used
for leader election. The elected node is known as the Area Leader. for leader election. The elected node is known as the Area Leader.
In the case of centralized mode, the Area Leader is responsible for In the case of centralized mode, the Area Leader is responsible for
computing and distributing the flooding topology. When a new Area computing and distributing the flooding topology. When a new Area
Leader is elected and has distributed new flooding topology Leader is elected and has distributed new flooding topology
information, then any prior Area Leaders should withdraw any of their information, then any prior Area Leaders should withdraw any of their
flooding topology information from their link state database entries. flooding topology information from their LSDB entries.
In the case of distributed mode, the distributed algorithm advertised In the case of distributed mode, the distributed algorithm advertised
by the Area Leader MUST be used by all nodes that participate in by the Area Leader MUST be used by all nodes that participate in
Dynamic Flooding. dynamic flooding.
Not every node needs to be a candidate to be the Area Leader within Not every node needs to be a candidate to be the Area Leader within
an area, as a single candidate is sufficient for correct operation. an area, as a single candidate is sufficient for correct operation.
For redundancy, however, it is strongly RECOMMENDED that there be However, for redundancy, it is strongly RECOMMENDED that there be
multiple candidates. multiple candidates.
4.3. Computing the Flooding Topology 4.3. Computing the Flooding Topology
There is a great deal of flexibility in how the flooding topology may There is a great deal of flexibility in how the flooding topology may
be computed. For resilience, it needs to at least contain a cycle of be computed. For resilience, it needs to at least contain a cycle of
all nodes in the dense subgraph. However, additional links could be all nodes in the dense subgraph. However, additional links could be
added to decrease the convergence time. The trade-off between the added to decrease the convergence time. The trade-off between the
density of the flooding topology and the convergence time is a matter density of the flooding topology and the convergence time is a matter
for further study. The exact algorithm for computing the flooding for further study. The exact algorithm for computing the flooding
topology in the case of the centralized computation need not be topology in the case of the centralized computation need not be
standardized, as it is not an interoperability issue. Only the standardized, as it is not an interoperability issue. Only the
encoding of the resultant topology needs to be documented. In the encoding of the resultant topology needs to be documented. In the
case of distributed mode, all nodes in the IGP area need to use the case of distributed mode, all nodes in the IGP area need to use the
same algorithm to compute the flooding topology. It is possible to same algorithm to compute the flooding topology. It is possible to
use private algorithms to compute flooding topology, so long as all use private algorithms to compute flooding topology, so long as all
nodes in the IGP area use the same algorithm. nodes in the IGP area use the same algorithm.
While the flooding topology should be a covering cycle, it need not While the flooding topology should be a covering cycle, it need not
be a Hamiltonian cycle where each node appears only once. In fact, be a Hamiltonian cycle where each node appears only once. In fact,
in many relevant topologies, this will not be possible, e.g., K5,8. in many relevant topologies, this will not be possible (e.g., K5,8).
This is fortunate, as computing a Hamiltonian cycle is known to be This is fortunate, as computing a Hamiltonian cycle is known to be
NP-complete. NP-complete.
A simple algorithm to compute the topology for a complete bipartite A simple algorithm to compute the topology for a complete bipartite
graph is to simply select unvisited nodes on each side of the graph graph is to simply select unvisited nodes on each side of the graph
until both sides are completely visited. If the numbers of nodes on until both sides are completely visited. If the numbers of nodes on
each side of the graph are unequal, then revisiting nodes on the less each side of the graph are unequal, then revisiting nodes on the less
populated side of the graph will be inevitable. This algorithm can populated side of the graph will be inevitable. This algorithm can
run in O(N) time, so it is quite efficient. run in O(N) time, so it is quite efficient.
While a simple cycle is adequate for correctness and resiliency, it While a simple cycle is adequate for correctness and resiliency, it
may not be optimal for convergence. At scale, a cycle may have a may not be optimal for convergence. At scale, a cycle may have a
diameter that is half the number of nodes in the graph. This could diameter that is half the number of nodes in the graph. This could
cause an undue delay in link state update propagation. Therefore it cause an undue delay in link-state update propagation. Therefore, it
may be useful to have a bound on the diameter of the flooding may be useful to have a bound on the diameter of the flooding
topology. Introducing more links into the flooding topology would topology. Introducing more links into the flooding topology would
reduce the diameter but at the trade-off of possibly adding redundant reduce the diameter but at the trade-off of possibly adding redundant
messaging. The optimal trade-off between convergence time and graph messaging. The optimal trade-off between convergence time and graph
diameter is for further study. diameter is for further study.
Similarly, if additional redundancy is added to the flooding Similarly, if additional redundancy is added to the flooding
topology, specific nodes in that topology may end up with a very high topology, specific nodes in that topology may end up with a very high
degree. This could result in overloading the control plane of those degree. This could result in overloading the control plane of those
nodes, resulting in poor convergence. Thus, it may be preferable to nodes, resulting in poor convergence. Thus, it may be preferable to
skipping to change at page 10, line 19 skipping to change at line 443
4.4. Topologies on Complete Bipartite Graphs 4.4. Topologies on Complete Bipartite Graphs
Complete bipartite graph topologies have become popular for data Complete bipartite graph topologies have become popular for data
center applications and are commonly called leaf-spine or spine-leaf center applications and are commonly called leaf-spine or spine-leaf
topologies. This section discusses some flooding topologies that are topologies. This section discusses some flooding topologies that are
of particular interest in these networks. of particular interest in these networks.
4.4.1. A Minimal Flooding Topology 4.4.1. A Minimal Flooding Topology
A Minimal Flooding Topology on a complete bipartite graph is one in A minimal flooding topology on a complete bipartite graph is one in
which the topology is connected and each node has at least degree which the topology is connected and each node has at least degree
two. This is of interest because it guarantees that the flooding two. This is of interest because it guarantees that the flooding
topology has no single point of failure. topology has no single point of failure.
In practice, this implies that every leaf node in the flooding In practice, this implies that every leaf node in the flooding
topology will have a degree of two. As there are usually more leaves topology will have a degree of two. As there are usually more leaves
than spines, the degree of the spines will be higher, but the load on than spines, the degree of the spines will be higher, but the load on
the individual spines can be evenly distributed. the individual spines can be evenly distributed.
This type of flooding topology is also of interest because it scales This type of flooding topology is also of interest because it scales
well. As the number of leaves increases, it is possible to construct well. As the number of leaves increases, it is possible to construct
flooding topologies that perform well. Specifically, for N spines flooding topologies that perform well. Specifically, for N spines
and M leaves, if M >= N(N/2-1), then there is a flooding topology and M leaves, if M >= N(N/2-1), then there is a flooding topology
that has a diameter of four. that has a diameter of 4.
4.4.2. Xia Topologies 4.4.2. Xia Topologies
A Xia Topology on a complete bipartite graph is one in which all A Xia topology on a complete bipartite graph is one in which all
spine nodes are bi-connected through leaves with degree two, but the spine nodes are biconnected through leaves with degree two, but the
remaining leaves all have degree one and are evenly distributed remaining leaves all have degree one and are evenly distributed
across the spines. across the spines.
Constructively, one can create a Xia topology by iterating through Constructively, one can create a Xia topology by iterating through
the spines. Each spine can be connected to the next spine by the spines. Each spine can be connected to the next spine by
selecting any unused leaf. Since leaves are connected to all spines, selecting any unused leaf. Since leaves are connected to all spines,
all leaves will have a connection to both the first and second spine all leaves will have a connection to both the first and second spine
and one can therefore choose any leaf without loss of generality. and one can therefore choose any leaf without loss of generality.
Continuing this iteration across all of the spines, selecting a new Continuing this iteration across all of the spines, selecting a new
leaf at each iteration, will result in a path that connects all leaf at each iteration will result in a path that connects all
spines. Adding one more leaf between the last and first spine will spines. Adding one more leaf between the last and first spine will
produce a cycle of N spines and N leaves. produce a cycle of N spines and N leaves.
At this point, M-N leaves remain unconnected. These can be At this point, M-N leaves remain unconnected. These can be
distributed evenly across the remaining spines, connected by a single distributed evenly across the remaining spines and connected by a
link. single link.
Xia topologies represent a compromise that trades off increased risk Xia topologies represent a compromise that trades off increased risk
and decreased performance for lower flooding amplification. Xia and decreased performance for lower flooding amplification. Xia
topologies will have a larger diameter. For M spines, the diameter topologies will have a larger diameter. For M spines, the diameter
will be M + 2. will be M + 2.
In a Xia topology, some leaves are singly connected. This represents In a Xia topology, some leaves are singly connected. This represents
a risk in that in some failures, convergence may be delayed. a risk in that convergence may be delayed in some failures. However,
However, there may be some alternate behaviors that can be employed there may be some alternate behaviors that can be employed to
to mitigate these risks. If a leaf node sees that its single link on mitigate these risks. If a leaf node sees that its single link on
the flooding topology has failed, it can compensate by performing a the flooding topology has failed, it can compensate by performing a
database synchronization check with a different spine. Similarly, if database synchronization check with a different spine. Similarly, if
a leaf determines that its connected spine on the flooding topology a leaf determines that its connected spine on the flooding topology
has failed, it can compensate by performing a database has failed, it can compensate by performing a database
synchronization check with a different spine. In both of these synchronization check with a different spine. In both of these
cases, the synchronization check is intended to ameliorate any delays cases, the synchronization check is intended to ameliorate any delays
in link state propagation due to the fragmentation of the flooding in link-state propagation due to the fragmentation of the flooding
topology. topology.
The benefit of this topology is that flooding load is easily The benefit of this topology is that flooding load is easily
understood. Each node in the spine cycle will never receive an understood. Each node in the spine cycle will never receive an
update more than twice. For M leaves and N spines, a spine never update more than twice. For M leaves and N spines, a spine never
transmits more than (M/N +1) updates. transmits more than (M/N +1) updates.
4.4.3. Optimization 4.4.3. Optimization
If two nodes are adjacent in the flooding topology and there is a set If two nodes are adjacent in the flooding topology and there is a set
of parallel links between them, then any given update MUST be flooded of parallel links between them, then any given update MUST be flooded
over only one of those links. The selection of the specific link is over only one of those links. The selection of the specific link is
implementation-specific. implementation-specific.
4.5. Encoding the Flooding Topology 4.5. Encoding the Flooding Topology
There are a variety of ways that the flooding topology could be There are a variety of ways that the flooding topology could be
encoded efficiently. If the topology was only a cycle, a simple list encoded efficiently. If the topology was only a cycle, a simple list
of the nodes in the topology would suffice. However, this is of the nodes in the topology would suffice. However, this is
insufficiently flexible as it would require a slightly different insufficiently flexible, as it would require a slightly different
encoding scheme as soon as a single additional link is added. encoding scheme as soon as a single additional link is added.
Instead, this document chooses to encode the flooding topology as a Instead, this document chooses to encode the flooding topology as a
set of intersecting paths, where each path is a set of connected set of intersecting paths, where each path is a set of connected
links. links.
Advertisement of the flooding topology includes support for multi- Advertisement of the flooding topology includes support for multi-
access broadcast LANs. When a LAN is included in the flooding access broadcast LANs. When a LAN is included in the flooding
topology, all edges between the LAN and nodes connected to the LAN topology, all edges between the LAN and nodes connected to the LAN
are assumed to be part of the flooding topology. To reduce the size are assumed to be part of the flooding topology. To reduce the size
of the flooding topology advertisement, explicit advertisement of of the flooding topology advertisement, explicit advertisement of
these edges is optional. Note that this may result in the these edges is optional. Note that this may result in the
possibility of "hidden nodes" or "stealth nodes" which are part of possibility of "hidden nodes" or "stealth nodes", which are part of
the flooding topology but are not explicitly mentioned in the the flooding topology but are not explicitly mentioned in the
flooding topology advertisements. These hidden nodes can be found by flooding topology advertisements. These hidden nodes can be found by
examination of the Link State database where connectivity between a examination of the LSDB where connectivity between a LAN and nodes
LAN and nodes connected to the LAN is fully specified. connected to the LAN is fully specified.
Note that while all nodes MUST be part of the advertised flooding Note that while all nodes MUST be part of the advertised flooding
topology, not all multi-access LANs need to be included. Only those topology, not all multi-access LANs need to be included. Only those
LANs which are part of the flooding topology need to be included in LANs that are part of the flooding topology need to be included in
the advertised flooding topology. the advertised flooding topology.
Other encodings are certainly possible. This document has attempted Other encodings are certainly possible. This document has attempted
to make a useful trade-off between simplicity, generality, and space. to make a useful trade-off between simplicity, generality, and space.
4.6. Advertising the Local Edges Enabled for Flooding 4.6. Advertising the Local Edges Enabled for Flooding
Correct operation of the flooding topology requires that all nodes Correct operation of the flooding topology requires that all nodes
which participate in the flooding topology choose local links for that participate in the flooding topology choose local links for
flooding which are part of the calculated flooding topology. Failure flooding that are part of the calculated flooding topology. Failure
to do so could result in an unexpected partition of the flooding to do so could result in an unexpected partition of the flooding
topology and/or sub-optimal flooding reduction. As an aid to topology and/or suboptimal flooding reduction. As an aid to
diagnosing problems when dynamic flooding is in use, this document diagnosing problems when dynamic flooding is in use, this document
defines a means of advertising what local edges are enabled for defines a means of advertising the Local Edges Enabled for Flooding
flooding (LEEF). The protocol-specific encodings are defined in (LEEF). The protocol-specific encodings are defined in Sections
Sections 5.1.6 and 5.2.8. 5.1.6 and 5.2.8.
The following guidelines apply: The following guidelines apply:
Advertisement of LEEFs is optional. * Advertisement of LEEF is optional.
As the flooding topology is defined in terms of edges (i.e., pairs * As the flooding topology is defined in terms of edges (i.e., pairs
of nodes) and not in terms of links, in cases where parallel of nodes) and not in terms of links, the advertisement SHOULD
adjacencies to the same neighbor exist, the advertisement SHOULD indicate that all such links have been enabled in cases where
indicate that all such links have been enabled. parallel adjacencies to the same neighbor exist.
LEEF advertisements MUST NOT include edges enabled for temporary * LEEF advertisements MUST NOT include edges enabled for temporary
flooding (Section 6.7). flooding (Section 6.7).
LEEF advertisements MUST NOT be used either when calculating a * LEEF advertisements MUST NOT be used either when calculating a
flooding topology or when determining what links to add flooding topology or when determining what links to add
temporarily to the flooding topology when the flooding topology is temporarily to the flooding topology when the flooding topology is
temporarily partitioned. temporarily partitioned.
5. Protocol Elements 5. Protocol Elements
5.1. IS-IS TLVs 5.1. IS-IS TLVs
The following TLVs/sub-TLVs are added to IS-IS: The following TLVs/sub-TLVs are added to IS-IS:
1. A sub-TLV that an IS may include in its Link State Protocol Data 1. A sub-TLV that an IS may include in its Link State PDU (LSP) to
Unit (LSP) to indicate its preference for becoming the Area indicate its preference for becoming the Area Leader.
Leader.
2. A sub-TLV that an IS may include in its LSP to indicate that it 2. A sub-TLV that an IS may include in its LSP to indicate that it
supports Dynamic Flooding and the algorithms that it supports for supports dynamic flooding and the algorithms that it supports for
distributed mode, if any. distributed mode, if any.
3. A TLV to advertise the list of system IDs that compose the 3. A TLV to advertise the list of system IDs that compose the
flooding topology for the area. A system ID is an identifier for flooding topology for the area. A system ID is an identifier for
a node. a node.
4. A TLV to advertise a path that is part of the flooding topology. 4. A TLV to advertise a path that is part of the flooding topology.
5. A TLV that requests flooding from the adjacent node. 5. A TLV that requests flooding from the adjacent node.
5.1.1. IS-IS Area Leader Sub-TLV 5.1.1. IS-IS Area Leader Sub-TLV
The Area Leader Sub-TLV allows a system to: The IS-IS Area Leader Sub-TLV allows a system to:
1. Indicate its eligibility and priority for becoming the Area 1. Indicate its eligibility and priority for becoming the Area
Leader. Leader.
2. Indicate whether centralized or distributed mode is to be used to 2. Indicate whether centralized or distributed mode is to be used to
compute the flooding topology in the area. compute the flooding topology in the area.
3. Indicate the algorithm identifier for the algorithm that is used 3. Indicate the algorithm identifier for the algorithm that is used
to compute the flooding topology in distributed mode. to compute the flooding topology in distributed mode.
Intermediate Systems (nodes) that are not advertising this Sub-TLV Intermediate Systems (nodes) that are not advertising this sub-TLV
are not eligible to become the Area Leader. are not eligible to become the Area Leader.
The Area Leader is the node with the numerically highest Area Leader The Area Leader is the node with the numerically highest Area Leader
priority in the area. In the event of ties, the node with the priority in the area. In the event of ties, the node with the
numerically highest system ID is the Area Leader. Due to transients numerically highest system ID is the Area Leader. Due to transients
during database flooding, different nodes may not agree on the Area during database flooding, different nodes may not agree on the Area
Leader. This is not problematic, as subsequent flooding will cause Leader. This is not problematic, as subsequent flooding will cause
the entire area to converge. the entire area to converge.
The Area Leader Sub-TLV is advertised as a Sub-TLV of the IS-IS The IS-IS Area Leader Sub-TLV is advertised as a sub-TLV of the IS-IS
Router Capability TLV-242 that is defined in [RFC7981] and has the Router Capability TLV (242) [RFC7981] and has the following format:
following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Priority | Algorithm | | Type | Length | Priority | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD1 Figure 1: IS-IS Area Leader Sub-TLV
Length: 2 Type: 27
Priority: 0-255, unsigned integer. Determination of the priority Length: 2 octets
is outside of the scope of this document.
Algorithm: a numeric identifier in the range 0-255 that identifies Priority: 0-255, unsigned integer. Determination of the priority is
outside of the scope of this document.
Algorithm: A numeric identifier in the range 0-255 that identifies
the algorithm used to calculate the flooding topology. The the algorithm used to calculate the flooding topology. The
following values are defined: following values are defined:
- 0: Centralized computation by the Area Leader. 0: Centralized computation by the Area Leader.
- 1-127: Standardized distributed algorithms. 1-127: Standardized distributed algorithms.
- 128-254: Private distributed algorithms. Individual values are 128-254: Private distributed algorithms. Individual values are
to be assigned according to the "Private Use" policy defined in to be assigned according to the "Private Use" policy defined in
[RFC8126] (see Section 7.3). Section 4.1 of [RFC8126] (see Section 7.3).
- 255: Reserved 255: Reserved
5.1.2. IS-IS Dynamic Flooding Sub-TLV 5.1.2. IS-IS Dynamic Flooding Sub-TLV
The Dynamic Flooding Sub-TLV allows a system to: The IS-IS Dynamic Flooding Sub-TLV allows a system to:
1. Indicate that it supports Dynamic Flooding. This is indicated by 1. Indicate that it supports dynamic flooding. This is indicated by
the advertisement of this Sub-TLV. the advertisement of this sub-TLV.
2. Indicate the set of algorithms that it supports. 2. Indicate the set of algorithms that it supports.
In incremental deployments, understanding which nodes support Dynamic In incremental deployments, understanding which nodes support dynamic
Flooding can be used to optimize the flooding topology. In flooding can be used to optimize the flooding topology. In
distributed mode, knowing the capabilities of the nodes can allow the distributed mode, knowing the capabilities of the nodes can allow the
Area Leader to select the optimal algorithm. Area Leader to select the optimal algorithm.
The Dynamic Flooding Sub-TLV is advertised as a Sub-TLV of the IS-IS The IS-IS Dynamic Flooding Sub-TLV is advertised as a sub-TLV of the
Router Capability TLV (242) [RFC7981] and has the following format: IS-IS Router Capability TLV (242) [RFC7981] and has the following
format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Algorithm... | | Type | Length | Algorithm... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD7 Figure 2: IS-IS Dynamic Flooding Sub-TLV
Length: 1-255; number of Algorithms Type: 28
Algorithm: numeric identifiers in the range 0-255 that identify Length: 1-255 octets; number of Algorithms
the algorithm used to calculate the flooding topology, as
described in Section 5.1.1. Algorithm: Numeric identifiers in the range 0-255 that identify the
algorithm used to calculate the flooding topology as described in
Section 5.1.1.
5.1.3. IS-IS Area Node IDs TLV 5.1.3. IS-IS Area Node IDs TLV
The IS-IS Area Node IDs TLV is only used in centralized mode. The IS-IS Area Node IDs TLV is only used in centralized mode.
The Area Node IDs TLV is used by the Area Leader to enumerate the The IS-IS Area Node IDs TLV is used by the Area Leader to enumerate
Node IDs (System ID + pseudo-node ID) that it has used in computing the node IDs (System ID + pseudonode ID) that it has used in
the area flooding topology. Conceptually, the Area Leader creates a computing the area flooding topology. Conceptually, the Area Leader
list of node IDs for all nodes in the area (including pseudo-nodes creates a list of node IDs for all nodes in the area (including
for all LANs in the topology), assigning an index to each node, pseudonodes for all LANs in the topology) and assigns an index to
starting with index 0. Indices are implicitly assigned sequentially, each node, starting with index 0. Indices are implicitly assigned
with the index of the first node being the Starting Index and each sequentially, with the index of the first node being the Starting
subsequent node's index is the previous node's index + 1. Index and each subsequent node's index is the previous node's index +
1.
Because the space in a single TLV is limited, more than one TLV may Because the space in a single TLV is limited, more than one TLV may
be required to encode all of the node IDs in the area. This TLV may be required to encode all of the node IDs in the area. This TLV may
be present in multiple LSPs. be present in multiple LSPs.
The format of the Area Node IDs TLV is: The IS-IS Area Node IDs TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Starting Index | | Type | Length | Starting Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L| Reserved | Node IDs ... |L| Reserved | Node IDs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node IDs continued .... Node IDs continued ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD2 Figure 3: IS-IS Area Node IDs TLV
Length: 3 + ((System ID Length + 1) * (number of node IDs)) Type: 17
Starting index: The index of the first node ID that appears in
this TLV.
L (Last): This bit is set if the index of the last node ID that Length: 3 + ((System ID Length + 1) * (number of node IDs)) in
octets
Starting Index: The index of the first node ID that appears in this
TLV.
L (Last): This bit is set if the index of the last node ID that
appears in this TLV is equal to the last index in the full list of appears in this TLV is equal to the last index in the full list of
node IDs for the area. node IDs for the area.
Node IDs: A concatenated list of node IDs for the area Node IDs: A concatenated list of node IDs for the area.
If there are multiple IS-IS Area Node IDs TLVs with the L-bit set If multiple IS-IS Area Node IDs TLVs with the L bit set are
advertised by the same node, the TLV which specifies the smaller advertised by the same node, the TLV that specifies the smaller
maximum index is used and the other TLV(s) with L-bit set are maximum index is used and the other TLVs with the L bit set are
ignored. TLVs which specify node IDs with indices greater than that ignored. TLVs that specify node IDs with indices greater than that
specified by the TLV with the L-bit set are also ignored. specified by the TLV with the L bit set are also ignored.
5.1.4. IS-IS Flooding Path TLV 5.1.4. IS-IS Flooding Path TLV
The IS-IS Flooding Path TLV is only used in centralized mode. The IS-IS Flooding Path TLV is only used in centralized mode.
The Flooding Path TLV is used to denote a path in the flooding The IS-IS Flooding Path TLV is used to denote a path in the flooding
topology. The goal is an efficient encoding of the links of the topology. The goal is an efficient encoding of the links of the
topology. A single link is a simple case of a path that only covers topology. A single link is a simple case of a path that only covers
two nodes. A connected path may be described as a sequence of two nodes. A connected path may be described as a sequence of
indices: (I1, I2, I3, ...), denoting a link from the system with indices (I1, I2, I3, ...), denoting a link from the system with index
index 1 to the system with index 2, a link from the system with index 1 to the system with index 2, a link from the system with index 2 to
2 to the system with index 3, and so on. the system with index 3, and so on.
If a path exceeds the size that can be stored in a single TLV, then If a path exceeds the size that can be stored in a single TLV, then
the path may be distributed across multiple TLVs by the replication the path may be distributed across multiple TLVs by the replication
of a single system index. of a single system index.
Complex topologies that are not a single path can be described using Complex topologies that are not a single path can be described using
multiple TLVs. multiple TLVs.
The Flooding Path TLV contains a list of system indices relative to The IS-IS Flooding Path TLV contains a list of system indices
the systems advertised through the Area Node IDs TLV. At least 2 relative to the systems advertised through the IS-IS Area Node IDs
indices must be included in the TLV. Due to the length restriction TLV. At least 2 indices must be included in the TLV. Due to the
of TLVs, this TLV can contain at most 126 system indices. length restriction of TLVs, this TLV can contain 126 system indices
at most.
The Flooding Path TLV has the format: The IS-IS Flooding Path TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Starting Index | | Type | Length | Starting Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index 2 | Additional indices ... | Index 2 | Additional indices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD3
Length: 2 * (number of indices in the path) Figure 4: IS-IS Flooding Path TLV
Starting index: The index of the first system in the path. Type: 18
Index 2: The index of the next system in the path. Length: 2 * (number of indices in the path) in octets
Additional indices (optional): A sequence of additional indices to Starting Index: The index of the first system in the path.
Index 2: The index of the next system in the path.
Additional indices (optional): A sequence of additional indices to
systems along the path. systems along the path.
5.1.5. IS-IS Flooding Request TLV 5.1.5. IS-IS Flooding Request TLV
The Flooding Request TLV allows a system to request an adjacent node The IS-IS Flooding Request TLV allows a system to request an adjacent
to enable flooding towards it on a specific link in the case where node to enable flooding towards it on a specific link in the case
the connection to the adjacent node is not part of the existing where the connection to the adjacent node is not part of the existing
flooding topology. flooding topology.
A node that supports Dynamic Flooding MAY include the Flooding A node that supports dynamic flooding MAY include the IS-IS Flooding
Request TLV in its Intermediate System to Intermediate System Hello Request TLV in its IS-IS Hello (IIH) Protocol Data Units (PDUs).
(IIH) Protocol Data Units (PDUs).
The Flooding Request TLV has the format: The IS-IS Flooding Request TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Levels | Scope | | Type | Length | Levels | Scope |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... | | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD9 Figure 5: IS-IS Flooding Request TLV
Length: 1 + number of advertised Flooding Scopes Type: 19
Levels: the level(s) for which flooding is requested. Levels are Length: 1 + number of advertised flooding scopes in octets
Levels: The levels for which flooding is requested. Levels are
encoded as the circuit type as specified in IS-IS [ISO10589] encoded as the circuit type as specified in IS-IS [ISO10589]
Scope (8 bits): Flooding Scope for which the flooding is requested Scope (8 bits): Flooding scope for which the flooding is requested
as defined in the LSP Flooding Scope Identifier Registry as as defined in the LSP Flooding Scope Identifier Registry as
created by [RFC7356]. Inclusion of flooding scopes is optional created by [RFC7356]. Inclusion of flooding scopes is optional
and is only necessary if [RFC7356] is supported. Multiple and is only necessary if [RFC7356] is supported. Multiple
flooding scopes MAY be included. Values are restricted to the flooding scopes MAY be included. Values are restricted to the
range 0..127. range 0..127.
Circuit Flooding Scope MUST NOT be sent in the Flooding Request TLV Circuit flooding scope MUST NOT be sent in the Flooding Request TLV
and MUST be ignored if received. and MUST be ignored if received.
When the TLV is received in a level-specific LAN-Hello PDU (L1-LAN- When the TLV is received in a level-specific LAN-Hello PDU (L1-LAN-
IIH or L2-LAN-IIH), only levels that match the PDU type are valid. IIH or L2-LAN-IIH), only levels that match the PDU type are valid.
Levels that do not match the PDU type MUST be ignored on receipt. Levels that do not match the PDU type MUST be ignored on receipt.
When the TLV is received in a Point-to-Point Hello (P2P-IIH), only When the TLV is received in a Point-to-Point Hello (P2P-IIH), only
levels that are supported by the established adjacency are valid. levels that are supported by the established adjacency are valid.
Levels that are not supported by the adjacency MUST be ignored on Levels that are not supported by the adjacency MUST be ignored on
receipt. receipt.
If flooding was disabled on the received link due to Dynamic If flooding was disabled on the received link due to dynamic
Flooding, then flooding MUST be temporarily enabled over the link for flooding, then flooding MUST be temporarily enabled over the link for
the specified Circuit Type(s) and Flooding Scope(s) received in the the specified Circuit Types and flooding scopes received in the in
in the Flooding Request TLV. Flooding MUST be enabled until the the IS-IS Flooding Request TLV. Flooding MUST be enabled until the
Circuit Type or Flooding Scope is no longer advertised in the Circuit Type or Flooding Scope is no longer advertised in the IS-IS
Flooding Request TLV or the TLV no longer appears in IIH PDUs Flooding Request TLV or the TLV no longer appears in IIH PDUs
received on the link. received on the link.
When flooding is temporarily enabled on the link for any Circuit Type When flooding is temporarily enabled on the link for any Circuit Type
or Flooding Scope due to receiving the Flooding Request TLV, the or Flooding Scope due to receiving the IS-IS Flooding Request TLV,
receiver MUST perform standard database synchronization for the the receiver MUST perform standard database synchronization for the
corresponding Circuit Type(s) and Flooding Scope(s) on the link. In corresponding Circuit Types and flooding scopes on the link. In the
the case of IS-IS, this results in setting the Send Routeing Message case of IS-IS, this results in setting the Send Routeing Message
(SRM) flag for all related LSPs on the link and sending CSNPs. (SRM) flag for all related LSPs on the link and sending CSNPs.
So long as the Flooding Request TLV is being received, flooding MUST So long as the IS-IS Flooding Request TLV is being received, flooding
NOT be disabled for any of the Circuit Types or Flooding Scopes MUST NOT be disabled for any of the Circuit Types or flooding scopes
present in the Flooding Request TLV, even if the connection between present in the IS-IS Flooding Request TLV, even if the connection
the neighbors is removed from the flooding topology. Flooding for between the neighbors is removed from the flooding topology.
such Circuit Types or Flooding Scopes MUST continue on the link and Flooding for such Circuit Types or flooding scopes MUST continue on
be considered temporarily enabled. the link and be considered temporarily enabled.
5.1.6. IS-IS LEEF Advertisement 5.1.6. IS-IS LEEF Advertisement
In support of advertising which edges are currently enabled in the In support of advertising which edges are currently enabled in the
flooding topology, an implementation MAY indicate that a link is part flooding topology, an implementation MAY indicate that a link is part
of the flooding topology by advertising a bit-value in the Link of the flooding topology by advertising a bit value in the Link
Attributes sub-TLV defined by [RFC5029]. Attributes sub-TLV defined by [RFC5029].
The following bit-value is defined by this document: The following bit-value is defined by this document:
Local Edge Enabled for Flooding (LEEF) - suggested value 4 (to be Local Edge Enabled for Flooding (LEEF): 0x4
assigned by IANA)
5.2. OSPF LSAs and TLVs 5.2. OSPF LSAs and TLVs
This section defines new LSAs and TLVs for both OSPFv2 and OSPFv3. This section defines new Link State Advertisements (LSAs) and TLVs
for both OSPFv2 and OSPFv3.
The following LSAs and TLVs/sub-TLVs are added to OSPFv2/OSPFv3: The following LSAs and TLVs/sub-TLVs are added to OSPFv2/OSPFv3:
1. A TLV that is used to advertise the preference for becoming the 1. A TLV that is used to advertise the preference for becoming the
Area Leader. Area Leader.
2. A TLV that is used to indicate the support for Dynamic Flooding 2. A TLV that is used to indicate the support for dynamic flooding
and the algorithms that the advertising node supports for and the algorithms that the advertising node supports for
distributed mode, if any. distributed mode, if any.
3. An OSPFv2 Opaque LSA and OSPFv3 LSA to advertise the flooding 3. An OSPFv2 Opaque LSA and OSPFv3 LSA to advertise the flooding
topology for centralized mode. topology for centralized mode.
4. A TLV to advertise the list of Router IDs that comprise the 4. A TLV to advertise the list of Router IDs that comprise the
flooding topology for the area. flooding topology for the area.
5. A TLV to advertise a path that is part of the flooding topology. 5. A TLV to advertise a path that is part of the flooding topology.
6. A bit in the LLS Type 1 Extended Options and Flags that requests 6. A bit in the Link-Local Singaling (LLS) Type 1 Extended Options
flooding from the adjacent node. and Flags that requests flooding from the adjacent node.
5.2.1. OSPF Area Leader Sub-TLV 5.2.1. OSPF Area Leader Sub-TLV
The usage of the OSPF Area Leader Sub-TLV is identical to IS-IS and The usage of the OSPF Area Leader Sub-TLV is identical to that of the
is described in Section 5.1.1. IS-IS Area Leader Sub-TLV described in Section 5.1.1.
The OSPF Area Leader Sub-TLV is used by both OSPFv2 and OSPFv3. The OSPF Area Leader Sub-TLV is used by both OSPFv2 and OSPFv3.
The OSPF Area Leader Sub-TLV is advertised as a top-level TLV of the The OSPF Area Leader Sub-TLV is advertised as a top-level TLV of the
RI LSA that is defined in [RFC7770] and has the following format: Router Information (RI) LSA that is defined in [RFC7770] and has the
following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Algorithm | Reserved | | Priority | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD4 Figure 6: OSPF Area Leader Sub-TLV
Length: 4 octets Type: 17
Priority: 0-255, unsigned integer Length: 4 octets
Algorithm: As defined in Section 5.1.1. Priority: 0-255, unsigned integer
Algorithm: As defined in Section 5.1.1.
5.2.2. OSPF Dynamic Flooding Sub-TLV 5.2.2. OSPF Dynamic Flooding Sub-TLV
The usage of the OSPF Dynamic Flooding Sub-TLV is identical to IS-IS The usage of the OSPF Dynamic Flooding Sub-TLV is identical to that
and is described in Section 5.1.2. of the IS-IS Dynamic Flooding Sub-TLV described in Section 5.1.2.
The OSPF Dynamic Flooding Sub-TLV is used by both OSPFv2 and OSPFv3. The OSPF Dynamic Flooding Sub-TLV is used by both OSPFv2 and OSPFv3.
The OSPF Dynamic Flooding Sub-TLV is advertised as a top-level TLV of The OSPF Dynamic Flooding Sub-TLV is advertised as a top-level TLV of
the RI LSA that is defined in [RFC7770] and has the following format: the RI LSA that is defined in [RFC7770] and has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm ... | | | Algorithm ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD8 Figure 7: OSPF Dynamic Flooding Sub-TLV
Length: Number of Algorithms Type: 18
Algorithm: As defined in Section 5.1.1. Length: Number of Algorithms in octets
Algorithm: As defined in Section 5.1.1.
5.2.3. OSPFv2 Dynamic Flooding Opaque LSA 5.2.3. OSPFv2 Dynamic Flooding Opaque LSA
The OSPFv2 Dynamic Flooding Opaque LSA is only used in centralized The OSPFv2 Dynamic Flooding Opaque LSA is only used in centralized
mode. mode.
The OSPFv2 Dynamic Flooding Opaque LSA is used to advertise The OSPFv2 Dynamic Flooding Opaque LSA is used to advertise
additional data related to dynamic flooding in OSPFv2. OSPFv2 Opaque additional data related to dynamic flooding in OSPFv2. OSPFv2 Opaque
LSAs are described in [RFC5250]. LSAs are described in [RFC5250].
Multiple OSPFv2 Dynamic Flooding Opaque LSAs can be advertised by an Multiple OSPFv2 Dynamic Flooding Opaque LSAs can be advertised by an
OSPFv2 router. The flooding scope of the OSPFv2 Dynamic Flooding OSPFv2 router. The flooding scope of the OSPFv2 Dynamic Flooding
Opaque LSA is area-local. Opaque LSA is area-local.
The format of the OSPFv2 Dynamic Flooding Opaque LSA is as follows: The format of the OSPFv2 Dynamic Flooding Opaque LSA is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type | | LS age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TBD5 | Opaque ID | | 10 | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- TLVs -+ +- TLVs -+
| ... | | ... |
Figure 1: OSPFv2 Dynamic Flooding Opaque LSA Figure 8: OSPFv2 Dynamic Flooding Opaque LSA
The opaque type used by OSPFv2 Dynamic Flooding Opaque LSA is TBD. The opaque type used by OSPFv2 Dynamic Flooding Opaque LSA is 10.
The opaque type is used to differentiate the various types of OSPFv2 The opaque type is used to differentiate the various types of OSPFv2
Opaque LSAs as described in section 3 of [RFC5250]. The LS Type is Opaque LSAs as described in Section 3 of [RFC5250]. The LS Type is
10. The LSA Length field [RFC2328] represents the total length (in 10. The LSA Length field [RFC2328] represents the total length (in
octets) of the Opaque LSA including the LSA header and all TLVs octets) of the Opaque LSA including the LSA header and all TLVs
(including padding). (including padding).
The Opaque ID field is an arbitrary value used to maintain multiple The Opaque ID field is an arbitrary value used to maintain multiple
Dynamic Flooding Opaque LSAs. For OSPFv2 Dynamic Flooding Opaque Dynamic Flooding Opaque LSAs. For OSPFv2 Dynamic Flooding Opaque
LSAs, the Opaque ID has no semantic significance other than to LSAs, the Opaque ID has no semantic significance other than to
differentiate Dynamic Flooding Opaque LSAs originated from the same differentiate Dynamic Flooding Opaque LSAs originated from the same
OSPFv2 router. OSPFv2 router.
The format of the TLVs within the body of the OSPFv2 Dynamic Flooding The format of the TLVs within the body of the OSPFv2 Dynamic Flooding
Opaque LSA is the same as the format used by the Traffic Engineering Opaque LSA is the same as the format used by the Traffic Engineering
Extensions to OSPF [RFC3630]. Extensions to OSPF [RFC3630].
The Length field defines the length of the value portion in octets The Length field defines the length of the value portion in octets
(thus a TLV with no value portion would have a length of 0). The TLV (thus a TLV with no value portion would have a length of 0 octets).
is padded to a 4-octet alignment; padding is not included in the The TLV is padded to a 4-octet alignment; padding is not included in
length field (so a 3-octet value would have a length of 3, but the the length field (so a 3-octet value would have a length of 3 octets,
total size of the TLV would be 8 octets). Nested TLVs are also but the total size of the TLV would be 8 octets). Nested TLVs are
32-bit aligned. For example, a 1-octet value would have the length also 32-bit aligned. For example, a 1-octet value would have the
field set to 1, and 3 octets of padding would be added to the end of length field set to 1, and 3 octets of padding would be added to the
the value portion of the TLV. The padding is composed of zeros. end of the value portion of the TLV. The padding is composed of
zeros.
5.2.4. OSPFv3 Dynamic Flooding LSA 5.2.4. OSPFv3 Dynamic Flooding LSA
The OSPFv3 Dynamic Flooding Opaque LSA is only used in centralized The OSPFv3 Dynamic Flooding Opaque LSA is only used in centralized
mode. mode.
The OSPFv3 Dynamic Flooding LSA is used to advertise additional data The OSPFv3 Dynamic Flooding LSA is used to advertise additional data
related to dynamic flooding in OSPFv3. related to dynamic flooding in OSPFv3.
The OSPFv3 Dynamic Flooding LSA has a function code of TBD. The The OSPFv3 Dynamic Flooding LSA has a function code of 16. The
flooding scope of the OSPFv3 Dynamic Flooding LSA is area-local. The flooding scope of the OSPFv3 Dynamic Flooding LSA is area-local. The
U bit will be set indicating that the OSPFv3 Dynamic Flooding LSA U bit will be set indicating that the OSPFv3 Dynamic Flooding LSA
should be flooded even if it is not understood. The Link State ID should be flooded even if it is not understood. The Link State ID
(LSID) value for this LSA is the Instance ID. OSPFv3 routers MAY (LSID) value for this LSA is the Instance ID. OSPFv3 routers MAY
advertise multiple OSPFv3 Dynamic Flooding Opaque LSAs in each area. advertise multiple OSPFv3 Dynamic Flooding Opaque LSAs in each area.
The format of the OSPFv3 Dynamic Flooding LSA is as follows: The format of the OSPFv3 Dynamic Flooding LSA is as follows:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |1|0|1| TBD6 | | LS age |1|0|1| 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID | | Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router | | Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- TLVs -+ +- TLVs -+
| ... | | ... |
Figure 2: OSPFv3 Dynamic Flooding LSA Figure 9: OSPFv3 Dynamic Flooding LSA
5.2.5. OSPF Area Router ID TLVs 5.2.5. OSPF Area Router ID TLVs
In OSPF, TLVs are defined to advertise indices associated with nodes In OSPF, TLVs are defined to advertise indices associated with nodes
and Broadcast/NBMA networks. Due to identifier differences between and Broadcast / Non-Broadcast Multi-Access (NBMA) networks. Due to
OSPFv2 and OSPFv3, two different TLVs are defined as described in the identifier differences between OSPFv2 and OSPFv3, two different TLVs
following sub-sections. are defined as described in the following sub-sections.
The OSPF Area Router ID TLVs are used by the Area Leader to enumerate The OSPF Area Router ID TLVs are used by the Area Leader to enumerate
the Router IDs that it has used in computing the flooding topology. the Router IDs that it has used in computing the flooding topology.
This includes the identifiers associated with Broadcast/NBMA networks This includes the identifiers associated with Broadcast/NBMA networks
as defined for Network LSAs. Conceptually, the Area Leader creates a as defined for Network LSAs. Conceptually, the Area Leader creates a
list of Router IDs for all routers in the area, assigning an index to list of Router IDs for all routers in the area and assigns an index
each router, starting with index 0. Indices are implicitly assigned to each router, starting with index 0. Indices are implicitly
sequentially, with the index of the first node being the Starting assigned sequentially, with the index of the first node being the
Index and each subsequent node's index is the previous node's index + Starting Index and each subsequent node's index is the previous
1. node's index + 1.
5.2.5.1. OSPFv2 Area Router ID TLV 5.2.5.1. OSPFv2 Area Router ID TLV
This TLV is a top-level TLV of the OSPFv2 Dynamic Flooding Opaque This TLV is a top-level TLV of the OSPFv2 Dynamic Flooding Opaque
LSA. LSA.
Because the space in a single OSPFv2 opaque LSA is limited, more than Because the space in a single OSPFv2 opaque LSA is limited, more than
one LSA may be required to encode all of the Router IDs in the area. one LSA may be required to encode all of the Router IDs in the area.
This TLV MAY be advertised in multiple OSPFv2 Dynamic Flooding Opaque This TLV MAY be advertised in multiple OSPFv2 Dynamic Flooding Opaque
LSAs so that all Router IDs can be advertised. LSAs so that all Router IDs can be advertised.
The format of the Area Router IDs TLV is: The OSPFv2 Area Router IDs TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Index |L| Flags | Reserved | | Starting Index |L| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- OSPFv2 Router ID TLV Entry -+ +- OSPFv2 Router ID TLV Entry -+
| ... | | ... |
Figure 3: OSPFv2 Area Router IDs TLV Figure 10: OSPFv2 Area Router IDs TLV
TLV Type: 1 Type: 1
TLV Length: 4 + sum of the lengths of all TLV entries Length: 4 + sum of the lengths of all TLV entries in octets
Starting index: The index of the first Router/Designated Router ID Starting Index: The index of the first Router/Designated Router ID
that appears in this TLV. that appears in this TLV.
L (Last): This bit is set if the index of the last Router/ L (Last): This bit is set if the index of the last Router/Designated
Designated ID that appears in this TLV is equal to the last index Router ID that appears in this TLV is equal to the last index in
in the full list of Router IDs for the area. the full list of Router IDs for the area.
OSPFv2 Router ID TLV Entries: A concatenated list of Router ID TLV OSPFv2 Router ID TLV Entries: A concatenated list of Router ID TLV
Entries for the area. Entries for the area.
If there are multiple OSPFv2 Area Router ID TLVs with the L-bit set If multiple OSPFv2 Area Router ID TLVs with the L bit set are
advertised by the same router, the TLV which specifies the smaller advertised by the same router, the TLV that specifies the smaller
maximum index is used and the other TLV(s) with L-bit set are maximum index is used and the other TLVs with L bit set are ignored.
ignored. TLVs which specify Router IDs with indices greater than TLVs that specify Router IDs with indices greater than that specified
that specified by the TLV with the L-bit set are also ignored. by the TLV with the L bit set are also ignored.
Each entry in the OSPFv2 Area Router IDs TLV represents either a node Each entry in the OSPFv2 Area Router IDs TLV represents either a node
or a Broadcast/NBMA network identifier. An entry has the following or a Broadcast/NBMA network identifier. An entry has the following
format: format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | Number of IDs | Reserved | | ID Type | Number of IDs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- Originating Router ID/DR Address -+ +- Originating Router ID/DR Address -+
| ... | | ... |
Figure 4: OSPFv2 Router IDs TLV Entry Figure 11: OSPFv2 Router IDs TLV Entry
ID Type: 1 octet. The following values are defined: ID Type: 1 octet. The following values are defined:
- 1 - Router 1: Router
- 2 - Designated Router 2: Designated Router
Number of IDs: 2 octets Number of IDs: 2 octets
Reserved: 1 octet, MUST be transmitted as 0 and MUST be ignored on Reserved: 1 octet. MUST be transmitted as 0 and MUST be ignored on
receipt receipt.
Originating Router ID/DR Address:(4 * Number of IDs) octets as Originating Router ID/DR Address: (4 * Number of IDs) octets as
indicated by the ID Type indicated by the ID Type.
5.2.5.2. OSPFv3 Area Router ID TLV 5.2.5.2. OSPFv3 Area Router ID TLV
This TLV is a top-level TLV of the OSPFv3 Dynamic Flooding LSA. This TLV is a top-level TLV of the OSPFv3 Dynamic Flooding LSA.
Because the space in a single OSPFv3 Dynamic Flooding LSA is limited, Because the space in a single OSPFv3 Dynamic Flooding LSA is limited,
more than one LSA may be required to encode all of the Router IDs in more than one LSA may be required to encode all of the Router IDs in
the area. This TLV MAY be advertised in multiple OSPFv3 Dynamic the area. This TLV MAY be advertised in multiple OSPFv3 Dynamic
Flooding Opaque LSAs so that all Router IDs can be advertised. Flooding Opaque LSAs so that all Router IDs can be advertised.
The format of the OSPFv3 Area Router IDs TLV is: The OSPFv3 Area Router IDs TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Index |L| Flags | Reserved | | Starting Index |L| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- OSPFv3 Router ID TLV Entry -+ +- OSPFv3 Router ID TLV Entry -+
| ... | | ... |
Figure 5: OSPFv3 Area Router IDs TLV Figure 12: OSPFv3 Area Router IDs TLV
TLV Type: 1 Type: 1
TLV Length: 4 + sum of the lengths of all TLV entries Length: 4 + sum of the lengths of all TLV entries in octets
Starting index: The index of the first Router/Designated Router ID Starting Index: The index of the first Router/Designated Router ID
that appears in this TLV. that appears in this TLV.
L (Last): This bit is set if the index of the last Router/ L (Last): This bit is set if the index of the last Router/Designated
Designated Router ID that appears in this TLV is equal to the last Router ID that appears in this TLV is equal to the last index in
index in the full list of Router IDs for the area. the full list of Router IDs for the area.
OSPFv3 Router ID TLV Entries: A concatenated list of Router ID TLV OSPFv3 Router ID TLV Entries: A concatenated list of Router ID TLV
Entries for the area. Entries for the area.
If there are multiple OSPFv3 Area Router ID TLVs with the L-bit set If multiple OSPFv3 Area Router ID TLVs with the L bit set are
advertised by the same router, the TLV which specifies the smaller advertised by the same router the TLV that specifies the smaller
maximum index is used and the other TLV(s) with L-bit set are maximum index is used and the other TLVs with L bit set are ignored.
ignored. TLVs which specify Router IDs with indices greater than TLVs that specify Router IDs with indices greater than that specified
that specified by the TLV with the L-bit set are also ignored. by the TLV with the L bit set are also ignored.
Each entry in the OSPFv3 Area Router IDs TLV represents either a Each entry in the OSPFv3 Area Router IDs TLV represents either a
router or a Broadcast/NBMA network identifier. An entry has the router or a Broadcast/NBMA network identifier. An entry has the
following format: following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | Number of IDs | Reserved | | ID Type | Number of IDs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- Originating ID Entry -+ +- Originating ID Entry -+
| ... | | ... |
Figure 6: OSPFv3 Router ID TLV Entry Figure 13: OSPFv3 Router ID TLV Entry
ID Type - 1 octet. The following values are defined: ID Type: 1 octet. The following values are defined:
- 1 - Router 1: Router
- 2 - Designated Router 2: Designated Router
Number of IDs - 2 octets Number of IDs: 2 octets
Reserved - 1 octet, MUST be transmitted as 0 and MUST be ignored Reserved: 1 octet. MUST be transmitted as 0 and MUST be ignored on
on receipt receipt.
The Originating ID Entry takes one of the following forms, depending The Originating ID Entry takes one of the following forms, depending
on the ID Type. on the ID Type.
For a Router: For a Router:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Router ID | | Originating Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the Originating ID Entry is (4 * Number of IDs) octets. The length of the Originating ID Entry is (4 * Number of IDs) octets.
For a Designated Router: For a Designated Router:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Router ID | | Originating Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID | | Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The length of the Originating ID Entry is (8 * Number of IDs) octets The length of the Originating ID Entry is (8 * Number of IDs) octets.
5.2.6. OSPF Flooding Path TLV 5.2.6. OSPF Flooding Path TLV
The OSPF Flooding Path TLV is a top-level TLV of the OSPFv2 Dynamic The OSPF Flooding Path TLV is a top-level TLV of the OSPFv2 Dynamic
Flooding Opaque LSAs and OSPFv3 Dynamic Flooding LSA. Flooding Opaque LSAs and OSPFv3 Dynamic Flooding LSA.
The usage of the OSPF Flooding Path TLV is identical to IS-IS and is The usage of the OSPF Flooding Path TLV is identical to that of the
described in Section 5.1.4. IS-IS Flooding Path TLV described in Section 5.1.4.
The OSPF Flooding Path TLV contains a list of Router ID indices The OSPF Flooding Path TLV contains a list of Router ID indices
relative to the Router IDs advertised through the OSPF Area Router relative to the Router IDs advertised through the OSPF Area Router
IDs TLV. At least 2 indices must be included in the TLV. IDs TLV. At least 2 indices must be included in the TLV.
Multiple OSPF Flooding Path TLVs can be advertised in a single OSPFv2 Multiple OSPF Flooding Path TLVs can be advertised in a single OSPFv2
Dynamic Flooding Opaque LSA or OSPFv3 Dynamic Flooding LSA. OSPF Dynamic Flooding Opaque LSA or OSPFv3 Dynamic Flooding LSA. OSPF
Flooding Path TLVs can also be advertised in multiple OSPFv2 Dynamic Flooding Path TLVs can also be advertised in multiple OSPFv2 Dynamic
Flooding Opaque LSAs or OSPFv3 Dynamic Flooding LSA, if they all can Flooding Opaque LSAs or OSPFv3 Dynamic Flooding LSAs if they all
not fit in a single LSA. cannot fit in a single LSA.
The Flooding Path TLV has the format: The OSPF Flooding Path TLV has the following format:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Index | Index 2 | | Starting Index | Index 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- Additional Indices -+ +- Additional Indices -+
| ... | | ... |
Figure 7: OSPF Flooding Path TLV Figure 14: OSPF Flooding Path TLV
TLV Type: 2 Type: 2
TLV Length: 2 * (number of indices in the path) Length: 2 * (number of indices in the path) in octets
Starting index: The index of the first Router ID in the path. Starting Index: The index of the first Router ID in the path.
Index 2: The index of the next Router ID in the path. Index 2: The index of the next Router ID in the path.
Additional indices (optional): A sequence of additional indices to Additional indices (optional): A sequence of additional indices to
Router IDs along the path. Router IDs along the path.
5.2.7. OSPF Flooding Request Bit 5.2.7. OSPF Flooding Request Bit
A single new option bit, the Flooding Request (FR) bit, is defined in A single new option bit, the Flooding Request (FR) bit, is defined in
the LLS Type 1 Extended Options and Flags field [RFC5613]. The FR the LLS Type 1 Extended Options and Flags field [RFC5613]. The FR
bit allows a router to request an adjacent node to enable flooding bit allows a router to request an adjacent node to enable flooding
towards it on a specific link in the case where the connection to the towards it on a specific link in the case where the connection to the
adjacent node is not part of the current flooding topology. adjacent node is not part of the current flooding topology.
A node that supports Dynamic Flooding MAY include the FR bit in its A node that supports dynamic flooding MAY include the FR bit in its
OSPF LLS Extended Options and Flags TLV. OSPF LLS Extended Options and Flags TLV.
If the FR bit is signaled for a link on which flooding was disabled If the FR bit is signaled for a link on which flooding was disabled
due to Dynamic Flooding, then flooding MUST be temporarily enabled due to dynamic flooding, then flooding MUST be temporarily enabled
over the link. Flooding MUST be enabled until the FR bit is no over the link. Flooding MUST be enabled until the FR bit is no
longer advertised in the OSPF LLS Extended Options and Flags TLV or longer advertised in the OSPF LLS Extended Options and Flags TLV or
the OSPF LLS Extended Options and Flags TLV no longer appear in the the OSPF LLS Extended Options and Flags TLV no longer appears in the
OSPF Hellos. OSPF Hellos.
When flooding is temporarily enabled on the link for any area due to When flooding is temporarily enabled on the link for any area due to
receiving the FR bit in the OSPF LLS Extended Options and Flags TLV, receiving the FR bit in the OSPF LLS Extended Options and Flags TLV,
the receiver MUST perform standard database synchronization for the the receiver MUST perform standard database synchronization for the
area corresponding to the link. If the adjacency is already in the area corresponding to the link. If the adjacency is already in the
FULL state, the mechanism specified in [RFC4811] MUST be used for FULL state, the mechanism specified in [RFC4811] MUST be used for
database resynchronization. database resynchronization.
So long as the FR bit is being received in the OSPF LLS Extended So long as the FR bit is being received in the OSPF LLS Extended
Options and Flags TLV for a link, flooding MUST NOT be disabled on Options and Flags TLV for a link, flooding MUST NOT be disabled on
the link even if the connection between the neighbors is removed from the link, even if the connection between the neighbors is removed
the flooding topology. Flooding MUST continue on the link and be from the flooding topology. Flooding MUST continue on the link and
considered as temporarily enabled. be considered as temporarily enabled.
5.2.8. OSPF LEEF Advertisement 5.2.8. OSPF LEEF Advertisement
In support of advertising the specific edges that are currently In support of advertising the specific edges that are currently
enabled in the flooding topology, an implementation MAY indicate that enabled in the flooding topology, an implementation MAY indicate that
a link is part of the flooding topology. The OSPF Link Attributes a link is part of the flooding topology. The OSPF Link Attributes
Bits TLV is defined to support this advertisement. Bits TLV is defined to support this advertisement.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Attribute Bits | | Link Attribute Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- Additional Link Attribute Bits -+ +- Additional Link Attribute Bits -+
| ... | | ... |
Figure 8: OSPF Link Attributes Bits TLV Figure 15: OSPF Link Attributes Bits TLV
Type: TBD and specific to OSPFv2 and OSPFv3 Type: 21 (for OSPFv2) or 10 (for OSPFv3)
Length: Size of the Link Attribute Bits in octets. It MUST be a Length: Size of the Link Attribute Bits in octets. It MUST be a
multiple of 4 octets. multiple of 4 octets.
The following bits are defined: The following bits are defined:
Bit #0: - Local Edge Enabled for Flooding (LEEF) Bit #0: Local Edge Enabled for Flooding (LEEF)
OSPF Link-attribute Bits TLV appears as: OSPF Link-attribute Bits TLV appears as:
1. A sub-TLV of the OSPFv2 Extended Link TLV [RFC7684] 1. A sub-TLV of the OSPFv2 Extended Link TLV [RFC7684].
2. A sub-TLV of the OSPFv3 Router-Link TLV [RFC8362] 2. A sub-TLV of the OSPFv3 Router-Link TLV [RFC8362].
6. Behavioral Specification 6. Behavioral Specification
This section specifies the detailed behavior of the nodes This section specifies the detailed behavior of the nodes
participating in the IGP. participating in the IGP.
6.1. Terminology 6.1. Terminology
Some terminology to be used in the following sections: Some terminology to be used in the following sections:
A node is considered reachable if it is part of the connected Reachable: A node is considered reachable if it is part of the
network graph. Note that this is independent of any constraints connected network graph. Note that this is independent of any
that may be considered when performing IGP shortest-path tree constraints that may be considered when performing IGP shortest-
calculation (e.g., link metrics, overload bit state, etc.). The path tree calculation, e.g., link metrics, overload bit state,
two-way connectivity check MUST be performed before including an etc. The two-way connectivity check MUST be performed before
edge in the connected network graph. including an edge in the connected network graph.
A node is connected to the flooding topology, if it has at least Connected: A node is connected to the flooding topology if it has at
one local link, which is part of the flooding topology. least one local link, which is part of the flooding topology.
A node is disconnected from the flooding topology when it is not Disconnected: A node is disconnected from the flooding topology when
connected to the flooding topology. it is not connected to the flooding topology.
Current flooding topology - The latest version of the flooding Current flooding topology: The latest version of the flooding
topology that has been received (in the case of centralized mode) topology that has been received (in the case of centralized mode)
or calculated locally (in the case of distributed mode). or calculated locally (in the case of distributed mode).
6.2. Flooding Topology 6.2. Flooding Topology
The flooding topology MUST include all reachable nodes in the area. The flooding topology MUST include all reachable nodes in the area.
If a node's reachability changes, the flooding topology MUST be If a node's reachability changes, the flooding topology MUST be
recalculated. In centralized mode, the Area Leader MUST advertise a recalculated. In centralized mode, the Area Leader MUST advertise a
new flooding topology. new flooding topology.
If a node becomes disconnected from the current flooding topology but If a node becomes disconnected from the current flooding topology but
is still reachable, then a new flooding topology MUST be calculated. is still reachable, then a new flooding topology MUST be calculated.
In centralized mode, the Area Leader MUST advertise the new flooding In centralized mode, the Area Leader MUST advertise the new flooding
topology. topology.
The flooding topology SHOULD be bi-connected to provide network The flooding topology SHOULD be biconnected to provide network
resiliency, but this does incur some amount of redundant flooding. resiliency, but this does incur some amount of redundant flooding.
Xia topologies (Section 4.4.2) are an example of an explicit decision Xia topologies (Section 4.4.2) are an example of an explicit decision
to sacrifice resiliency to avoid redundancy. to sacrifice resiliency to avoid redundancy.
6.3. Leader Election 6.3. Leader Election
Any capable node MAY advertise its eligibility to become the Area Any capable node MAY advertise its eligibility to become the Area
Leader. Leader.
Nodes that are not reachable are not eligible to become the Area Nodes that are not reachable are not eligible to become the Area
Leader. Nodes that do not advertise their eligibility to become the Leader. Nodes that do not advertise their eligibility to become the
Area Leader are not eligible. Amongst the eligible nodes, the node Area Leader are not eligible. Amongst the eligible nodes, the node
with the numerically highest priority is the Area Leader. If with the numerically highest priority is the Area Leader. If
multiple nodes all have the highest priority, then the node with the multiple nodes all have the highest priority, then the node with the
numerically highest system identifier in the case of IS-IS, or numerically highest system identifier (in the case of IS-IS) or
Router-ID in the case of OSPFv2 and OSPFv3 is the Area Leader. Router ID (in the case of OSPFv2 and OSPFv3) is the Area Leader.
6.4. Area Leader Responsibilities 6.4. Area Leader Responsibilities
If the Area Leader operates in centralized mode, it MUST advertise If the Area Leader operates in centralized mode, it MUST advertise
algorithm 0 in its Area Leader Sub-TLV. For Dynamic Flooding to be algorithm 0 in its Area Leader Sub-TLV. For dynamic flooding to be
enabled, it also MUST compute and advertise a flooding topology for enabled, it also MUST compute and advertise a flooding topology for
the area. The Area Leader may update the flooding topology at any the area. The Area Leader may update the flooding topology at any
time, however, it should not destabilize the network with undue or time. However, it should not destabilize the network with undue or
overly frequent topology changes. If the Area Leader operates in overly frequent topology changes. If the Area Leader operates in
centralized mode and needs to advertise a new flooding topology, it centralized mode and needs to advertise a new flooding topology, it
floods the new flooding topology on both the new and old flooding floods the new flooding topology on both the new and old flooding
topologies. topologies.
If the Area Leader operates in distributed mode, it MUST advertise a If the Area Leader operates in distributed mode, it MUST advertise a
non-zero algorithm in its Area Leader Sub-TLV. nonzero algorithm in its Area Leader Sub-TLV.
When the Area Leader advertises algorithm 0 in its Area Leader Sub- When the Area Leader advertises algorithm 0 in its Area Leader Sub-
TLV and does not advertise a flooding topology, Dynamic Flooding is TLV and does not advertise a flooding topology, dynamic flooding is
disabled for the area. Note this applies whether the Area Leader disabled for the area. Note this applies whether the Area Leader
intends to operate in centralized mode or distributed mode. intends to operate in centralized mode or distributed mode.
Note that once Dynamic Flooding is enabled, disabling it risks Note that once dynamic flooding is enabled, disabling it risks
destabilizing the network due to the issues discussed in Section 1. destabilizing the network due to the issues discussed in Section 1.
6.5. Distributed Flooding Topology Calculation 6.5. Distributed Flooding Topology Calculation
If the Area Leader advertises a non-zero algorithm in its Area Leader If the Area Leader advertises a nonzero algorithm in its Area Leader
Sub-TLV, all nodes in the area that support Dynamic Flooding and Sub-TLV, all nodes in the area that support dynamic flooding and
support the algorithm advertised by the Area Leader MUST compute the support the algorithm advertised by the Area Leader MUST compute the
flooding topology based on the Area Leader's advertised algorithm. flooding topology based on the Area Leader's advertised algorithm.
Nodes that do not support the advertised algorithm MUST continue to Nodes that do not support the advertised algorithm MUST continue to
use standard IS-IS/OSPF flooding mechanisms. Nodes that do not use standard IS-IS/OSPF flooding mechanisms. Nodes that do not
support the flooding algorithm advertised by the Area Leader MUST be support the flooding algorithm advertised by the Area Leader MUST be
considered as Dynamic Flooding incapable nodes by the Area Leader. considered as dynamic flooding incapable nodes by the Area Leader.
If the value of the algorithm advertised by the Area Leader is from If the value of the algorithm advertised by the Area Leader is from
the range 128-254 (private distributed algorithms), it is the the range 128-254 (private distributed algorithms), it is the
responsibility of the network operator to guarantee that all nodes in responsibility of the network operator to guarantee that all nodes in
the area agree on the dynamic flooding algorithm corresponding to the the area agree on the dynamic flooding algorithm corresponding to the
advertised value. advertised value.
6.6. Use of LANs in the Flooding Topology 6.6. Use of LANs in the Flooding Topology
The use of LANs in the flooding topology differs depending on whether The use of LANs in the flooding topology differs depending on whether
the area is operating in centralized mode or distributed mode. the area is operating in centralized mode or distributed mode.
6.6.1. Use of LANs in Centralized mode 6.6.1. Use of LANs in Centralized Mode
As specified in Section 4.5, when a LAN is advertised as part of the As specified in Section 4.5, when a LAN is advertised as part of the
flooding topology, all nodes connected to the LAN are assumed to be flooding topology, all nodes connected to the LAN are assumed to be
using the LAN as part of the flooding topology. This assumption is using the LAN as part of the flooding topology. This assumption is
made to reduce the size of the Flooding Topology advertisement. made to reduce the size of the flooding topology advertisement.
6.6.2. Use of LANs in Distributed Mode 6.6.2. Use of LANs in Distributed Mode
In distributed mode, the flooding topology is NOT advertised, In distributed mode, the flooding topology is NOT advertised; thus,
therefore the space consumed to advertise it is not a concern. It is the space consumed to advertise it is not a concern. Therefore, it
therefore possible to assign only a subset of the nodes connected to is possible to assign only a subset of the nodes connected to the LAN
the LAN to use the LAN as part of the flooding topology. Doing so to use the LAN as part of the flooding topology. Doing so may
may further optimize flooding by reducing the amount of redundant further optimize flooding by reducing the amount of redundant
flooding on a LAN. However, support of flooding by a subset of the flooding on a LAN. However, support of flooding by a subset of the
nodes connected to a LAN requires some modest, but backward- nodes connected to a LAN requires some modest but backward-compatible
compatible, changes in the way flooding is performed on a LAN. changes in the way flooding is performed on a LAN.
6.6.2.1. Partial flooding on a LAN in IS-IS 6.6.2.1. Partial Flooding on a LAN in IS-IS
The Designated Intermediate System (DIS) for a LAN MUST use the The Designated Intermediate System (DIS) for a LAN MUST use the
standard flooding behavior. standard flooding behavior.
Non-DIS nodes whose connection to the LAN is included in the flooding Non-DIS nodes whose connection to the LAN is included in the flooding
topology MUST use the standard flooding behavior. topology MUST use the standard flooding behavior.
Non-DIS nodes whose connection to the LAN is NOT included in the Non-DIS nodes whose connection to the LAN is NOT included in the
flooding topology behave as follows: flooding topology behave as follows:
* Received CSNPs from the DIS are ignored. * Received CSNPs from the DIS are ignored.
* Partial Sequence Number Protocol Data Units (PSNPs) are NOT * Partial Sequence Number PDUs (PSNPs) are NOT originated on the
originated on the LAN. LAN.
* An LSP received on the LAN that is newer than the corresponding * An LSP that is received on the LAN and is newer than the
LSP present in the LSPDB is retained and flooded on all local corresponding LSP present in the Link State PDU Database (LSPDB)
circuits which are part of the flooding topology (i.e., do not is retained and flooded on all local circuits that are part of the
discard newer LSPs simply because they were received on a LAN flooding topology (i.e., do not discard newer LSPs simply because
which the receiving node is not using for flooding). they were received on a LAN that the receiving node is not using
for flooding).
* An LSP received on the LAN which is older or the same as the * An LSP received on the LAN that is older or the same as the
corresponding LSP in the LSPDB is silently discarded. corresponding LSP in the LSPDB is silently discarded.
* LSPs received on links other than the LAN are NOT flooded on the * LSPs received on links other than the LAN are NOT flooded on the
LAN. LAN.
NOTE: If any node connected to the LAN requests the enablement of NOTE: If any node connected to the LAN requests the enablement of
temporary flooding, all nodes MUST revert to the standard flooding temporary flooding, all nodes MUST revert to the standard flooding
behavior on the LAN. behavior on the LAN.
6.6.2.2. Partial Flooding on a LAN in OSPF 6.6.2.2. Partial Flooding on a LAN in OSPF
skipping to change at page 32, line 44 skipping to change at line 1508
* LSAs received on the LAN are acknowledged to the DR/BDR. * LSAs received on the LAN are acknowledged to the DR/BDR.
* LSAs received on interfaces other than the LAN are NOT flooded on * LSAs received on interfaces other than the LAN are NOT flooded on
the LAN. the LAN.
NOTE: If any node connected to the LAN requests the enablement of NOTE: If any node connected to the LAN requests the enablement of
temporary flooding, all nodes revert to the standard flooding temporary flooding, all nodes revert to the standard flooding
behavior. behavior.
NOTE: The sending of LSA Acks by nodes NOT using the LAN as part of NOTE: The sending of LSA Acknowledgements by nodes NOT using the LAN
the flooding topology eliminates the need for changes on the part of as part of the flooding topology eliminates the need for changes on
the DR/BDR, which might include nodes that do not support the dynamic the part of the DR/BDR, which might include nodes that do not support
flooding algorithm. the dynamic flooding algorithm.
6.7. Flooding Behavior 6.7. Flooding Behavior
Nodes that support Dynamic Flooding MUST use the flooding topology Nodes that support dynamic flooding MUST use the flooding topology
for flooding when possible, and MUST NOT revert to standard flooding for flooding when possible and MUST NOT revert to standard flooding
when a valid flooding topology is available. when a valid flooding topology is available.
In some cases, a node that supports Dynamic Flooding may need to add In some cases, a node that supports dynamic flooding may need to add
a local link(s) to the flooding topology temporarily, even though the local links to the flooding topology temporarily, even though the
link(s) is not part of the calculated flooding topology. This is links are not part of the calculated flooding topology. This is
termed "temporary flooding" and is discussed in Section 6.8.1. termed "temporary flooding" and is discussed in Section 6.8.1.
In distributed mode, the flooding topology is calculated locally. In In distributed mode, the flooding topology is calculated locally. In
centralized mode, the flooding topology is advertised in the area centralized mode, the flooding topology is advertised in the area
link state database. Received link state updates, whether received LSDB. Received link-state updates, whether received on a link that
on a link that is in the flooding topology or on a link that is not is in the flooding topology or on a link that is not in the flooding
in the flooding topology, MUST be flooded on all links that are in topology, MUST be flooded on all links that are in the flooding
the flooding topology, except for the link on which the update was topology except for the link on which the update was received.
received.
In centralized mode, new information in the form of new paths or new In centralized mode, new information in the form of new paths or new
node ID assignments can be received at any time. This may replace node ID assignments can be received at any time. This may replace
some or all of the existing information about the flooding topology. some or all of the existing information about the flooding topology.
There may be transient conditions where the information that a node There may be transient conditions where the information that a node
has is inconsistent or incomplete. If a node detects that its has is inconsistent or incomplete. If a node detects that its
current information is inconsistent, then the node may wait for an current information is inconsistent, then the node may wait for an
implementation-specific amount of time, expecting more information to implementation-specific amount of time, expecting more information to
arrive that will provide a consistent, complete view of the flooding arrive that will provide a consistent, complete view of the flooding
topology. topology.
skipping to change at page 33, line 46 skipping to change at line 1553
should add those and begin flooding on those adjacencies immediately. should add those and begin flooding on those adjacencies immediately.
If a node determines that adjacencies are to be removed from the If a node determines that adjacencies are to be removed from the
flooding topology, then it should wait for an implementation-specific flooding topology, then it should wait for an implementation-specific
amount of time before acting on that information. This serves to amount of time before acting on that information. This serves to
ensure that new information is flooded promptly and completely, ensure that new information is flooded promptly and completely,
allowing all nodes to receive updates in a timely fashion. allowing all nodes to receive updates in a timely fashion.
6.8. Treatment of Topology Events 6.8. Treatment of Topology Events
This section explicitly considers a variety of different topological This section explicitly considers a variety of different topological
events in the network and how Dynamic Flooding should address them. events in the network and how dynamic flooding should address them.
6.8.1. Temporary Addition of Links to the Flooding Topology 6.8.1. Temporary Addition of Links to the Flooding Topology
In some cases, a node that supports Dynamic Flooding may need to add
a local link(s) to the flooding topology temporarily, even though the
link(s) is not part of the calculated flooding topology. This is
referred to as "temporary flooding" on the link.
When temporary flooding is enabled on the link, the flooding needs to When temporary flooding is enabled on the link, the flooding needs to
be enabled in both directions on the link. To achieve that, the be enabled in both directions. To achieve that, the following steps
following steps MUST be performed: MUST be performed:
The Link State Database needs to be re-synchronised on the link. * The LSDB needs to be resynchronised on the link. This is done
This is done using the standard protocol mechanisms. In the case using the standard protocol mechanisms. In the case of IS-IS,
of IS-IS, this results in setting the SRM bit for all LSPs on the this results in setting the SRM bit for all LSPs on the circuit
circuit and sending a complete set of CSNPs on the link. In OSPF, and sending a complete set of CSNPs on the link. In OSPF, the
the mechanism specified in [RFC4811] is used. mechanism specified in [RFC4811] is used.
Flooding is enabled locally on the link. * Flooding is enabled locally on the link.
Flooding is requested from the neighbor using the mechanism * Flooding is requested from the neighbor using the mechanism
specified in section Section 5.1.5 or Section 5.2.7. specified in Sections 5.1.5 or 5.2.7.
The request for temporary flooding MUST be withdrawn on the link when The request for temporary flooding MUST be withdrawn on the link when
all of the following conditions are met: all of the following conditions are met:
The node itself is connected to the current flooding topology. * The node itself is connected to the current flooding topology.
The adjacent node is connected to the current flooding topology. * The adjacent node is connected to the current flooding topology.
Any change in the flooding topology MUST result in an evaluation of Any change in the flooding topology MUST result in an evaluation of
the above conditions for any link on which temporary flooding was the above conditions for any link on which temporary flooding was
enabled. enabled.
Temporary flooding is stopped on the link when both adjacent nodes Temporary flooding is stopped on the link when both adjacent nodes
stop requesting temporary flooding on the link. stop requesting temporary flooding on the link.
6.8.2. Local Link Addition 6.8.2. Local Link Addition
If a local link is added to the topology, the protocol will form a If a local link is added to the topology, the protocol will form a
normal adjacency on the link and update the appropriate link state normal adjacency on the link and update the appropriate LSAs for the
advertisements for the nodes on either end of the link. These link nodes on either end of the link. These link state updates will be
state updates will be flooded on the flooding topology. flooded on the flooding topology.
In centralized mode, the Area Leader, upon receiving these updates, In centralized mode, the Area Leader may choose to retain the
may choose to retain the existing flooding topology or may choose to existing flooding topology or modify the flooding topology upon
modify the flooding topology. If the Area Leader decides to change receiving these updates. If the Area Leader decides to change the
the flooding topology, it will update the flooding topology in the flooding topology, it will update the flooding topology in the LSDB
link state database and flood it using the new flooding topology. and flood it using the new flooding topology.
In distributed mode, any change in the topology, including the link In distributed mode, any change in the topology, including the link
addition, MUST trigger the flooding topology recalculation. This is addition, MUST trigger the flooding topology recalculation. This is
done to ensure that all nodes converge to the same flooding topology, done to ensure that all nodes converge to the same flooding topology,
regardless of the time of the calculation. regardless of the time of the calculation.
Temporary flooding MUST be enabled on the newly added local link, as Temporary flooding MUST be enabled on the newly added local link as
long as at least one of the following conditions are met: long as at least one of the following conditions are met:
The node on which the local link was added is not connected to the * The node on which the local link was added is not connected to the
current flooding topology. current flooding topology.
The new adjacent node is not connected to the current flooding * The new adjacent node is not connected to the current flooding
topology. topology.
Note that in this case there is no need to perform a database Note that in this case there is no need to perform a database
synchronization as part of the enablement of the temporary flooding, synchronization as part of the enablement of the temporary flooding
because it was part of the adjacency bring-up itself. because it was part of the adjacency bring-up itself.
If multiple local links are added to the topology before the flooding If multiple local links are added to the topology before the flooding
topology is updated, temporary flooding MUST be enabled on a subset topology is updated, temporary flooding MUST be enabled on a subset
of these links per the conditions discussed in Section 6.8.12. of these links per the conditions discussed in Section 6.8.12.
6.8.3. Node Addition 6.8.3. Node Addition
If a node is added to the topology, then at least one link is also If a node is added to the topology, then at least one link is also
added to the topology. Section 6.8.2 applies. added to the topology. Section 6.8.2 applies.
A node that has a large number of neighbors is at risk of introducing A node that has a large number of neighbors is at risk of introducing
a local flooding storm if all neighbors are brought up at once and a local flooding storm if all neighbors are brought up at once and
temporary flooding is enabled on all links simultaneously. The most temporary flooding is enabled on all links simultaneously. The most
robust way to address this is to limit the rate of initial adjacency robust way to address this is to limit the rate of initial adjacency
formation following bootup. This reduces unnecessary redundant formation following bootup. This reduces unnecessary redundant
flooding as part of initial database synchronization and minimizes flooding as part of initial database synchronization and minimizes
the need for temporary flooding as it allows time for the new node to the need for temporary flooding, as it allows time for the new node
be added to the flooding topology after only a small number of to be added to the flooding topology after only a small number of
adjacencies have been formed. adjacencies have been formed.
In the event a node elects to bring up a large number of adjacencies In the event a node elects to bring up a large number of adjacencies
simultaneously, a significant amount of redundant flooding may be simultaneously, a significant amount of redundant flooding may be
introduced as multiple neighbors of the new node enable temporary introduced as multiple neighbors of the new node enable temporary
flooding to the new node which initially is not part of the flooding flooding to the new node, which initially is not part of the flooding
topology. topology.
6.8.4. Failures of Links Not on the Flooding Topology 6.8.4. Failures of Links Not on the Flooding Topology
If a link that is not part of the flooding topology fails, then the If a link that is not part of the flooding topology fails, then the
adjacent nodes will update their link state advertisements and flood adjacent nodes will update their LSAs and flood them on the flooding
them on the flooding topology. topology.
In centralized mode, the Area Leader, upon receiving these updates, In centralized mode, the Area Leader may choose to retain the
may choose to retain the existing flooding topology or may choose to existing flooding topology or modify the flooding topology upon
modify the flooding topology. If it elects to change the flooding receiving these updates. If it elects to change the flooding
topology, it will update the flooding topology in the link state topology, it will update the flooding topology in the LSDB and flood
database and flood it using the new flooding topology. it using the new flooding topology.
In distributed mode, any change in the topology, including the In distributed mode, any change in the topology, including the
failure of the link that is not part of the flooding topology MUST failure of the link that is not part of the flooding topology, MUST
trigger the flooding topology recalculation. This is done to ensure trigger the flooding topology recalculation. This is done to ensure
that all nodes converge to the same flooding topology, regardless of that all nodes converge to the same flooding topology, regardless of
the time of the calculation. the time of the calculation.
6.8.5. Failures of Links On the Flooding Topology 6.8.5. Failures of Links On the Flooding Topology
If there is a failure on the flooding topology, the adjacent nodes If there is a failure on the flooding topology, the adjacent nodes
will update their link state advertisements and flood them. If the will update their LSAs and flood them. If the original flooding
original flooding topology is bi-connected, the flooding topology topology is biconnected, the flooding topology should still be
should still be connected despite a single failure. connected despite a single failure.
If the failed local link represented the only connection to the If the failed local link represented the only connection to the
flooding topology on the node where the link failed, the node MUST flooding topology on the node where the link failed, the node MUST
enable temporary flooding on a subset of its local links. This enable temporary flooding on a subset of its local links. This
allows the node to send its updated link state advertisement(s) and allows the node to send its updated LSAs and receive link-state
also, keep receiving link state updates from other nodes in the updates from other nodes in the network before the new flooding
network before the new flooding topology is calculated and topology is calculated and distributed (in the case of centralized
distributed (in the case of centralized mode). mode).
In centralized mode, the Area Leader will notice the change in the In centralized mode, the Area Leader will notice the change in the
flooding topology, recompute the flooding topology, and flood it flooding topology, recompute the flooding topology, and flood it
using the new flooding topology. using the new flooding topology.
In distributed mode, all nodes supporting dynamic flooding will In distributed mode, all nodes supporting dynamic flooding will
notice the change in the topology and recompute the new flooding notice the change in the topology and recompute the new flooding
topology. topology.
6.8.6. Node Deletion 6.8.6. Node Deletion
skipping to change at page 36, line 52 skipping to change at line 1695
If a node is deleted from the topology, then at least one link is If a node is deleted from the topology, then at least one link is
also removed from the topology. Section 6.8.4 and Section 6.8.5 also removed from the topology. Section 6.8.4 and Section 6.8.5
apply. apply.
6.8.7. Local Link Addition to the Flooding Topology 6.8.7. Local Link Addition to the Flooding Topology
If the flooding topology changes and a local link that was not part If the flooding topology changes and a local link that was not part
of the flooding topology is now part of the flooding topology, then of the flooding topology is now part of the flooding topology, then
the node MUST: the node MUST:
Re-synchronize the Link State Database over the link. This is * Resynchronize the LSDB over the link. This is done using the
done using the standard protocol mechanisms. In the case of IS- standard protocol mechanisms. In the case of IS-IS, this requires
IS, this requires sending a complete set of CSNPs. In OSPF, the sending a complete set of CSNPs. In OSPF, the mechanism specified
mechanism specified in [RFC4811] is used. in [RFC4811] is used.
Make the link part of the flooding topology and start flooding on * Make the link part of the flooding topology and start flooding on
it. it.
6.8.8. Local Link Deletion from the Flooding Topology 6.8.8. Local Link Deletion from the Flooding Topology
If the flooding topology changes and a local link that was part of If the flooding topology changes and a local link that was part of
the flooding topology is no longer part of the flooding topology, the flooding topology is no longer part of the flooding topology,
then the node MUST remove the link from the flooding topology. then the node MUST remove the link from the flooding topology.
The node MUST keep flooding on such link for a limited amount of time The node MUST keep flooding on such link for a limited amount of time
to allow other nodes to migrate to the new flooding topology. to allow other nodes to migrate to the new flooding topology.
If the removed local link represented the only connection to the If the removed local link represented the only connection to the
flooding topology on the node, the node MUST enable temporary flooding topology on the node, the node MUST enable temporary
flooding on a subset of its local links. This allows the node to flooding on a subset of its local links. This allows the node to
send its updated link state advertisement(s) and also keep receiving send its updated LSAs and receive link-state updates from other nodes
link state updates from other nodes in the network before the new in the network before the new flooding topology is calculated and
flooding topology is calculated and distributed (in the case of distributed (in the case of centralized mode).
centralized mode).
6.8.9. Treatment of Disconnected Adjacent Nodes 6.8.9. Treatment of Disconnected Adjacent Nodes
Every time there is a change in the flooding topology, a node MUST Every time there is a change in the flooding topology, a node MUST
check if any adjacent nodes are disconnected from the current check if any adjacent nodes are disconnected from the current
flooding topology. Temporary flooding MUST be enabled towards a flooding topology. Temporary flooding MUST be enabled towards a
subset of the disconnected nodes per the discussion in Section 6.8.12 subset of the disconnected nodes per Sections 6.8.12 and 6.7.
and Section 6.7.
6.8.10. Failure of the Area Leader 6.8.10. Failure of the Area Leader
The failure of the Area Leader can be detected by observing that it The failure of the Area Leader can be detected by observing that it
is no longer reachable. In this case, the Area Leader election is no longer reachable. In this case, the Area Leader election
process is repeated and a new Area Leader is elected. process is repeated and a new Area Leader is elected.
To minimize disruption to Dynamic Flooding if the Area Leader becomes To minimize disruption to dynamic flooding if the Area Leader becomes
unreachable, the node that has the second-highest priority for unreachable, the node that has the second-highest priority for
becoming Area Leader (including the system identifier/Router-ID tie- becoming Area Leader (including the system identifier / Router ID
breaker if necessary) SHOULD advertise the same algorithm in its Area tiebreaker if necessary) SHOULD advertise the same algorithm in its
Leader Sub-TLV as the Area Leader and (in centralized mode) SHOULD Area Leader Sub-TLV as the Area Leader and (in centralized mode)
advertise a flooding topology. This SHOULD be done even when the SHOULD advertise a flooding topology. This SHOULD be done even when
Area Leader is reachable. the Area Leader is reachable.
In centralized mode, the new Area Leader will compute a new flooding In centralized mode, the new Area Leader will compute a new flooding
topology and flood it using the new flooding topology. To minimize topology and flood it using the new flooding topology. To minimize
disruption, the new flooding topology SHOULD have as much in common disruption, the new flooding topology SHOULD have as much in common
as possible with the old flooding topology. This will minimize the as possible with the old flooding topology. This will minimize the
risk of over-flooding. risk of excess flooding with the new flooding topology.
In the distributed mode, the new flooding topology will be calculated In the distributed mode, the new flooding topology will be calculated
on all nodes that support the algorithm that is advertised by the new on all nodes that support the algorithm that is advertised by the new
Area Leader. Nodes that do not support the algorithm advertised by Area Leader. Nodes that do not support the algorithm advertised by
the new Area Leader will no longer participate in Dynamic Flooding the new Area Leader will no longer participate in dynamic flooding
and will revert to standard flooding. and will revert to standard flooding.
6.8.11. Recovery from Multiple Failures 6.8.11. Recovery from Multiple Failures
In the event of multiple failures on the flooding topology, it may In the event of multiple failures on the flooding topology, it may
become partitioned. The nodes that remain active on the edges of the become partitioned. The nodes that remain active on the edges of the
flooding topology partitions will recognize this and will try to flooding topology partitions will recognize this and will try to
repair the flooding topology locally by enabling temporary flooding repair the flooding topology locally by enabling temporary flooding
towards the nodes that they consider disconnected from the flooding towards the nodes that they consider disconnected from the flooding
topology until a new flooding topology becomes connected again. topology until a new flooding topology becomes connected again.
Nodes, where local failure was detected, update their link state Nodes, where local failure was detected, update their LSAs and flood
advertisements and flood them on the remainder of the flooding them on the remainder of the flooding topology.
topology.
In centralized mode, the Area Leader will notice the change in the In centralized mode, the Area Leader will notice the change in the
flooding topology, recompute the flooding topology, and flood it flooding topology, recompute the flooding topology, and flood it
using the new flooding topology. using the new flooding topology.
In distributed mode, all nodes that actively participate in Dynamic In distributed mode, all nodes that actively participate in dynamic
Flooding will compute the new flooding topology. flooding will compute the new flooding topology.
Note that this is very different from the area partition because Note that this is very different from the area partition because
there is still a connected network graph between the nodes in the there is still a connected network graph between the nodes in the
area. The area may remain connected and forwarding may still be area. The area may remain connected and forwarding may still be
functioning correctly. functioning correctly.
6.8.12. Rate-Limiting Temporary Flooding 6.8.12. Rate-Limiting Temporary Flooding
As discussed in the previous sections, some events require the As discussed in the previous sections, some events require the
introduction of temporary flooding on edges that are not part of the introduction of temporary flooding on edges that are not part of the
skipping to change at page 39, line 18 skipping to change at line 1801
It is recommended that a node rate limit the number of edges on which It is recommended that a node rate limit the number of edges on which
it chooses to enable temporary flooding. Initial values for the it chooses to enable temporary flooding. Initial values for the
number of edges on which to enable temporary flooding and the rate at number of edges on which to enable temporary flooding and the rate at
which additional edges may subsequently be enabled is left as an which additional edges may subsequently be enabled is left as an
implementation decision. implementation decision.
7. IANA Considerations 7. IANA Considerations
7.1. IS-IS 7.1. IS-IS
This document requests the following code points from the "IS-IS Sub- The following code points have been assigned in the "IS-IS Sub-TLVs
TLVs for IS-IS Router CAPABILITY TLV" registry (IS-IS TLV 242). for IS-IS Router CAPABILITY TLV" registry (IS-IS TLV 242).
Type: TBD1
Description: IS-IS Area Leader Sub-TLV
Reference: This document (Section 5.1.1)
Type: TBD7
Description: IS-IS Dynamic Flooding Sub-TLV
Reference: This document (Section 5.1.2)
This document requests that IANA allocate and assign code points from
the "IS-IS Top-Level TLV Codepoints" registry. One for each of the
following TLVs:
Type: TBD2
Description: IS-IS Area System IDs TLV
Reference: This document (Section 5.1.3)
Type: TBD3 +======+========================+==========================+
| Type | Description | Reference |
+======+========================+==========================+
| 27 | IS-IS Area Leader | RFC 9667 (Section 5.1.1) |
+------+------------------------+--------------------------+
| 28 | IS-IS Dynamic Flooding | RFC 9667 (Section 5.1.2) |
+------+------------------------+--------------------------+
Description: IS-IS Flooding Path TLV Table 1
Reference: This document (Section 5.1.4) IANA has assigned code points from the "IS-IS Top-Level TLV
Codepoints" registry, one for each of the following TLVs:
Type: TBD9 +======+========================+==========================+
| Type | Description | Reference |
+======+========================+==========================+
| 17 | IS-IS Area Node IDs | RFC 9667 (Section 5.1.3) |
+------+------------------------+--------------------------+
| 18 | IS-IS Flooding Path | RFC 9667 (Section 5.1.4) |
+------+------------------------+--------------------------+
| 19 | IS-IS Flooding Request | RFC 9667 (Section 5.1.5) |
+------+------------------------+--------------------------+
Description: IS-IS Flooding Request TLV Table 2
Reference: This document (Section 5.1.5)
This document requests that IANA extend the "IS-IS Neighbor Link- IANA has extended the "IS-IS Neighbor Link-Attribute Bit Values"
Attribute Bit Values" registry to contain a "L2BM" column that registry to contain an "L2BM" column that indicates if a bit may
indicates if a bit may appear in an L2 Bundle Member Attributes TLV. appear in an L2 Bundle Member Attributes TLV. All existing rows have
All existing rows should have the value "N" for "L2BM". The the value "N" for "L2BM". The following explanatory note has been
following explanatory note should be added to the registry: added to the registry:
| The "L2BM" column indicates applicability to the L2 Bundle Member | The "L2BM" column indicates applicability to the L2 Bundle Member
| Attributes TLV. The options for the "L2BM" column are: | Attributes TLV. The options for the "L2BM" column are:
| |
| Y - This bit MAY appear in the L2 Bundle Member Attributes TLV. | Y - This bit MAY appear in the L2 Bundle Member Attributes TLV.
| |
| N - This bit MUST NOT appear in the L2 Bundle Member Attributes | N - This bit MUST NOT appear in the L2 Bundle Member Attributes
| TLV. | TLV.
This document requests that IANA allocate a new bit-value from the IANA has allocated a new bit-value from the "IS-IS Neighbor Link-
"IS-IS Neighbor Link-Attribute Bit Values" registry. Attribute Bit Values" registry.
Value: 0x4 (suggested, to be assigned by IANA)
L2BM: N
Name: Local Edge Enabled for Flooding (LEEF) +=======+======+========================================+===========+
| Value | L2BM | Name | Reference |
+=======+======+========================================+===========+
| 0x4 | N | Local Edge Enabled | RFC 9667 |
| | | for Flooding (LEEF) | |
+-------+------+----------------------------------------+-----------+
Reference: This document Table 3
7.2. OSPF 7.2. OSPF
This document requests the following code points from the "OSPF The following code points have been assigned in the "OSPF Router
Router Information (RI) TLVs" registry: Information (RI) TLVs" registry:
Type: TBD4
Description: OSPF Area Leader Sub-TLV
Reference: This document (Section 5.2.1)
Type: TBD8
Description: OSPF Dynamic Flooding Sub-TLV +=======+=======================+==========================+
| Value | TLV Name | Reference |
+=======+=======================+==========================+
| 17 | OSPF Area Leader | RFC 9667 (Section 5.2.1) |
+-------+-----------------------+--------------------------+
| 18 | OSPF Dynamic Flooding | RFC 9667 (Section 5.2.2) |
+-------+-----------------------+--------------------------+
Reference: This document (Section 5.2.2) Table 4
This document requests the following code point from the "Opaque The following code points have been assigned in the "Opaque Link-
Link-State Advertisements (LSA) Option Types" registry: State Advertisements (LSA) Option Types" registry:
Type: TBD5 +=======+====================================+=================+
Description: OSPFv2 Dynamic Flooding Opaque LSA | Value | Opaque Type | Reference |
+=======+====================================+=================+
| 10 | OSPFv2 Dynamic Flooding Opaque LSA | RFC 9667 |
| | | (Section 5.2.3) |
+-------+------------------------------------+-----------------+
Reference: This document (Section 5.2.3) Table 5
This document requests the following code point from the "OSPFv3 LSA The following code point has been assigned in the "OSPFv3 LSA
Function Codes" registry: Function Codes" registry:
Type: TBD6 +=======+=============================+==========================+
| Value | LSA Function Code Name | Reference |
Description: OSPFv3 Dynamic Flooding LSA +=======+=============================+==========================+
| 16 | OSPFv3 Dynamic Flooding LSA | RFC 9667 (Section 5.2.4) |
Reference: This document (Section 5.2.4) +-------+-----------------------------+--------------------------+
This document requests a new bit in the "LLS Type 1 Extended Options
and Flags" registry:
Bit Position: TBD10
Description: Flooding Request bit
Reference: This document (Section 5.2.7)
This document requests the following code point from the "OSPFv2 Table 6
Extended Link TLV Sub-TLVs" registry:
Type: TBD11 IANA has assigned a new bit in the "LLS Type 1 Extended Options and
Flags" registry:
Description: OSPFv2 Link Attributes Bits Sub-TLV +==============+======================+==========================+
| Bit Position | Description | Reference |
+==============+======================+==========================+
| 0x00000020 | Flooding Request bit | RFC 9667 (Section 5.2.7) |
+--------------+----------------------+--------------------------+
Reference: This document (Section 5.2.8) Table 7
L2 Bundle Member Attributes (L2BM): Y The following code point has been assigned in the "OSPFv2 Extended
Link TLV Sub-TLVs" registry:
This document requests the following code point from the "OSPFv3 +======+========================+===========+===================+
Extended LSA Sub-TLVs" registry: | Type | Description | Reference | L2 Bundle Member |
| | | | Attributes (L2BM) |
+======+========================+===========+===================+
| 21 | OSPFv2 Link Attributes | RFC 9667 | Y |
| | Bits Sub-TLV | (Section | |
| | | 5.2.8) | |
+------+------------------------+-----------+-------------------+
Type: TBD12 Table 8
Description: OSPFv3 Link Attributes Bits Sub-TLV The following code point has been assigned in the "OSPFv3 Extended
LSA Sub-TLVs" registry:
Reference: This document (Section 5.2.8) +======+========================+===========+===================+
| Type | Description | Reference | L2 Bundle Member |
| | | | Attributes (L2BM) |
+======+========================+===========+===================+
| 10 | OSPFv3 Link Attributes | RFC 9667 | Y |
| | Bits Sub-TLV | (Section | |
| | | 5.2.8) | |
+------+------------------------+-----------+-------------------+
L2 Bundle Member Attributes (L2BM): Y Table 9
7.2.1. OSPF Dynamic Flooding LSA TLVs Registry 7.2.1. OSPF Dynamic Flooding LSA TLVs Registry
This specification also requests a new registry - "OSPF Dynamic A new registry has been created: "OSPF Dynamic Flooding LSA TLVs".
Flooding LSA TLVs". New values can be allocated via IETF Review or New values can be allocated via IETF Review or IESG Approval.
IESG Approval.
The "OSPF Dynamic Flooding LSA TLVs" registry will define top-level
TLVs for the OSPFv2 Dynamic Flooding Opaque LSA and OSPFv3 Dynamic
Flooding LSAs. It should be added to the "Open Shortest Path First
(OSPF) Parameters" registries group.
The following initial values are allocated:
Type: 0
Description: Reserved
Reference: This document
Type: 1
Description: OSPF Area Router IDs TLV
Reference: This document (Section 5.2.5) The "OSPF Dynamic Flooding LSA TLVs" registry defines top-level TLVs
for the OSPFv2 Dynamic Flooding Opaque LSA and OSPFv3 Dynamic
Flooding LSAs. It has been added to the "Open Shortest Path First
(OSPF) Parameters" registry group.
Type: 2 The following initial values have been allocated:
Description: OSPF Flooding Path TLV +======+======================+==========================+
| Type | Description | Reference |
+======+======================+==========================+
| 0 | Reserved | RFC 9667 |
+------+----------------------+--------------------------+
| 1 | OSPF Area Router IDs | RFC 9667 (Section 5.2.5) |
+------+----------------------+--------------------------+
| 2 | OSPF Flooding Path | RFC 9667 (Section 5.2.6) |
+------+----------------------+--------------------------+
Reference: This document (Section 5.2.6) Table 10
Types in the range 32768-33023 are for experimental use; these will Types in the range 32768-33023 are Reserved for Experimental Use;
not be registered with IANA, and MUST NOT be mentioned by RFCs. these will not be registered with IANA and MUST NOT be mentioned by
RFCs.
Types in the range 33024-65535 are not to be assigned at this time. Types in the range 33024-65535 are Reserved. They are not to be
Before any assignments can be made in the 33024-65535 range, there assigned at this time. Before any assignments can be made in the
MUST be an IETF specification that specifies IANA Considerations that 33024-65535 range, there MUST be an IETF specification that specifies
cover the range being assigned. IANA Considerations that cover the range being assigned.
7.2.2. OSPF Link Attributes Sub-TLV Bit Values Registry 7.2.2. OSPF Link Attributes Sub-TLV Bit Values Registry
This specification also requests a new registry - "OSPF Link A new registry has been created: "OSPF Link Attributes Sub-TLV Bit
Attributes Sub-TLV Bit Values". New values can be allocated via IETF Values". New values can be allocated via IETF Review or IESG
Review or IESG Approval. Approval.
The "OSPF Link Attributes Sub-TLV Bit Values" registry defines Link The "OSPF Link Attributes Sub-TLV Bit Values" registry defines Link
Attribute bit-values for the OSPFv2 Link Attributes Sub-TLV and Attribute bit-values for the OSPFv2 Link Attributes Sub-TLV and
OSPFv3 Link Attributes Sub-TLV. It should be added to the "Open OSPFv3 Link Attributes Sub-TLV. It has been added to the "Open
Shortest Path First (OSPF) Parameters" registries group. This Shortest Path First (OSPF) Parameters" registry group. This registry
registry should contain a column "L2BM" that indicates if a bit may contains a column "L2BM" that indicates if a bit may appear in an L2
appear in an L2 Bundle Member Attributes (L2BM) sub-TLV. The Bundle Member Attributes (L2BM) Sub-TLV. The following explanatory
following explanatory note should be added to the registry: note has been added to the registry:
| The "L2BM" column indicates applicability to the L2 Bundle Member | The "L2BM" column indicates applicability to the L2 Bundle Member
| Attributes sub-TLV. The options for the "L2BM" column are: | Attributes sub-TLV. The options for the "L2BM" column are:
| |
| Y - This bit MAY appear in the L2 Bundle Member Attributes sub- | Y - This bit MAY appear in the L2 Bundle Member Attributes sub-
| TLV. | TLV.
| |
| N - This bit MUST NOT appear in the L2 Bundle Member Attributes | N - This bit MUST NOT appear in the L2 Bundle Member Attributes
| sub-TLV. | sub-TLV.
The following initial value is allocated: The following initial value is allocated:
Bit Number: 0 +========+=====================+===========+===================+
| Bit | Description | Reference | L2 Bundle Member |
Description: Local Edge Enabled for Flooding(LEEF) | Number | | | Attributes (L2BM) |
+========+=====================+===========+===================+
Reference: This document (Section 5.2.8) | 0 | Local Edge Enabled | RFC 9667 | N |
| | for Flooding (LEEF) | (Section | |
| | | 5.2.8) | |
+--------+---------------------+-----------+-------------------+
L2 Bundle Member Attributes (L2BM): N Table 11
7.3. IGP 7.3. IGP
IANA is requested to set up a registry called "IGP Algorithm Type For IANA has created a registry called "IGP Algorithm Type For Computing
Computing Flooding Topology" under the existing "Interior Gateway Flooding Topology" in the existing "Interior Gateway Protocol (IGP)
Protocol (IGP) Parameters" IANA registry. Parameters" registry group.
The registration policy for this registry is Expert Review. The registration policy for this registry is Expert Review.
Values in this registry come from the range 0-255. Values in this registry come from the range 0-255.
The initial values in the IGP Algorithm Type For Computing Flooding The initial values in the "IGP Algorithm Type For Computing Flooding
Topology registry are: Topology" registry are as follows:
0: Reserved for centralized mode.
1-127: Individual values are to be assigned according to the
"Expert Review" policy defined in [RFC8126]. The designated
experts should require a clear, public specification of the
algorithm and comply with [RFC7370].
128-254: Reserved for private use. +=========+==================================================+
| Value | Description |
+=========+==================================================+
| 0 | Reserved for centralized mode |
+---------+--------------------------------------------------+
| 1-127 | Unassigned. Individual values are to be |
| | assigned according to the "Expert Review" policy |
| | defined in [RFC8126]. The designated experts |
| | should require a clear, public specification of |
| | the algorithm and comply with [RFC7370]. |
+---------+--------------------------------------------------+
| 128-254 | Reserved for Private Use |
+---------+--------------------------------------------------+
| 255 | Reserved |
+---------+--------------------------------------------------+
255: Reserved. Table 12
8. Security Considerations 8. Security Considerations
This document introduces no new security issues. Security of routing This document introduces no new security issues. Security of routing
within a domain is already addressed as part of the routing protocols within a domain is already addressed as part of the routing protocols
themselves. This document proposes no changes to those security themselves. This document proposes no changes to those security
architectures. architectures.
An attacker could become the Area Leader and introduce a flawed An attacker could become the Area Leader and introduce a flawed
flooding algorithm into the network thus compromising the operation flooding algorithm into the network thus compromising the operation
of the protocol. Authentication methods as described in [RFC5304] of the protocol. Authentication methods as described in [RFC5304]
and [RFC5310] for IS-IS, [RFC2328] and [RFC7474] for OSPFv2 and and [RFC5310] for IS-IS, [RFC2328] and [RFC7474] for OSPFv2, and
[RFC5340] and [RFC4552] for OSPFv3 SHOULD be used to prevent such [RFC5340] and [RFC4552] for OSPFv3 SHOULD be used to prevent such
attacks. attacks.
9. Acknowledgements 9. References
The authors would like to thank Sarah Chen, Tony Przygienda, Dave
Cooper, Gyan Mishra, and Les Ginsberg for their contribution to this
work. The authors would also like to thank Arista Networks for
supporting the development of this technology.
The authors would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam
Sweeney, Acee Lindem, and Olufemi Komolafe for their helpful
comments.
The authors would like to thank Tom Edsall for initially introducing
them to the problem.
Advertising Local Edges Enabled for Flooding (LEEF) is based on an
idea proposed by Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng
Liu, Yanhe Fan, and Lei Liu. We wish to thank them for their
contribution.
10. References
10.1. Normative References 9.1. Normative References
[ISO10589] ISO, "Intermediate System to Intermediate System Intra- [ISO10589] ISO, "Information technology — Telecommunications and
Domain Routing Exchange Protocol for use in Conjunction information exchange between systems — Intermediate System
with the Protocol for Providing the Connectionless-mode to Intermediate System intra-domain routeing information
Network Service (ISO 8473)", ISO/IEC 10589:2002, October exchange protocol for use in conjunction with the protocol
2002. for providing the connectionless-mode network service (ISO
8473)", Second Edition, ISO/IEC 10589:2002, November 2002,
<https://www.iso.org/standard/30932.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>. <https://www.rfc-editor.org/info/rfc2328>.
skipping to change at page 46, line 29 skipping to change at line 2136
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and [RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA) F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>. 2018, <https://www.rfc-editor.org/info/rfc8362>.
10.2. Informative References 9.2. Informative References
[Bondy] Bondy, J. A. and U. S. R. Murty, "Graph Theory With [Bondy] Bondy, J. A. and U. S. R. Murty, "Graph Theory With
Applications", 1976, Applications", Elsevier Science Publishing Co., Inc.,
ISBN 0-444-19451-7, 1976,
<https://www.zib.de/groetschel/teaching/WS1314/ <https://www.zib.de/groetschel/teaching/WS1314/
BondyMurtyGTWA.pdf>. ISBN 0-444-19451-7 BondyMurtyGTWA.pdf>.
[Clos] Clos, C., "A Study of Non-Blocking Switching Networks", [Clos] Clos, C., "A study of non-blocking switching networks",
The Bell System Technical Journal Vol. 32(2), DOI The Bell System Technical Journal, Volume 32, Issue 2, pp.
10.1002/j.1538-7305.1953.tb01433.x, March 1953, 406-424, DOI 10.1002/j.1538-7305.1953.tb01433.x, March
<http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>. 1953,
<https://doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
[Leiserson] [Leiserson]
Leiserson, C. E., "Fat-Trees: Universal Networks for Leiserson, C. E., "Fat-trees: Universal networks for
Hardware-Efficient Supercomputing", IEEE Transactions on hardware-efficient supercomputing", IEEE Transactions on
Computers 34(10):892-901, 1985. Computers, Volume C-34, Issue 10, pp. 892-901,
DOI 10.1109/TC.1985.6312192, October 1985,
<https://doi.org/10.1109/TC.1985.6312192>.
[RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups", [RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups",
RFC 2973, DOI 10.17487/RFC2973, October 2000, RFC 2973, DOI 10.17487/RFC2973, October 2000,
<https://www.rfc-editor.org/info/rfc2973>. <https://www.rfc-editor.org/info/rfc2973>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630, (TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003, DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>. <https://www.rfc-editor.org/info/rfc3630>.
skipping to change at page 47, line 24 skipping to change at line 2180
[RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints
Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014,
<https://www.rfc-editor.org/info/rfc7370>. <https://www.rfc-editor.org/info/rfc7370>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of [RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938, BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016, DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>. <https://www.rfc-editor.org/info/rfc7938>.
Acknowledgements
The authors would like to thank Sarah Chen, Tony Przygienda, Dave
Cooper, Gyan Mishra, and Les Ginsberg for their contributions to this
work. The authors would also like to thank Arista Networks for
supporting the development of this technology.
The authors would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam
Sweeney, Acee Lindem, and Olufemi Komolafe for their helpful
comments.
The authors would like to thank Tom Edsall for initially introducing
them to the problem.
Advertising Local Edges Enabled for Flooding (LEEF) is based on an
idea proposed by Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng
Liu, Yanhe Fan, and Lei Liu. The authors wish to thank them for
their contributions.
Authors' Addresses Authors' Addresses
Tony Li (editor) Tony Li (editor)
Juniper Networks Juniper Networks
1133 Innovation Way 1133 Innovation Way
Sunnyvale, California 94089 Sunnyvale, California 94089
United States of America United States of America
Email: tony.li@tony.li Email: tony.li@tony.li
Peter Psenak (editor) Peter Psenak (editor)
Cisco Systems, Inc. Cisco Systems, Inc.
Eurovea Centre, Central 3 Eurovea Centre, Central 3
Pribinova Street 10 Pribinova Street 10
81109 Bratislava 81109 Bratislava
Slovakia Slovakia
Email: ppsenak@cisco.com Email: ppsenak@cisco.com
Huaimo Chen Huaimo Chen
Futurewei Futurewei
Boston, MA, Boston, Massachusetts
United States of America United States of America
Email: hchen.ietf@gmail.com Email: hchen.ietf@gmail.com
Luay Jalil Luay Jalil
Verizon Verizon
Richardson, Texas 75081 Richardson, Texas 75081
United States of America United States of America
Email: luay.jalil@verizon.com Email: luay.jalil@verizon.com
Srinath Dontula Srinath Dontula
ATT AT&T
200 S Laurel Ave 200 S Laurel Ave
Middletown, New Jersey 07748 Middletown, New Jersey 07748
United States of America United States of America
Email: sd947e@att.com Email: sd947e@att.com
 End of changes. 312 change blocks. 
863 lines changed or deleted 894 lines changed or added

This html diff was produced by rfcdiff 1.48.