--- 1/draft-ietf-lsr-dynamic-flooding-00.txt 2019-05-21 11:14:40.421390130 -0700 +++ 2/draft-ietf-lsr-dynamic-flooding-01.txt 2019-05-21 11:14:40.509392356 -0700 @@ -1,28 +1,28 @@ Internet Engineering Task Force T. Li, Ed. Internet-Draft Arista Networks Intended status: Standards Track P. Psenak, Ed. -Expires: August 29, 2019 L. Ginsberg +Expires: November 22, 2019 L. Ginsberg Cisco Systems, Inc. T. Przygienda Juniper Networks, Inc. D. Cooper CenturyLink L. Jalil Verizon S. Dontula ATT - February 25, 2019 + May 21, 2019 Dynamic Flooding on Dense Graphs - draft-ietf-lsr-dynamic-flooding-00 + draft-ietf-lsr-dynamic-flooding-01 Abstract Routing with link state protocols in dense network topologies can result in sub-optimal convergence times due to the overhead associated with flooding. This can be addressed by decreasing the flooding topology so that it is less dense. This document discusses the problem in some depth and an architectural solution. Specific protocol changes for IS-IS, OSPFv2, @@ -36,97 +36,109 @@ 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3. Solution Requirements . . . . . . . . . . . . . . . . . . . . 5 - 4. Dynamic Flooding . . . . . . . . . . . . . . . . . . . . . . 5 + 4. Dynamic Flooding . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 - 4.2. Leader election . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Leader election . . . . . . . . . . . . . . . . . . . . . 8 4.3. Computing the Flooding Topology . . . . . . . . . . . . . 8 4.4. Topologies on Complete Bipartite Graphs . . . . . . . . . 9 4.4.1. A Minimal Flooding Topology . . . . . . . . . . . . . 9 - 4.4.2. Xia Topologies . . . . . . . . . . . . . . . . . . . 9 - 4.4.3. Optimization . . . . . . . . . . . . . . . . . . . . 10 + 4.4.2. Xia Topologies . . . . . . . . . . . . . . . . . . . 10 + 4.4.3. Optimization . . . . . . . . . . . . . . . . . . . . 11 4.5. Encoding the Flooding Topology . . . . . . . . . . . . . 11 - 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1. IS-IS TLVs . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1.1. IS-IS Area Leader Sub-TLV . . . . . . . . . . . . . . 11 - 5.1.2. IS-IS Dynamic Flooding Sub-TLV . . . . . . . . . . . 12 - 5.1.3. IS-IS Area System IDs TLV . . . . . . . . . . . . . . 13 - 5.1.4. IS-IS Flooding Path TLV . . . . . . . . . . . . . . . 14 - 5.1.5. IS-IS Flooding Request TLV . . . . . . . . . . . . . 15 - 5.2. OSPF LSAs and TLVs . . . . . . . . . . . . . . . . . . . 16 - 5.2.1. OSPF Area Leader Sub-TLV . . . . . . . . . . . . . . 17 - 5.2.2. OSPF Dynamic Flooding Sub-TLV . . . . . . . . . . . . 17 - 5.2.3. OSPFv2 Dynamic Flooding Opaque LSA . . . . . . . . . 18 - 5.2.4. OSPFv3 Dynamic Flooding LSA . . . . . . . . . . . . . 19 - 5.2.5. OSPF Area Router IDs TLV . . . . . . . . . . . . . . 20 - 5.2.6. OSPF Flooding Path TLV . . . . . . . . . . . . . . . 21 - 5.2.7. OSPF Flooding Request Bit . . . . . . . . . . . . . . 22 - 6. Behavioral Specification . . . . . . . . . . . . . . . . . . 23 - 6.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 23 - 6.2. Flooding Topology . . . . . . . . . . . . . . . . . . . . 23 - 6.3. Leader Election . . . . . . . . . . . . . . . . . . . . . 24 - 6.4. Area Leader Responsibilities . . . . . . . . . . . . . . 24 - 6.5. Distributed Flooding Topology Calculation . . . . . . . . 24 - 6.6. Flooding Behavior . . . . . . . . . . . . . . . . . . . . 25 - 6.7. Treatment of Topology Events . . . . . . . . . . . . . . 25 - 6.7.1. Temporary Addition of Link to Flooding Topology . . . 26 - 6.7.2. Local Link Addition . . . . . . . . . . . . . . . . . 26 - 6.7.3. Node Addition . . . . . . . . . . . . . . . . . . . . 27 - 6.7.4. Failures of Link Not on Flooding Topology . . . . . . 27 - 6.7.5. Failures of Link On the Flooding Topology . . . . . . 28 - 6.7.6. Node Deletion . . . . . . . . . . . . . . . . . . . . 28 - 6.7.7. Local Link Addition to the Flooding Topology . . . . 28 - 6.7.8. Local Link Deletion from the Flooding Topology . . . 29 - 6.7.9. Treatment of Disconnected Adjacent Nodes . . . . . . 29 - 6.7.10. Failure of the Area Leader . . . . . . . . . . . . . 29 - 6.7.11. Recovery from Multiple Failures . . . . . . . . . . . 30 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 - 7.1. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 7.2. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 31 - 7.2.1. OSPF Dynamic Flooding LSA TLVs Registry . . . . . . . 32 - 7.3. IGP . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 33 - 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 - 10.1. Normative References . . . . . . . . . . . . . . . . . . 34 - 10.2. Informative References . . . . . . . . . . . . . . . . . 35 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36 + 4.6. Advertising the Local Edges Enabled for Flooding . . . . 11 + 5. Protocol Elements . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1. IS-IS TLVs . . . . . . . . . . . . . . . . . . . . . . . 12 + 5.1.1. IS-IS Area Leader Sub-TLV . . . . . . . . . . . . . . 12 + 5.1.2. IS-IS Dynamic Flooding Sub-TLV . . . . . . . . . . . 13 + 5.1.3. IS-IS Area Node IDs TLV . . . . . . . . . . . . . . . 14 + 5.1.4. IS-IS Flooding Path TLV . . . . . . . . . . . . . . . 15 + 5.1.5. IS-IS Flooding Request TLV . . . . . . . . . . . . . 16 + 5.1.6. IS-IS LEEF Advertisement . . . . . . . . . . . . . . 18 + 5.2. OSPF LSAs and TLVs . . . . . . . . . . . . . . . . . . . 18 + 5.2.1. OSPF Area Leader Sub-TLV . . . . . . . . . . . . . . 18 + 5.2.2. OSPF Dynamic Flooding Sub-TLV . . . . . . . . . . . . 19 + 5.2.3. OSPFv2 Dynamic Flooding Opaque LSA . . . . . . . . . 19 + 5.2.4. OSPFv3 Dynamic Flooding LSA . . . . . . . . . . . . . 21 + 5.2.5. OSPF Area Router ID TLVs . . . . . . . . . . . . . . 22 + 5.2.5.1. OSPFv2 Area Router ID TLV . . . . . . . . . . . . 22 + 5.2.5.2. OSPFv3 Area Router ID TLV . . . . . . . . . . . . 24 + 5.2.6. OSPF Flooding Path TLV . . . . . . . . . . . . . . . 26 + 5.2.7. OSPF Flooding Request Bit . . . . . . . . . . . . . . 27 + 5.2.8. OSPF LEEF Advertisement . . . . . . . . . . . . . . . 28 + 6. Behavioral Specification . . . . . . . . . . . . . . . . . . 28 + 6.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 29 + 6.2. Flooding Topology . . . . . . . . . . . . . . . . . . . . 29 + 6.3. Leader Election . . . . . . . . . . . . . . . . . . . . . 29 + 6.4. Area Leader Responsibilities . . . . . . . . . . . . . . 30 + 6.5. Distributed Flooding Topology Calculation . . . . . . . . 30 + 6.6. Use of LANs in the Flooding Topology . . . . . . . . . . 30 + 6.6.1. Use of LANs in Centralized mode . . . . . . . . . . . 30 + 6.6.2. Use of LANs in Distributed Mode . . . . . . . . . . . 31 + 6.6.2.1. Partial flooding on a LAN in IS-IS . . . . . . . 31 + 6.6.2.2. Partial Flooding on a LAN in OSPF . . . . . . . . 31 + 6.7. Flooding Behavior . . . . . . . . . . . . . . . . . . . . 32 + 6.8. Treatment of Topology Events . . . . . . . . . . . . . . 33 + 6.8.1. Temporary Addition of Link to Flooding Topology . . . 33 + 6.8.2. Local Link Addition . . . . . . . . . . . . . . . . . 33 + 6.8.3. Node Addition . . . . . . . . . . . . . . . . . . . . 34 + 6.8.4. Failures of Link Not on Flooding Topology . . . . . . 35 + 6.8.5. Failures of Link On the Flooding Topology . . . . . . 35 + 6.8.6. Node Deletion . . . . . . . . . . . . . . . . . . . . 35 + 6.8.7. Local Link Addition to the Flooding Topology . . . . 36 + 6.8.8. Local Link Deletion from the Flooding Topology . . . 36 + 6.8.9. Treatment of Disconnected Adjacent Nodes . . . . . . 36 + 6.8.10. Failure of the Area Leader . . . . . . . . . . . . . 36 + 6.8.11. Recovery from Multiple Failures . . . . . . . . . . . 37 + 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 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 or leaf-spine), Clos [Clos], or Fat Tree [Leiserson] topology. Conventional Interior Gateway Protocols (IGPs, i.e., IS-IS [ISO10589], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) under-perform, redundantly flooding information throughout the dense topology, leading to overloaded control plane inputs and thereby creating @@ -272,21 +284,21 @@ IGP area and first flood on its flooding topology. The rationale behind this is straightforward: if there is a transient and there has been a recent change in Area Leader, then propagating topology information promptly along the most likely flooding topology should be the priority. During transients, it is possible that loops will form in the flooding topology. This is not problematic, as the legacy flooding rules would cause duplicate updates to be ignored. Similarly, during 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. 4.1. Applicability In a complete graph, this approach is appealing because it drastically decreases the flooding topology without the manual configuration of mesh groups. By controlling the diameter of the flooding topology, as well as the maximum degree node in the flooding topology, convergence time goals can be met and the stability of the control plane can be assured. @@ -474,23 +486,69 @@ 4.5. Encoding the Flooding Topology There are a variety of ways that the flooding topology could be encoded efficiently. If the topology was only a cycle, a simple list of the nodes in the topology would suffice. However, this is insufficiently flexible as it would require a slightly different encoding scheme as soon as a single additional link is added. Instead, we choose to encode the flooding topology as a set of 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 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.1. IS-IS TLVs 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 preference for becoming Area Leader. 2. A sub-TLV that an IS may inject into its LSP to indicate that it @@ -582,64 +640,65 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD7 Length: 0-255; number of Algorithms Algorithm: zero or more numeric identifiers in the range 0-255 that identifies the algorithm used to calculate the flooding 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 - system IDs that it has used in computing the flooding topology. - Conceptually, the Area Leader creates a list of system IDs for all - nodes in the area, assigning indices to each system, starting with - index 0. + The Area Node IDs TLV is used by the Area Leader to enumerate the + Node IDs (System ID + pseudo-node ID) that it has used in computing + the area flooding topology. Conceptually, the Area Leader creates a + list of node IDs for all nodes in the area (including pseudo-nodes + 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 - required to encode all of the system IDs in the area. This 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 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 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| Reserved | System IDs ... + |L| Reserved | Node IDs ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - System IDs continued .... + Node IDs continued .... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. - 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 - 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 maximum index is used and the other TLV(s) with L bit set are - ignored. TLVs which specify system IDs with indices greater than - that specified by the TLV with the L bit set are also ignored. + ignored. TLVs which specify node IDs with indices greater than that + specified by the TLV with the L bit set are also ignored. 5.1.4. IS-IS Flooding Path TLV IS-IS Flooding Path TLV is only used in centralized mode. 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. 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 indices: (I1, I2, I3, ...), denoting a link from the system with @@ -647,21 +706,21 @@ 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 the path may be distributed across multiple TLVs by the replication of a single system index. Complex topologies that are not a single path can be described using multiple TLVs. 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 of TLVs, this TLV can contain at most 126 system indices. The Flooding Path TLV has the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Starting Index | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ @@ -687,81 +746,103 @@ topology. Nodes that support Dynamic Flooding MAY include the Flooding Request TLV in its IIH PDUs. The Flooding Request TLV has the 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | Type | Length | Circuit Type |R| Scope | + | Type | Length | Levels |R| Scope | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |R| ... | -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: TBD9 - 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. Scope: Flooding Scope for which the flooding is requested as defined by LSP Flooding Scope Identifier Registry defined by [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 - 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 Flooding, then flooding MUST be temporarily enabled over the link for the specified Circuit Type(s) and Flooding Scope(s) received in the in the Flooding Request TLV. Flooding MUST be enabled until the Circuit Type or Flooding Scope is no longer advertised in the Flooding Request TLV or the TLV no longer appears in IIH PDUs received on the link. When the flooding is temporarily enabled on the link for any Circuit Type or Flooding Scope due to received Flooding Request TLV, the receiver MUST perform standard database synchronization for the 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 LSPs on the link and sending CSNPs. 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 the neighbors is removed from the flooding topology. Flooding for such Circuit Types or Flooding Scopes MUST continue on the link and 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 This section defines new LSAs and TLVs for both OSPFv2 and OSPFv3. Following objects are added: 1. A TLV that is used to advertise the preference for becoming Area Leader. 2. A TLV that is used to indicate the support for Dynamic Flooding and the algorithms that the advertising node supports for distributed mode, if any. 3. OSPFv2 Opaque LSA and OSPFv3 LSA to advertise the flooding topology for centralized mode. - 4. A TLV to carry the list of system IDs that compromise the - flooding topology for the area. + 4. A TLV to carry the list of Router IDs that comprise the flooding + topology for the area. 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 flooding from the adjacent node. 5.2.1. OSPF Area Leader Sub-TLV The usage of the OSPF Area Leader Sub-TLV is identical to IS-IS and is described in Section 5.1.1. @@ -900,66 +981,177 @@ | LS sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LS checksum | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +- TLVs -+ | ... | 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 - Flooding Opaque LSA and OSPFv3 Dynamic Flooding LSA. + In OSPF new TLVs are introduced to advertise indeces associated with + 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. - Conceptually, the Area Leader creates a list of Router IDs for all - routers in the area, assigning indices to each router, starting with - index 0. + This includes the identifiers associated with Broadcast/NBMA networks + as defined for Network LSAs. Conceptually, the Area Leader creates a + 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 - the area. This TLV may also recur in multiple OSPFv2 Dynamic - Flooding Opaque LSAs or OSPFv3 Dynamic Flooding LSA, so that all - Router IDs can be advertised. + the area. This TLV may also occur in multiple OSPFv2 Dynamic + Flooding Opaque LSAs so that all 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: 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | - +- Router IDs -+ + +- OSPFv2 Router ID TLV Entry -+ | ... | - OSPF Area Router IDs TLV + OSPFv2 Area Router IDs TLV 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 this TLV. 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 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 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.6. OSPF Flooding Path TLV The OSPF Flooding Path TLV is a top level TLV of the OSPFv2 Dynamic Flooding Opaque LSAs and OSPFv3 Dynamic Flooding LSA. @@ -1021,25 +1213,60 @@ no longer appears in the OSPF Hellos. 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 receiver MUST perform standard database synchronization for the corresponding area(s) on the link. If the adjacency is already in the FULL state, mechanism specified in [RFC4811] MUST be used for database resynchronization. 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 from the flooding topology. Flooding for such area MUST continue on 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 In this section, we specify the detailed behaviors of the nodes participating in the IGP. 6.1. Terminology We define some terminology here that is used in the following sections: @@ -1115,65 +1342,142 @@ Nodes that do not support the value of algorithm advertised by the Area Leader MUST be considered as Dynamic Flooding incapable nodes by the Area Leader. If the value of the algorithm advertised by the Area Leader is from the range 128-254 (private distributed algorithms), it is the responsibility of the network operator to guarantee that all nodes in the area have a common understanding of what the given algorithm 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 for flooding when possible, and MUST NOT revert to standard flooding when a valid flooding topology is available. 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 - 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 distributed mode. In centralized mode the flooding topology is advertised in the area link state database. Received link state 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 all links that are in the flooding topology, except for the link on which the update was received. In centralized mode, if multiple flooding topologies are present in - the area link state database, the node SHOULD flood on the on each of - these topologies. + the area link state database, the node SHOULD flood on each of these + topologies. 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 advertisement from the Area Leader in centralized mode, the node MUST continue to flood on both the old and new flooding topology for a limited amount of time. This is required to provide all nodes 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 topological events in the network and how Dynamic Flooding should 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 local link(s) to the flooding topology temporarily, even though the link(s) is not part of the calculated flooding topology. We refer to this as "temporary flooding" on the link. 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: Link State Database needs to be re-synchronised on the link. This 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 and sending compete set of CSNPs on it. In OSPF, the mechanism specified in [RFC4811] is used. Flooding is enabled locally on the link. @@ -1187,21 +1491,21 @@ Adjacent node is connected to the current flooding topology. Any change in the flooding topology MUST result in evaluation of the above conditions for any link on which the temporary flooding was enabled. Temporary flooding is stopped on the link when both adjacent nodes 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 normal adjacency on the link and update the appropriate link state advertisements for the nodes on either end of the link. These link state updates will be flooded on the flooding topology. In centralized mode, the Area Leader, upon receiving these updates, may choose to retain the existing flooding topology or may choose to modify the flooding topology. If it elects to change the flooding topology, it will update the flooding topology in the link state @@ -1222,44 +1526,60 @@ topology. Note that in this case there is no need to perform a database synchronization as part of the enablement of the temporary flooding, because it has been part of the adjacency bring-up itself. If multiple local links are added to the topology before the flooding topology is updated, temporary flooding MUST be enabled on a subset 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 - 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 adjacent nodes will update their link state advertisements and flood them on the flooding topology. In centralized mode, the Area Leader, upon receiving these updates, may choose to retain the existing flooding topology or may choose to modify the flooding topology. If it elects to change the flooding topology, it will update the flooding topology in the link state database and flood it using the new flooding topology. In distributed mode, any change in the topology, including the failure of the link that is not part of the flooding topology MUST trigger the flooding topology recalculation. This is done to ensure that all nodes converge to the same flooding topology, regardless of 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 will update their link state advertisements and flood them. If the original flooding topology is bi-connected, the flooding topology should still be connected despite a single failure. If the failed local link represented the only connection to the flooding topology on the node where the link failed, the node MUST enable temporary flooding on a subset of its local links. This allows the node to send its updated link state advertisement(s) and @@ -1268,88 +1588,89 @@ distributed (in the case of centralized mode). In centralized mode, the Area Leader will notice the change in the flooding topology, recompute the flooding topology, and flood it using the new flooding topology. In distributed mode, all nodes supporting dynamic flooding will notice the change in the topology and recompute the new flooding 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 - 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 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 been added to the flooding topology, the node MUST: Re-synchronize the Link State Database over the link. This 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 and sending a complete set of CSNPs. In OSPF, the mechanism specified in [RFC4811] is used. Make the link part of the flooding topology and start flooding 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 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 been removed from the flooding topology, the node MUST remove the link from the flooding topology. 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. If the removed local link represented the only connection to the flooding topology on the node, the node MUST enable temporary flooding on a subset of its local links. This allows the node to send its updated link state advertisement(s) and also keep receiving link state updates from other nodes in the network before the new flooding topology is calculated and distributed (in the case of 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 check if there are any adjacent nodes that are disconnected from the current flooding topology. Temporary flooding MUST be enabled 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 is no longer reachable. In this case, the Area Leader election process is repeated and a new Area Leader is elected. In the centralized mode, the new Area Leader will compute a new flooding topology and flood it using the new flooding topology. As an optimization, applicable to centralized mode, the new Area Leader MAY compute a new flooding topology that has as much in common as possible with the old flooding topology. This will minimize the risk of over-flooding. In the distributed mode, the new flooding topology will be calculated on all nodes that support the algorithm that is advertised by the new Area Leader. Nodes that do not support the algorithm advertised by the new Area Leader will no longer participate in Dynamic 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, it may become partitioned. The nodes that remain active on the edges of the flooding topology partitions will recognize this and will try to repair the flooding topology locally by enabling temporary flooding towards the nodes that they consider disconnected from the flooding topology until a new flooding topology becomes connected again. Nodes where local failure was detected update their own link state @@ -1361,42 +1682,64 @@ using the new flooding topology. In distributed mode, all nodes that actively participate in Dynamic Flooding will compute the new flooding topology. Note that this is very different from the area partition because there is still a connected network graph between the nodes in the area. The area may remain connected and forwarding may still be 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.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). 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 two code points - from the "IS-IS TLV Codepoints" registry. One for each of the - following TLVs: + This document requests that IANA allocate and assign code points from + the "IS-IS 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 Description: IS-IS Flooding Path TLV @@ -1393,29 +1736,34 @@ Type: TBD2 Description: IS-IS Area System IDs TLV Reference: This document (Section 5.1.3) Type: TBD3 Description: IS-IS Flooding Path TLV - Reference: This document (Section 5.1.4) Type: TBD9 Description: IS-IS Flooding Request TLV 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 This document requests the following code points from the "OSPF Router Information (RI) TLVs" registry: Type: TBD4 Description: OSPF Area Leader Sub-TLV Reference: This document (Section 5.2.1) @@ -1445,23 +1794,41 @@ This document requests a new bit in 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 + 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 - 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 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: @@ -1484,20 +1850,39 @@ Reference: This document (Section 5.2.6) Types in the range 32768-33023 are for experimental use; 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. Before any assignments can be made in the 33024-65535 range, there MUST be an IETF specification that specifies IANA Considerations that 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 IANA is requested to set up a registry called "IGP Algorithm Type For Computing Flooding Topology" under an existing "Interior Gateway Protocol (IGP) Parameters" IANA registries. Values in this registry come from the range 0-255. The initial values in the IGP Algorithm Type For Computing Flooding Topology registry are: @@ -1532,20 +1917,24 @@ The authors would like to thank Sarah Chen for her contribution to this work. The authors would like to thank Zeqing (Fred) Xia, Naiming Shen, Adam Sweeney 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 in [I-D.cc-lsr-flooding-reduction]. We wish to thank + the authors of that draft - in particular Huaimo Chen. + 10. References 10.1. Normative References [ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System Intra-Domain Routing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. @@ -1556,20 +1945,24 @@ . [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, . + [RFC5029] Vasseur, JP. and S. Previdi, "Definition of an IS-IS Link + Attribute Sub-TLV", RFC 5029, DOI 10.17487/RFC5029, + September 2007, . + [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250, July 2008, . [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic Authentication", RFC 5304, DOI 10.17487/RFC5304, October 2008, . [RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R., and M. Fanto, "IS-IS Generic Cryptographic @@ -1592,42 +1985,58 @@ [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding Scope Link State PDUs (LSPs)", RFC 7356, DOI 10.17487/RFC7356, September 2014, . [RFC7474] Bhatia, M., Hartman, S., Zhang, D., and A. Lindem, Ed., "Security Extension for OSPFv2 When Using Manual Key Management", RFC 7474, DOI 10.17487/RFC7474, April 2015, . + [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, . + [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, . [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions for Advertising Router Information", RFC 7981, DOI 10.17487/RFC7981, October 2016, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . + [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, . + 10.2. Informative References [Clos] Clos, C., "A Study of Non-Blocking Switching Networks", The Bell System Technical Journal Vol. 32(2), DOI 10.1002/j.1538-7305.1953.tb01433.x, March 1953, . + [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, C., "Fat-Trees: Universal Networks for Hardware-Efficient Supercomputing", IEEE Transactions on Computers 34(10):892-901, 1985. [RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups", RFC 2973, DOI 10.17487/RFC2973, October 2000, . [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering