RFC 9667
Dynamic Flooding on Dense Graphs
RFC 9667 🎀 Dynamic Flooding on Dense Graphs
Okay bestie, let's look at the title block first, because it has all the good stuff 💅
- Publisher: Internet Engineering Task Force (IETF) 🌸
- Number: Request for Comments 9667
- Category: Experimental 🧪
- ISSN: 2070-1721
- Date: October 2024 📅
- Authors: T. Li, Ed. (Juniper Networks) 💜, P. Psenak, Ed. (Cisco Systems, Inc.) 💜, H. Chen (Futurewei) ✨, L. Jalil (Verizon) 🌈, and S. Dontula (AT&T) 🦋
- Obsoletes / Updates: none listed in this title block 🙈
Abstract ✨
So here's the tea ☕ Routing with link-state protocols in dense network topologies can converge slowly, because all the flooding creates so much overhead 😩 The usual fix is to make the flooding topology less dense, so there are fewer paths carrying the same updates.
This document goes deep on the problem and proposes an architectural solution 🧠 It also describes the specific protocol changes for IS-IS, OSPFv2, and OSPFv3 💖
Status of This Memo 📝
Heads up, this one is not an Internet Standards Track specification 🙅♀️ It's published so people can examine it, implement it experimentally, and evaluate it.
This document defines an Experimental Protocol for the Internet community 🧪 It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community 🫶 It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved document is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you're curious about that ✨
For the current status, any errata, and how to send feedback, head to https://www.rfc-editor.org/info/rfc9667 🔗
Copyright Notice 💜
Copyright (c) 2024 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. Please read those carefully, because they spell out your rights and restrictions for this document 📜 Code Components pulled out of this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ⚖️
Table of Contents 📚
1. Introduction
1.1. Requirements Language
2. Problem Statement
3. Solution Requirements
4. Dynamic Flooding
4.1. Applicability
4.2. Leader Election
4.3. Computing the Flooding Topology
4.4. Topologies on Complete Bipartite Graphs
4.4.1. A Minimal Flooding Topology
4.4.2. Xia Topologies
4.4.3. Optimization
4.5. Encoding the Flooding Topology
4.6. Advertising the Local Edges Enabled for Flooding
5. Protocol Elements
5.1. IS-IS TLVs
5.1.1. IS-IS Area Leader Sub-TLV
5.1.2. IS-IS Dynamic Flooding Sub-TLV
5.1.3. IS-IS Area Node IDs TLV
5.1.4. IS-IS Flooding Path TLV
5.1.5. IS-IS Flooding Request TLV
5.1.6. IS-IS LEEF Advertisement
5.2. OSPF LSAs and TLVs
5.2.1. OSPF Area Leader Sub-TLV
5.2.2. OSPF Dynamic Flooding Sub-TLV
5.2.3. OSPFv2 Dynamic Flooding Opaque LSA
5.2.4. OSPFv3 Dynamic Flooding LSA
5.2.5. OSPF Area Router ID TLVs
5.2.5.1. OSPFv2 Area Router ID TLV
5.2.5.2. OSPFv3 Area Router ID TLV
5.2.6. OSPF Flooding Path TLV
5.2.7. OSPF Flooding Request Bit
5.2.8. OSPF LEEF Advertisement
6. Behavioral Specification
6.1. Terminology
6.2. Flooding Topology
6.3. Leader Election
6.4. Area Leader Responsibilities
6.5. Distributed Flooding Topology Calculation
6.6. Use of LANs in the Flooding Topology
6.6.1. Use of LANs in Centralized Mode
6.6.2. Use of LANs in Distributed Mode
6.6.2.1. Partial Flooding on a LAN in IS-IS
6.6.2.2. Partial Flooding on a LAN in OSPF
6.7. Flooding Behavior
6.8. Treatment of Topology Events
6.8.1. Temporary Addition of Links to the Flooding Topology
6.8.2. Local Link Addition
6.8.3. Node Addition
6.8.4. Failures of Links Not on the Flooding Topology
6.8.5. Failures of Links On the Flooding Topology
6.8.6. Node Deletion
6.8.7. Local Link Addition to the Flooding Topology
6.8.8. Local Link Deletion from the Flooding Topology
6.8.9. Treatment of Disconnected Adjacent Nodes
6.8.10. Failure of the Area Leader
6.8.11. Recovery from Multiple Failures
6.8.12. Rate-Limiting Temporary Flooding
7. IANA Considerations
7.1. IS-IS
7.2. OSPF
7.2.1. OSPF Dynamic Flooding LSA TLVs Registry
7.2.2. OSPF Link Attributes Sub-TLV Bit Values Registry
7.3. IGP
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Authors' Addresses1. Introduction ✨
Lately everyone's been obsessed with routing in networks shaped like a bipartite graph (also called spine-leaf or leaf-spine), a Clos [Clos] network, or a Fat-tree [Leiserson] topology 🌈 The conventional Interior Gateway Protocols (IGPs; i.e., IS-IS [ISO10589], OSPFv2 [RFC2328], and OSPFv3 [RFC5340]) struggle here 😭 They flood information redundantly all over the dense topology, which overloads the control plane inputs and causes real operational problems 💀 So network architects have been getting creative. For example, they run BGP in the data center [RFC7938]. Some architects think using an Exterior Gateway Protocol (EGP) as an IGP is suboptimal, maybe only because the configuration is such a hassle 🙄
The main thing that shows up when conventional IGPs get used here is how slowly the network reacts to topology changes 🐢 Normal link-state protocols use a flooding algorithm to spread state around an area. In a dense topology, that flooding is super redundant and creates a ton of unnecessary overhead 💅 Every node gets each link state update several times. All those extra copies get thrown away in the end, but only after they've already reached the control plane and been processed 🤦♀️ That's a problem because important LSDB (Link State Database) updates can get stuck in line behind a pile of duplicate copies of some other update. Convergence drags because the LSDB can't settle down quickly 🫠
In the real world, the packet queues leading to the control plane are finite. So if flooding outpaces update processing for long enough, the control plane has no choice but to drop incoming updates 😬 If those lost updates matter, the LSDB stabilizes even later and the network converges even slower 📉
This isn't a brand-new problem, bestie 🙃 Back when routing protocols ran on networks where the underlying topology was a complete graph, they had similar issues. That was more common when the link-layer fabric gave the network layer a full mesh of virtual connections. It got addressed by shrinking the flooding topology with IS-IS Mesh Groups [RFC2973], but that approach needs careful configuration of the flooding topology 🎀
So the root problem isn't limited to massively scalable data centers. It shows up in any dense topology at scale 🌍
Link-state routing protocols were designed when links were very expensive and topologies were sparse, so it shouldn't shock anyone that those same designs don't fit a dense topology perfectly 🙈 Technology has moved on: links are now cheap and common. That's a total flip in the economics of network engineering 🤯 The original designs deserve credit for still working correctly this long, and it's totally expected that they'd need optimizing for today's environment 🫶
1.1. Requirements Language 📖
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 🔑
These words may also show up in lowercase in this document as plain English words, without their normative meanings 💖
2. Problem Statement 🧩
In a dense topology, the flooding algorithm at the heart of conventional link-state routing protocols causes a huge amount of redundant messaging 😩 Scale makes it worse. The protocol can survive that combo, but all the redundant messaging is unnecessary overhead, and it slows convergence 🐌 So the problem is how to provide routing in dense, scalable topologies while still converging rapidly ⚡
3. Solution Requirements 🎯
A solution to this problem must meet the following requirements 💅
- Requirement 1: Provide a dynamic routing solution. Reachability must be restored after any topology change 🔄
- Requirement 2: Provide a significant improvement in convergence 🚀
- Requirement 3: The solution should address a variety of dense topologies 🌸 Just handling a complete bipartite topology such as
K5,8is insufficient (see [Bondy]). Multi-stage Clos topologies must also be addressed, along with topologies that are slight variants. Addressing complete graphs is a good demonstration of generality 👑 - Requirement 4: There must be no single point of failure. The loss of any link or node should not unduly hinder convergence 🛡️
- Requirement 5: The workload for flooding should be evenly distributed. A hot spot, where one node has an extreme workload, would be a performance limitation and a vulnerability for resiliency 🫧
- Requirement 6: Dense topologies are subgraphs of much larger topologies 🌐 Operational efficiency requires that the dense subgraph not operate in a radically different manner than the rest of the topology. Some operational differences are permissible, but they should be minimized. Any change to any node outside of the dense subgraph is not acceptable 🚫 These situations come up when massively scaled data centers are part of a larger wide-area network. Having a second protocol running just on this subgraph would add a lot more complexity at the edge of the subgraph, where the two protocols would have to interoperate 🥺
4. Dynamic Flooding ✨
okay so bestie, here's the big idea 💖 Running flooding on a super dense topology is kinda inefficient if you're trying to scale. BUT if you decouple the flooding topology from the physical topology and shrink it down to a much smaller slice of it, you get efficient flooding AND you keep the resilience that existing protocols already have 🦋 A node that supports flooding on that decoupled flooding topology is said to support dynamic flooding.
With dynamic flooding, the flooding topology gets computed inside an IGP area that has the dense topology. It can be done centrally on an elected node called the Area Leader, or in a distributed way on all the nodes that support dynamic flooding 🧚 If it's computed centrally, it gets encoded into the normal LSDB and distributed as part of it, and that's the centralized mode of operation. If it's computed in a distributed fashion, that's the distributed mode of operation. Nodes in an area like this would only flood on the flooding topology. On links outside of it, the normal database synchronization mechanisms still apply, meaning OSPF database exchange and IS-IS Complete Sequence Number PDUs (CSNPs), but flooding may not 🙈 The detailed behavior of the nodes participating in IGP is described in Section 6. New link-state information that shows up from outside the flooding topology is a hint that the sender either has no flooding topology information or is working off old info about it. In those cases, the new link-state information should also get flooded on the flooding topology 💅
The flooding topology covers the full set of nodes in the area, but it skips some of the links that standard flooding would use. Iconic, right? 👑
Since the flooding topology gets computed before topology changes happen, the effort to compute it doesn't count toward convergence time, and it can be done while the topology is stable ✨ With centralized mode, how fast the computation runs and how fast it gets distributed isn't a big deal.
Graph theory defines the "degree" of a node as the number of edges attached to it. To keep the flooding workload scalable and spread out, there should be no nodes in the flooding topology with a way higher degree than everyone else 💜
If a node doesn't have any flooding topology information when new link-state information arrives, it should flood using the standard flooding rules. This happens when the dense topology is first set up, but it's unlikely to happen again 🌸
Link-state protocols are intentionally asynchronous, with nodes acting on their own. While flooding is happening, different nodes can have different information, and that creates transient conditions that can temporarily lead to suboptimal forwarding 😭 These periods are known as "transients."
When centralized mode is in use and there are multiple flooding topologies being advertised during a transient, nodes should flood link-state updates on all of those flooding topologies. Each node should also locally evaluate the election of the Area Leader for the IGP area and first flood on its own flooding topology 🫶 The logic is pretty simple: if there's a transient and the Area Leader changed recently, then getting topology info out quickly along the most likely flooding topology should be the top priority.
During transients, loops can form in the flooding topology. That's not a problem, because the standard flooding rules make duplicate updates get ignored 🎀 Similarly, during transients the flooding topology can become disconnected. Section 6.8.11 talks about how those conditions get handled 🌈
4.1. Applicability
In a complete graph, this approach is so appealing because it drastically shrinks the flooding topology without needing manual configuration of mesh groups 🍓 By controlling the diameter of the flooding topology, as well as the maximum node degree in it, convergence time goals can be met, and the stability of the control plane can be assured 💅
It's also amazing in a massively scaled data center, where there are lots of chances for redundant flooding. Here, this mechanism guarantees that flooding is redundant, with each leaf and spine well connected. It also makes sure no update takes too many hops and that no single node carries an undue share of the flooding work 👑
In a network where only some of the nodes support dynamic flooding, the remaining nodes just keep doing standard flooding. This doesn't hurt correctness, because no node can become isolated ✨
Flooding started by nodes that support dynamic flooding stays inside the flooding topology until it reaches a legacy node, and then standard flooding picks back up 🦋 Standard flooding gets bounded by the nodes that support dynamic flooding, which can help limit the spread of unnecessary flooding. Whether the network can stay stable in this situation really depends on how many nodes support dynamic flooding and where they sit 🧚
During incremental deployment of dynamic flooding, an area will have one or more sets of connected nodes that support dynamic flooding, plus one or more sets of connected nodes that don't, meaning nodes that support only standard flooding. The flooding topology is the union of these sets of nodes. Every set of nodes that doesn't support dynamic flooding needs to be part of the flooding topology, and such a set can provide connectivity between two or more sets of nodes that do support dynamic flooding 🌸
4.2. Leader Election
A single node within the dense topology is elected as an Area Leader 💖
A generalization of the mechanisms used in existing Designated Router (OSPF) or Designated Intermediate-System (IS-IS) elections is used for leader election. The elected node is known as the Area Leader 🎀
In centralized mode, the Area Leader is in charge of computing and distributing the flooding topology. When a new Area Leader gets elected and has distributed new flooding topology information, then any prior Area Leaders should withdraw any of their flooding topology information from their LSDB entries 😭
In distributed mode, the distributed algorithm advertised by the Area Leader MUST be used by all nodes that participate in dynamic flooding. No exceptions, bestie 💅
Not every node has to be a candidate to become the Area Leader within an area, because a single candidate is enough for correct operation. However, for redundancy, it is strongly RECOMMENDED that there be multiple candidates 🫶
4.3. Computing the Flooding Topology
There's a ton of flexibility in how the flooding topology can be computed 🌈 For resilience, it needs to at least contain a cycle of all nodes in the dense subgraph. Extra links can be added to decrease convergence time, though. The trade-off between how dense the flooding topology is and how fast convergence happens is a matter for further study 🧚 The exact algorithm for computing the flooding topology in centralized mode doesn't need to be standardized, since it's not an interoperability issue. Only the encoding of the resulting topology needs to be documented 💜 In distributed mode, all nodes in the IGP area need to use the same algorithm to compute the flooding topology. Private algorithms are allowed for this, as long as every node in the IGP area uses the same one ✨
The flooding topology should be a covering cycle, but it doesn't have to be a Hamiltonian cycle where each node appears only once. In fact, in lots of relevant topologies that won't be possible (for example, K5,8). Honestly that's fortunate, because computing a Hamiltonian cycle is known to be NP-complete 🙈
A simple algorithm for computing the topology of a complete bipartite graph is to keep selecting unvisited nodes on each side of the graph until both sides are completely visited. If the number of nodes on each side is unequal, then revisiting nodes on the less populated side is inevitable 🍓 This algorithm can run in O(N) time, so it's super efficient 🦋
A simple cycle is good enough for correctness and resiliency, but it may not be optimal for convergence. At scale, a cycle can have a diameter that's half the number of nodes in the graph, and that could cause an undue delay in link-state update propagation 😭 So it may be useful to put a bound on the diameter of the flooding topology. Adding more links to the flooding topology would reduce the diameter, but it comes with the trade-off of possibly adding redundant messaging. The optimal trade-off between convergence time and graph diameter is for further study 🌸
Similarly, if extra redundancy is added to the flooding topology, certain nodes in that topology might end up with a very high degree. That could overload the control plane of those nodes and lead to poor convergence 💀 So it may be preferable to have an upper bound on the degree of nodes in the flooding topology. Again, the optimal trade-off between graph diameter, node degree, convergence time, and topology computation time is for further study 💜
If the leader chooses to include a multi-access broadcast LAN segment as part of the flooding topology, then all of the adjacencies in that LAN segment should be included too. Once updates are flooded onto the LAN, every attached node will receive them 🫶
4.4. Topologies on Complete Bipartite Graphs
Complete bipartite graph topologies have become really popular for data center applications, and they're commonly called leaf-spine or spine-leaf topologies 🌈 This section covers some flooding topologies that are of particular interest in these networks 🎀
4.4.1. A Minimal Flooding Topology
A minimal flooding topology on a complete bipartite graph is one where the topology is connected and each node has at least degree two. This matters because it guarantees the flooding topology has no single point of failure 💖
In practice, this means every leaf node in the flooding topology has a degree of two. There are usually more leaves than spines, so the spines end up with a higher degree, but the load on the individual spines can be spread out evenly 🧚
This type of flooding topology is also a big deal because it scales well. As the number of leaves grows, it's possible to construct flooding topologies that perform well. Specifically, for N spines and M leaves, if the following holds, then there is a flooding topology that has a diameter of 4 👑
M >= N(N/2-1)4.4.2. Xia Topologies ✨
okay so a Xia topology is a complete bipartite graph thing 🦋 where all the spine nodes end up biconnected through leaves that have degree two, but the rest of the leaves are degree one and get spread out evenly across the spines 💅
how you actually build one is kinda iconic 😭 you go through the spines one by one, and each spine hooks up to the next spine using any leaf that's still unused. every leaf is wired to every spine, so every leaf already touches both the first and the second spine, which means you can grab any leaf and it's totally fine, no loss of generality 🫶 keep doing that across all the spines, picking a fresh leaf each time, and boom, you get a path that links every spine together 🌈 then you add one more leaf between the last spine and the first one and now you've got a cycle of N spines and N leaves 🔥
at this point there are M-N leaves just sitting there unconnected 🥺 those get spread evenly across the remaining spines and each one gets a single link 💖
the Xia topology is basically a trade-off ngl 🎀 you get lower flooding amplification, but you pay with more risk and worse performance. the diameter gets bigger too: for M spines, the diameter is M + 2 ✨
now the risk part 💀 some leaves only have one connection, so if something fails convergence might get delayed. BUT there are backup moves! 🦋 if a leaf sees that its single link on the flooding topology died, it can do a database synchronization check with a different spine to make up for it 🙈 same deal if a leaf notices that its connected spine on the flooding topology has failed. both of these checks exist so that any delays in link-state propagation caused by the flooding topology breaking into pieces get smoothed out 🫶
and the good news? the flooding load is super predictable 💜 each node in the spine cycle never gets an update more than twice. for M leaves and N spines, a spine never transmits more than (M/N +1) updates 👑
4.4.3. Optimization 🌸
okay so if two nodes are adjacent in the flooding topology and there's a bunch of parallel links between them, then any given update MUST be flooded over only one of those links 💅 which specific link gets picked is totally up to the implementation 🎀
4.5. Encoding the Flooding Topology 🧚
there are a bunch of ways you could encode the flooding topology efficiently 🍓 if the topology was only a cycle, a simple list of the nodes would do the job ✨ but that's not flexible enough, because the moment you add even one extra link you'd need a different encoding scheme 😭 so this document goes with encoding the flooding topology as a set of intersecting paths, where each path is a set of connected links 💖
advertising the flooding topology includes support for multi-access broadcast LANs 🌈 when a LAN is part of the flooding topology, all the edges between the LAN and the nodes connected to it are assumed to be part of the flooding topology 💅 to keep the advertisement small, explicitly advertising those edges is optional 🦋 heads up though, this can lead to "hidden nodes" or "stealth nodes" 👀, which are part of the flooding topology but never get explicitly mentioned in the advertisements. you can find them by looking through the LSDB, where the connectivity between a LAN and its nodes is fully specified 🫶
while all nodes MUST be part of the advertised flooding topology, not all multi-access LANs need to be included 🚨 only the LANs that are actually part of the flooding topology need to show up in the advertised flooding topology ✨
other encodings are totally possible 💜 this document just tried to find a useful balance between simplicity, generality, and space 👑
4.6. Advertising the Local Edges Enabled for Flooding 💅
okay this part is important bestie 😭 all nodes that take part in the flooding topology MUST choose local links for flooding that are part of the calculated flooding topology 🔥 if they don't, you could get an unexpected partition of the flooding topology and/or worse flooding reduction 💀 to help debug things when dynamic flooding is running, this document defines a way to advertise the Local Edges Enabled for Flooding (LEEF) 🦋 the protocol-specific encodings are in Sections 5.1.6 and 5.2.8 🌸
here are the guidelines:
- advertising LEEF is optional 🎀
- the flooding topology is defined in terms of edges (pairs of nodes), not links, so the advertisement SHOULD indicate that all such links are enabled when there are parallel adjacencies to the same neighbor 🫶
- 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 deciding which links to temporarily add to the flooding topology when the flooding topology is temporarily partitioned 💀
5. Protocol Elements 🎀
5.1. IS-IS TLVs 🦋
the following TLVs and sub-TLVs get added to IS-IS 🌈
- a sub-TLV an IS may include in its Link State PDU (LSP) to show its preference for becoming the Area Leader 👑
- a sub-TLV an IS may include in its LSP to say it supports dynamic flooding, plus the algorithms it supports for distributed mode, if any 💖
- a TLV that advertises the list of system IDs making up the flooding topology for the area 🧚 a system ID is just an identifier for a node 🫶
- a TLV that advertises a path that's part of the flooding topology 🌸
- a TLV that requests flooding from the adjacent node 💅
5.1.1. IS-IS Area Leader Sub-TLV 👑
the IS-IS Area Leader Sub-TLV lets a system do three things ✨
- indicate its eligibility and priority for becoming the Area Leader 🦋
- indicate whether centralized or distributed mode is used to compute the flooding topology in the area 🎀
- indicate the algorithm identifier for the algorithm used to compute the flooding topology in distributed mode 🫶
Intermediate Systems (nodes) that are NOT advertising this sub-TLV are not eligible to become the Area Leader 🙅♀️
the Area Leader is the node with the numerically highest Area Leader priority in the area 👑 if there's a tie, the node with the numerically highest system ID wins 💅 during database flooding, different nodes might not agree on who the Area Leader is 🌀 that's not a big deal though, because subsequent flooding will get the whole area to converge 🌈
the IS-IS Area Leader Sub-TLV is advertised as a sub-TLV of the IS-IS Router Capability TLV (242) [RFC7981] and looks like this 👇
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 | Priority | Algorithm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 1: IS-IS Area Leader Sub-TLV 🖼️
- Type: 27 🔢
- Length: 2 octets 📏
- Priority: 0-255, unsigned integer 💯 figuring out the priority is outside the scope of this document 🤷♀️
- Algorithm: a numeric identifier in the range 0-255 that identifies the algorithm used to calculate the flooding topology 🧮 these values are defined:
- 0: centralized computation by the Area Leader 👑
- 1-127: standardized distributed algorithms ✨
- 128-254: private distributed algorithms 🔒 individual values get assigned according to the "Private Use" policy in Section 4.1 of [RFC8126] (see Section 7.3) 🎀
- 255: Reserved 🚫
5.1.2. IS-IS Dynamic Flooding Sub-TLV 🌸
the IS-IS Dynamic Flooding Sub-TLV lets a system do two things 💖
- indicate that it supports dynamic flooding, which is shown by advertising this sub-TLV 🦋
- indicate the set of algorithms it supports 🫶
in incremental deployments, knowing which nodes support dynamic flooding can be used to optimize the flooding topology 🌈 in distributed mode, knowing each node's capabilities lets the Area Leader pick the optimal algorithm 👑
the IS-IS Dynamic Flooding Sub-TLV is advertised as a sub-TLV of the IS-IS Router Capability TLV (242) [RFC7981] and looks like this 💅
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 | Algorithm... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2: IS-IS Dynamic Flooding Sub-TLV 🖼️
- Type: 28 🔢
- Length: 1-255 octets; number of Algorithms 📏
- Algorithm: numeric identifiers in the range 0-255 that identify the algorithm used to calculate the flooding topology, as described in Section 5.1.1 🧮
5.1.3. IS-IS Area Node IDs TLV 🧚
the IS-IS Area Node IDs TLV is ONLY used in centralized mode 💅
the Area Leader uses this TLV to list the node IDs (System ID + pseudonode ID) it used when computing the area flooding topology 🫶 conceptually, the Area Leader makes a list of node IDs for all nodes in the area (including pseudonodes for all LANs in the topology) and gives each one an index, starting at index 0 🌸 indices are assigned sequentially: the first node's index is the Starting Index, and each following node's index is the previous one plus 1 ✨
the space in a single TLV is limited, so more than one TLV might be needed to encode all the node IDs in the area 🌈 this TLV may show up in multiple LSPs 💖
the IS-IS Area Node IDs TLV looks like this 👇
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 | Node IDs ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Node IDs continued ....
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3: IS-IS Area Node IDs TLV 🖼️
- Type: 17 🔢
- Length: 3 + ((System ID Length + 1) * (number of node IDs)) in octets 📏
- Starting Index: the index of the first node ID that appears in this TLV 🎯
- L (Last): this bit is set if the index of the last node ID that appears in this TLV is equal to the last index in the full list of node IDs for the area 🏁
- Node IDs: a concatenated list of node IDs for the area 🧾
if multiple IS-IS Area Node IDs TLVs with the L bit set are advertised by the same node, the TLV that specifies the smaller maximum index is used, and the other TLVs with the L bit set are ignored 🙈 TLVs that specify node IDs with indices greater than the one specified by the TLV with the L bit set are also ignored 🚫
5.1.4. IS-IS Flooding Path TLV 🛤️
Okay so the IS-IS Flooding Path TLV is only used in centralized mode 🧚, so distributed mode doesn't touch it at all.
This TLV is how we describe a path through the flooding topology, and the goal is an efficient way to encode the links ✨. A single link is the simplest possible path since it only covers two nodes 💅. A connected path gets written as a list of indices (I1, I2, I3, ...), which means a link from system 1 to system 2, then a link from system 2 to system 3, and so on, bestie 🦋
If a path is too long for one TLV, you can split it across multiple TLVs by repeating a single system index 🧩. And if the topology isn't just one path? No problem, use multiple TLVs 🌈
The TLV holds system indices that point at the systems advertised through the IS-IS Area Node IDs TLV. You need at least 2 indices in there 🫶. Because of the TLV length limit, it can hold 126 system indices at most 💀
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Index 2 | Additional indices ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4: IS-IS Flooding Path TLV
Here's the breakdown:
- Type:
18 - Length:
2 * (number of indices in the path), in octets - Starting Index: the index of the first system in the path
- Index 2: the index of the next system in the path
- Additional indices (optional): a sequence of extra indices for the systems along the path
5.1.5. IS-IS Flooding Request TLV 🙋
The IS-IS Flooding Request TLV lets a system ask an adjacent node to turn on flooding towards it over a specific link. This comes in handy when that connection isn't part of the existing flooding topology 🤝
A node that supports dynamic flooding MAY include the IS-IS Flooding Request TLV in its IS-IS Hello (IIH) Protocol Data Units (PDUs) 💜
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 | Levels | Scope |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5: IS-IS Flooding Request TLV
Here's the rundown on each field:
- Type:
19 - Length:
1 + number of advertised flooding scopesin octets - Levels: the levels that flooding is requested for. These are encoded as the circuit type, as specified in IS-IS [ISO10589]
- Scope (8 bits): the flooding scope being requested, as defined in the LSP Flooding Scope Identifier Registry created by [RFC7356]. Including flooding scopes is optional and only needed if [RFC7356] is supported. Multiple flooding scopes MAY be included. Values are restricted to the range
0..127
Circuit flooding scope MUST NOT be sent in the Flooding Request TLV, and MUST be ignored if received 🙅♀️
When this TLV shows up in a level-specific LAN-Hello PDU (L1-LAN-IIH or L2-LAN-IIH), only the levels that match the PDU type are valid. Levels that don't match the PDU type MUST be ignored on receipt 💅
When the TLV arrives in a Point-to-Point Hello (P2P-IIH), only the levels supported by the established adjacency are valid. Levels that the adjacency doesn't support MUST be ignored on receipt ✨
If flooding was disabled on the received link because of dynamic flooding, then flooding MUST be temporarily enabled over that link for the Circuit Types and flooding scopes in the IS-IS Flooding Request TLV. Flooding MUST stay enabled until the Circuit Type or Flooding Scope is no longer advertised in the TLV, or until the TLV no longer appears in IIH PDUs received on the link 🔥
When flooding gets temporarily enabled on the link for any Circuit Type or Flooding Scope because of this TLV, the receiver MUST perform standard database synchronization for the matching Circuit Types and flooding scopes on the link. For IS-IS, that means setting the Send Routeing Message (SRM) flag for all related LSPs on the link and sending CSNPs 🧠
So long as the IS-IS Flooding Request TLV keeps being received, flooding MUST NOT be disabled for any of the Circuit Types or flooding scopes in it, even if the connection between the neighbors gets removed from the flooding topology. Flooding for those Circuit Types or flooding scopes MUST continue on the link and be considered temporarily enabled 👑
5.1.6. IS-IS LEEF Advertisement 🦋
To advertise which edges are currently enabled in the flooding topology, an implementation MAY indicate that a link is part of the flooding topology. It does this by setting a bit value in the Link Attributes sub-TLV defined by [RFC5029] ✨
This document defines the following bit value:
- Local Edge Enabled for Flooding (LEEF):
0x4
5.2. OSPF LSAs and TLVs 🌸
This section defines new Link State Advertisements (LSAs) and TLVs for both OSPFv2 and OSPFv3 💖
The following LSAs and TLVs/sub-TLVs get added to OSPFv2/OSPFv3:
- A TLV that is used to advertise the preference for becoming the Area Leader.
- 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.
- An OSPFv2 Opaque LSA and OSPFv3 LSA to advertise the flooding topology for centralized mode.
- A TLV to advertise the list of Router IDs that comprise the flooding topology for the area.
- A TLV to advertise a path that is part of the flooding topology.
- A bit in the Link-Local Signaling (LLS) Type 1 Extended Options and Flags that requests flooding from the adjacent node.
5.2.1. OSPF Area Leader Sub-TLV 👑
The OSPF Area Leader Sub-TLV works exactly like the IS-IS Area Leader Sub-TLV described in Section 5.1.1 🤝
It's used by both OSPFv2 and OSPFv3. It gets advertised as a top-level TLV of the Router Information (RI) LSA defined in [RFC7770], and it looks like this:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Priority | Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 6: OSPF Area Leader Sub-TLV
- Type:
17 - Length: 4 octets
- Priority:
0-255, unsigned integer - Algorithm: as defined in Section 5.1.1
5.2.2. OSPF Dynamic Flooding Sub-TLV ✨
The OSPF Dynamic Flooding Sub-TLV is used exactly the same way as the IS-IS Dynamic Flooding Sub-TLV described in Section 5.1.2 💅
It's used by both OSPFv2 and OSPFv3, and it's advertised as a top-level TLV of the RI LSA defined in [RFC7770]. Here's the layout:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm ... | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 7: OSPF Dynamic Flooding Sub-TLV
- Type:
18 - Length: Number of Algorithms in octets
- Algorithm: As defined in Section 5.1.1
5.2.3. OSPFv2 Dynamic Flooding Opaque LSA 🔥
The OSPFv2 Dynamic Flooding Opaque LSA is only used in centralized mode 🧚
It's how you advertise extra dynamic flooding data in OSPFv2 🫶 OSPFv2 Opaque LSAs are described in [RFC5250]. An OSPFv2 router can advertise multiple OSPFv2 Dynamic Flooding Opaque LSAs, and their flooding scope is area-local 🌈
The format looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 10 | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |Figure 8: OSPFv2 Dynamic Flooding Opaque LSA
The opaque type used by the OSPFv2 Dynamic Flooding Opaque LSA is 10. The opaque type is what tells the different OSPFv2 Opaque LSA types apart, as described in Section 3 of [RFC5250]. The LS Type is also 10. The LSA Length field [RFC2328] is the total length in octets of the Opaque LSA, including the LSA header and all TLVs (padding included) 📏
The Opaque ID is an arbitrary value used to keep multiple Dynamic Flooding Opaque LSAs apart. For OSPFv2 Dynamic Flooding Opaque LSAs, the Opaque ID has no semantic significance beyond telling apart the Dynamic Flooding Opaque LSAs that come from the same OSPFv2 router 🦋
The TLVs in the body of the OSPFv2 Dynamic Flooding Opaque LSA use the same format as the Traffic Engineering Extensions to OSPF [RFC3630] 💜
The Length field tells you the length of the value portion in octets, so a TLV with no value portion has a length of 0 octets. Each TLV is padded to a 4-octet alignment, but the padding is NOT counted in the length field. For example, a 3-octet value has a length of 3 octets, but the total size of the TLV is 8 octets. Nested TLVs are also 32-bit aligned 🙈 So a 1-octet value has its length field set to 1, and 3 octets of padding get added to the end of the value portion. The padding is made of zeros 🫶
5.2.4. OSPFv3 Dynamic Flooding LSA ✨
Okay so the OSPFv3 Dynamic Flooding Opaque LSA is only used in centralized mode 🌸
The OSPFv3 Dynamic Flooding LSA is how OSPFv3 advertises extra dynamic flooding data, and it's giving main character energy 💅 It has a function code of 16 🔥 Its flooding scope is area-local, and the U bit gets set so it's still flooded even when a router doesn't understand it 🫶 The Link State ID (LSID) for this LSA is the Instance ID. OSPFv3 routers MAY advertise multiple OSPFv3 Dynamic Flooding Opaque LSAs in each area. Iconic 🦋
Here's the layout:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age |1|0|1| 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |Figure 9: OSPFv3 Dynamic Flooding LSA
5.2.5. OSPF Area Router ID TLVs 🌈
Okay bestie, OSPF has TLVs that advertise indices tied to nodes and Broadcast / Non-Broadcast Multi-Access (NBMA) networks 🧚 Because OSPFv2 and OSPFv3 use different identifiers, there are two separate TLVs, covered in the sub-sections below.
The OSPF Area Router ID TLVs are how the Area Leader lists the Router IDs it used when it computed the flooding topology. That includes the identifiers for Broadcast/NBMA networks, as defined for Network LSAs. Conceptually, the Area Leader makes a list of Router IDs for every router in the area and gives each one an index, starting at index 0 🍓 The indices are assigned in order. The first node's index is the Starting Index, and each node after that gets the previous node's index + 1 ✨
5.2.5.1. OSPFv2 Area Router ID TLV 💖
This TLV is a top-level TLV of the OSPFv2 Dynamic Flooding Opaque LSA.
OSPFv2 opaque LSAs don't have a ton of space, so one LSA might not be enough to fit every Router ID in the area 😭 This TLV MAY be advertised in multiple OSPFv2 Dynamic Flooding Opaque LSAs so that all of the Router IDs can get out there.
The OSPFv2 Area Router IDs TLV looks like this:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- OSPFv2 Router ID TLV Entry -+
| ... |Figure 10: OSPFv2 Area Router IDs TLV
Type: 1
Length: 4 + sum of the lengths of all TLV entries in octets
Starting Index: The index of the first Router/Designated Router ID that appears in this TLV.
L (Last): This bit is set if the index of the last Router/Designated Router ID 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 the same router advertises multiple OSPFv2 Area Router ID TLVs with the L bit set, the TLV with the smaller maximum index wins, and the other TLVs with the L bit set get ignored. TLVs that specify Router IDs with indices bigger than the ones in the TLV with the L bit set also get ignored 🙈
Each entry in the OSPFv2 Area Router IDs TLV stands for either a node or a Broadcast/NBMA network identifier. Each entry looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | Number of IDs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Originating Router ID/DR Address -+
| ... |Figure 11: OSPFv2 Router IDs TLV Entry
ID Type: 1 octet. The following values are defined:
- 1: Router
- 2: Designated Router
Number of IDs: 2 octets
Reserved: 1 octet. MUST be transmitted as 0 and MUST be ignored on receipt.
Originating Router ID/DR Address: (4 * Number of IDs) octets, as indicated by the ID Type.
5.2.5.2. OSPFv3 Area Router ID TLV 🦋
This TLV is a top-level TLV of the OSPFv3 Dynamic Flooding LSA.
Same story as before: the OSPFv3 Dynamic Flooding LSA doesn't have much room, so more than one LSA might be needed to hold all the Router IDs in the area. This TLV MAY be advertised in multiple OSPFv3 Dynamic Flooding Opaque LSAs so that every Router ID can be advertised.
The OSPFv3 Area Router IDs TLV looks like this:
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 -+
| ... |Figure 12: OSPFv3 Area Router IDs TLV
Type: 1
Length: 4 + sum of the lengths of all TLV entries in octets
Starting Index: The index of the first Router/Designated Router ID that appears in this TLV.
L (Last): This bit is set if the index of the last Router/Designated Router ID in this TLV is equal to the last index in the full list of Router IDs for the area.
OSPFv3 Router ID TLV Entries: A concatenated list of Router ID TLV Entries for the area.
If the same router advertises multiple OSPFv3 Area Router ID TLVs with the L bit set, the TLV that specifies the smaller maximum index wins, and the other TLVs with the L bit set get ignored. TLVs that specify Router IDs with indices bigger than the ones in the TLV with the L bit set also get ignored 💅
Each entry in the OSPFv3 Area Router IDs TLV stands for either a router or a Broadcast/NBMA network identifier. Each entry looks like this:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ID Type | Number of IDs | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Originating ID Entry -+
| ... |Figure 13: OSPFv3 Router ID TLV Entry
ID Type: 1 octet. The following values are defined:
- 1: Router
- 2: Designated Router
Number of IDs: 2 octets
Reserved: 1 octet. MUST be transmitted as 0 and MUST be ignored on receipt.
The Originating ID Entry takes one of two forms, depending on the ID Type 🧚
For a Router:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The length of the Originating ID Entry is (4 * Number of IDs) octets.
For a Designated Router:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Originating Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+The length of the Originating ID Entry is (8 * Number of IDs) octets.
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 the OSPFv3 Dynamic Flooding LSA.
It works exactly the same way as the IS-IS Flooding Path TLV described in Section 5.1.4 🫶
The OSPF Flooding Path TLV holds a list of Router ID indices, relative to the Router IDs advertised through the OSPF Area Router IDs TLV. At least 2 indices must be included in the TLV.
You can advertise several OSPF Flooding Path TLVs in one OSPFv2 Dynamic Flooding Opaque LSA or OSPFv3 Dynamic Flooding LSA. If they can't all fit in a single LSA, they can also be spread across multiple OSPFv2 Dynamic Flooding Opaque LSAs or OSPFv3 Dynamic Flooding LSAs 🌸
The OSPF Flooding Path TLV looks like this:
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 | Index 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Additional Indices -+
| ... |Figure 14: OSPF Flooding Path TLV
Type: 2
Length: 2 * (number of indices in the path) in octets
Starting Index: The index of the first Router ID in the path.
Index 2: The index of the next Router ID in the path.
Additional indices (optional): A sequence of additional indices to Router IDs along the path.
5.2.7. OSPF Flooding Request Bit 🙋♀️
Okay so there's exactly one new option bit here, the Flooding Request (FR) bit, and it lives in the LLS Type 1 Extended Options and Flags field [RFC5613] 💅. Its whole purpose is letting a router ask an adjacent node to switch on flooding toward it over a specific link. That's super clutch when the connection to that neighbour isn't part of the current flooding topology 🦋.
A node that supports dynamic flooding MAY include the FR bit in its OSPF LLS Extended Options and Flags TLV ✨.
If the FR bit is signaled for a link where flooding got switched off because of dynamic flooding, then flooding MUST be temporarily enabled over that link 🔥. And it stays on MUST-style until the FR bit stops showing up in the OSPF LLS Extended Options and Flags TLV, or until that TLV disappears from the OSPF Hellos entirely 🫶.
When flooding gets temporarily enabled on a link for any area because the receiver saw the FR bit in the OSPF LLS Extended Options and Flags TLV, the receiver MUST perform standard database synchronization for the area that matches the link 🌸. If the adjacency is already in the FULL state, the mechanism specified in [RFC4811] MUST be used for database resynchronization. Bestie, that's the rule, no skipping it 💀.
So long as the FR bit is being received in the OSPF LLS Extended Options and Flags TLV for a link, flooding MUST NOT be disabled on that link. That's true even if the connection between the neighbours gets removed from the flooding topology. Flooding MUST continue on the link and be considered as temporarily enabled 👑.
5.2.8. OSPF LEEF Advertisement 🦋
To advertise 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 -+
| ... |
Figure 15: OSPF Link Attributes Bits TLV- Type:
21(for OSPFv2) or10(for OSPFv3) 🧚 - Length: Size of the Link Attribute Bits in octets. It MUST be a multiple of 4 octets 🎀.
The following bits are defined:
- Bit #0: Local Edge Enabled for Flooding (LEEF) ✨
The OSPF Link-attribute Bits TLV appears as:
- A sub-TLV of the OSPFv2 Extended Link TLV [RFC7684].
- A sub-TLV of the OSPFv3 Router-Link TLV [RFC8362].
6. Behavioral Specification 🧠
This section specifies the detailed behavior of the nodes participating in the IGP. It's the rulebook for everyone running the IGP, so pay attention 🍓.
6.1. Terminology 📖
Some terminology to be used in the following sections:
Reachable: A node is considered reachable if it is part of the connected network graph. Note that this is independent of any constraints that may be considered when performing IGP shortest-path tree calculation, e.g., link metrics, overload bit state, etc. The two-way connectivity check MUST be performed before including an edge in the connected network graph 🔍.
Connected: A node is connected to the flooding topology if it has at least one local link, which is part of the flooding topology 🔗.
Disconnected: A node is disconnected from the flooding topology when it is not connected to the flooding topology 💔.
Current flooding topology: The latest version of the flooding topology that has been received (in the case of centralized mode) or calculated locally (in the case of distributed mode) 📍.
6.2. Flooding Topology 🗺️
The flooding topology MUST include all reachable nodes in the area 💖.
If a node's reachability changes, the flooding topology MUST be recalculated. In centralized mode, the Area Leader MUST advertise a new flooding topology 📣.
If a node becomes disconnected from the current flooding topology but is still reachable, then a new flooding topology MUST be calculated. In centralized mode, the Area Leader MUST advertise the new flooding topology 🙃.
The flooding topology SHOULD be biconnected to provide network resiliency, but this does incur some amount of redundant flooding. Xia topologies (Section 4.4.2) are an example of an explicit decision to sacrifice resiliency to avoid redundancy 🤷♀️.
6.3. Leader Election 👑
Any capable node MAY advertise its eligibility to become the Area Leader 🙋.
Nodes that are not reachable are not eligible to become the Area Leader. Nodes that do not advertise their eligibility to become the Area Leader are not eligible. Amongst the eligible nodes, the node with the numerically highest priority is the Area Leader. If multiple nodes all have the highest priority, then the node with the numerically highest system identifier (in the case of IS-IS) or Router ID (in the case of OSPFv2 and OSPFv3) is the Area Leader 🏆.
6.4. Area Leader Responsibilities 💼
If the Area Leader operates in centralized mode, it MUST advertise algorithm 0 in its Area Leader Sub-TLV. For dynamic flooding to be enabled, it also MUST compute and advertise a flooding topology for the area. The Area Leader may update the flooding topology at any time. However, it should not destabilize the network with undue or overly frequent topology changes 🥺. If the Area Leader operates in centralized mode and needs to advertise a new flooding topology, it floods the new flooding topology on both the new and old flooding topologies 🌈.
If the Area Leader operates in distributed mode, it MUST advertise a nonzero algorithm in its Area Leader Sub-TLV 🧮.
When the Area Leader advertises algorithm 0 in its Area Leader Sub-TLV and does not advertise a flooding topology, dynamic flooding is disabled for the area. Note this applies whether the Area Leader intends to operate in centralized mode or distributed mode 🛑.
Note that once dynamic flooding is enabled, disabling it risks destabilizing the network due to the issues discussed in Section 1. Be careful with that switch 🚨.
6.5. Distributed Flooding Topology Calculation 🧮
If the Area Leader advertises a nonzero algorithm in its Area Leader Sub-TLV, all nodes in the area that support dynamic flooding and support the algorithm advertised by the Area Leader MUST compute the flooding topology based on the Area Leader's advertised algorithm ✨.
Nodes that do not support the advertised algorithm MUST continue to use standard IS-IS/OSPF flooding mechanisms. Nodes that do not support the flooding 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 agree on the dynamic flooding algorithm corresponding to the advertised value 🔐.
6.6. Use of LANs in the Flooding Topology 🌐
The use of LANs in the flooding topology differs depending on whether the area is operating in centralized mode 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; thus, the space consumed to advertise it is not a concern. Therefore, it is 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 by a subset of the nodes connected to a LAN requires some modest but backward-compatible changes in the way flooding is performed on a LAN 💅.
6.6.2.1. Partial Flooding on a LAN in IS-IS 🐟
The Designated Intermediate System (DIS) for a LAN MUST use the standard flooding behavior 🦾.
Non-DIS nodes whose connection to the LAN is included in the flooding topology MUST use the standard flooding behavior 🌷.
Non-DIS nodes whose connection to the LAN is NOT included in the flooding topology behave as follows:
- Received CSNPs from the DIS are ignored.
- Partial Sequence Number PDUs (PSNPs) are NOT originated on the LAN.
- An LSP that is received on the LAN and is newer than the corresponding LSP present in the Link State PDU Database (LSPDB) is retained and flooded on all local circuits that are part of the flooding topology (i.e., do not discard newer LSPs simply because they were received on a LAN that the receiving node is not using for flooding) 🧠.
- An LSP received on the LAN that is older or the same as the corresponding LSP in the LSPDB is silently discarded.
- 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 MUST revert to the standard flooding behavior on the LAN 🚦.
6.6.2.2. Partial Flooding on a LAN in OSPF 🦋
The Designated Router (DR) and Backup Designated Router (BDR) for LANs MUST use the standard flooding behavior 💪.
Non-DR/BDR nodes with a connection to a LAN that is included in the flooding topology use the standard flooding behavior on that LAN 🌸.
Non-DR/BDR nodes with a connection to a LAN that is NOT included in the flooding topology behave as follows:
- LSAs received on the LAN are acknowledged to the DR/BDR.
- 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 the standard flooding behavior 🚨.
NOTE: The sending of LSA Acknowledgements 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 that do not support the dynamic flooding algorithm. That's a whole vibe: fewer changes for the DR/BDR, even for the nodes that don't support the algorithm ✨🫶.
6.7. Flooding Behavior ✨
okay bestie, the big rule here: nodes that support dynamic flooding MUST use the flooding topology for flooding whenever it's possible, and they MUST NOT go back to standard flooding when a valid flooding topology is available. 💅 no cap, it's not optional.
sometimes a node might need to temporarily add local links to the flooding topology, even though those links aren't in the calculated one. that's called "temporary flooding" and we'll get into it in Section 6.8.1 🦋
in distributed mode, the flooding topology is calculated locally. in centralized mode, it's advertised in the area LSDB 🌸 and any received link-state update MUST be flooded on all links in the flooding topology except the one it came in on. it doesn't matter whether that update came in on a flooding-topology link or on a link that isn't part of it. 🔥
in centralized mode, new info (new paths or new node ID assignments) can show up at any time 👀 it might replace some or all of what a node already knows about the flooding topology. there can be transient moments where a node's info is inconsistent or incomplete. if a node notices its info doesn't add up, it may wait for an implementation-specific amount of time so more info can arrive and give it a consistent, complete view 🧚
in both centralized and distributed mode, if a node decides some adjacencies should join the flooding topology, it should add them and start flooding on them right away ⭐ if adjacencies should leave the flooding topology, it should wait an implementation-specific amount of time before acting on that. this keeps new info flooding promptly and completely, so every node gets updates in a timely way 💖
6.8. Treatment of Topology Events 🗺️
this section is the "what happens when..." chapter. it looks at a bunch of different topology events and how dynamic flooding handles each one 🌈
6.8.1. Temporary Addition of Links to the Flooding Topology 🎀
when temporary flooding is turned on for a link, flooding needs to be enabled in both directions. to make that happen, the following steps MUST be performed:
- The LSDB needs to be resynchronised on the link. This is done using the standard protocol mechanisms. For IS-IS, that means setting the SRM bit for all LSPs on the circuit and sending a complete set of CSNPs on the link. For OSPF, the mechanism specified in [RFC4811] is used.
- Flooding is enabled locally on the link.
- Flooding is requested from the neighbor using the mechanism specified in Sections 5.1.5 or 5.2.7.
the request for temporary flooding MUST be withdrawn on the link once all of these conditions are met:
- The node itself is connected to the current flooding topology.
- The adjacent node is connected to the current flooding topology.
any change in the flooding topology MUST result in an evaluation of those conditions for any link where temporary flooding was enabled 🔍 and temporary flooding stops on the link when both adjacent nodes stop requesting it on that link 🫶
6.8.2. Local Link Addition 🌟
if a local link gets added to the topology, the protocol forms a normal adjacency on it and updates the appropriate LSAs for the nodes on either end. those link state updates get flooded over the flooding topology 📣
in centralized mode, the Area Leader can choose to keep the existing flooding topology or change it after getting these updates. if it decides to change things, it updates the flooding topology in the LSDB and floods it using the new flooding topology 👑
in distributed mode, any change in the topology, link addition included, MUST trigger a flooding topology recalculation 🔁 that's how everyone ends up converging on the same flooding topology, no matter when they did the math ✨
temporary flooding MUST be enabled on the newly added local link as long as at least one of these conditions is met:
- The node the local link was added on is not connected to the current flooding topology.
- The new adjacent node is not connected to the current flooding topology.
in this case there's no need for a database synchronization as part of turning on temporary flooding, because that already happened when the adjacency came up 🙈
if multiple local links get added before the flooding topology is updated, temporary flooding MUST be enabled on a subset of those links, following the conditions discussed in Section 6.8.12 💅
6.8.3. Node Addition 🧚♀️
if a node gets added to the topology, then at least one link is added too, so Section 6.8.2 applies 💖
a node with a LOT of neighbors can cause a local flooding storm if all of them come up at once and temporary flooding gets enabled on every link simultaneously 😭 the most robust fix is to limit how fast initial adjacencies form after bootup. that cuts down on redundant flooding during the initial database sync, and it means there's less need for temporary flooding, since the new node has time to join the flooding topology after only a few adjacencies form 🍓
if a node does bring up a big pile of adjacencies at the same time anyway, a lot of redundant flooding can happen. multiple neighbors of the new node enable temporary flooding toward it, even though it isn't part of the flooding topology yet 🌊
6.8.4. Failures of Links Not on the Flooding Topology 💀
if a link that isn't part of the flooding topology fails, the adjacent nodes update their LSAs and flood them over the flooding topology 📨
in centralized mode, the Area Leader can keep the existing flooding topology or change it after seeing these updates. if it changes it, it updates the flooding topology in the LSDB and floods it using the new flooding topology 🌸
in distributed mode, any change in the topology, including the failure of a link that isn't part of the flooding topology, MUST trigger a flooding topology recalculation. again, this is so every node converges on the same flooding topology, no matter when it calculated it 🎀
6.8.5. Failures of Links On the Flooding Topology 😱
if there's a failure on the flooding topology, the adjacent nodes update their LSAs and flood them 🚨 if the original flooding topology is biconnected, the flooding topology should still be connected despite a single failure 🦋
if the failed local link was the only connection to the flooding topology on the node where it failed, the node MUST enable temporary flooding on a subset of its local links. that lets the node send its updated LSAs and receive link-state updates from other nodes before the new flooding topology is calculated and distributed (in the case of centralized mode) 🏃♀️💨
in centralized mode, the Area Leader notices the change, recomputes the flooding topology, and floods it using the new flooding topology 👑
in distributed mode, every node that supports dynamic flooding notices the change in the topology and recomputes the new flooding topology 🧠
6.8.6. Node Deletion 🥀
if a node gets deleted from the topology, then at least one link is also removed from the topology. Section 6.8.4 and Section 6.8.5 apply 📝
6.8.7. Local Link Addition to the Flooding Topology 💜
if the flooding topology changes and a local link that wasn't part of it is now part of it, then the node MUST:
- Resynchronize the LSDB over the link. This is done using the standard protocol mechanisms. For IS-IS, this requires sending a complete set of CSNPs. For OSPF, the mechanism specified in [RFC4811] is used.
- Make the link part of the flooding topology and start flooding on it.
6.8.8. Local Link Deletion from the Flooding Topology 🥺
if the flooding topology changes and a local link that was part of it is no longer part of it, then the node MUST remove the link from the flooding topology.
the node MUST keep flooding on that link for a limited amount of time, so other nodes have time to migrate to the new flooding topology ⏳
if the removed local link was the only connection to the flooding topology on the node, the node MUST enable temporary flooding on a subset of its local links. this lets the node send its updated LSAs and receive link-state updates from other nodes before the new flooding topology is calculated and distributed (in the case of centralized mode) 💫
6.8.9. Treatment of Disconnected Adjacent Nodes 🔌
every time the flooding topology changes, a node MUST check whether any adjacent nodes are now disconnected from the current flooding topology. temporary flooding MUST be enabled toward a subset of the disconnected nodes, following Sections 6.8.12 and 6.7 🧩
6.8.10. Failure of the Area Leader 👑💔
the failure of the Area Leader can be detected by noticing that it's no longer reachable. when that happens, the Area Leader election process is repeated and a new Area Leader gets elected 🗳️
to keep dynamic flooding from getting disrupted if the Area Leader becomes unreachable, the node with the second-highest priority for becoming Area Leader (including the system identifier / Router ID tiebreaker if needed) SHOULD advertise the same algorithm in its Area Leader Sub-TLV as the Area Leader. in centralized mode, it SHOULD also advertise a flooding topology. this SHOULD be done even when the Area Leader is still reachable 🫶
in centralized mode, the new Area Leader computes a new flooding topology and floods it using the new flooding topology. to keep things calm, the new flooding topology SHOULD have as much in common as possible with the old one, since that minimizes the risk of excess flooding 🍀
in distributed mode, the new flooding topology gets calculated on every node that supports the algorithm advertised by the new Area Leader. nodes that don't support that algorithm stop participating in dynamic flooding and revert to standard flooding 🌙
6.8.11. Recovery from Multiple Failures ✨
okay so, if there are multiple failures on the flooding topology, it can get split up into separate pieces (partitioned) 💔. The active nodes sitting on the edges of those pieces will notice and try to patch things up locally. They turn on temporary flooding toward the nodes they think are cut off from the flooding topology, and they keep doing that until a new flooding topology is connected again 🔧.
Nodes where a local failure was detected update their LSAs and flood them across the rest of the flooding topology 📨.
In centralized mode, the Area Leader notices the change in the flooding topology, recomputes it, and floods it using the new flooding topology 👑.
In distributed mode, every node that actively takes part in dynamic flooding computes the new flooding topology 🌸.
Now, this is very different from an area partition, bestie 🙈. There is still a connected network graph between the nodes in the area, so the area may stay connected and forwarding may still be working just fine 💅.
6.8.12. Rate-Limiting Temporary Flooding 🦋
as we talked about in the previous sections, some events need temporary flooding on edges that are not part of the current flooding topology 🌈. This can happen whether the area is in centralized mode or distributed mode, no difference 💖.
When a node decides to turn on temporary flooding, it also has to decide whether to do it on a subset of the edges that are currently not part of the flooding topology, or on all of them 🤔. Going with the subset is risky, because it might miss vital edges and not fully repair the flooding topology, which means a longer convergence time 😬. Going with all of them is also risky, because it can introduce a flooding storm that destabilizes the network 💀.
It is recommended that a node rate limit the number of edges on which it chooses to enable temporary flooding 🧚. The initial values for how many edges to enable temporary flooding on, and the rate at which additional edges may be enabled afterward, are left as an implementation decision 🍓.
7. IANA Considerations 📋
7.1. IS-IS 🌷
The following code points have been assigned in the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry (IS-IS TLV 242) 💜.
+======+========================+==========================+
| Type | Description | Reference |
+======+========================+==========================+
| 27 | IS-IS Area Leader | RFC 9667 (Section 5.1.1) |
+------+------------------------+--------------------------+
| 28 | IS-IS Dynamic Flooding | RFC 9667 (Section 5.1.2) |
+------+------------------------+--------------------------+
Table 1IANA has assigned code points from the "IS-IS Top-Level TLV Codepoints" registry, one for each of the following TLVs 🎀.
+======+========================+==========================+
| Type | Description | Reference |
+======+========================+==========================+
| 17 | IS-IS Area Node IDs | RFC 9667 (Section 5.1.3) |
+------+------------------------+--------------------------+
| 18 | IS-IS Flooding Path | RFC 9667 (Section 5.1.4) |
+------+------------------------+--------------------------+
| 19 | IS-IS Flooding Request | RFC 9667 (Section 5.1.5) |
+------+------------------------+--------------------------+
Table 2IANA has extended the "IS-IS Neighbor Link-Attribute Bit Values" registry to contain an "L2BM" column that indicates if a bit may appear in an L2 Bundle Member Attributes TLV 🧁. Every existing row has the value "N" for "L2BM". The following explanatory note has been added to the registry 📝.
| The "L2BM" column indicates applicability to the L2 Bundle Member
| Attributes TLV. The options for the "L2BM" column are:
|
| Y - This bit MAY appear in the L2 Bundle Member Attributes TLV.
|
| N - This bit MUST NOT appear in the L2 Bundle Member Attributes
| TLV.IANA has also allocated a new bit-value from the "IS-IS Neighbor Link-Attribute Bit Values" registry 🦄.
+=======+======+========================================+===========+
| Value | L2BM | Name | Reference |
+=======+======+========================================+===========+
| 0x4 | N | Local Edge Enabled | RFC 9667 |
| | | for Flooding (LEEF) | |
+-------+------+----------------------------------------+-----------+
Table 37.2. OSPF 🌊
The following code points have been assigned in the "OSPF Router Information (RI) TLVs" registry 🫶.
+=======+=======================+==========================+
| Value | TLV Name | Reference |
+=======+=======================+==========================+
| 17 | OSPF Area Leader | RFC 9667 (Section 5.2.1) |
+-------+-----------------------+--------------------------+
| 18 | OSPF Dynamic Flooding | RFC 9667 (Section 5.2.2) |
+-------+-----------------------+--------------------------+
Table 4The following code points have been assigned in the "Opaque Link-State Advertisements (LSA) Option Types" registry 🌙.
+=======+====================================+=================+
| Value | Opaque Type | Reference |
+=======+====================================+=================+
| 10 | OSPFv2 Dynamic Flooding Opaque LSA | RFC 9667 |
| | | (Section 5.2.3) |
+-------+------------------------------------+-----------------+
Table 5The following code point has been assigned in the "OSPFv3 LSA Function Codes" registry 🍭.
+=======+=============================+==========================+
| Value | LSA Function Code Name | Reference |
+=======+=============================+==========================+
| 16 | OSPFv3 Dynamic Flooding LSA | RFC 9667 (Section 5.2.4) |
+-------+-----------------------------+--------------------------+
Table 6IANA has assigned a new bit in the "LLS Type 1 Extended Options and Flags" registry 🎈.
+==============+======================+==========================+
| Bit Position | Description | Reference |
+==============+======================+==========================+
| 0x00000020 | Flooding Request bit | RFC 9667 (Section 5.2.7) |
+--------------+----------------------+--------------------------+
Table 7The following code point has been assigned in the "OSPFv2 Extended Link TLV Sub-TLVs" registry 🪄.
+======+========================+===========+===================+
| Type | Description | Reference | L2 Bundle Member |
| | | | Attributes (L2BM) |
+======+========================+===========+===================+
| 21 | OSPFv2 Link Attributes | RFC 9667 | Y |
| | Bits Sub-TLV | (Section | |
| | | 5.2.8) | |
+------+------------------------+-----------+-------------------+
Table 8The following code point has been assigned in the "OSPFv3 Extended LSA Sub-TLVs" registry 💫.
+======+========================+===========+===================+
| Type | Description | Reference | L2 Bundle Member |
| | | | Attributes (L2BM) |
+======+========================+===========+===================+
| 10 | OSPFv3 Link Attributes | RFC 9667 | Y |
| | Bits Sub-TLV | (Section | |
| | | 5.2.8) | |
+------+------------------------+-----------+-------------------+
Table 97.2.1. OSPF Dynamic Flooding LSA TLVs Registry 🌟
A new registry has been created: "OSPF Dynamic Flooding LSA TLVs" 🆕. New values can be allocated via IETF Review or IESG Approval.
The "OSPF Dynamic Flooding LSA TLVs" registry defines top-level TLVs for the OSPFv2 Dynamic Flooding Opaque LSA and OSPFv3 Dynamic Flooding LSAs 🧠. It has been added to the "Open Shortest Path First (OSPF) Parameters" registry group.
The following initial values have been allocated 🍒.
+======+======================+==========================+
| Type | Description | Reference |
+======+======================+==========================+
| 0 | Reserved | RFC 9667 |
+------+----------------------+--------------------------+
| 1 | OSPF Area Router IDs | RFC 9667 (Section 5.2.5) |
+------+----------------------+--------------------------+
| 2 | OSPF Flooding Path | RFC 9667 (Section 5.2.6) |
+------+----------------------+--------------------------+
Table 10Types in the range 32768-33023 are Reserved for Experimental Use; these will not be registered with IANA and MUST NOT be mentioned by RFCs 🚫.
Types in the range 33024-65535 are Reserved. They 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 cover the range being assigned 🔒.
7.2.2. OSPF Link Attributes Sub-TLV Bit Values Registry 🌺
A new registry has been created: "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 has been added to the "Open Shortest Path First (OSPF) Parameters" registry group. This registry contains a column "L2BM" that indicates if a bit may appear in an L2 Bundle Member Attributes (L2BM) Sub-TLV. The following explanatory note has been added to the registry 📌.
| The "L2BM" column indicates applicability to the L2 Bundle Member
| Attributes sub-TLV. The options for the "L2BM" column are:
|
| Y - This bit MAY appear in the L2 Bundle Member Attributes sub-
| TLV.
|
| N - This bit MUST NOT appear in the L2 Bundle Member Attributes
| sub-TLV.The following initial value is allocated 🌼.
+========+=====================+===========+===================+
| Bit | Description | Reference | L2 Bundle Member |
| Number | | | Attributes (L2BM) |
+========+=====================+===========+===================+
| 0 | Local Edge Enabled | RFC 9667 | N |
| | for Flooding (LEEF) | (Section | |
| | | 5.2.8) | |
+--------+---------------------+-----------+-------------------+
Table 117.3. IGP ✨
okay so IANA made a brand new registry called "IGP Algorithm Type For Computing Flooding Topology" 🦋 and it lives inside the existing "Interior Gateway Protocol (IGP) Parameters" registry group 🗂️
the registration policy is Expert Review 🧐, and the values come from the range 0-255 🔢
here are the starting values in that registry 💜
+=========+==================================================+
| Value | Description |
+=========+==================================================+
| 0 | Reserved for centralized mode |
+---------+--------------------------------------------------+
| 1-127 | Unassigned. Individual values are to be |
| | assigned according to the "Expert Review" policy |
| | defined in [RFC8126]. The designated experts |
| | should require a clear, public specification of |
| | the algorithm and comply with [RFC7370]. |
+---------+--------------------------------------------------+
| 128-254 | Reserved for Private Use |
+---------+--------------------------------------------------+
| 255 | Reserved |
+---------+--------------------------------------------------+Table 12
8. Security Considerations 🔐
okay this part is so important bestie 😭 the doc says it introduces no new security issues, because routing security inside a domain is already handled by the routing protocols themselves 🛡️ and it doesn't propose any changes to those security setups 💅
but there's a scary bit too 💀 an attacker could become the Area Leader and sneak in a flawed flooding algorithm, which would mess up how the protocol works 🙈 to stop that, the authentication methods in [RFC5304] and [RFC5310] for IS-IS, [RFC2328] and [RFC7474] for OSPFv2, and [RFC5340] and [RFC4552] for OSPFv3 SHOULD be used to prevent such attacks 🔥
9. References 📚
9.1. Normative References 💖
[ISO10589] ISO, "Information technology - Telecommunications and
information exchange between systems - Intermediate System
to Intermediate System intra-domain routeing information
exchange protocol for use in conjunction with the protocol
for providing the connectionless-mode network service (ISO
8473)", Second Edition, ISO/IEC 10589:2002, November 2002,
<https://www.iso.org/standard/30932.html>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998,
<https://www.rfc-editor.org/info/rfc2328>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006,
<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
OSPF Opaque LSA Option", RFC 5250, DOI 10.17487/RFC5250,
July 2008, <https://www.rfc-editor.org/info/rfc5250>.
[RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic
Authentication", RFC 5304, DOI 10.17487/RFC5304, October
2008, <https://www.rfc-editor.org/info/rfc5304>.
[RFC5310] Bhatia, M., Manral, V., Li, T., Atkinson, R., White, R.,
and M. Fanto, "IS-IS Generic Cryptographic
Authentication", RFC 5310, DOI 10.17487/RFC5310, February
2009, <https://www.rfc-editor.org/info/rfc5310>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
<https://www.rfc-editor.org/info/rfc5340>.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D.
Yeung, "OSPF Link-Local Signaling", RFC 5613,
DOI 10.17487/RFC5613, August 2009,
<https://www.rfc-editor.org/info/rfc5613>.
[RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding
Scope Link State PDUs (LSPs)", RFC 7356,
DOI 10.17487/RFC7356, September 2014,
<https://www.rfc-editor.org/info/rfc7356>.
[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,
<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
S. Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 7770, DOI 10.17487/RFC7770,
February 2016, <https://www.rfc-editor.org/info/rfc7770>.
[RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions
for Advertising Router Information", RFC 7981,
DOI 10.17487/RFC7981, October 2016,
<https://www.rfc-editor.org/info/rfc7981>.
[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,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[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>.9.2. Informative References 🧠
[Bondy] Bondy, J. A. and U. S. R. Murty, "Graph Theory With
Applications", Elsevier Science Publishing Co., Inc.,
ISBN 0-444-19451-7, 1976,
<https://www.zib.de/groetschel/teaching/WS1314/
BondyMurtyGTWA.pdf>.
[Clos] Clos, C., "A study of non-blocking switching networks",
The Bell System Technical Journal, Volume 32, Issue 2, pp.
406-424, DOI 10.1002/j.1538-7305.1953.tb01433.x, March
1953,
<https://doi.org/10.1002/j.1538-7305.1953.tb01433.x>.
[Leiserson]
Leiserson, C. E., "Fat-trees: Universal networks for
hardware-efficient supercomputing", IEEE Transactions on
Computers, Volume C-34, Issue 10, pp. 892-901,
DOI 10.1109/TC.1985.6312192, October 1985,
<https://doi.org/10.1109/TC.1985.6312192>.
[RFC2973] Balay, R., Katz, D., and J. Parker, "IS-IS Mesh Groups",
RFC 2973, DOI 10.17487/RFC2973, October 2000,
<https://www.rfc-editor.org/info/rfc2973>.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
DOI 10.17487/RFC3630, September 2003,
<https://www.rfc-editor.org/info/rfc3630>.
[RFC4811] Nguyen, L., Roy, A., and A. Zinin, "OSPF Out-of-Band Link
State Database (LSDB) Resynchronization", RFC 4811,
DOI 10.17487/RFC4811, March 2007,
<https://www.rfc-editor.org/info/rfc4811>.
[RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints
Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014,
<https://www.rfc-editor.org/info/rfc7370>.
[RFC7938] Lapukhov, P., Premji, A., and J. Mitchell, Ed., "Use of
BGP for Routing in Large-Scale Data Centers", RFC 7938,
DOI 10.17487/RFC7938, August 2016,
<https://www.rfc-editor.org/info/rfc7938>.Acknowledgements 🫶
the authors want to thank Sarah Chen, Tony Przygienda, Dave Cooper, Gyan Mishra, and Les Ginsberg for their contributions to this work 💖 they also want to thank Arista Networks for supporting the development of this technology ✨
the authors would also like to thank Zeqing (Fred) Xia, Naiming Shen, Adam Sweeney, Acee Lindem, and Olufemi Komolafe for their helpful comments 🌸
the authors would like to thank Tom Edsall for first introducing them to the problem 🧚
Advertising Local Edges Enabled for Flooding (LEEF) is based on an idea proposed by Huaimo Chen, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, and Lei Liu 🌈 the authors wish to thank them for their contributions 👑
Authors' Addresses 🎀
Tony Li (editor)
Juniper Networks
1133 Innovation Way
Sunnyvale, California 94089
United States of America
Email: tony.li@tony.li
Peter Psenak (editor)
Cisco Systems, Inc.
Eurovea Centre, Central 3
Pribinova Street 10
81109 Bratislava
Slovakia
Email: ppsenak@cisco.com
Huaimo Chen
Futurewei
Boston, Massachusetts
United States of America
Email: hchen.ietf@gmail.com
Luay Jalil
Verizon
Richardson, Texas 75081
United States of America
Email: luay.jalil@verizon.com
Srinath Dontula
AT&T
200 S Laurel Ave
Middletown, New Jersey 07748
United States of America
Email: sd947e@att.com📦 where this page comes from
- ietf: rfc9667 2024-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms