RFC 9377

IS-IS Flood Reflection

📅 published April 2023, from ietf

RFC 9377: IS-IS Flood Reflection 🦋

Bestie, this one is so good. It's an Experimental RFC from April 2023 by T. Przygienda (Ed., Juniper), C. Bowers (Individual), Y. Lee (Comcast), A. Sharma (Individual), and R. White (Akamai). It's published under ISSN 2070-1721, and the whole thing is about making IS-IS scale better without forcing every router in your network to upgrade 💅

Abstract

okay so this doc describes an optional IS-IS extension that is backward-compatible 🎀 It lets you build IS-IS flood reflection topologies. Flood reflection means L1 areas give transit forwarding to L2 areas, and they use every available L1 node internally to do it. The trick is that it creates L2 flood reflection adjacencies inside each L1 area. Those adjacencies get used to flood L2 Link State Protocol Data Units (LSPs) and to run the L2 Shortest Path First (SPF) computation, but they aren't normally used for forwarding inside the flood reflection cluster ✨

Why is this iconic? The L2 topology gets way better scaling than the usual flat designs. Plus, only the routers that directly take part in flood reflection need to support the feature. So you can roll out scalable L1 transit areas into a network that's already flat, and you don't have to upgrade every single router to do it. Main character energy 👑

Status of This Memo

ngl this part is a little dry, but it matters 🙈

This document is not an Internet Standards Track specification. It's published for examination, experimental implementation, and evaluation.

This document defines an Experimental Protocol for the Internet community. It's a product of the Internet Engineering Task Force (IETF) and it 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 see Section 2 of RFC 7841.

You can find info about the current status of this document, any errata, and how to send feedback at https://www.rfc-editor.org/info/rfc9377.

Copyright (c) 2023 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, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Revised BSD License. 📜

Table of Contents 🧚

1.  Introduction
2.  Conventions Used in This Document
  2.1.  Terminology
  2.2.  Requirements Language
3.  Further Details
4.  Encodings
  4.1.  Flood Reflection TLV
  4.2.  Flood Reflection Discovery Sub-TLV
  4.3.  Flood Reflection Discovery Tunnel Type Sub-Sub-TLV
  4.4.  Flood Reflection Adjacency Sub-TLV
  4.5.  Flood Reflection Discovery
  4.6.  Flood Reflection Adjacency Formation
5.  Route Computation
  5.1.  Tunnel-Based Deployment
  5.2.  No-Tunnel Deployment
6.  Redistribution of Prefixes
7.  Special Considerations
8.  IANA Considerations
  8.1.  New IS-IS TLV Codepoint
  8.2.  Sub-TLVs for IS-IS Router CAPABILITY TLV
  8.3.  Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV
  8.4.  Sub-TLVs for TLVs Advertising Neighbor Information
9.  Security Considerations
10. References
  10.1.  Normative References
  10.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

okay so this section sets the scene for the whole problem and gives the solution in a nutshell. Some of the terms might be unfamiliar if you aren't deep in IS-IS yet, and that's totally fine 🫶 The terminology lives in Section 2.1 for you.

Here's the tea. Because of how link-state protocols work, the number of IS-IS routers inside a flooding domain is capped by the processing and flooding overhead on each node. Good implementations and tricks like exponential backoffs can push that number up, but IS-IS will still hit a saturation point where no more routers fit in a single flooding domain. In some L2 backbone deployments, that limit is a real problem 😭

The standard way to scale an IS-IS deployment is to split it into several L1 flooding domains with a single L2 backbone. That works great when an L2 backbone connects L1 access topologies. It gets limiting when one flat L2 domain has to span a huge number of routers. In that case, you could try multiple L2 flooding domains connected through L1 flooding domains instead. The L2 domains get linked by "L1/L2 lanes" running through the L1 areas, which forms one L2 backbone again. The catch is that the simplest version of this needs most, or all, of the transit L1 routers to be L1/L2 as well, so traffic can take optimal paths through those transit areas. So it doesn't actually reduce the number of L2 routers involved, and it doesn't really boost the scalability of the L2 backbone either. Not it 💀

Figure 1 is an example of a network where a topologically rich L1 area provides transit between six different L2-only routers (R1-R6). Notice that the six L2-only routers have no connectivity to each other over L2 links. To take advantage of all the paths in the L1 transit area, you could put every intermediate system into both L1 and L2. But that basically merges the separate L2 flooding domains into one, which brings back the maximum L2 scale limit we were trying to get around in the first place 🙈

 +====+  +=======+             +=======+               +======-+  +====+
 I R1 I  I  R10  +-------------+  R20  +---------------+  R30  I  I R4 I
 I L2 +--+ L1/L2 I             I  L1   I               I L1/L2 +--+ L2 I
 I    I  I       +          +--+       I  +------------+       I  I    I
 +====+  ++====+=+          |  +===+===+  |            +=+==+=++  +====+
          |    |            |      |      |              |    |
          |    |            |      |      |  +-----------+    |
          |    +-------+    |      |      |  |                |
          |            |    |      |      |  |                |
          |            |    |      |      |  |                |
          |            |    |      |      |  |                |
 +====+  ++=====-+     |    |  +===+===+--+  |         +======++  +====+
 I R2 I  I  R11  I     |    |  I  R21  I     |         I  R31  I  I R5 I
 I L2 +--+ L1/L2 +-------------+  L1   +---------------+ L1/L2 +--+ L2 I
 I    I  I       I     |    |  I       I     | +-------+       I  I    I
 +====+  ++=====-+     |    |  ++==+==++     | |       +======++  +====+
          |            |    |   |  |  |      | |              |
          | +---------------+   |  |  |      | |              |
          | |          |        |  |  |      | |              |
          | |  +----------------+  |  +-----------------+     |
          | |  |       |           |         | |        |     |
 +====+  ++=+==+=+     +-------+===+===+-----+ |       ++=====++  +====+
 I R3 I  I  R12  I             I  R22  I       |       +  R32  I  I R6 I
 I L2 +--+ L1/L2 I             I  L1   +-------+       I L1/L2 +--+ L2 I
 I    I  I       +-------------+       +---------------+       I  I    I
 +====+  +=======+             +=======+               +=======+  +====+

            Figure 1: Example Topology of L1 with L2 Borders

A much better solution would cut down the number of links and routers exposed in L2, while still using the full L1 topology when forwarding through the network. That's the vibe we're going for 🦋

[RFC8099] describes Topology Transparent Zones (TTZ) for OSPF. The TTZ mechanism represents a group of OSPF routers as a full mesh of adjacencies between the routers at the edge of the group. A similar mechanism could be applied to IS-IS too. But a full mesh of adjacencies between edge routers (or L1/L2 nodes) really limits how big the resulting topology can practically get 😬 Figure 1's topology has six L1/L2 nodes. Figure 2 shows a full mesh of L2 adjacencies between those six L1/L2 nodes, which comes out to (5 * 6)/2 = 15 L2 adjacencies. In a somewhat bigger topology with 20 L1/L2 nodes, the number of L2 adjacencies in a full mesh climbs to 190. Yikes, not slay 💀

  +----+  +-------+    +-------------------------------+-------+  +----+
  | R1 |  |  R10  |    |                               |  R30  |  | R4 |
  | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 |
  |    |  |       |    |                               |       |  |    |
  +----+  ++-+-+--+-+  |                             +-+--+---++  +----+
           | | |    |  |                             |    |   |
           | +----------------------------------------------+ |
           |   |    |  |                             |    | | |
           |   +-----------------------------------+ |    | | |
           |        |  |                           | |    | | |
           |     +----------------------------------------+ | |
           |     |  |  |                           | |      | |
  +----+  ++-----+- |  |                           | | -----+-++  +----+
  | R2 |  |  R11  | |  |                           | | |  R31  |  | R5 |
  | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 |
  |    |  |       | |  |                           | | |       |  |    |
  +----+  ++------+------------------------------+ | | +----+-++  +----+
           |        |  |                         | | |      | |
           |        |  |                         | | |      | |
           |    +-------------------------------------------+ |
           |    |   |  |                         | | |        |
           |    |   |  |                         +----------+ |
           |    |   |  |                           | |      | |
           |    |   |  |                           +-----+  | |
           |    |   |  |                             |   |  | |
  +----+  ++----+-+-+  |                             +-+-+--+-++  +----+
  | R3 |  |  R12  |    |      L2 adjacency             |  R32  |  | R6 |
  | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 |
  |    |  |       |    |                               |       |  |    |
  +----+  +-------+----+                               +-------+  +----+

     Figure 2: Example Topology Represented in L2 with a Full Mesh of
                    L2 Adjacencies between L1/L2 Nodes

BGP, as specified in [RFC4271], hit the same scaling wall, and lots of networks fixed it with BGP route reflectors [RFC4456]. 💅 Here's the lowkey genius part: route reflectors don't have to sit in the forwarding path of the traffic. That means the control plane can scale on its own, separate from the forwarding plane, and that's a seriously interesting degree of freedom in network architecture 🧠✨

So this document proposes a similar fix for IS-IS and calls it "flood reflection," which is basically the sibling of "route reflection" 🦋 Here's a simple flood reflector setup, shown in Figure 3, where router R21 is the flood reflector 👑 Each L1/L2 ingress/egress router builds a tunnel to the flood reflector, and an L2 adjacency runs over each tunnel. In this setup you only need six L2 adjacencies instead of the 15 a full mesh would take 🙈 In a somewhat bigger topology with 20 L1/L2 nodes, you only need 20 L2 adjacencies instead of the 190 a full mesh would need. Multiple flood reflectors are allowed too, so the operator can balance resilience, path utilization, and control plane state 🌈 The resulting L2 adjacency scale is R*n, where R is the number of flood reflectors used and n is the number of L1/L2 nodes. Compare that to n*(n-1)/2 L2 adjacencies in a topologically full-mesh L2 solution, and it's giving no contest 💖

  +----+  +-------+                                    +-------+  +----+
  | R1 |  |  R10  |                                    |  R30  |  | R4 |
  | L2 +--+ L1/L2 +--------------+   +-----------------+ L1/L2 +--+ L2 |
  |    |  |       |  L2 adj      |   |      L2 adj     |       |  |    |
  +----+  +-------+  over        |   |      over       +-------+  +----+
                     tunnel      |   |      tunnel
  +----+  +-------+           +--+---+--+              +-------+  +----+
  | R2 |  |  R11  |           |   R21   |              |  R31  |  | R5 |
  | L2 +--+ L1/L2 +-----------+  L1/L2  +--------------+ L1/L2 +--+ L2 |
  |    |  |       |  L2 adj   |  flood  |   L2 adj     |       |  |    |
  +----+  +-------+  over     |reflector|   over       +-------+  +----+
                     tunnel   +--+---+--+   tunnel
  +----+  +-------+              |   |                 +-------+  +----+
  | R3 |  |  R12  +--------------+   +-----------------+  R32  |  | R6 |
  | L2 +--+ L1/L2 |  L2 adj                 L2 adj     | L1/L2 +--+ L2 |
  |    |  |       |  over                   over       |       |  |    |
  +----+  +-------+  tunnel                 tunnel     +-------+  +----+

     Figure 3: Example Topology Represented in L2 with L2 Adjacencies
            from Each L1/ L2 Node to a Single Flood Reflector

As Figure 3 shows, when R21 is the flood reflector, it gives L2 connectivity across all the previously disconnected L2 islands by reflooding every L2 Link State Protocol Data Unit (LSP) 🫶 At the same time, R20 and R22 in Figure 1 stay L1-only routers, and L1-only routers and L1-only links are invisible in L2. So the flood reflector gets you L2 control plane connectivity in a way that scales much better than a flat L2 domain 🎀

Now, the solution in Figure 3 only leans on IS-IS features that are already standardized, which is nice. But without any new functionality, all the data traffic would squeeze through R21 alone 😭 That's a bottleneck waiting to happen, even though there's still spare capacity on the paths through the L1-only routers R20 and R22 in Figure 1.

So we need extra functionality so the L1/L2 edge nodes (R10-12 and R30-32 in Figure 3) can figure out that the L2 adjacency to R21 should not be used for forwarding 🔥 Instead, those edge nodes should push traffic that would normally go over the L2 adjacency to R21 over L1 links. That lets forwarding inside the L1 area use the L1-only nodes and links from Figure 1 too. Networks can then use the full forwarding capacity of their L1 areas, and they still get the control plane scaling perks that L2 flood reflectors bring 🌸

It's expected that once this runs at scale for a while, there'll be enough evidence to either move this extension into a Standards Track document or suggest the changes needed to get it there 🧚

The rest of this document defines the remaining extensions needed for a complete flood reflection solution:

  • It defines a special "flood reflector adjacency" built just for reflecting flooding information. These adjacencies let "flood reflectors" join the IS-IS control plane without necessarily being used in the forwarding plane 💜 Keeping them up is a purely local operation on the L1/L2 ingress and flood reflectors. It doesn't require replacing or modifying any routers that aren't part of the reflection process. In real deployments, it's way less tricky to just upgrade the routers involved in flood reflection than to have a flag day for the whole IS-IS domain 🙌
  • It specifies an (optional) full mesh of tunnels between the L1/L2 ingress routers, ideally load-balancing across all available L1 links. This uses every forwarding path between the L1/L2 edge nodes without injecting unneeded state into the L2 flooding domain or creating "choke points" at the "flood reflectors" themselves ✨ The specification doesn't care which tunneling technology you use, but it gives enough information for automatic tunnel establishment if you want it. How IS-IS adjacency formation and/or liveness discovery works on those tunnels is outside the scope of this specification and is mostly up to the underlying implementation. A solution without tunnels is also possible by scoping reachability information correctly between the levels, and that's covered in more detail later 🦋
  • Finally, this document defines support for reflector redundancy and an (optional) way to auto-discover and annotate flood reflector adjacencies in advertisements. That extra info in link advertisements lets L2 nodes outside the L1 area recognize a flood reflection cluster and its adjacencies 👑

2. Conventions Used in This Document ✨

2.1. Terminology

Here are the terms this document uses, bestie 📚

IS-IS Level 1 and Level 2 areas (mostly abbreviated as L1 and L2): IS-IS concepts where a routing domain has two "levels," with a single L2 area being the "backbone" that connects multiple L1 areas for scaling and reliability purposes. IS-IS architecture prescribes a routing domain with two "levels" where a single L2 area functions as the "backbone" that connects multiple L1 areas amongst themselves for scaling and reliability purposes. In that architecture, L2 can be used as transit for traffic carried from one L1 area to another, but L1 areas themselves cannot be used for that purpose, because the L2 level must be a single "connected" entity, and all traffic exiting an L1 area flows along L2 routers until it arrives at the destination L1 area itself 🌈

Flood Reflector: A node configured to connect in L2 only to flood reflector clients and to reflect (reflood) IS-IS L2 LSPs amongst them 💖

Flood Reflector Client: A node configured to build Flood Reflector Adjacencies to Flood Reflectors, and to build normal adjacencies to other clients and to L2 nodes not participating in flood reflection 🎀

Flood Reflector Adjacency: An IS-IS L2 adjacency where one end is a Flood Reflector Client and the other is a Flood Reflector. Both have the same Flood Reflector Cluster ID 🫶

Flood Reflector Cluster: A collection of clients and flood reflectors configured with the same cluster identifier 🧚

Tunnel-Based Deployment: A deployment where Flood Reflector Clients build a partial or full mesh of tunnels in L1 to "shortcut" forwarding of L2 traffic through the cluster 🦋

No-Tunnel Deployment: A deployment where Flood Reflector Clients redistribute L2 reachability into L1 to allow forwarding through the cluster without underlying tunnels 🌸

Tunnel Endpoint: An endpoint that allows the establishment of a bidirectional tunnel carrying IS-IS control traffic or, alternatively, serves as the origin of such a tunnel 💜

L1 shortcut: A tunnel established between two clients that is visible in L1 only and is used as a next hop, i.e., to carry data traffic in tunnel-based deployment mode 🔥

Hot-Potato Routing: In the context of this document, a routing paradigm where L2->L1 routes are less preferred than L2 routes [RFC5302] 👑

2.2. Requirements Language

Okay, this is the important bit about how the capitalized key words work 🤓 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 💅

3. Further Details

Several considerations should be noted about this flood reflection mechanism 🧐

First, the flood reflection mechanism lets multi-area IS-IS deployments scale without any major modifications to the IS-IS implementation on most of the nodes in the network. Unmodified (standard) L2 routers will compute reachability across the transit L1 area using the flood reflector adjacencies. (In this document, the term "standard" refers to IS-IS as specified in [ISO10589].) 🌈

Second, flood reflectors are not required to participate in forwarding traffic through the L1 transit area. These flood reflectors can be hosted on virtual devices outside the forwarding topology 🦋

Third, astute readers will realize that flood reflection may cause the use of suboptimal paths. This is similar to the BGP route reflection suboptimal routing problem described in [RFC9107] 🙈 The L2 computation determines the egress L1/L2 and, with that, can create illusions of ECMP where there is none. In certain scenarios, the L2 computation can also lead to an L1/L2 egress that is not globally optimal. This is a straightforward instance of the trade-off between the amount of control plane state and the optimal use of paths through the network, which often shows up when routing information gets aggregated 😭

One possible fix for this is to expose additional topology information into the L2 flooding domains. In the example network, links from router R10 to router R11 can be exposed into L2 even when R10 and R11 are participating in flood reflection. That information would let L2 nodes build "shortcuts" when the L2 flood-reflected part of the topology looks more expensive to cross distance-wise ✨

Another possible variation is for an implementation to use the tunnel cost to approximate the cost of the underlying topology 💜

Redundancy can be achieved by configuring multiple flood reflectors in an L1 area. Multiple flood reflectors don't need any synchronization mechanisms amongst themselves, except standard IS-IS flooding and database maintenance procedures 🫶

4. Encodings ✨

4.1. Flood Reflection TLV 🎀

okay bestie, so the Flood Reflection TLV is a top-level TLV that MUST appear in L2 IIHs (IS-IS Hello) on all Flood Reflection Adjacencies 💅 It basically tells everyone which flood reflector cluster (based on Flood Reflection Cluster ID) a router is set up to hang out in, and whether it's playing flood reflector or flood reflector client. The cluster ID and roles in the IIHs are what keep things iconic: flood reflector adjacencies only form between a flood reflector and a client, and the cluster IDs have to match ✨ Here's 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     |C|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Flood Reflection Cluster ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Sub-TLVs ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 161
  • Length: the length, in octets, of the following fields.
  • C (Client): this bit is set to show the router is a flood reflector client. When this bit is NOT set, the router is a flood reflector. On a given router, the same value of the C-bit MUST be advertised across all interfaces advertising the Flood Reflection TLV in IIHs.
  • Reserved: this field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.
  • Flood Reflection Cluster ID: the same arbitrary 32-bit value MUST be assigned to all of the flood reflectors and flood reflector clients in the same L1 area. The value MUST be unique across different L1 areas within the IGP domain. If those rules get broken 💀, multiple L1 areas may become a single cluster, or a single area may split in flood reflection sense, and several mechanisms, such as auto-discovery of tunnels, may not work correctly. On a given router, the same value of the Flood Reflection Cluster ID MUST be advertised across all interfaces advertising the Flood Reflection TLV in IIHs. When a router discovers that a node is using more than a single Cluster IDs based on its advertised TLVs and IIHs, the node MAY log such violations subject to rate-limiting. This implies that a flood reflector MUST NOT participate in more than a single L1 area. In case of Cluster ID value of 0, the TLV containing it MUST be ignored.
  • Sub-TLVs (Optional Sub-TLVs): for future extensibility, the format of the Flood Reflection TLV allows for the possibility of including optional sub-TLVs. No sub-TLVs of the Flood Reflection TLV are defined in this document.

The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. A router receiving one or more Flood Reflection TLVs in the same IIH MUST use the values in the first TLV, and it SHOULD log such violations subject to rate-limiting 🫶

4.2. Flood Reflection Discovery Sub-TLV 🦋

The Flood Reflection Discovery sub-TLV rides along as a sub-TLV of the IS-IS Router Capability TLV 242, defined in [RFC7981]. It shows up in L1 and L2 LSPs with area flooding scope so routers can auto-discover each other's flood reflection capabilities. The format 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     |C|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Flood Reflection Cluster ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 161
  • Length: the length, in octets, of the following fields.
  • C (Client): this bit is set to show the router is a flood reflector client. When this bit is NOT set, the router is a flood reflector.
  • Reserved: this field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.
  • Flood Reflection Cluster ID: the Flood Reflection Cluster Identifier is the same as the one defined in the Flood Reflection TLV in Section 4.1 and obeys the same rules.

The Flood Reflection Discovery sub-TLV SHOULD NOT appear more than once in TLV 242. A router receiving one or more Flood Reflection Discovery sub-TLVs in TLV 242 MUST use the values in the first sub-TLV of the lowest numbered fragment, and it SHOULD log such violations subject to rate-limiting 🌸

4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV 🧚

okay this one is the Flood Reflection Discovery Tunnel Type sub-sub-TLV, and it's optional 💖 It gets advertised as a sub-sub-TLV of the Flood Reflection Discovery Sub-TLV from Section 4.2. Its whole vibe is letting L2 tunnels get created automatically, for use as flood reflector adjacencies and L1 shortcut tunnels. The format 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     | Reserved    |F|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                Tunnel Encapsulation Attribute                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 161
  • Length: the length, in octets, of zero or more of the following fields.
  • Reserved: SHOULD be 0 on transmission and MUST be ignored on reception.
  • F Flag: when set, it means a flood reflection tunnel endpoint. When clear, it means a possible L1 shortcut tunnel endpoint.
  • Tunnel Encapsulation Attribute: carries the encapsulation type and the further attributes needed for tunnel establishment, as defined in [RFC9012]. In the context of this attribute, the protocol Type sub-TLV as defined in [RFC9012] MAY be included to make sure IS-IS frames get encapsulated properly. If that sub-TLV is included and the F flag is set (so the resulting tunnel is a flood reflector adjacency), this sub-TLV MUST include a type that allows encapsulated IS-IS frames to be carried. On top of that, such a tunnel type MUST be able to transport IS-IS frames of size up to "originatingL2LSPBufferSize".

A flood reflector receiving Flood Reflection Discovery Tunnel Type sub-sub-TLVs in a Flood Reflection Discovery sub-TLV with the F flag set (so the resulting tunnel is a flood reflector adjacency) SHOULD use one or more of the specified tunnel endpoints to automatically establish one or more tunnels that serve as a flood reflection adjacency and/or adjacencies to the clients advertising those endpoints.

A flood reflection client receiving one or more Flood Reflection Discovery Tunnel Type sub-sub-TLVs in a Flood Reflection Discovery sub-TLV with the F flag clear (so the resulting tunnel supports tunnel-based mode) from other leaves MAY use one or more of the specified tunnel endpoints to automatically establish one or more tunnels that serve as L1 tunnel shortcuts to the clients advertising those endpoints.

For automatic flood reflection adjacency tunnels, and for cases where IS-IS adjacencies are formed across L1 shortcuts, all the rules mentioned above in Section 4.5 apply as well ✨

Optional address validation procedures as defined in [RFC9012] MUST be disregarded. 🙈

It's worth noticing that automatic tunnel discovery is an optional part of the spec. It can be replaced or mixed with statically configured tunnels for flood reflector adjacencies and tunnel-based shortcuts. Exactly how both mechanisms interact is up to the implementation and mode of operation, and it's outside the scope of this document.

Flood reflector adjacencies rely on IS-IS L2 liveliness procedures. For L1 shortcuts, the mechanism used to ensure liveliness and tunnel integrity is outside the scope of this document 🦋

4.4. Flood Reflection Adjacency Sub-TLV 💜

The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of TLVs 22, 23, 25, 141, 222, and 223 (the "TLVs Advertising Neighbor Information"). Its presence tells you a given adjacency is a flood reflector adjacency. It's included in L2 area scope flooded LSPs. The format 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     |C|  Reserved   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Flood Reflection Cluster ID                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • Type: 161
  • Length: the length, in octets, of the following fields.
  • C (Client): this bit is set to show the router advertising this adjacency is a flood reflector client. When this bit is NOT set, the router advertising this adjacency is a flood reflector.
  • Reserved: this field is reserved for future use. It MUST be set to 0 when sent and MUST be ignored when received.
  • Flood Reflection Cluster ID: the Flood Reflection Cluster Identifier is the same as the one defined in the Flood Reflection TLV in Section 4.1 and obeys the same rules.

The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than once in a given TLV. A router receiving one or more Flood Reflection Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV of the lowest numbered fragment, and it SHOULD log such violations subject to rate-limiting 👑

4.5. Flood Reflection Discovery 📡

Okay bestie, first things first: any router doing flood reflection, as a client or a reflector, MUST be configured as an L1/L2 router 🫶 It MAY originate the Flood Reflection Discovery sub-TLV with area flooding scope in L1 and L2. Normally, every router on the edge of the L1 area (the ones with standard L2 adjacencies) will advertise itself as a flood reflector client. So a flood reflector client ends up with standard L2 adjacencies AND flood reflector L2 adjacencies. Two kinds of friends, one router 💅

A router acting as a flood reflector MUST NOT form any standard L2 adjacencies except with flood reflector clients. It only ends up as an L1/L2 router because it has flood reflector L2 adjacencies 🦋 If a router wants to be a flood reflector, it MAY advertise itself that way using the Flood Reflection Discovery sub-TLV in L1 and L2.

A flood reflector or flood reflector client can only be in one cluster, which is decided by its Flood Reflection Cluster ID. If the cluster ID doesn't match, it should disregard other routers' TLVs for flood reflection purposes. No drama, no mixing clusters 🙅‍♀️✨

When a flood reflector gets Flood Reflection Discovery sub-TLVs, it SHOULD start a tunnel towards each flood reflector client that shares its Flood Reflection Cluster ID. It uses one or more of the tunnel encapsulations provided with F flag is set. The L2 adjacencies formed over those tunnels MUST be marked as flood reflector adjacencies 🎀 And if the client or reflector already has a direct L2 adjacency with the remote side, it SHOULD use that instead of making a tunnel. Why build what you already have, right? 💖

If the optional auto-discovery mechanism isn't implemented or enabled, a deployment MAY use statically configured tunnels to create flood reflection adjacencies 🧚

The IS-IS metrics for all flood reflection adjacencies in a cluster SHOULD be identical 🍓

Last one for this section: when a flood reflector client gets Flood Reflection Discovery TLVs, it MAY start tunnels with L1-only adjacencies towards any other flood reflector clients in its cluster that have lower router IDs, using encapsulations with F flag clear. Those tunnels MAY be used for forwarding to improve the load-balancing vibes of the L1 area 🌈 If the clients have a direct L2 adjacency, they SHOULD use it instead of making a new tunnel. Same energy as before, periodt 💅

4.6. Flood Reflection Adjacency Formation 🔥

Real talk: to keep implementation complexity from getting out of hand, this document does NOT allow complex hierarchies of flood reflectors and clients, and it doesn't allow multiple clusters in a single L1 area 😭 So all flood reflectors and flood reflector clients in the same L1 area MUST share the same Flood Reflector Cluster ID. Using multiple cluster IDs in the same L1 area is outside the scope of this document, so that's a whole other story 📖

A flood reflector MUST NOT form flood reflection adjacencies with flood reflector clients that have a different Cluster ID. A flood reflector MUST NOT form any standard L2 adjacencies. Strict, but iconic 👑

Flood reflector clients MUST NOT form flood reflection adjacencies with flood reflectors that have a different Cluster ID 🙈

Flood reflector clients MAY form standard L2 adjacencies with flood reflector clients or with nodes that aren't doing flood reflection at all. When two flood reflector clients form a standard L2 adjacency, the Cluster IDs get ignored. Cluster ID who? 💀

The Flood Reflector Cluster ID and the flood reflector roles get advertised in the Flood Reflection TLVs in IIHs. That's how everyone makes sure the flood reflection adjacencies that form actually meet the criteria above 🫶

If the flood reflection role or the cluster ID changes on the IIH, on either the local or the remote side, the adjacency HAS to be reset. Then it gets re-established if that's possible ✨ Fresh start, no cap.

Once a flood reflection adjacency is up, the flood reflector and the flood reflector client MUST advertise it by including the Flood Reflection Adjacency Sub-TLV in the Extended IS reachability TLV or the Multi-Topology Intermediate System Neighbor (MT-ISN) TLV. Get it on the record, babe 📣

5. Route Computation 🗺️

To keep routing loop-free, the flood reflection client MUST follow the normal L2 computation to figure out its L2 routes. Why? Because nodes outside the L1 area usually won't even know flood reflection is happening, so the flood reflection clients need to get the same L2 route computation result as a router that isn't doing flood reflection. Consistency is everything 💖

5.1. Tunnel-Based Deployment 🦋

In the tunnel-based option, the reflection client has to do the L2 and L1 computation first, and then it MUST examine all L2 routes that have flood reflector next-hop adjacencies. Those next hops must get swapped out for the matching tunnel next hops that lead to the correct egress nodes of the flood reflection cluster. Glow-up arc for next hops 💅✨

5.2. No-Tunnel Deployment 🌸

If there are no underlying tunnels, the necessary L2 routes get distributed into the area, usually as L2->L1 routes. Because of the rules in Section 4.6, the computation in the resulting topology is pretty simple. The L2 SPF from a flood reflector client is guaranteed to reach the Flood Reflector in a single hop, and on the next hop it's guaranteed to reach the L2 egress it has a forwarding tunnel to. So all the flood reflector tunnel next hops in that L2 route can be removed. And if the L2 route has no other ECMP L2 next hops, the L2 route MUST be suppressed in the RIB by some means, so the less preferred L2->L1 route can be used to forward traffic toward the advertising egress. Main character move, honestly 👑

Now the tricky bit 🙃 If the client has L2 routes that AREN'T flood reflected, those win naturally, because they usually "hot-potato" packets right out of the L1 area. BUT if the L2 route through the flood reflector egress is "shorter" than those non-flood-reflected L2 routes, the node SHOULD make sure those routes get suppressed, so the L2->L1 route toward the egress still takes priority. Operationally, the fix is actually pretty simple: give the flood reflector adjacencies a high metric. That makes the flood reflector topology "last resort," and the leaves will try to "hot-potato" out of the area as fast as possible, which is usually what you want 🫶

In no-tunnel deployment, all L1/L2 edge nodes MUST be flood reflection clients. No exceptions, bestie 🔥

6. Redistribution of Prefixes 📮

In a no-tunnel deployment (per Section 5.2), a client that doesn't have any L2 flood reflector adjacencies MUST NOT redistribute L2 routes into the cluster. Don't overshare, sweetie 🙊

The L2 prefix advertisements that get redistributed into an L1 containing flood reflectors SHOULD normally be limited to L2 intra-area routes (as defined in [RFC7775]), as long as there's info that lets you tell them apart from other L2 prefix advertisements 🧐

On the flip side, in topologies that use flood reflection to hide the structure of L1 areas while still providing transit forwarding across them through tunnels, we generally don't need to redistribute L1 prefix advertisements into L2. Hiding the mess is a whole vibe 🌈

7. Special Considerations ⚠️

Okay, this part is serious, so pay attention 🥺 In pathological cases, setting the overload bit in L1 (but NOT in L2) can partition L1 forwarding, while still letting L2 reachability through flood reflector adjacencies exist. In that situation, a node can't swap a route through a flood reflector adjacency for an L1 shortcut, so the client MAY use the L2 tunnel to the flood reflector for forwarding. And in all of those cases, the node MUST initiate an alarm and declare misconfiguration. Alarm bells, bestie 🚨

A flood reflector with directly L2 attached prefixes should advertise those in L1 as well. The reason is that clients prefer L1 routes, so they won't try to use the L2 flood reflector adjacency to route packets toward those prefixes. There's a very unlikely corner case where the flood reflector is only reachable via the L2 flood reflector adjacency (because of an underlying L1 partition). In that instance, the client can use the L2 tunnel to the flood reflector to forward toward those prefixes, but it MUST initiate an alarm and declare misconfiguration. Rare, but still a crisis 😭

A flood reflector MUST NOT set the attached bit on its LSPs. Don't flex the ATT bit, it's not your moment 🙅‍♀️

Now the broadcast medium situation 🥴 In certain cases, reflectors are attached to the same broadcast medium, and some other L2 router that is neither a flood reflector nor a flood reflector client (a "non-FR router", meaning a router not participating in flood reflection) also attaches to that same medium. Flooding between those reflectors might not succeed, which could partition the flood reflection domain. This could specifically happen if the non-FR router gets chosen as the Designated Intermediate System (DIS), which is the designated router. Since, per Section 4.6, a flood reflector MUST NOT form an adjacency with a non-FR router, the flood reflector(s) won't be represented in the pseudo-node. Plot twist nobody wanted 💀

To avoid this mess, it is RECOMMENDED that flood reflectors not be deployed on the same broadcast medium as non-FR routers. Keep your squads separated 🫶

A router that discovers this condition MUST initiate an alarm and declare misconfiguration. Sound the alarm, girl 🚨💅

8. IANA Considerations 🧾

IANA has assigned the following IS-IS TLVs and sub-TLVs, and has created a new registry. Paperwork that's actually cute 🎀

8.1. New IS-IS TLV Codepoint 🔢

The following IS-IS TLV has been registered in the "IS-IS Top-Level TLV Codepoints" registry:

       +=======+==================+=====+=====+=====+=======+
       | Value | Name             | IIH | LSP | SNP | Purge |
       +=======+==================+=====+=====+=====+=======+
       | 161   | Flood Reflection | y   | n   | n   | n     |
       +-------+------------------+-----+-----+-----+-------+

           Table 1: Flood Reflection IS-IS TLV Codepoint

8.2. Sub-TLVs for IS-IS Router CAPABILITY TLV 🧩

The following has been registered in the "IS-IS Sub-TLVs for IS-IS Router CAPABILITY TLV" registry:

                +======+============================+
                | Type | Description                |
                +======+============================+
                | 161  | Flood Reflection Discovery |
                +------+----------------------------+

                 Table 2: IS-IS Router CAPABILITY TLV

8.3. Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV 🦋

IANA has created a new registry named "IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV" under the "IS-IS TLV Codepoints" grouping. The registration procedure for this registry is Expert Review [RFC8126], following the common expert review guidance given for the grouping. Expert review, but make it aesthetic ✨

The range of values in this registry is 0-255. The registry contains the following initial registration:

+======+===========================================================+
| Type | Description                                               |
+======+===========================================================+
| 161  | Flood Reflection Discovery Tunnel Encapsulation Attribute |
+------+-----------------------------------------------------------+

 Table 3: IS-IS Sub-Sub-TLVs for Flood Reflection Discovery Sub-TLV

8.4. Sub-TLVs for TLVs Advertising Neighbor Information 🎀

okay so IANA added a new entry to the "IS-IS Sub-TLVs for TLVs Advertising Neighbor Information" registry 🦋 The new Sub-TLV is Type 161, called Flood Reflector Adjacency. It's allowed in TLVs 22, 23, 141, 222, and 223 (marked y), but NOT in TLV 25 (marked n) 💅 Here's the whole table, verbatim, because implementers need every single cell:

+======+===========================+====+====+====+=====+=====+=====+
| Type | Description               | 22 | 23 | 25 | 141 | 222 | 223 |
+======+===========================+====+====+====+=====+=====+=====+
| 161  | Flood Reflector           | y  | y  | n  | y   | y   | y   |
|      | Adjacency                 |    |    |    |     |     |     |
+------+---------------------------+----+----+----+-----+-----+-----+

Table 4: IS-IS Sub-TLVs for TLVs Advertising Neighbor Information

9. Security Considerations 🛡️

okay bestie, this part is SERIOUS, so read it with your whole brain 🧠😭 This document uses flood reflection tunnels to carry IS-IS control traffic. If an attacker can inject traffic into one of those tunnels, the damage could be (in the most extreme case) a complete subversion of the IS-IS Level 2 information 💀 So a mechanism that's built into the tunnel technology should be used to stop that injection from happening. The security procedures change depending on the deployment and the tunnel type, so the details of securing tunnels are beyond the scope of this document 🔐

This document also specifies the information used to form dynamically discovered shortcut tunnels. If an attacker managed to hijack the endpoint of one of those tunnels and form an adjacency, they could divert shortcut traffic to themselves 🙈 That puts them on-path and makes on-path attacks easy, and they could even completely subvert the IS-IS Level 2 routing ngl, terrifying. So steps should be taken to stop that kind of capture, using mechanisms that are inherent to the tunnel type being used. Again, the available security procedures vary by deployment and tunnel type, so the details of securing tunnels are beyond the scope of this document 💖

Also, the usual IS-IS security mechanisms [RFC5304] SHOULD be deployed 🚨 This prevents misrepresentation of routing information by an attacker in case a tunnel gets compromised and the tunnel itself doesn't provide mechanisms strong enough to guarantee the integrity of the messages exchanged. Protect your tunnels, protect your routing, periodt ✨

10. References 📚

10.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.

[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>.

[RFC5302]  Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix
           Distribution with Two-Level IS-IS", RFC 5302,
           DOI 10.17487/RFC5302, October 2008,
           <https://www.rfc-editor.org/info/rfc5302>.

[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>.

[RFC7775]  Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route
           Preference for Extended IP and IPv6 Reachability",
           RFC 7775, DOI 10.17487/RFC7775, February 2016,
           <https://www.rfc-editor.org/info/rfc7775>.

[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>.

[RFC9012]  Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
           "The BGP Tunnel Encapsulation Attribute", RFC 9012,
           DOI 10.17487/RFC9012, April 2021,
           <https://www.rfc-editor.org/info/rfc9012>.

10.2. Informative References

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271,
           DOI 10.17487/RFC4271, January 2006,
           <https://www.rfc-editor.org/info/rfc4271>.

[RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route
           Reflection: An Alternative to Full Mesh Internal BGP
           (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
           <https://www.rfc-editor.org/info/rfc4456>.

[RFC8099]  Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF
           Topology-Transparent Zone", RFC 8099,
           DOI 10.17487/RFC8099, February 2017,
           <https://www.rfc-editor.org/info/rfc8099>.

[RFC9107]  Raszuk, R., Ed., Decraene, B., Ed., Cassar, C., Åman, E.,
           and K. Wang, "BGP Optimal Route Reflection (BGP ORR)",
           RFC 9107, DOI 10.17487/RFC9107, August 2021,
           <https://www.rfc-editor.org/info/rfc9107>.

Acknowledgements 🫶

big thank-you hugs to Shraddha Hegde, Peter Psenak, Acee Lindem, Robert Raszuk, and Les Ginsberg for their thorough review and detailed discussions 🌸 Thanks also to Michael Richardson for an excellent routing directorate review 👑 And John Scudder literally spent significant time helping make the document more comprehensible and coherent, which is iconic behaviour 💜

Authors' Addresses 💌

Tony Przygienda (editor)
Juniper
1137 Innovation Way
Sunnyvale, CA
United States of America
Email: prz@juniper.net


Chris Bowers
Individual
Email: chrisbowers.ietf@gmail.com


Yiu Lee
Comcast
1800 Bishops Gate Blvd
Mount Laurel, NJ 08054
United States of America
Email: Yiu_Lee@comcast.com


Alankar Sharma
Individual
Email: as3957@gmail.com


Russ White
Akamai
Email: russ@riw.us
📦 where this page comes from