draft-ietf-lsr-dynamic-flooding-00.txt   draft-ietf-lsr-dynamic-flooding-01.txt 
Internet Engineering Task Force T. Li, Ed. Internet Engineering Task Force T. Li, Ed.
Internet-Draft Arista Networks Internet-Draft Arista Networks
Intended status: Standards Track P. Psenak, Ed. Intended status: Standards Track P. Psenak, Ed.
Expires: August 29, 2019 L. Ginsberg Expires: November 22, 2019 L. Ginsberg
Cisco Systems, Inc. Cisco Systems, Inc.
T. Przygienda T. Przygienda
Juniper Networks, Inc. Juniper Networks, Inc.
D. Cooper D. Cooper
CenturyLink CenturyLink
L. Jalil L. Jalil
Verizon Verizon
S. Dontula S. Dontula
ATT ATT
February 25, 2019 May 21, 2019
Dynamic Flooding on Dense Graphs Dynamic Flooding on Dense Graphs
draft-ietf-lsr-dynamic-flooding-00 draft-ietf-lsr-dynamic-flooding-01
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 sub-optimal convergence times due to the overhead
associated with flooding. This can be addressed by decreasing the associated with flooding. This can be addressed by decreasing the
flooding topology so that it is less dense. flooding 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,
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2019. This Internet-Draft will expire on November 22, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5
3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 5 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 5
4. Dynamic Flooding . . . . . . . . . . . . . . . . . . . . . . 5 4. Dynamic Flooding . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Leader election . . . . . . . . . . . . . . . . . . . . . 7 4.2. Leader election . . . . . . . . . . . . . . . . . . . . . 8
4.3. Computing the Flooding Topology . . . . . . . . . . . . . 8 4.3. Computing the Flooding Topology . . . . . . . . . . . . . 8
4.4. Topologies on Complete Bipartite Graphs . . . . . . . . . 9 4.4. Topologies on Complete Bipartite Graphs . . . . . . . . . 9
4.4.1. A Minimal Flooding Topology . . . . . . . . . . . . . 9 4.4.1. A Minimal Flooding Topology . . . . . . . . . . . . . 9
4.4.2. Xia Topologies . . . . . . . . . . . . . . . . . . . 9 4.4.2. Xia Topologies . . . . . . . . . . . . . . . . . . . 10
4.4.3. Optimization . . . . . . . . . . . . . . . . . . . . 10 4.4.3. Optimization . . . . . . . . . . . . . . . . . . . . 11
4.5. Encoding the Flooding Topology . . . . . . . . . . . . . 11 4.5. Encoding the Flooding Topology . . . . . . . . . . . . . 11
5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 4.6. Advertising the Local Edges Enabled for Flooding . . . . 11
5.1. IS-IS TLVs . . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 12
5.1.1. IS-IS Area Leader Sub-TLV . . . . . . . . . . . . . . 11 5.1. IS-IS TLVs . . . . . . . . . . . . . . . . . . . . . . . 12
5.1.2. IS-IS Dynamic Flooding Sub-TLV . . . . . . . . . . . 12 5.1.1. IS-IS Area Leader Sub-TLV . . . . . . . . . . . . . . 12
5.1.3. IS-IS Area System IDs TLV . . . . . . . . . . . . . . 13 5.1.2. IS-IS Dynamic Flooding Sub-TLV . . . . . . . . . . . 13
5.1.4. IS-IS Flooding Path TLV . . . . . . . . . . . . . . . 14 5.1.3. IS-IS Area Node IDs TLV . . . . . . . . . . . . . . . 14
5.1.5. IS-IS Flooding Request TLV . . . . . . . . . . . . . 15 5.1.4. IS-IS Flooding Path TLV . . . . . . . . . . . . . . . 15
5.2. OSPF LSAs and TLVs . . . . . . . . . . . . . . . . . . . 16 5.1.5. IS-IS Flooding Request TLV . . . . . . . . . . . . . 16
5.2.1. OSPF Area Leader Sub-TLV . . . . . . . . . . . . . . 17 5.1.6. IS-IS LEEF Advertisement . . . . . . . . . . . . . . 18
5.2.2. OSPF Dynamic Flooding Sub-TLV . . . . . . . . . . . . 17 5.2. OSPF LSAs and TLVs . . . . . . . . . . . . . . . . . . . 18
5.2.3. OSPFv2 Dynamic Flooding Opaque LSA . . . . . . . . . 18 5.2.1. OSPF Area Leader Sub-TLV . . . . . . . . . . . . . . 18
5.2.4. OSPFv3 Dynamic Flooding LSA . . . . . . . . . . . . . 19 5.2.2. OSPF Dynamic Flooding Sub-TLV . . . . . . . . . . . . 19
5.2.5. OSPF Area Router IDs TLV . . . . . . . . . . . . . . 20 5.2.3. OSPFv2 Dynamic Flooding Opaque LSA . . . . . . . . . 19
5.2.6. OSPF Flooding Path TLV . . . . . . . . . . . . . . . 21 5.2.4. OSPFv3 Dynamic Flooding LSA . . . . . . . . . . . . . 21
5.2.7. OSPF Flooding Request Bit . . . . . . . . . . . . . . 22 5.2.5. OSPF Area Router ID TLVs . . . . . . . . . . . . . . 22
6. Behavioral Specification . . . . . . . . . . . . . . . . . . 23 5.2.5.1. OSPFv2 Area Router ID TLV . . . . . . . . . . . . 22
6.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 23 5.2.5.2. OSPFv3 Area Router ID TLV . . . . . . . . . . . . 24
6.2. Flooding Topology . . . . . . . . . . . . . . . . . . . . 23 5.2.6. OSPF Flooding Path TLV . . . . . . . . . . . . . . . 26
6.3. Leader Election . . . . . . . . . . . . . . . . . . . . . 24 5.2.7. OSPF Flooding Request Bit . . . . . . . . . . . . . . 27
6.4. Area Leader Responsibilities . . . . . . . . . . . . . . 24 5.2.8. OSPF LEEF Advertisement . . . . . . . . . . . . . . . 28
6.5. Distributed Flooding Topology Calculation . . . . . . . . 24 6. Behavioral Specification . . . . . . . . . . . . . . . . . . 28
6.6. Flooding Behavior . . . . . . . . . . . . . . . . . . . . 25 6.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 29
6.7. Treatment of Topology Events . . . . . . . . . . . . . . 25 6.2. Flooding Topology . . . . . . . . . . . . . . . . . . . . 29
6.7.1. Temporary Addition of Link to Flooding Topology . . . 26 6.3. Leader Election . . . . . . . . . . . . . . . . . . . . . 29
6.7.2. Local Link Addition . . . . . . . . . . . . . . . . . 26 6.4. Area Leader Responsibilities . . . . . . . . . . . . . . 30
6.7.3. Node Addition . . . . . . . . . . . . . . . . . . . . 27 6.5. Distributed Flooding Topology Calculation . . . . . . . . 30
6.7.4. Failures of Link Not on Flooding Topology . . . . . . 27 6.6. Use of LANs in the Flooding Topology . . . . . . . . . . 30
6.7.5. Failures of Link On the Flooding Topology . . . . . . 28 6.6.1. Use of LANs in Centralized mode . . . . . . . . . . . 30
6.7.6. Node Deletion . . . . . . . . . . . . . . . . . . . . 28 6.6.2. Use of LANs in Distributed Mode . . . . . . . . . . . 31
6.7.7. Local Link Addition to the Flooding Topology . . . . 28 6.6.2.1. Partial flooding on a LAN in IS-IS . . . . . . . 31
6.7.8. Local Link Deletion from the Flooding Topology . . . 29 6.6.2.2. Partial Flooding on a LAN in OSPF . . . . . . . . 31
6.7.9. Treatment of Disconnected Adjacent Nodes . . . . . . 29 6.7. Flooding Behavior . . . . . . . . . . . . . . . . . . . . 32
6.7.10. Failure of the Area Leader . . . . . . . . . . . . . 29 6.8. Treatment of Topology Events . . . . . . . . . . . . . . 33
6.7.11. Recovery from Multiple Failures . . . . . . . . . . . 30 6.8.1. Temporary Addition of Link to Flooding Topology . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 6.8.2. Local Link Addition . . . . . . . . . . . . . . . . . 33
7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.8.3. Node Addition . . . . . . . . . . . . . . . . . . . . 34
7.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.8.4. Failures of Link Not on Flooding Topology . . . . . . 35
7.2.1. OSPF Dynamic Flooding LSA TLVs Registry . . . . . . . 32 6.8.5. Failures of Link On the Flooding Topology . . . . . . 35
7.3. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.8.6. Node Deletion . . . . . . . . . . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 6.8.7. Local Link Addition to the Flooding Topology . . . . 36
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 6.8.8. Local Link Deletion from the Flooding Topology . . . 36
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 6.8.9. Treatment of Disconnected Adjacent Nodes . . . . . . 36
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 6.8.10. Failure of the Area Leader . . . . . . . . . . . . . 36
10.2. Informative References . . . . . . . . . . . . . . . . . 35 6.8.11. Recovery from Multiple Failures . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 6.8.12. Rate Limiting Temporary Flooding . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 39
7.2.1. OSPF Dynamic Flooding LSA TLVs Registry . . . . . . . 40
7.2.2. OSPF Link Attributes Sub-TLV Bit Values Registry . . 41
7.3. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 42
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
10.1. Normative References . . . . . . . . . . . . . . . . . . 42
10.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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 (a.k.a. spine-leaf
or leaf-spine), Clos [Clos], or Fat Tree [Leiserson] topology. or leaf-spine), Clos [Clos], or Fat Tree [Leiserson] topology.
Conventional Interior Gateway Protocols (IGPs, i.e., IS-IS Conventional Interior Gateway Protocols (IGPs, i.e., IS-IS
[ISO10589], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) under-perform, [ISO10589], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) under-perform,
redundantly flooding information throughout the dense topology, redundantly flooding information throughout the dense topology,
leading to overloaded control plane inputs and thereby creating leading to overloaded control plane inputs and thereby creating
skipping to change at page 6, line 50 skipping to change at page 7, line 11
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, it is possible that loops will form in the During transients, it is possible that loops will form in the
flooding topology. This is not problematic, as the legacy flooding flooding topology. This is not problematic, as the legacy flooding
rules would cause duplicate updates to be ignored. Similarly, during rules would cause duplicate updates to be ignored. Similarly, during
transients, it is possible that the flooding topology may become transients, it is possible that the flooding topology may become
disconnected. Section 6.7.11 discusses how such conditions are disconnected. Section 6.8.11 discusses how such conditions are
handled. handled.
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 degree node in the flooding flooding topology, as well as the maximum degree node 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.
skipping to change at page 11, line 15 skipping to change at page 11, line 22
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, we choose to encode the flooding topology as a set of Instead, we choose to encode the flooding topology as a set of
intersecting paths, where each path is a set of connected edges. intersecting paths, where each path is a set of connected edges.
Advertisement of the flooding topology includes support for multi-
access LANs. When a LAN is included in the flooding topology, all
edges between the LAN and nodes connected to the LAN are assumed to
be part of the flooding topology. In order to reduce the size of the
flooding topology advertisement, explicit advertisement of these
edges is optional. Note that this may result in the possibility of
"hidden nodes" existing which are actually part of the flooding
topology but which are not explicitly mentioned in the flooding
topology advertisements. These hidden nodes can be found by
examination of the Link State database where connectivity between a
LAN and nodes connected to the LAN is fully specified.
Note that while all nodes MUST be part of the advertised flooding
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
the advertised flooding topology.
Other encodings are certainly possible. We have attempted to make a Other encodings are certainly possible. We have attempted to make a
useful trade off between simplicity, generality, and space. useful trade off between simplicity, generality, and space.
4.6. Advertising the Local Edges Enabled for Flooding
Correct operation of the flooding topology requires that all nodes
which participate in the flooding topology choose local links for
flooding which are consistent with the calculated flooding topology.
Failure to do so could result in unexpected partition of the flooding
topology and/or sub-optimal flooding reduction. As an aid to
diagnosing problems when dynamic flooding is in use, this document
defines a means of advertising what local edges are enabled for
flooding (LEEF). The protocol specific encodings are defined in
Sections 5.1.6 and 5.2.8.
The following guidelines apply:
Advertisement of LEEFs is optional.
As the flooding topology is defined by edges (not by links), in
cases where parallel adjacencies to the same neighbor exist, the
advertisement SHOULD indicate that all such links have been
enabled.
LEEF advertisements MUST NOT include edges enabled for temporary
flooding (Section 6.7).
LEEF advertisements MUST NOT be used either when calculating a
flooding topology or when determining what links to add
temporarily to the flooding topology when the flooding topology is
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 inject into its LSP to indicate its 1. A sub-TLV that an IS may inject into its LSP to indicate its
preference for becoming Area Leader. preference for becoming Area Leader.
2. A sub-TLV that an IS may inject into its LSP to indicate that it 2. A sub-TLV that an IS may inject into its LSP to indicate that it
skipping to change at page 12, line 15 skipping to change at page 13, line 18
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. Leader.
The Area Leader Sub-TLV is advertised as a Sub-TLV of the IS-IS The 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 that is defined in [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 Type: TBD1
Length: 2 Length: 2
Priority: 0-255, unsigned integer Priority: 0-255, unsigned integer
Algorithm: a numeric identifier in the range 0-255 that identifies 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:
skipping to change at page 13, line 13 skipping to change at page 14, line 16
mode, if any. mode, if any.
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 Dynamic Flooding Sub-TLV is advertised as a Sub-TLV of the IS-IS
Router Capability TLV (242) [RFC7981] and has the following format: 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 Type: TBD7
Length: 0-255; number of Algorithms Length: 0-255; number of Algorithms
Algorithm: zero or more numeric identifiers in the range 0-255 Algorithm: zero or more numeric identifiers in the range 0-255
that identifies the algorithm used to calculate the flooding that identifies the algorithm used to calculate the flooding
topology, as described in Section 5.1.1. topology, as described in Section 5.1.1.
5.1.3. IS-IS Area System IDs TLV 5.1.3. IS-IS Area Node IDs TLV
IS-IS Area System IDs TLV is only used in centralized mode. The IS-IS Area Node IDs TLV is only used in centralized mode.
The Area System IDs TLV is used by the Area Leader to enumerate the The Area Node IDs TLV is used by the Area Leader to enumerate the
system IDs that it has used in computing the flooding topology. Node IDs (System ID + pseudo-node ID) that it has used in computing
Conceptually, the Area Leader creates a list of system IDs for all the area flooding topology. Conceptually, the Area Leader creates a
nodes in the area, assigning indices to each system, starting with list of node IDs for all nodes in the area (including pseudo-nodes
index 0. for all LANs in the topology), assigning indices to each node,
starting with index 0.
Because the space in a single TLV is small, more than one TLV may be Because the space in a single TLV is limited, more than one TLV may
required to encode all of the system 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 System IDs TLV is: The format of the Area Node IDs TLV is:
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 | System IDs ... |L| Reserved | Node IDs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
System IDs continued .... Node IDs continued ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD2 Type: TBD2
Length: 3 + (System ID length * (number of System IDs)) Length: 3 + ((System ID Length + 1) * (number of node IDs))
Starting index: The index of the first system ID that appears in Starting index: The index of the first node ID that appears in
this TLV. this TLV.
L (Last): This bit is set if the index of the last system ID that 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
system IDs for the area. node IDs for the area.
System IDs: A concatenated list of system IDs for the area. Node IDs: A concatenated list of node IDs for the area
If there are multiple IS-IS Area System IDs TLVs with the L bit set If there are multiple IS-IS Area Node IDs TLVs with the L bit set
advertised by the same node, the TLV which specifies the smaller advertised by the same node, the TLV which specifies the smaller
maximum index is used and the other TLV(s) with L bit set are maximum index is used and the other TLV(s) with L bit set are
ignored. TLVs which specify system IDs with indices greater than ignored. TLVs which specify node IDs with indices greater than that
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
IS-IS Flooding Path TLV is only used in centralized mode. 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 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
skipping to change at page 14, line 44 skipping to change at page 16, line 6
2 to the system with index 3, and so on. 2 to 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 Flooding Path TLV contains a list of system indices relative to
the systems advertised through the Area System IDs TLV. At least 2 the systems advertised through the Area Node IDs TLV. At least 2
indices must be included in the TLV. Due to the length restriction indices must be included in the TLV. Due to the length restriction
of TLVs, this TLV can contain at most 126 system indices. of TLVs, this TLV can contain at most 126 system indices.
The Flooding Path TLV has the format: The Flooding Path TLV has the 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 Type: TBD3
Length: 2 * (number of indices in the path) Length: 2 * (number of indices in the path)
Starting index: The index of the first system in the path. Starting index: The index of the first system in the path.
Index 2: The index of the next system in the path. Index 2: The index of the next system in the path.
Additional indices (optional): A sequence of additional indices to Additional indices (optional): A sequence of additional indices to
skipping to change at page 15, line 36 skipping to change at page 16, line 43
The Flooding Request TLV allows a system to request an adjacent node The Flooding Request TLV allows a system to request an adjacent node
to enable flooding towards it on a specific link in the case where to enable flooding towards it on a specific link in the case where
the connection to adjacent node is not part of the existing flooding the connection to adjacent node is not part of the existing flooding
topology. topology.
Nodes that support Dynamic Flooding MAY include the Flooding Request Nodes that support Dynamic Flooding MAY include the Flooding Request
TLV in its IIH PDUs. TLV in its IIH PDUs.
The Flooding Request TLV has the format: The Flooding Request TLV has the 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 | Circuit Type |R| Scope | | Type | Length | Levels |R| Scope |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R| ... | |R| ... |
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD9 Type: TBD9
Length: 1 + number of advertised Flooding Scopes Length: 1 + number of advertised Flooding Scopes
Circuit Type - circuit type as specified in IS-IS [ISO10589] Levels - the level(s) for which flooding is requested. Levels are
encoded as the circuit type specified in IS-IS [ISO10589]
R bit: MUST be 0 and is ignored on receipt. R bit: MUST be 0 and is ignored on receipt.
Scope: Flooding Scope for which the flooding is requested as Scope: Flooding Scope for which the flooding is requested as
defined by LSP Flooding Scope Identifier Registry defined by defined by LSP Flooding Scope Identifier Registry defined by
[RFC7356]. Inclusion of flooding scopes is optional and is only [RFC7356]. Inclusion of flooding scopes is optional and is only
necessary if [RFC7356] is supported. necessary if [RFC7356] is supported. Multiple flooding scopes MAY
be included.
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 ignore if received. and MUST be ignored if received.
When the TLV is received in a level specific LAN-Hello PDU (L1-LAN-
IIH or L2-LAN-IIH) only levels which match the PDU type are valid.
Levels which 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
levels which are supported by the established adjacency are valid.
Levels which are not supported by the adjacency MUST be ignored on
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 Type(s) and Flooding Scope(s) received in the
in the Flooding Request TLV. Flooding MUST be enabled until the in the 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
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 the flooding is temporarily enabled on the link for any Circuit When the flooding is temporarily enabled on the link for any Circuit
Type or Flooding Scope due to received Flooding Request TLV, the Type or Flooding Scope due to received Flooding Request TLV, the
receiver MUST perform standard database synchronization for the receiver MUST perform standard database synchronization for the
corresponding Circuit Type(s) and Flooding Scope(s) on the link. In corresponding Circuit Type(s) and Flooding Scope(s) on the link. In
the case of IS-IS, this results in setting SRM bit for all related the case of IS-IS, this results in setting SRM bit for all related
LSPs on the link and sending CSNPs. LSPs on the link and sending CSNPs.
So long as the Flooding Request TLV is being received flooding MUST So long as the Flooding Request TLV is being received flooding MUST
not be disabled for any of the Circuit Types or Flooding Scopes 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 Flooding Request TLV even if the connection between
the neighbors is removed from the flooding topology. Flooding for the neighbors is removed from the flooding topology. Flooding for
such Circuit Types or Flooding Scopes MUST continue on the link and such Circuit Types or Flooding Scopes MUST continue on the link and
be considered as temporarily enabled. be considered as temporarily enabled.
5.1.6. IS-IS LEEF Advertisement
In support of advertising which edges are currently enabled in the
flooding topology, an implementation MAY indicate that a link is part
of the flooding topology by advertising a bit value in the Link
Attributes sub-TLV defined by [RFC5029].
The following bit value is defined by this document:
Local Edge Enabled for Flooding (LEEF) - suggested value 4 (to be
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 LSAs and TLVs for both OSPFv2 and OSPFv3.
Following objects are added: Following objects are added:
1. A TLV that is used to advertise the preference for becoming Area 1. A TLV that is used to advertise the preference for becoming Area
Leader. 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. OSPFv2 Opaque LSA and OSPFv3 LSA to advertise the flooding 3. OSPFv2 Opaque LSA and OSPFv3 LSA to advertise the flooding
topology for centralized mode. topology for centralized mode.
4. A TLV to carry the list of system IDs that compromise the 4. A TLV to carry the list of Router IDs that comprise the flooding
flooding topology for the area. topology for the area.
5. A TLV to carry a path which is part of the flooding topology. 5. A TLV to carry a path which is part of the flooding topology.
6. The bit in the LLS Type 1 Extended Options and Flags requests 6. The bit in the LLS Type 1 Extended Options and Flags requests
flooding from the adjacent node. 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 IS-IS and
is described in Section 5.1.1. is described in Section 5.1.1.
skipping to change at page 20, line 24 skipping to change at page 22, line 5
| LS sequence number | | LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length | | LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- TLVs -+ +- TLVs -+
| ... | | ... |
OSPFv3 Dynamic Flooding LSA OSPFv3 Dynamic Flooding LSA
5.2.5. OSPF Area Router IDs TLV 5.2.5. OSPF Area Router ID TLVs
The OSPF Area Router IDs TLV is a top level TLV of the OSPFv2 Dynamic In OSPF new TLVs are introduced to advertise indeces associated with
Flooding Opaque LSA and OSPFv3 Dynamic Flooding LSA. nodes and Broadcast/NBMA networks. Due to identifier differences
between OSPFv2 and OSPFv3 two different TLVs are defined as decribed
in the following sub-sections.
The OSPF Area Router IDs TLV is 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.
Conceptually, the Area Leader creates a list of Router IDs for all This includes the identifiers associated with Broadcast/NBMA networks
routers in the area, assigning indices to each router, starting with as defined for Network LSAs. Conceptually, the Area Leader creates a
index 0. list of Router IDs for all routers in the area, assigning indices to
each router, starting with index 0.
Because the space in a single OSPF Area Router IDs TLV is limited, 5.2.5.1. OSPFv2 Area Router ID TLV
This TLV is a top level TLV of the OSPFv2 Dynamic Flooding Opaque
LSA.
Because the space in a single OSPFv2 Area Router IDs TLV is limited,
more than one TLV may be required to encode all of the Router IDs in more than one TLV may be required to encode all of the Router IDs in
the area. This TLV may also recur in multiple OSPFv2 Dynamic the area. This TLV may also occur in multiple OSPFv2 Dynamic
Flooding Opaque LSAs or OSPFv3 Dynamic Flooding LSA, so that all Flooding Opaque LSAs so that all Router IDs can be advertised.
Router IDs can be advertised.
Each entry in the OSPFv2 Area Router IDs TLV represents either a node
or a Broadcast/NBMA network identifier. An entry has the following
format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conn Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Router ID/DR Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
Conn Type - 1 byte
The following values are defined:
1 - Router
2 - Designated Router
Reserved - 3 bytes
MUST be transmitted as 0 and MUST be ignored on receipt
Originating Router ID/DR Address - 4 bytes
As indicated by the ID Type
OSPFv2 Router IDs TLV Entry
The format of the Area Router IDs TLV is: The format of the Area Router IDs TLV is:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+- Router IDs -+ +- OSPFv2 Router ID TLV Entry -+
| ... | | ... |
OSPF Area Router IDs TLV OSPFv2 Area Router IDs TLV
TLV Type: 1 TLV Type: 1
TLV Length: 4 + (Router ID length * (number of Router IDs)) TLV Length: 4 + (8 * the number TLV entries)
Starting index: The index of the first Router ID that appears in Starting index: The index of the first Router ID that appears in
this TLV. this TLV.
L (Last): This bit is set if the index of the last system ID that L (Last): This bit is set if the index of the last system 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
Rourer IDs for the area. Rourer IDs for the area.
Router IDs: A concatenated list of Router IDs for the area. OSPFv2 Router ID TLV Entries: A concatenated list of Router ID TLV
Entries for the area.
If there are multiple OSPF Area Router IDs TLVs with the L bit set If there are multiple OSPFv2 Area Router ID TLVs with the L bit set
advertised by the same router, the TLV which specifies the smaller
maximum index is used and the other TLV(s) with L bit set are
ignored. TLVs which specify Router IDs with indices greater than
that specified by the TLV with the L bit set are also ignored.
5.2.5.2. OSPFv3 Area Router ID TLV
This TLV is a top level TLV of the OSPFv3 Dynamic Flooding LSA.
Because the space in a single OSPFv3 Area Router ID TLV is limited,
more than one TLV may be required to encode all of the Router IDs in
the area. This TLV may also occur in multiple OSPFv3 Dynamic
Flooding Opaque LSAs so that all Router IDs can be advertised.
Each entry in the OSPFv3 Area Router IDs TLV represents either a
router or a Broadcast/NBMA network identifier. An entry has the
following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Conn Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Router ID (always present) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID (present for DRs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where
Conn Type - 1 byte
The following values are defined:
1 - Router
2 - Designated Router
Reserved - 3 bytes
MUST be transmitted as 0 and MUST be ignored on receipt
Originating Router ID - 4 bytes
Interface ID - 4 bytes
This field MUST be present when Conn Type indicates Designated
Router.
This field MUST NOT be present when Conn Type indicates Router.
OSPFv3 Router ID TLV Entry
The format of the OSPFv3Area Router IDs TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Starting Index |L| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- OSPFv3 Router ID TLV Entry -+
| ... |
OSPFv3 Area Router IDs TLV
TLV Type: 1
TLV Length: 4 + sum of the lengths of all TLV entries
Starting index: The index of the first Router ID that appears in
this TLV.
L (Last): This bit is set if the index of the last router ID that
appears in this TLV is equal to the last index in the full list of
Router IDs for the area.
OSPFv2 Router ID TLV Entries: A concatenated list of Router ID TLV
Entries for the area.
If there are multiple OSPFv3 Area Router ID TLVs with the L bit set
advertised by the same router, the TLV which specifies the smaller advertised by the same router, the TLV which specifies the smaller
maximum index is used and the other TLV(s) with L bit set are maximum index is used and the other TLV(s) with L bit set are
ignored. TLVs which specify Router IDs with indices greater than ignored. TLVs which specify Router IDs with indices greater than
that specified by the TLV with the L bit set are also ignored. that specified by the TLV with the L bit set are also ignored.
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.
skipping to change at page 23, line 15 skipping to change at page 28, line 6
no longer appears in the OSPF Hellos. no longer appears in the OSPF Hellos.
When the flooding is temporarily enabled on the link for any area due When the flooding is temporarily enabled on the link for any area due
to received FR-bit in OSPF LLS Extended Options and Flags TLV, the to received FR-bit in OSPF LLS Extended Options and Flags TLV, the
receiver MUST perform standard database synchronization for the receiver MUST perform standard database synchronization for the
corresponding area(s) on the link. If the adjacency is already in corresponding area(s) on the link. If the adjacency is already in
the FULL state, mechanism specified in [RFC4811] MUST be used for the FULL state, 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 an area, flooding MUST not be disabled in Options and Flags TLV for an area, flooding MUST NOT be disabled in
such area even if the connection between the neighbors is removed such area even if the connection between the neighbors is removed
from the flooding topology. Flooding for such area MUST continue on from the flooding topology. Flooding for such area MUST continue on
the link and be considered as temporarily enabled. the link and be considered as temporarily enabled.
5.2.8. OSPF LEEF Advertisement
In support of advertising which edges are currently enabled in the
flooding topology, an implementation MAY indicate that a link is part
of the flooding topology. The OSPF Link Attributes Bits TLV is
defined to support this advertisement.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Attribute Bits |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Additional Link Attribute Bits -+
| ... |
OSPF Link Attributes Bits TLV
Type: TBD and specific to OSPFv2 and OSPFv3
Length: size of the Link Attribute Bits in bytes. It MUST be a
multiple of 4 bytes.
The following bits are defined:
Bit #0: - Local Edge Enabled for Flooding (LEEF)
OSPF Link-attribute Bits TLV appears as:
1. a sub-TLV of the OSPFv2 Extended Link TLV [RFC7684]
2. a sub-TLV of the OSPFv3 Router-Link TLV [RFC8362]
6. Behavioral Specification 6. Behavioral Specification
In this section, we specify the detailed behaviors of the nodes In this section, we specify the detailed behaviors of the nodes
participating in the IGP. participating in the IGP.
6.1. Terminology 6.1. Terminology
We define some terminology here that is used in the following We define some terminology here that is used in the following
sections: sections:
skipping to change at page 25, line 15 skipping to change at page 30, line 41
Nodes that do not support the value of algorithm advertised by the Nodes that do not support the value of algorithm advertised by the
Area Leader MUST be considered as Dynamic Flooding incapable nodes by Area Leader MUST be considered as Dynamic Flooding incapable nodes by
the Area Leader. 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 have a common understanding of what the given algorithm the area have a common understanding of what the given algorithm
value represents. value represents.
6.6. Flooding Behavior 6.6. Use of LANs in the Flooding Topology
Use of LANs in the flooding topology differs depending on whether the
area is operating in Centralized or Distributed 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
flooding topology, all nodes connected to the LAN are assumed to be
using the LAN as part of the flooding topology. This assumption is
made to reduce the size of the Flooding Topology advertisement.
6.6.2. Use of LANs in Distributed Mode
In distributed mode, the flooding topology is NOT advertised,
therefore the space consumed to advertise it is not a concern. It is
therefore possible to assign only a subset of the nodes connected to
the LAN to use the LAN as part of the flooding topology. Doing so
may further optimize flooding by reducing the amount of redundant
flooding on a LAN. However, support of flooding only by a subset of
the nodes connected to a LAN requires some modest - but backwards
compatible - changes in the way flooding is performed on a LAN.
6.6.2.1. Partial flooding on a LAN in IS-IS
Designated Intermediate System (DIS) for a LAN MUST use standard
flooding behavior:
Non-DIS nodes whose connection to the LAN is included in the flooding
topology MUST use standard flooding behavior.
Non-DIS nodes whose connection to the LAN is NOT included in the
flooding topology behave as follows:
o Received CSNPs from the DIS are ignored
o PSNPs are NOT originated on the LAN
o LSPs received on the LAN which are newer than the corresponding
LSP present in the LSPDB are retained and flooded on all local
circuits which are part of the flooding topology (i.e., do not
discard newer LSPs simply because they were received on a LAN
which the receiving node is not using for flooding)
o LSPs received on the LAN which are older or same as the
corresponding LSP present in the LSPDB are silently discarded
o LSPs received on links other than the LAN are NOT flooded on the
LAN
NOTE: If any node connected to the LAN requests the enablement of
temporary flooding all nodes revert to standard flooding behavior.
6.6.2.2. Partial Flooding on a LAN in OSPF
Designated Router (DR) and Backup Designated Router (BDR) for LANs
MUST use standard flooding behavior.
Non-DR/BDR nodes whose connection to the LAN is included in the
flooding topology use standard flooding behavior.
Non-DR/BDR nodes whose connection to the LAN is NOT included in the
flooding topology behave as follows:
o LSAs received on the LAN are acknowledged to DR/BDR
o LSAs received on interfaces other than the LAN are NOT flooded on
the LAN
NOTE: If any node connected to the LAN requests the enablement of
temporary flooding all nodes revert to standard flooding behavior.
NOTE: The sending of LSA acks by nodes NOT using the LAN as part of
the flooding topology eliminates the need for changes on the part of
the DR/BDR - which might Include nodes which do not support the
flooding optimizations.
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 a 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 link(s) to the flooding topology temporarily, even though the
link(s) is not part of the calculated flooding topology. This is link(s) is not part of the calculated flooding topology. This is
termed "temporary flooding" and is discussed in Section 6.7.1. termed "temporary flooding" and is discussed in Section 6.8.1.
The flooding topology is calculated locally in the case of The flooding topology is calculated locally in the case of
distributed mode. In centralized mode the flooding topology is distributed mode. In centralized mode the flooding topology is
advertised in the area link state database. Received link state advertised in the area link state database. Received link state
updates, whether received on a link that is in the flooding topology updates, whether received on a link that is in the flooding topology
or on a link that is not in the flooding topology, MUST be flooded on or on a link that is not in the flooding topology, MUST be flooded on
all links that are in the flooding topology, except for the link on all links that are in the flooding topology, except for the link on
which the update was received. which the update was received.
In centralized mode, if multiple flooding topologies are present in In centralized mode, if multiple flooding topologies are present in
the area link state database, the node SHOULD flood on the on each of the area link state database, the node SHOULD flood on each of these
these topologies. topologies.
When the flooding topology changes on a node, either as a result of When the flooding topology changes on a node, either as a result of
the local computation in distributed mode or as a result of the the local computation in distributed mode or as a result of the
advertisement from the Area Leader in centralized mode, the node MUST advertisement from the Area Leader in centralized mode, the node MUST
continue to flood on both the old and new flooding topology for a continue to flood on both the old and new flooding topology for a
limited amount of time. This is required to provide all nodes limited amount of time. This is required to provide all nodes
sufficient time to migrate to the new flooding topology. sufficient time to migrate to the new flooding topology.
6.7. Treatment of Topology Events 6.8. Treatment of Topology Events
In this section, we explicitly consider a variety of different In this section, we explicitly consider a variety of different
topological events in the network and how Dynamic Flooding should topological events in the network and how Dynamic Flooding should
address them. address them.
6.7.1. Temporary Addition of Link to Flooding Topology 6.8.1. Temporary Addition of Link to Flooding Topology
In some cases a node that supports Dynamic Flooding may need to add a 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 link(s) to the flooding topology temporarily, even though the
link(s) is not part of the calculated flooding topology. We refer to link(s) is not part of the calculated flooding topology. We refer to
this as "temporary flooding" on the link. this 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 from both directions on such link. To achieve that, the be enabled from both directions on the link. To achieve that, the
following steps MUST be performed: following steps MUST be performed:
Link State Database needs to be re-synchronised on the link. This Link State Database needs to be re-synchronised on the link. This
is done using the standard protocol mechanisms. In the case of is done using the standard protocol mechanisms. In the case of
IS-IS, this results in setting SRM bit for all LSPs on the circuit IS-IS, this results in setting SRM bit for all LSPs on the circuit
and sending compete set of CSNPs on it. In OSPF, the mechanism and sending compete set of CSNPs on it. In OSPF, the mechanism
specified in [RFC4811] is used. specified in [RFC4811] is used.
Flooding is enabled locally on the link. Flooding is enabled locally on the link.
skipping to change at page 26, line 41 skipping to change at page 33, line 47
Adjacent node is connected to the current flooding topology. Adjacent node is connected to the current flooding topology.
Any change in the flooding topology MUST result in evaluation of the Any change in the flooding topology MUST result in evaluation of the
above conditions for any link on which the temporary flooding was above conditions for any link on which the 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.7.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 link state
advertisements for the nodes on either end of the link. These link advertisements for the nodes on either end of the link. These link
state updates will be flooded on the flooding topology. state updates will be flooded on the flooding topology.
In centralized mode, the Area Leader, upon receiving these updates, In centralized mode, the Area Leader, upon receiving these updates,
may choose to retain the existing flooding topology or may choose to may choose to retain the existing flooding topology or may choose to
modify the flooding topology. If it elects to change the flooding modify the flooding topology. 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 link state
skipping to change at page 27, line 27 skipping to change at page 34, line 33
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 has been part of the adjacency bring-up itself. because it has been 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. of these links.
6.7.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.7.2 applies. added to the topology. Section 6.8.2 applies.
6.7.4. Failures of Link Not on Flooding Topology A node which has a large number of neighbors is at risk for
introducing a local flooding storm if all neighbors are brought up at
once and temporary flooding is enabled on all links simultaneously.
The most robust way to address this is to limit the rate of initial
adjacency formation following bootup. This both reduces unnecessary
redundant flooding as part of initial database synchronization and
minimizes the need for temporary flooding as it allows time for the
new node to be added to the flooding topology after only a small
number of adjacencies have been formed.
In the event a node elects to bring up a large number of adjacencies
simultaneously, a significant amount of redundant flooding may be
introduced as multiple neighbors of the new node enable temporary
flooding to the new node which initially is not part of the flooding
topology.
6.8.4. Failures of Link Not on 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 link state advertisements and flood
them on the flooding topology. them on the flooding topology.
In centralized mode, the Area Leader, upon receiving these updates, In centralized mode, the Area Leader, upon receiving these updates,
may choose to retain the existing flooding topology or may choose to may choose to retain the existing flooding topology or may choose to
modify the flooding topology. If it elects to change the flooding modify the flooding topology. 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 link state
database and flood it using the new flooding topology. database and flood 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.7.5. Failures of Link On the Flooding Topology 6.8.5. Failures of Link 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 link state advertisements and flood them. If the
original flooding topology is bi-connected, the flooding topology original flooding topology is bi-connected, the flooding topology
should still be connected despite a single failure. should still be 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 link state advertisement(s) and
skipping to change at page 28, line 28 skipping to change at page 35, line 46
distributed (in the case of centralized mode). distributed (in the case of centralized 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.7.6. Node Deletion 6.8.6. Node Deletion
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. The two sections above apply. also removed from the topology. Section 6.8.4 and Section 6.8.5
apply.
6.7.7. Local Link Addition to the Flooding Topology 6.8.7. Local Link Addition to the Flooding Topology
If the new flooding topology is received in the case of centralized If the new flooding topology is received in the case of centralized
mode, or calculated locally in the case of distributed mode and the mode, or calculated locally in the case of distributed mode and the
local link on the node that was not part of the flooding topology has local link on the node that was not part of the flooding topology has
been added to the flooding topology, the node MUST: been added to the flooding topology, the node MUST:
Re-synchronize the Link State Database over the link. This is Re-synchronize the Link State Database over the link. This is
done using the standard protocol mechanisms. In the case of IS- done using the standard protocol mechanisms. In the case of IS-
IS, this results in setting SRM bit for all LSPs on the circuit IS, this results in setting SRM bit for all LSPs on the circuit
and sending a complete set of CSNPs. In OSPF, the mechanism and sending a complete set of CSNPs. In OSPF, the mechanism
specified in [RFC4811] is used. specified in [RFC4811] is used.
Make the link part of the flooding topology and start flooding Make the link part of the flooding topology and start flooding
over it over it
6.7.8. Local Link Deletion from the Flooding Topology 6.8.8. Local Link Deletion from the Flooding Topology
If the new flooding topology is received in the case of centralized If the new flooding topology is received in the case of centralized
mode, or calculated locally in the case of distributed mode and the mode, or calculated locally in the case of distributed mode and the
local link on the node that was part of the flooding topology has local link on the node that was part of the flooding topology has
been removed from the flooding topology, the node MUST remove the been removed from the flooding topology, the node MUST remove the
link from the flooding topology. 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 link state advertisement(s) and also keep receiving
link state updates from other nodes in the network before the new link state updates from other nodes in the network before the new
flooding topology is calculated and distributed (in the case of flooding topology is calculated and distributed (in the case of
centralized mode). centralized mode).
6.7.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 there are any adjacent nodes that are disconnected from the check if there are any adjacent nodes that are disconnected from the
current flooding topology. Temporary flooding MUST be enabled current flooding topology. Temporary flooding MUST be enabled
towards a subset of the disconnected nodes. towards a subset of the disconnected nodes.
6.7.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.
In the centralized mode, the new Area Leader will compute a new In the centralized mode, the new Area Leader will compute a new
flooding topology and flood it using the new flooding topology. flooding topology and flood it using the new flooding topology.
As an optimization, applicable to centralized mode, the new Area As an optimization, applicable to centralized mode, the new Area
Leader MAY compute a new flooding topology that has as much in common Leader MAY compute a new flooding topology that has 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 over-flooding.
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.7.11. Recovery from Multiple Failures 6.8.11. Recovery from Multiple Failures
In the unlikely event of multiple failures on the flooding topology, In the unlikely event of multiple failures on the flooding topology,
it may become partitioned. The nodes that remain active on the edges it may become partitioned. The nodes that remain active on the edges
of the flooding topology partitions will recognize this and will try of the flooding topology partitions will recognize this and will try
to repair the flooding topology locally by enabling temporary to 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 flooding topology until a new flooding topology becomes connected
again. again.
Nodes where local failure was detected update their own link state Nodes where local failure was detected update their own link state
skipping to change at page 30, line 31 skipping to change at page 37, line 45
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
effective. effective.
6.8.12. Rate Limiting Temporary Flooding
As discussed in the previous sections, there are events which require
the introduction of temporary flooding on edges which are not part of
the current flooding topology. This can occur regardless of whether
the area is operating in centralized mode or distributed mode.
Nodes which decide to enable temporary flooding also have to decide
whether to do so on a subset of the edges which are currently not
part of the flooding topology or on all the edges which are currently
not part of the flooding topology. Doing the former risks a longer
convergence time as it is possible that the initial set of edges
enabled does not fully repair the flooding topology. Doing the
latter risks introducing a flooding storm which destablizes the
network.
It is recommended that a node implement rate limiting on the number
of edges on which it chooses to enable temporary flooding. Initial
values for the number of edges to enable and the rate at which
additional edges may subsequently be enabled is left as an
implementation decision.
7. IANA Considerations 7. IANA Considerations
7.1. IS-IS 7.1. IS-IS
This document requests the following code point from the "sub-TLVs This document requests the following code points from the "sub-TLVs
for TLV 242" registry (IS-IS Router CAPABILITY TLV). for TLV 242" registry (IS-IS Router CAPABILITY TLV).
Type: TBD1 Type: TBD1
Description: IS-IS Area Leader Sub-TLV Description: IS-IS Area Leader Sub-TLV
Reference: This document (Section 5.1.1) Reference: This document (Section 5.1.1)
Type: TBD7 Type: TBD7
Description: IS-IS Dynamic Flooding Sub-TLV Description: IS-IS Dynamic Flooding Sub-TLV
Reference: This document (Section 5.1.2) Reference: This document (Section 5.1.2)
This document requests that IANA allocate and assign two code points This document requests that IANA allocate and assign code points from
from the "IS-IS TLV Codepoints" registry. One for each of the the "IS-IS TLV Codepoints" registry. One for each of the following
following TLVs: TLVs:
Type: TBD2 Type: TBD2
Description: IS-IS Area System IDs TLV Description: IS-IS Area System IDs TLV
Reference: This document (Section 5.1.3) Reference: This document (Section 5.1.3)
Type: TBD3 Type: TBD3
Description: IS-IS Flooding Path TLV Description: IS-IS Flooding Path TLV
skipping to change at page 31, line 14 skipping to change at page 39, line 4
Type: TBD2 Type: TBD2
Description: IS-IS Area System IDs TLV Description: IS-IS Area System IDs TLV
Reference: This document (Section 5.1.3) Reference: This document (Section 5.1.3)
Type: TBD3 Type: TBD3
Description: IS-IS Flooding Path TLV Description: IS-IS Flooding Path TLV
Reference: This document (Section 5.1.4) Reference: This document (Section 5.1.4)
Type: TBD9 Type: TBD9
Description: IS-IS Flooding Request TLV Description: IS-IS Flooding Request TLV
Reference: This document (Section 5.1.5) Reference: This document (Section 5.1.5)
This document requests that IANA allocate a new bit value from the
"link-attribute bit values for sub-TLV 19 of TLV 22" registry.
Local Edge Enabled for Flooding (LEEF) - suggested value 4 (to be
assigned by IANA)
7.2. OSPF 7.2. OSPF
This document requests the following code points from the "OSPF This document requests the following code points from the "OSPF
Router Information (RI) TLVs" registry: Router Information (RI) TLVs" registry:
Type: TBD4 Type: TBD4
Description: OSPF Area Leader Sub-TLV Description: OSPF Area Leader Sub-TLV
Reference: This document (Section 5.2.1) Reference: This document (Section 5.2.1)
skipping to change at page 32, line 17 skipping to change at page 40, line 14
This document requests a new bit in LLS Type 1 Extended Options and This document requests a new bit in LLS Type 1 Extended Options and
Flags registry: Flags registry:
Bit Position: TBD10 Bit Position: TBD10
Description: Flooding Request bit Description: Flooding Request bit
Reference: This document (Section 5.2.7) Reference: This document (Section 5.2.7)
This document requests the following code point from the "OSPFv2
Extended Link TLV Sub-TLVs" registry:
Type: TBD11
Description: OSPFv2 Link Attributes Bits Sub-TLV
Reference: This document (Section 5.2.8)
This document requests the following code point from the "OSPFv3
Extended LSA Sub-TLVs" registry:
Type: TBD12
Description: OSPFv3 Link Attributes Bits Sub-TLV
Reference: This document (Section 5.2.8)
7.2.1. OSPF Dynamic Flooding LSA TLVs Registry 7.2.1. OSPF Dynamic Flooding LSA TLVs Registry
This specification also requests one new registry - "OSPF Dynamic This specification also requests a new registry - "OSPF Dynamic
Flooding LSA TLVs". New values can be allocated via IETF Review or Flooding LSA TLVs". New values can be allocated via IETF Review or
IESG Approval IESG Approval
The "OSPF Dynamic Flooding LSA TLVs" registry will define top-level The "OSPF Dynamic Flooding LSA TLVs" registry will define top-level
TLVs for the OSPFv2 Dynamic Flooding Opaque LSA and OSPFv3 Dynamic TLVs for the OSPFv2 Dynamic Flooding Opaque LSA and OSPFv3 Dynamic
Flooding LSAs. It should be added to the "Open Shortest Path First Flooding LSAs. It should be added to the "Open Shortest Path First
(OSPF) Parameters" registries group. (OSPF) Parameters" registries group.
The following initial values are allocated: The following initial values are allocated:
skipping to change at page 33, line 10 skipping to change at page 41, line 22
Reference: This document (Section 5.2.6) Reference: This document (Section 5.2.6)
Types in the range 32768-33023 are for experimental use; these will Types in the range 32768-33023 are for experimental use; these will
not be registered with IANA, and MUST NOT be mentioned by RFCs. 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 not to be assigned at this time.
Before any assignments can be made in the 33024-65535 range, there Before any assignments can be made in the 33024-65535 range, there
MUST be an IETF specification that specifies IANA Considerations that MUST be an IETF specification that specifies IANA Considerations that
covers the range being assigned. covers the range being assigned.
7.2.2. OSPF Link Attributes Sub-TLV Bit Values Registry
This specification also requests a new registry - "OSPF Link
Attributes Sub-TLV Bit Values". New values can be allocated via IETF
Review or IESG Approval
The "OSPF Link Attributes Sub-TLV Bit Values" registry defines Link
Attribute bit values for the OSPFv2 Link Attributes Sub-TLV and
OSPFv3 Link Attributes Sub-TLV. It should be added to the "Open
Shortest Path First (OSPF) Parameters" registries group.
The following initial value is allocated:
Bit Number: 0
Description: Local Edge Enabled for Flooding(LEEF)
Reference: This document (Section 5.2.8)
7.3. IGP 7.3. IGP
IANA is requested to set up a registry called "IGP Algorithm Type For IANA is requested to set up a registry called "IGP Algorithm Type For
Computing Flooding Topology" under an existing "Interior Gateway Computing Flooding Topology" under an existing "Interior Gateway
Protocol (IGP) Parameters" IANA registries. Protocol (IGP) Parameters" IANA registries.
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:
skipping to change at page 34, line 11 skipping to change at page 42, line 42
The authors would like to thank Sarah Chen for her contribution to The authors would like to thank Sarah Chen for her contribution to
this work. this work.
The authors would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam The authors would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam
Sweeney and Olufemi Komolafe for their helpful comments. Sweeney and Olufemi Komolafe for their helpful comments.
The authors would like to thank Tom Edsall for initially introducing The authors would like to thank Tom Edsall for initially introducing
them to the problem. them to the problem.
Advertising Local Edges Enabled for Flooding (LEEF) is based on an
idea proposed in [I-D.cc-lsr-flooding-reduction]. We wish to thank
the authors of that draft - in particular Huaimo Chen.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ISO10589] [ISO10589]
International Organization for Standardization, International Organization for Standardization,
"Intermediate System to Intermediate System Intra-Domain "Intermediate System to Intermediate System Intra-Domain
Routing Exchange Protocol for use in Conjunction with the Routing Exchange Protocol for use in Conjunction with the
Protocol for Providing the Connectionless-mode Network Protocol for Providing the Connectionless-mode Network
Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002.
skipping to change at page 34, line 35 skipping to change at page 43, line 25
<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>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<https://www.rfc-editor.org/info/rfc4552>. <https://www.rfc-editor.org/info/rfc4552>.
[RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link
Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029,
September 2007, <https://www.rfc-editor.org/info/rfc5029>.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <https://www.rfc-editor.org/info/rfc5250>. July 2008, <https://www.rfc-editor.org/info/rfc5250>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>. 2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic and M. Fanto, "IS-IS Generic Cryptographic
skipping to change at page 35, line 24 skipping to change at page 44, line 19
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356, Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014, DOI 10.17487/RFC7356, September 2014,
<https://www.rfc-editor.org/info/rfc7356>. <https://www.rfc-editor.org/info/rfc7356>.
[RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed.,
"Security Extension for OSPFv2 When Using Manual Key "Security Extension for OSPFv2 When Using Manual Key
Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, Management", RFC 7474, DOI 10.17487/RFC7474, April 2015,
<https://www.rfc-editor.org/info/rfc7474>. <https://www.rfc-editor.org/info/rfc7474>.
[RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W.,
Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute
Advertisement", RFC 7684, DOI 10.17487/RFC7684, November
2015, <https://www.rfc-editor.org/info/rfc7684>.
[RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and
S. Shaffer, "Extensions to OSPF for Advertising Optional S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>. February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981, for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016, DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>. <https://www.rfc-editor.org/info/rfc7981>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8362] Lindem, A., Roy, A., Goethals, D., Reddy Vallem, V., and
F. Baker, "OSPFv3 Link State Advertisement (LSA)
Extensibility", RFC 8362, DOI 10.17487/RFC8362, April
2018, <https://www.rfc-editor.org/info/rfc8362>.
10.2. Informative References 10.2. Informative References
[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 Vol. 32(2), DOI
10.1002/j.1538-7305.1953.tb01433.x, March 1953, 10.1002/j.1538-7305.1953.tb01433.x, March 1953,
<http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>. <http://dx.doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
[I-D.cc-lsr-flooding-reduction]
Chen, H., Cheng, D., Toy, M., Yang, Y., Wang, A., Liu, X.,
Fan, Y., and L. Liu, "LS Distributed Flooding Reduction",
draft-cc-lsr-flooding-reduction-03 (work in progress),
March 2019.
[Leiserson] [Leiserson]
Leiserson, C., "Fat-Trees: Universal Networks for Leiserson, C., "Fat-Trees: Universal Networks for
Hardware-Efficient Supercomputing", IEEE Transactions on Hardware-Efficient Supercomputing", IEEE Transactions on
Computers 34(10):892-901, 1985. Computers 34(10):892-901, 1985.
[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
 End of changes. 81 change blocks. 
156 lines changed or deleted 565 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/