idnits 2.17.1 draft-ietf-lsr-isis-flood-reflection-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (5 December 2022) is 515 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Przygienda, Ed. 3 Internet-Draft C. Bowers 4 Intended status: Experimental Juniper 5 Expires: 8 June 2023 Y. Lee 6 Comcast 7 A. Sharma 8 Individual 9 R. White 10 Akamai 11 5 December 2022 13 IS-IS Flood Reflection 14 draft-ietf-lsr-isis-flood-reflection-12 16 Abstract 18 This document describes a backward-compatible, optional IS-IS 19 extension that allows the creation of IS-IS flood reflection 20 topologies. Flood reflection permits topologies in which L1 areas 21 provide transit forwarding for L2 using all available L1 nodes 22 internally. It accomplishes this by creating L2 flood reflection 23 adjacencies within each L1 area. Those adjacencies are used to flood 24 L2 LSPDUs and are used in the L2 SPF computation. However, they are 25 not ordinarily utilized for forwarding within the flood reflection 26 cluster. This arrangement gives the L2 topology significantly better 27 scaling properties than traditionally used flat designs. As an 28 additional benefit, only those routers directly participating in 29 flood reflection are required to support the feature. This allows 30 for incremental deployment of scalable L1 transit areas in an 31 existing, previously flat network design, without the necessity of 32 upgrading all routers in the network. 34 Requirements Language 36 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 37 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 38 "OPTIONAL" in this document are to be interpreted as described in BCP 39 14 [RFC2119] [RFC8174] when, and only when, they appear in all 40 capitals, as shown here. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at https://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on 8 June 2023. 59 Copyright Notice 61 Copyright (c) 2022 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 66 license-info) in effect on the date of publication of this document. 67 Please review these documents carefully, as they describe your rights 68 and restrictions with respect to this document. Code Components 69 extracted from this document must include Revised BSD License text as 70 described in Section 4.e of the Trust Legal Provisions and are 71 provided without warranty as described in the Revised BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 3. Further Details . . . . . . . . . . . . . . . . . . . . . . . 9 78 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 4.1. Flood Reflection TLV . . . . . . . . . . . . . . . . . . 10 80 4.2. Flood Reflection Discovery Sub-TLV . . . . . . . . . . . 11 81 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV . . . 12 82 4.4. Flood Reflection Adjacency Sub-TLV . . . . . . . . . . . 14 83 4.5. Flood Reflection Discovery . . . . . . . . . . . . . . . 15 84 4.6. Flood Reflection Adjacency Formation . . . . . . . . . . 16 85 5. Route Computation . . . . . . . . . . . . . . . . . . . . . . 16 86 5.1. Tunnel-Based Deployment . . . . . . . . . . . . . . . . . 17 87 5.2. No-Tunnel Deployment . . . . . . . . . . . . . . . . . . 17 88 6. Redistribution of Prefixes . . . . . . . . . . . . . . . . . 17 89 7. Special Considerations . . . . . . . . . . . . . . . . . . . 18 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 91 8.1. New IS-IS TLV Codepoint . . . . . . . . . . . . . . . . . 19 92 8.2. Sub TLVs for IS-IS Router CAPABILITY TLV . . . . . . . . 19 93 8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV . . . 19 94 8.4. Sub TLVs for TLVs Advertising Neighbor Information . . . 19 96 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 97 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 98 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 99 11.1. Informative References . . . . . . . . . . . . . . . . . 20 100 11.2. Normative References . . . . . . . . . . . . . . . . . . 21 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 103 1. Introduction 105 This section introduces the problem space and outlines the solution. 106 Some of the terms may be unfamiliar to readers without extensive IS- 107 IS background; for such readers a glossary is provided in Section 2. 109 Due to the inherent properties of link-state protocols the number of 110 IS-IS routers within a flooding domain is limited by processing and 111 flooding overhead on each node. While that number can be maximized 112 by well-written implementations and techniques such as exponential 113 back-offs, IS-IS will still reach a saturation point where no further 114 routers can be added to a single flooding domain. In some L2 115 backbone deployment scenarios, this limit presents a significant 116 challenge. 118 The traditional approach to increasing the scale of an IS-IS 119 deployment is to break it up into multiple L1 flooding domains and a 120 single L2 backbone. This works well for designs where an L2 backbone 121 connects L1 access topologies, but it is limiting where a single, 122 flat L2 domain is supposed to span large number of routers. In such 123 scenarios, an alternative approach could be to consider multiple L2 124 flooding domains connected together via L1 flooding domains. In 125 other words, L2 flooding domains are connected by "L1/L2 lanes" 126 through the L1 areas to form a single L2 backbone again. 127 Unfortunately, in its simplest implementation, this requires the 128 inclusion of most, or all, of the transit L1 routers as L1/L2 to 129 allow traffic to flow along optimal paths through those transit 130 areas. Consequently, such an approach fails to reduce the number of 131 L2 routers involved and with that fails to increase the scalability 132 of the L2 backbone as well. 134 Figure 1 is an example of a network where a topologically rich L1 135 area is used to provide transit between six different L2-only routers 136 (R1-R6). Note that the six L2-only routers do not have connectivity 137 to one another over L2 links. To take advantage of the abundance of 138 paths in the L1 transit area, all the intermediate systems could be 139 placed into both L1 and L2, but this essentially combines the 140 separate L2 flooding domains into a single one, triggering again the 141 maximum L2 scale limitation we try to address in first place. 143 +====+ +=======+ +=======+ +======-+ +====+ 144 I R1 I I R10 +-------------+ R20 +---------------+ R30 I I R4 I 145 I L2 +--+ L1/L2 I I L1 I I L1/L2 +--+ L2 I 146 I I I + +--+ I +------------+ I I I 147 +====+ ++====+=+ | +===+===+ | +=+==+=++ +====+ 148 | | | | | | | 149 | | | | | +-----------+ | 150 | +-------+ | | | | | 151 | | | | | | | 152 | | | | | | | 153 | | | | | | | 154 +====+ ++=====-+ | | +===+===+--+ | +======++ +====+ 155 I R2 I I R11 I | | I R21 I | I R31 I I R5 I 156 I L2 +--+ L1/L2 +-------------+ L1 +---------------+ L1/L2 +--+ L2 I 157 I I I I | | I I | +-------+ I I I 158 +====+ ++=====-+ | | ++==+==++ | | +======++ +====+ 159 | | | | | | | | | 160 | +---------------+ | | | | | | 161 | | | | | | | | | 162 | | +----------------+ | +-----------------+ | 163 | | | | | | | | | 164 +====+ ++=+==+=+ +-------+===+===+-----+ | ++=====++ +====+ 165 I R3 I I R12 I I R22 I | + R32 I I R6 I 166 I L2 +--+ L1/L2 I I L1 +-------+ I L1/L2 +--+ L2 I 167 I I I +-------------+ +---------------+ I I I 168 +====+ +=======+ +=======+ +=======+ +====+ 170 Figure 1: Example Topology of L1 with L2 Borders 172 A more effective solution would allow to reduce the number of links 173 and routers exposed in L2, while still utilizing the full L1 topology 174 when forwarding through the network. 176 [RFC8099] describes Topology Transparent Zones (TTZ) for OSPF. The 177 TTZ mechanism represents a group of OSPF routers as a full mesh of 178 adjacencies between the routers at the edge of the group. A similar 179 mechanism could be applied to IS-IS as well. However, a full mesh of 180 adjacencies between edge routers (or L1/L2 nodes) significantly 181 limits the practically achievable scale of the resulting topology. 182 The topology in Figure 1 has 6 L1/L2 nodes. Figure 2 illustrates a 183 full mesh of L2 adjacencies between the 6 L1/L2 nodes, resulting in 184 (5 * 6)/2 = 15 L2 adjacencies. In a somewhat larger topology 185 containing 20 L1/L2 nodes, the number of L2 adjacencies in a full 186 mesh rises to 190. 188 +----+ +-------+ +-------------------------------+-------+ +----+ 189 | R1 | | R10 | | | R30 | | R4 | 190 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 191 | | | | | | | | | 192 +----+ ++-+-+--+-+ | +-+--+---++ +----+ 193 | | | | | | | | 194 | +----------------------------------------------+ | 195 | | | | | | | | 196 | +-----------------------------------+ | | | | 197 | | | | | | | | 198 | +----------------------------------------+ | | 199 | | | | | | | | 200 +----+ ++-----+- | | | | -----+-++ +----+ 201 | R2 | | R11 | | | | | | R31 | | R5 | 202 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 203 | | | | | | | | | | | | 204 +----+ ++------+------------------------------+ | | +----+-++ +----+ 205 | | | | | | | | 206 | | | | | | | | 207 | +-------------------------------------------+ | 208 | | | | | | | | 209 | | | | +----------+ | 210 | | | | | | | | 211 | | | | +-----+ | | 212 | | | | | | | | 213 +----+ ++----+-+-+ | +-+-+--+-++ +----+ 214 | R3 | | R12 | | L2 adjacency | R32 | | R6 | 215 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 216 | | | | | | | | | 217 +----+ +-------+----+ +-------+ +----+ 219 Figure 2: Example topology represented in L2 with a full mesh of 220 L2 adjacencies between L1/L2 nodes 222 BGP, as specified in [RFC4271], faced a similar scaling problem, 223 which has been solved in many networks by deploying BGP route 224 reflectors [RFC4456]. We note that BGP route reflectors do not 225 necessarily have to be in the forwarding path of the traffic. This 226 non-congruity of forwarding and control path for BGP route reflectors 227 allows the control plane to scale independently of the forwarding 228 plane and represents an interesting degree of freedom in network 229 architecture. 231 We propose in this document a similar solution for IS-IS and call it 232 "flood reflection" in fashion analogous to "route reflection". A 233 simple example of what a flood reflector control plane approach would 234 look like is shown in Figure 3, where router R21 plays the role of a 235 flood reflector. Each L1/L2 ingress/egress router builds a tunnel to 236 the flood reflector, and an L2 adjacency is built over each tunnel. 237 In this solution, we need only 6 L2 adjacencies, instead of the 15 238 needed for a full mesh. In a somewhat larger topology containing 20 239 L1/L2 nodes, this solution requires only 20 L2 adjacencies, instead 240 of the 190 needed for a full mesh. Multiple flood reflectors can be 241 used, allowing the network operator to balance between resilience, 242 path utilization, and state in the control plane. The resulting L2 243 adjacency scale is R*n, where R is the number of flood reflectors 244 used and n is the number of L1/L2 nodes. This compares quite 245 favorably with n*(n-1)/2 L2 adjacencies required in a topologically 246 fully meshed L2 solution. 248 +----+ +-------+ +-------+ +----+ 249 | R1 | | R10 | | R30 | | R4 | 250 | L2 +--+ L1/L2 +--------------+ +-----------------+ L1/L2 +--+ L2 | 251 | | | | L2 adj | | L2 adj | | | | 252 +----+ +-------+ over | | over +-------+ +----+ 253 tunnel | | tunnel 254 +----+ +-------+ +--+---+--+ +-------+ +----+ 255 | R2 | | R11 | | R21 | | R31 | | R5 | 256 | L2 +--+ L1/L2 +-----------+ L1/L2 +--------------+ L1/L2 +--+ L2 | 257 | | | | L2 adj | flood | L2 adj | | | | 258 +----+ +-------+ over |reflector| over +-------+ +----+ 259 tunnel +--+---+--+ tunnel 260 +----+ +-------+ | | +-------+ +----+ 261 | R3 | | R12 +--------------+ +-----------------+ R32 | | R6 | 262 | L2 +--+ L1/L2 | L2 adj L2 adj | L1/L2 +--+ L2 | 263 | | | | over over | | | | 264 +----+ +-------+ tunnel tunnel +-------+ +----+ 266 Figure 3: Example topology represented in L2 with L2 adjacencies 267 from each L1/ L2 node to a single flood reflector 269 As illustrated in Figure 3, when R21 plays the role of flood 270 reflector, it provides L2 connectivity among all of the previously 271 disconnected L2 islands by reflooding all L2 LSPDUs. At the same 272 time, R20 and R22 in Figure 1 remain L1-only routers. L1-only 273 routers and L1-only links are not visible in L2. In this manner, the 274 flood reflector allows us provide L2 control plane connectivity in a 275 manner more scalable than a flat L2 domain. 277 As described so far, the solution illustrated in Figure 3 relies only 278 on currently standardized IS-IS functionality. Without new 279 functionality, however, the data traffic will traverse only R21. 280 This will unnecessarily create a bottleneck at R21 since there is 281 still available capacity in the paths crossing the L1-only routers 282 R20 and R22 in Figure 1. 284 Hence, additional functionality is compulsory to allow the L1/L2 edge 285 nodes (R10-12 and R30-32 in Figure 3) to recognize that the L2 286 adjacency to R21 should not be used for forwarding. The L1/L2 edge 287 nodes should forward traffic that would normally be forwarded over 288 the L2 adjacency to R21 over L1 links instead. This would allow the 289 forwarding within the L1 area to use the L1-only nodes and links 290 shown in Figure 1 as well. It allows networks to be built that use 291 the entire forwarding capacity of the L1 areas, while at the same 292 time introducing control plane scaling benefits provided by L2 flood 293 reflectors. 295 It is expected that deployment at scale, and suitable time in 296 operation, will provide sufficient evidence to either make this 297 extension a standard, or suggest necessary modifications to 298 accomplish this. 300 The remainder of this document defines the remaining extensions 301 necessary for a complete flood reflection solution: 303 * It defines a special 'flood reflector adjacency' built for the 304 purpose of reflecting flooding information. These adjacencies 305 allow 'flood reflectors' to participate in the IS-IS control plane 306 without necessarily being used in the forwarding plane. 307 Maintenance of such adjacencies is a purely local operation on the 308 L1/L2 ingress and flood reflectors; it does not require replacing 309 or modifying any routers not involved in the reflection process. 310 In practical deployments, it is far less tricky to just upgrade 311 the routers involved in flood reflection rather than have a flag 312 day for the whole IS-IS domain. 314 * It specifies an (optional) full mesh of tunnels between the L1/L2 315 ingress routers, ideally load-balancing across all available L1 316 links. This harnesses all forwarding paths between the L1/L2 edge 317 nodes without injecting unneeded state into the L2 flooding domain 318 or creating 'choke points' at the 'flood reflectors' themselves. 319 The specification is agnostic as to the tunneling technology used 320 but provides enough information for automatic establishment of 321 such tunnels if desired. The discussion of IS-IS adjacency 322 formation and/or liveness discovery on such tunnels is outside the 323 scope of this specification and is largely a choice of the 324 underlying implementation. A solution without tunnels is also 325 possible by introducing the correct scoping of reachability 326 information between the levels. This is described in more detail 327 later. 329 * Finally, the document defines support of reflector redundancy and 330 an (optional) way to auto-discover and annotate flood reflector 331 adjacencies on advertisements. Such additional information in 332 link advertisements allows L2 nodes outside the L1 area to 333 recognize a flood reflection cluster and its adjacencies. 335 2. Glossary 337 The following terms are used in this document. 339 ISIS Level-1 and Level-2 areas, mostly abbreviated as L1 and L2: 340 Traditional ISIS concepts whereas a routing domain has two 341 "levels" with a single L2 area being the "backbone" that connects 342 multiple L1 areas for scaling and reliability purposes. In 343 traditional ISIS L2 can be used as transit for L1-L1 traffic but 344 L1 areas cannot be used for that purpose since L2 level must be 345 "connected" and all traffic flows along L2 routers until it 346 arrives at the destination L1 area. 348 Flood Reflector: 349 Node configured to connect in L2 only to flood reflector clients 350 and reflect (reflood) IS-IS L2 LSPs amongst them. 352 Flood Reflector Client: 353 Node configured to build Flood Reflector Adjacencies to Flood 354 Reflectors, and normal adjacencies to other clients and L2 nodes 355 not participating in flood reflection. 357 Flood Reflector Adjacency: 358 IS-IS L2 adjacency where one end is a Flood Reflector Client and 359 the other a Flood Reflector, and the two have the same Flood 360 Reflector Cluster ID. 362 Flood Reflector Cluster: 363 Collection of clients and flood reflectors configured with the 364 same cluster identifier. 366 Tunnel-Based Deployment: 367 Deployment where Flood Reflector Clients build a partial or full 368 mesh of tunnels in L1 to "shortcut" forwarding of L2 traffic 369 through the cluster. 371 No-Tunnel Deployment: 372 Deployment where Flood Reflector Clients redistribute L2 373 reachability into L1 to allow forwarding through the cluster 374 without underlying tunnels. 376 Tunnel Endpoint: 377 An endpoint that allows the establishment of a bi-directional 378 tunnel carrying IS-IS control traffic or alternately, serves as 379 the origin of such a tunnel. 381 L1 shortcut: 382 A tunnel between two clients visible in L1 only that is used as a 383 next-hop, i.e. to carry data traffic in tunnel-based deployment 384 mode. 386 Hot-Potato Routing: 387 In context of this document, a routing paradigm where L2->L1 388 routes are less preferred than L2 routes [RFC5302]. 390 3. Further Details 392 Several considerations should be noted in relation to such a flood 393 reflection mechanism. 395 First, this allows multi-area IS-IS deployments to scale without any 396 major modifications in the IS-IS implementation on most of the nodes 397 deployed in the network. Unmodified (traditional) L2 routers will 398 compute reachability across the transit L1 area using the flood 399 reflector adjacencies. 401 Second, the flood reflectors are not required to participate in 402 forwarding traffic through the L1 transit area. These flood 403 reflectors can be hosted on virtual devices outside the forwarding 404 topology. 406 Third, astute readers will realize that flooding reflection may cause 407 the use of suboptimal paths. This is similar to the BGP route 408 reflection suboptimal routing problem described in 409 [ID.draft-ietf-idr-bgp-optimal-route-reflection-28]. The L2 410 computation determines the egress L1/L2 and with that can create 411 illusions of ECMP where there is none, and in certain scenarios lead 412 to an L1/L2 egress which is not globally optimal. This represents a 413 straightforward instance of the trade-off between the amount of 414 control plane state and the optimal use of paths through the network 415 often encountered when aggregating routing information. 417 One possible solution to this problem is to expose additional 418 topology information into the L2 flooding domains. In the example 419 network given, links from router R10 to router R11 can be exposed 420 into L2 even when R10 and R11 are participating in flood reflection. 421 This information would allow the L2 nodes to build 'shortcuts' when 422 the L2 flood reflected part of the topology looks more expensive to 423 cross distance wise. 425 Another possible variation is for an implementation to approximate 426 with the tunnel cost the cost of the underlying topology. 428 Redundancy can be achieved by configuring multiple flood reflectors 429 in a L1 area. Multiple flood reflectors do not need any 430 synchronization mechanisms amongst themselves, except standard IS-IS 431 flooding and database maintenance procedures. 433 4. Encodings 435 4.1. Flood Reflection TLV 437 The Flood Reflection TLV is a top-level TLV that MUST appear in L2 438 IIHs on all Flood Reflection Adjacencies. The Flood Reflection TLV 439 indicates the flood reflector cluster (based on Flood Reflection 440 Cluster ID) that a given router is configured to participate in. It 441 also indicates whether the router is configured to play the role of 442 either flood reflector or flood reflector client. The Flood 443 Reflection Cluster ID and flood reflector roles advertised in the 444 IIHs are used to ensure that flood reflector adjacencies are only 445 formed between a flood reflector and flood reflector client, and that 446 the Flood Reflection Cluster IDs match. The Flood Reflection TLV has 447 the following format: 449 0 1 2 3 450 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 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Type | Length |C| RESERVED | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Flood Reflection Cluster ID | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Sub-TLVs ... 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Type: 161 461 Length: The length, in octets, of the following fields. 463 C (Client): This bit is set to indicate that the router acts as a 464 flood reflector client. When this bit is NOT set, the router acts 465 as a flood reflector. On a given router, the same value of the 466 C-bit MUST be advertised across all interfaces advertising the 467 Flood Reflection TLV in IIHs. 469 RESERVED: This field is reserved for future use. It MUST be set to 470 0 when sent and MUST be ignored when received. 472 Flood Reflection Cluster ID: Flood Reflection Cluster Identifier. 473 The same arbitrary 32-bit value MUST be assigned to all of the 474 flood reflectors and flood reflector clients in the same L1 area. 475 The value MUST be unique across different L1 areas within the IGP 476 domain. In case of violation of those rules multiple L1 areas may 477 become a single cluster or a single area may split in flood 478 reflection sense and several mechanisms such as auto-discovery of 479 tunnels may not work correctly. On a given router, the same value 480 of the Flood Reflection Cluster ID MUST be advertised across all 481 interfaces advertising the Flood Reflection TLV in IIHs. When a 482 router discovers that a node is using more than a single Cluster 483 IDs based on its advertised TLVs and IIHs, the node MAY log such 484 violations subject to rate limiting. This implies that a flood 485 reflector MUST NOT participate in more than a single L1 area. In 486 case of Cluster ID value of 0, the TLV containing it MUST be 487 ignored. 489 Sub-TLVs: Optional sub-TLVs. For future extensibility, the format 490 of the Flood Reflection TLV allows for the possibility of 491 including optional sub-TLVs. No sub-TLVs of the Flood Reflection 492 TLV are defined in this document. 494 The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. 495 A router receiving one or more Flood Reflection TLVs in the same IIH 496 MUST use the values in the first TLV and it SHOULD log such 497 violations subject to rate limiting. 499 4.2. Flood Reflection Discovery Sub-TLV 501 The Flood Reflection Discovery sub-TLV is advertised as a sub-TLV of 502 the IS-IS Router Capability TLV-242, defined in [RFC7981]. The Flood 503 Reflection Discovery sub-TLV is advertised in L1 and L2 LSPs with 504 area flooding scope in order to enable the auto-discovery of flood 505 reflection capabilities. The Flood Reflection Discovery sub-TLV has 506 the following format: 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Type | Length |C| Reserved | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | Flood Reflection Cluster ID | 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Type: 161 518 Length: The length, in octets, of the following fields. 520 C (Client): This bit is set to indicate that the router acts as a 521 flood reflector client. When this bit is NOT set, the router acts 522 as a flood reflector. 524 RESERVED: This field is reserved for future use. It MUST be set to 525 0 when sent and MUST be ignored when received. 527 Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier 528 is the same as that defined in the Flood Reflection TLV and obeys 529 the same rules. 531 The Flood Reflection Discovery sub-TLV SHOULD NOT appear more than 532 once in TLV 242. A router receiving one or more Flood Reflection 533 Discovery sub-TLVs in TLV 242 MUST use the values in the first sub- 534 TLV of the lowest numbered fragment and it SHOULD log such violations 535 subject to rate limiting. 537 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV 539 Flood Reflection Discovery Tunnel Type sub-sub-TLV is advertised 540 optionally as a sub-sub-TLV of the Flood Reflection Discovery Sub- 541 TLV, defined in Section 4.2. It allows the automatic creation of L2 542 tunnels to be used as flood reflector adjacencies and L1 shortcut 543 tunnels. The Flood Reflection Tunnel Type sub-sub-TLV has the 544 following format: 546 0 1 2 3 547 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 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+-+ 549 | Type | Length | Reserved |F| 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Tunnel Encapsulation Attribute | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Type: 161 555 Length: The length, in octets, of zero or more of the following 556 fields. 558 Reserved: SHOULD be 0 on transmission and MUST be ignored on 559 reception. 561 F Flag: When set indicates flood reflection tunnel endpoint, when 562 clear, indicates possible L1 shortcut tunnel endpoint. 564 Tunnel Encapsulation Attribute: Carries encapsulation type and 565 further attributes necessary for tunnel establishment as defined 566 in [RFC9012]. In context of this attribute the protocol Type sub- 567 TLV as defined in [RFC9012] MAY be included to ensure proper 568 encapsulation of IS-IS frames. In case such a sub-TLV is included 569 and the F flag is set (i.e. the resulting tunnel is a flood 570 reflector adjacency) this sub-TLV MUST include a type that allows 571 to carry encapsulated IS-IS frames. Furthermore, such tunnel type 572 MUST be able to transport IS-IS frames of size up to 573 `originatingL2LSPBufferSize`. 575 A flood reflector receiving Flood Reflection Discovery Tunnel Type 576 sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F flag set 577 (i.e. the resulting tunnel is a flood reflector adjacency) SHOULD use 578 one or more of the specified tunnel endpoints to automatically 579 establish one or more tunnels that will serve as flood reflection 580 adjacency(-ies) to the clients advertising the endpoints. 582 A flood reflection client receiving one or more Flood Reflection 583 Discovery Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub- 584 TLV with F flag clear (i.e. the resulting tunnel is used to support 585 tunnel-based mode) from other leaves MAY use one or more of the 586 specified tunnel endpoints to automatically establish one or more 587 tunnels that will serve as L1 tunnel shortcuts to the clients 588 advertising the endpoints. 590 In case of automatic flood reflection adjacency tunnels and in case 591 IS-IS adjacencies are being formed across L1 shortcuts all the 592 aforementioned rules in Section 4.5 apply as well. 594 Optional address validation procedures as defined in [RFC9012] MUST 595 be disregarded. 597 It remains to be observed that automatic tunnel discovery is an 598 optional part of the specification and can be replaced or mixed with 599 statically configured tunnels for either flood reflector adjacencies 600 and/or tunnel-based shortcuts. Specific implementation details how 601 both mechanisms interact are specific to an implementation and mode 602 of operation and are outside the scope of this document. 604 Flood reflector adjacencies rely on IS-IS L2 liveliness procedures. 605 In case of L1 shortcuts the mechanism used to ensure liveliness and 606 tunnel integrity are outside the scope of this document. 608 4.4. Flood Reflection Adjacency Sub-TLV 610 The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of 611 TLVs 22, 23, 25, 141, 222, and 223 (the "TLVs Advertising Neighbor 612 Information"). Its presence indicates that a given adjacency is a 613 flood reflector adjacency. It is included in L2 area scope flooded 614 LSPs. The Flood Reflection Adjacency sub-TLV has the following 615 format: 617 0 1 2 3 618 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 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Type | Length |C| Reserved | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Flood Reflection Cluster ID | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 Type: 161 627 Length: The length, in octets, of the following fields. 629 C (Client): This bit is set to indicate that the router advertising 630 this adjacency is a flood reflector client. When this bit is NOT 631 set, the router advertising this adjacency is a flood reflector. 633 RESERVED: This field is reserved for future use. It MUST be set to 634 0 when sent and MUST be ignored when received. 636 Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier 637 is the same as that defined in the Flood Reflection TLV and obeys 638 the same rules. 640 The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than 641 once in a given TLV. A router receiving one or more Flood Reflection 642 Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV 643 of the lowest numbered fragment and it SHOULD log such violations 644 subject to rate limiting. 646 4.5. Flood Reflection Discovery 648 A router participating in flood reflection as client or reflector 649 MUST be configured as an L1/L2 router. It MAY originate the Flood 650 Reflection Discovery sub-TLV with area flooding scope in L1 and L2. 651 Normally, all routers on the edge of the L1 area (those having 652 traditional L2 adjacencies) will advertise themselves as flood 653 reflector clients. Therefore, a flood reflector client will have 654 both traditional L2 adjacencies and flood reflector L2 adjacencies. 656 A router acting as a flood reflector MUST NOT form any traditional L2 657 adjacencies except with flood reflector clients. It will be an L1/L2 658 router only by virtue of having flood reflector L2 adjacencies. A 659 router desiring to act as a flood reflector MAY advertise itself as 660 such using the Flood Reflection Discovery sub-TLV in L1 and L2. 662 A given flood reflector or flood reflector client can only 663 participate in a single cluster, as determined by the value of its 664 Flood Reflection Cluster ID and should disregard other routers' TLVs 665 for flood reflection purposes if the cluster ID is not matching. 667 Upon reception of Flood Reflection Discovery sub-TLVs, a router 668 acting as flood reflector SHOULD initiate a tunnel towards each flood 669 reflector client with which it shares a Flood Reflection Cluster ID 670 using one or more of the tunnel encapsulations provided with F flag 671 is set. The L2 adjacencies formed over such tunnels MUST be marked 672 as flood reflector adjacencies. If the client or reflector has a 673 direct L2 adjacency with the according remote side it SHOULD use it 674 instead of instantiating a tunnel. 676 In case the optional auto-discovery mechanism is not implemented or 677 enabled a deployment MAY use statically configured tunnels to create 678 flood reflection adjacencies. 680 The IS-IS metrics for all flood reflection adjacencies in a cluster 681 SHOULD be identical. 683 Upon reception of Flood Reflection Discovery TLVs, a router acting as 684 a flood reflector client MAY initiate tunnels with L1-only 685 adjacencies towards any of the other flood reflector clients with 686 lower router IDs in its cluster using encapsulations with F flag 687 clear. These tunnels MAY be used for forwarding to improve the load- 688 balancing characteristics of the L1 area. If the clients have a 689 direct L2 adjacency they SHOULD use it instead of instantiating a new 690 tunnel. 692 4.6. Flood Reflection Adjacency Formation 694 In order to simplify implementation complexity, this document does 695 not allow the formation of complex hierarchies of flood reflectors 696 and clients or allow multiple clusters in a single L1 area. 697 Consequently, all flood reflectors and flood reflector clients in the 698 same L1 area MUST share the same Flood Reflector Cluster ID. 699 Deployment of multiple cluster IDs in the same L1 area are outside 700 the scope of this document. 702 A flood reflector MUST NOT form flood reflection adjacencies with 703 flood reflector clients with a different Cluster ID. A flood 704 reflector MUST NOT form any traditional L2 adjacencies. 706 Flood reflector clients MUST NOT form flood reflection adjacencies 707 with flood reflectors with a different Cluster ID. 709 Flood reflector clients MAY form traditional L2 adjacencies with 710 flood reflector clients or nodes not participating in flood 711 reflection. When two flood reflector clients form a traditional L2 712 adjacency the Cluster IDs are disregarded. 714 The Flood Reflector Cluster ID and flood reflector roles advertised 715 in the Flood Reflection TLVs in IIHs are used to ensure that flood 716 reflection adjacencies that are established meet the above criteria. 718 On change in either flood reflection role or cluster ID on IIH on the 719 local or remote side the adjacency has to be reset. It is then re- 720 established if possible. 722 Once a flood reflection adjacency is established, the flood reflector 723 and the flood reflector client MUST advertise the adjacency by 724 including the Flood Reflection Adjacency Sub-TLV in the Extended IS 725 reachability TLV or MT-ISN TLV. 727 5. Route Computation 729 To ensure loop-free routing, the flood reflection client MUST follow 730 the normal L2 computation to determine L2 routes. This is because 731 nodes outside the L1 area will generally not be aware that flood 732 reflection is being performed. The flood reflection clients need to 733 produce the same result for the L2 route computation as a router not 734 participating in flood reflection. 736 5.1. Tunnel-Based Deployment 738 In the tunnel-based option the reflection client, after L2 and L1 739 computation, MUST examine all L2 routes with flood reflector next-hop 740 adjacencies. Such next-hops must be replaced by the corresponding 741 tunnel next-hops to the correct egress nodes of the flood reflection 742 cluster. 744 5.2. No-Tunnel Deployment 746 In case of deployment without underlying tunnels, the necessary L2 747 routes are distributed into the area, normally as L2->L1 routes. Due 748 to the rules in Section 4.6 the computation in the resulting topology 749 is relatively simple, the L2 SPF from a flood reflector client is 750 guaranteed to reach the Flood Reflector within a single hop, and in 751 the following hop the L2 egress to which it has a forwarding tunnel. 752 All the flood reflector tunnel nexthops in the according L2 route can 753 hence be removed and if the L2 route has no other ECMP L2 nexthops, 754 the L2 route MUST be suppressed in the RIB by some means to allow the 755 less preferred L2->L1 route to be used to forward traffic towards the 756 advertising egress. 758 In the particular case the client has L2 routes which are not flood 759 reflected, those will be naturally preferred (such routes normally 760 "hot-potato" packets out of the L1 area). However in the case the L2 761 route through the flood reflector egress is "shorter" than such 762 present non flood reflected L2 routes, the node SHOULD ensure that 763 such routes are suppressed so the L2->L1 towards the egress still 764 takes preference. Observe that operationally this can be resolved in 765 a relatively simple way by configuring flood reflector adjacencies to 766 have a high metric, i.e. the flood reflector topology becomes "last 767 resort" and the leaves will try to "hot-potato" out the area as fast 768 as possible which is normally the desirable behavior. 770 In No-tunnel deployment all L1/L2 edge nodes MUST be flood reflection 771 clients. 773 6. Redistribution of Prefixes 775 In case of no-tunnel deployment per Section 5.2 a client that does 776 not have any L2 flood reflector adjacencies MUST NOT redistribute L2 777 routes into the cluster. 779 The L2 prefix advertisements redistributed into an L1 that contains 780 flood reflectors SHOULD be normally limited to L2 intra-area routes 781 (as defined in [RFC7775]), if the information exists to distinguish 782 them from other L2 prefix advertisements. 784 On the other hand, in topologies that make use of flood reflection to 785 hide the structure of L1 areas while still providing transit 786 forwarding across them using tunnels, we generally do not need to 787 redistribute L1 prefix advertisements into L2. 789 7. Special Considerations 791 In pathological cases setting the overload bit in L1 (but not in L2) 792 can partition L1 forwarding, while allowing L2 reachability through 793 flood reflector adjacencies to exist. In such a case a node cannot 794 replace a route through a flood reflector adjacency with a L1 795 shortcut and the client MAY use the L2 tunnel to the flood reflector 796 for forwarding but in any case it MUST initiate an alarm and declare 797 misconfiguration. 799 A flood reflector with directly L2 attached prefixes should advertise 800 those in L1 as well since based on preference of L1 routes the 801 clients will not try to use the L2 flood reflector adjacency to route 802 the packet towards them. A very unlikely corner case can occur when 803 the flood reflector is reachable via L2 flood reflector adjacency 804 (due to underlying L1 partition) exclusively, in which case the 805 client can use the L2 tunnel to the flood reflector for forwarding 806 towards those prefixes while it MUST initiate an alarm and declare 807 misconfiguration. 809 A flood reflector MUST NOT set the attached bit on its LSPs. 811 In certain cases where reflectors are attached to same broadcast 812 medium, and where some other L2 router, which is neither a flood 813 reflector nor a flood reflector client (a "non-FR router"), attaches 814 to the same broadcast medium, flooding between the reflectors in 815 question might not succeed, potentially partitioning the flood 816 reflection domain. This could happen specifically in the event that 817 the non-FR router is chosen as the designated intermediate system 818 ("DIS", the designated router). Since, per Section 4.6, a flood 819 reflector MUST NOT form an adjacency with a non-FR router, the flood 820 reflector(s) will not be represented in the pseudo-node. 822 To avoid this situation, it is RECOMMENDED that flood reflectors not 823 be deployed on the same broadcast medium as non-FR routers. 825 A router discovering such condition MUST initiate an alarm and 826 declare misconfiguration. 828 8. IANA Considerations 830 This document requests allocation for the following IS-IS TLVs and 831 Sub-TLVs, and requests creation of a new registry. 833 8.1. New IS-IS TLV Codepoint 835 This document requests the following IS-IS TLV under the IS-IS Top- 836 Level TLV Codepoints registry:: 838 Value Name IIH LSP SNP Purge 839 ----- --------------------------------- --- --- --- ----- 840 161 Flood Reflection y n n n 842 8.2. Sub TLVs for IS-IS Router CAPABILITY TLV 844 This document request the following registration in the "sub-TLVs for 845 IS-IS Router CAPABILITY TLV" registry. 847 Type Description 848 ---- ----------- 849 161 Flood Reflection Discovery 851 8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV 853 This document requests creation of a new registry named "Sub-sub TLVs 854 for Flood Reflection Discovery sub-TLV" under the "IS-IS TLV 855 Codepoints" grouping. The Registration Procedures for this registry 856 are Expert Review, following the common expert review guidance given 857 for the grouping. 859 The range of values in this registry is 0-255. The registry should 860 be seeded with the following initial registration: 862 Type Description 863 ---- ----------- 864 161 Flood Reflection Discovery Tunnel Encapsulation Attribute 866 8.4. Sub TLVs for TLVs Advertising Neighbor Information 868 This document requests the following registration in the "IS-IS Sub- 869 TLVs for TLVs Advertising Neighbor Information" registry. 871 Type Description 22 23 25 141 222 223 872 ---- -------------------------------- --- --- --- --- --- --- 873 161 Flood Reflector Adjacency y y n y y y 875 9. Security Considerations 877 This document uses flood reflection tunnels to carry IS-IS control 878 traffic. If an attacker can inject traffic into such a tunnel, the 879 consequences could be in the most extreme case the complete 880 subversion of the IS-IS level 2 information. Therefore, a mechanism 881 inherent to the tunnel technology should be taken to prevent such 882 injection. Since the available security procedures will vary by 883 deployment and tunnel type, the details of securing tunnels are 884 beyond the scope of this document. 886 This document specifies information used to form dynamically 887 discovered shortcut tunnels. If an attacker were able to hijack the 888 endpoint of such a tunnel and form an adjacency, it could divert 889 short-cut traffic to itself, placing itself on-path and facilitating 890 on-path attacks or could even completely subvert the IS-IS level 2 891 routing. Therefore, steps should be taken to prevent such capture by 892 using mechanism inherent to the tunnel type used. Since the 893 available security procedures will vary by deployment and tunnel 894 type, the details of securing tunnels are beyond the scope of this 895 document. 897 Additionally, the usual IS-IS security mechanisms [RFC5304] SHOULD be 898 deployed to prevent misrepresentation of routing information by an 899 attacker in case a tunnel is compromised if the tunnel itself does 900 not provide mechanisms strong enough guaranteeing the integrity of 901 the messages exchanged. 903 10. Acknowledgements 905 The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem, Robert 906 Raszuk and Les Ginsberg for their thorough review and detailed 907 discussions. Thanks are also extended to Michael Richardson for an 908 excellent routing directorate review. John Scudder ultimately spent 909 significant time helping to make the document more comprehensible and 910 coherent. 912 11. References 914 11.1. Informative References 916 [ID.draft-ietf-idr-bgp-optimal-route-reflection-28] 917 Raszuk et al., R., "BGP Optimal Route Reflection", July 918 2019, . 921 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 922 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 923 DOI 10.17487/RFC4271, January 2006, 924 . 926 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 927 Reflection: An Alternative to Full Mesh Internal BGP 928 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 929 . 931 [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 932 Topology-Transparent Zone", RFC 8099, 933 DOI 10.17487/RFC8099, February 2017, 934 . 936 11.2. Normative References 938 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 939 Requirement Levels", BCP 14, RFC 2119, 940 DOI 10.17487/RFC2119, March 1997, 941 . 943 [RFC5302] Li, T., Smit, H., and T. Przygienda, "Domain-Wide Prefix 944 Distribution with Two-Level IS-IS", RFC 5302, 945 DOI 10.17487/RFC5302, October 2008, 946 . 948 [RFC5304] Li, T. and R. Atkinson, "IS-IS Cryptographic 949 Authentication", RFC 5304, DOI 10.17487/RFC5304, October 950 2008, . 952 [RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route 953 Preference for Extended IP and IPv6 Reachability", 954 RFC 7775, DOI 10.17487/RFC7775, February 2016, 955 . 957 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 958 for Advertising Router Information", RFC 7981, 959 DOI 10.17487/RFC7981, October 2016, 960 . 962 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 963 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 964 May 2017, . 966 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 967 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 968 DOI 10.17487/RFC9012, April 2021, 969 . 971 Authors' Addresses 973 Tony Przygienda (editor) 974 Juniper 975 1137 Innovation Way 976 Sunnyvale, CA 977 United States of America 978 Email: prz@juniper.net 980 Chris Bowers 981 Juniper 982 1137 Innovation Way 983 Sunnyvale, CA 984 United States of America 985 Email: cbowers@juniper.net 987 Yiu Lee 988 Comcast 989 1800 Bishops Gate Blvd 990 Mount Laurel, NJ 08054 991 United States of America 992 Email: Yiu_Lee@comcast.com 994 Alankar Sharma 995 Individual 996 Email: as3957@gmail.com 998 Russ White 999 Akamai 1000 Email: russ@riw.us