idnits 2.17.00 (12 Aug 2021) /tmp/idnits18966/draft-ietf-lsr-isis-flood-reflection-07.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 (9 December 2021) is 156 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: 12 June 2022 Y. Lee 6 A. Sharma 7 Comcast 8 R. White 9 Juniper 10 9 December 2021 12 IS-IS Flood Reflection 13 draft-ietf-lsr-isis-flood-reflection-07 15 Abstract 17 This document describes a backwards compatible, optional IS-IS 18 extension that allows the creation of IS-IS flood reflection 19 topologies. Flood reflection allows topologies in which L1 areas 20 provide transit forwarding for L2 using all available L1 nodes 21 internally. It accomplishes this by creating L2 flood reflection 22 adjacencies within each L1 area. Those adjacencies are used to flood 23 L2 LSPDUs, and they are used in the L2 SPF computation. However, 24 they are not used for forwarding within the flood reflection cluster. 25 This arrangement gives the L2 topology significantly better scaling 26 properties. As additional benefit, only those routers directly 27 participating in flood reflection have to support the feature. This 28 allows for the incremental deployment of scalable L1 transit areas in 29 an existing network, without the necessity of upgrading other routers 30 in the network. 32 Requirements Language 34 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 35 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 36 document are to be interpreted as described in RFC 2119 [RFC2119]. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at https://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on 12 June 2022. 55 Copyright Notice 57 Copyright (c) 2021 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 62 license-info) in effect on the date of publication of this document. 63 Please review these documents carefully, as they describe your rights 64 and restrictions with respect to this document. Code Components 65 extracted from this document must include Revised BSD License text as 66 described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Revised BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 3. Further Details . . . . . . . . . . . . . . . . . . . . . . . 9 74 4. Encodings . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 4.1. Flood Reflection TLV . . . . . . . . . . . . . . . . . . 10 76 4.2. Flood Reflection Discovery Sub-TLV . . . . . . . . . . . 11 77 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV . . . 12 78 4.4. Flood Reflection Adjacency Sub-TLV . . . . . . . . . . . 13 79 4.5. Flood Reflection Discovery . . . . . . . . . . . . . . . 14 80 4.6. Flood Reflection Adjacency Formation . . . . . . . . . . 15 81 5. Route Computation . . . . . . . . . . . . . . . . . . . . . . 16 82 5.1. Tunnel Based Deployment . . . . . . . . . . . . . . . . . 16 83 5.2. No Tunnel Deployment . . . . . . . . . . . . . . . . . . 16 84 6. Redistribution of Prefixes . . . . . . . . . . . . . . . . . 17 85 7. Special Considerations . . . . . . . . . . . . . . . . . . . 17 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 8.1. New IS-IS TLV Codepoint . . . . . . . . . . . . . . . . . 18 88 8.2. Sub TLVs for TLV 242 . . . . . . . . . . . . . . . . . . 18 89 8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV . . . 18 90 8.4. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 . . . . . 18 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 92 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 93 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 94 11.1. Informative References . . . . . . . . . . . . . . . . . 19 95 11.2. Normative References . . . . . . . . . . . . . . . . . . 19 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 99 1. Introduction 101 This section introduces the problem space and outlines the solution. 102 Some of the terms may be unfamiliar to reader without extensive IS-IS 103 background and in such case a glossary is provided in Section 2 and 104 can be referenced. 106 Due to the inherent properties of link-state protocols the number of 107 IS-IS routers within a flooding domain is limited by processing and 108 flooding overhead on each node. While that number can be maximized 109 by well written implementations and techniques such as exponential 110 back-offs, IS-IS will still reach a saturation point where no further 111 routers can be added to a single flooding domain. In some L2 112 backbone deployment scenarios, this limit presents a significant 113 challenge. 115 The traditional approach to increasing the scale of an IS-IS 116 deployement is to break it up into multiple L1 flooding domains and a 117 single L2 backbone. This works well for designs where an L2 backbone 118 connects L1 access topologies, but it is limiting where a large L2 is 119 supposed to span large number of routers. In such scenarios, an 120 alternative approach is to consider multiple L2 flooding domains 121 connected together via L1 flooding domains. In other words, L2 122 flooding domains are connected by "L1/L2 lanes" through the L1 areas 123 to form a single L2 backbone again. Unfortunately, in its simplest 124 implementation, this requires the inclusion of most, or all, of the 125 transit L1 routers as L1/L2 to allow traffic to flow along optimal 126 paths through such transit areas. Consequently, this approach fails 127 to reduce the number of L2 routers involved, so it fails to increase 128 the scalability of the L2 backbone. 130 +====+ +=======+ +=======+ +======-+ +====+ 131 I R1 I I R10 +-------------+ R20 +---------------+ R30 I I R4 I 132 I L2 +--+ L1/L2 I I L1 I I L1/L2 +--+ L2 I 133 I I I + +--+ I +------------+ I I I 134 +====+ ++====+=+ | +===+===+ | +=+==+=++ +====+ 135 | | | | | | | 136 | | | | | +-----------+ | 137 | +-------+ | | | | | 138 | | | | | | | 139 | | | | | | | 140 | | | | | | | 141 +====+ ++=====-+ | | +===+===+--+ | +======++ +====+ 142 I R2 I I R11 I | | I R21 I | I R31 I I R5 I 143 I L2 +--+ L1/L2 +-------------+ L1 +---------------+ L1/L2 +--+ L2 I 144 I I I I | | I I | +-------+ I I I 145 +====+ ++=====-+ | | ++==+==++ | | +======++ +====+ 146 | | | | | | | | | 147 | +---------------+ | | | | | | 148 | | | | | | | | | 149 | | +----------------+ | +-----------------+ | 150 | | | | | | | | | 151 +====+ ++=+==+=+ +-------+===+===+-----+ | ++=====++ +====+ 152 I R3 I I R12 I I R22 I | + R32 I I R6 I 153 I L2 +--+ L1/L2 I I L1 +-------+ I L1/L2 +--+ L2 I 154 I I I +-------------+ +---------------+ I I I 155 +====+ +=======+ +=======+ +=======+ +====+ 157 Figure 1: Example Topology of L1 with L2 Borders 159 Figure 1 is an example of a network where a topologically rich L1 160 area is used to provide transit between six different L2-only routers 161 (R1-R6). Note that the six L2-only routers do not have connectivity 162 to one another over L2 links. To take advantage of the abundance of 163 paths in the L1 transit area, all the intermediate systems could be 164 placed into both L1 and L2, but this essentially combines the 165 separate L2 flooding domains into a single one, triggering again 166 maximum L2 scale limitation we try to address in first place. 168 A more effective solution would allow to reduce the number of links 169 and routers exposed in L2, while still utilizing the full L1 topology 170 when forwarding through the network. 172 [RFC8099] describes Topology Transparent Zones (TTZ) for OSPF. The 173 TTZ mechanism represents a group of OSPF routers as a full mesh of 174 adjacencies between the routers at the edge of the group. A similar 175 mechanism could be applied to IS-IS as well. However, a full mesh of 176 adjacencies between edge routers (or L1/L2 nodes) significantly 177 limits the scale of the topology. The topology in Figure 1 has 6 L1/ 178 L2 nodes. Figure 2 illustrates a full mesh of L2 adjacencies between 179 the 6 L1/L2 nodes, resulting in (5 * 6)/2 = 15 L2 adjacencies. In a 180 somewhat larger topology containing 20 L1/L2 nodes, the number of L2 181 adjacencies in a full mesh rises to 190. 183 +----+ +-------+ +-------------------------------+-------+ +----+ 184 | R1 | | R10 | | | R30 | | R4 | 185 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 186 | | | | | | | | | 187 +----+ ++-+-+--+-+ | +-+--+---++ +----+ 188 | | | | | | | | 189 | +----------------------------------------------+ | 190 | | | | | | | | 191 | +-----------------------------------+ | | | | 192 | | | | | | | | 193 | +----------------------------------------+ | | 194 | | | | | | | | 195 +----+ ++-----+- | | | | -----+-++ +----+ 196 | R2 | | R11 | | | | | | R31 | | R5 | 197 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 198 | | | | | | | | | | | | 199 +----+ ++------+------------------------------+ | | +----+-++ +----+ 200 | | | | | | | | 201 | | | | | | | | 202 | +-------------------------------------------+ | 203 | | | | | | | | 204 | | | | +----------+ | 205 | | | | | | | | 206 | | | | +-----+ | | 207 | | | | | | | | 208 +----+ ++----+-+-+ | +-+-+--+-++ +----+ 209 | R3 | | R12 | | L2 adjacency | R32 | | R6 | 210 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 211 | | | | | | | | | 212 +----+ +-------+----+ +-------+ +----+ 214 Figure 2: Example topology represented in L2 with a full mesh of 215 L2 adjacencies between L1/L2 nodes 217 BGP, as specified in [RFC4271], faced a similar scaling problem, 218 which has been solved in many networks by deploying BGP route 219 reflectors [RFC4456]. We note that BGP route reflectors do not 220 necessarily have to be in the forwarding path of the traffic. This 221 incongruity of forwarding and control path for BGP route reflectors 222 allows the control plane to scale independently of the forwarding 223 plane. 225 We propose here a similar solution for IS-IS. A simple example of 226 what a flood reflector control plane approach would look like is 227 shown in Figure 3, where router R21 plays the role of a flood 228 reflector. Each L1/L2 ingress/egress router builds a tunnel to the 229 flood reflector, and an L2 adjacency is built over each tunnel. In 230 this solution, we need only 6 L2 adjacencies, instead of the 15 231 needed for a full mesh. In a somewhat larger topology containing 20 232 L1/L2 nodes, this solution requires only 20 L2 adjacencies, instead 233 of the 190 need for a full mesh. Multiple flood reflectors can be 234 used, allowing the network operator to balance between resilience, 235 path utilization, and state in the control plane. The resulting L2 236 adjacency scale is R*n, where R is the number of flood reflectors 237 used and n is the number of L1/L2 nodes. This compares quite 238 favorably with n*(n-1)/2 L2 adjacencies required in a topologically 239 fully meshed L2 solution. 241 +----+ +-------+ +-------+ +----+ 242 | R1 | | R10 | | R30 | | R4 | 243 | L2 +--+ L1/L2 +--------------+ +-----------------+ L1/L2 +--+ L2 | 244 | | | | L2 adj | | L2 adj | | | | 245 +----+ +-------+ over | | over +-------+ +----+ 246 tunnel | | tunnel 247 +----+ +-------+ +--+---+--+ +-------+ +----+ 248 | R2 | | R11 | | R21 | | R31 | | R5 | 249 | L2 +--+ L1/L2 +-----------+ L1/L2 +--------------+ L1/L2 +--+ L2 | 250 | | | | L2 adj | flood | L2 adj | | | | 251 +----+ +-------+ over |reflector| over +-------+ +----+ 252 tunnel +--+---+--+ tunnel 253 +----+ +-------+ | | +-------+ +----+ 254 | R3 | | R12 +--------------+ +-----------------+ R32 | | R6 | 255 | L2 +--+ L1/L2 | L2 adj L2 adj | L1/L2 +--+ L2 | 256 | | | | over over | | | | 257 +----+ +-------+ tunnel tunnel +-------+ +----+ 259 Figure 3: Example topology represented in L2 with L2 adjacencies 260 from each L1/ L2 node to a single flood reflector 262 As illustrated in Figure 3, when R21 plays the role of flood 263 reflector, it provides L2 connectivity among all of the previously 264 disconnected L2 islands by reflooding all L2 LSPDUs. At the same 265 time, R20 and R22 in Figure 1 remain L1-only routers. L1-only 266 routers and L1-only links are not visible in L2. In this manner, the 267 flood reflector allows us provide L2 control plane connectivity in a 268 scalable manner. 270 As described so far, the solution illustrated in Figure 3 relies only 271 on currently standardized IS-IS functionality. Without new 272 functionality, however, the data traffic will traverse only R21. 273 This will unnecessarily create a bottleneck at R21 since there is 274 still available capacity in the paths crossing the L1-only routers 275 R20 and R22 in Figure 1. 277 Hence, some new functionality is necessary to allow the L1/L2 edge 278 nodes (R10-12 and R30-32 in Figure 3) to recognize that the L2 279 adjacency to R21 should not be used for forwarding. The L1/L2 edge 280 nodes should forward traffic that would normally be forwarded over 281 the L2 adjacency to R21 over L1 links instead. This would allow the 282 forwarding within the L1 area to use the L1-only nodes and links 283 shown in Figure 1 as well. It allows networks to be built that use 284 the entire forwarding capacity of the L1 areas, while at the same 285 time introducing control plane scaling benefits provided by L2 flood 286 reflectors. 288 This document defines all extensions necessary to support flood 289 reflector deployment: 291 * A 'flood reflector adjacency' for all the adjacencies built for 292 the purpose of reflecting flooding information. This allows these 293 'flood reflectors' to participate in the IS-IS control plane 294 without being used in the forwarding plane. This is a purely 295 local operation on the L1/L2 ingress; it does not require 296 replacing or modifying any routers not involved in the reflection 297 process. Deployment-wise, it is far less tricky to just upgrade 298 the routers involved in flood reflection rather than have a flag 299 day on the whole IS-IS domain. 301 * An (optional) full mesh of tunnels between the L1/L2 routers, 302 ideally load-balancing across all available L1 links. This 303 harnesses all forwarding paths between the L1/L2 edge nodes 304 without injecting unneeded state into the L2 flooding domain or 305 creating 'choke points' at the 'flood reflectors' themselves. The 306 draft is agnostic as to the tunneling technology used but provides 307 enough information for automatic establishment of such tunnels. 308 The discussion of IS-IS adjacency formation and/or liveness 309 discovery on such tunnels is outside the scope of this draft and 310 is largely choice of the underlying implementation. A solution 311 without tunnels is also possible by applying judicious scoping of 312 reachability information between the levels as described in more 313 details later. 315 * Some way to support reflector redundancy, and potentially some way 316 to auto-discover and advertise such adjacencies as flood reflector 317 adjacencies. Such advertisements may allow L2 nodes outside the 318 L1 to perform optimizations in the future based on this 319 information. 321 2. Glossary 323 This section is introduced with the intention of allowing quick 324 reference in the more detailed parts of the document to terms used 326 Flood Reflector: 327 Node configured to connect L2 only to flood reflector clients and 328 reflect (reflood) IS-IS L2 LSPs amongst them. 330 Flood Reflector Client: 331 Node configured to build flood reflector adjacencies and normal L2 332 nodes. 334 Flood Reflector Adjacency: 335 IS-IS L2 adjacency limited by one end being client and the other 336 reflector and agreeing on the same Flood Reflector Cluster ID. 338 Flood Reflector Cluster: 339 Collection of clients and flood reflectors configured with the 340 same cluster identifier. Cluster ID value of 0 SHOULD NOT be used 341 since it may be used in the future for special purposes. 343 Tunnel Deployment: 344 Deployment where flood reflector clients build a partial or full 345 mesh of tunnels in L1 to "shortcut" forwarding of L2 traffic 346 through the cluster. 348 No Tunnel Deployment: 349 Deployment where flood reflector clients redistribute L2 350 reachability into L1 to allow forwarding through the cluster 351 without underlying tunnels. 353 Tunnel Endpoint: 354 An endpoint that allows to establish a bi-directional tunnel 355 carrying ISIS control traffic or alternately serves as origin of 356 such tunnel. 358 L1 shortcut: 359 A tunnel between two clients visible in L1 only that is used as a 360 next-hop, i.e. to carry data traffic in tunnel deployment mode. 362 3. Further Details 364 Several considerations should be noted in relation to such a flood 365 reflection mechanism. 367 First, this allows multi-area IS-IS deployments to scale without any 368 major modifications in the IS-IS implementation on most of the nodes 369 deployed in the network. Unmodified (traditional) L2 routers will 370 compute reachability across the transit L1 area using the flood 371 reflector adjacencies. 373 Second, the flood reflectors are not required to participate in 374 forwarding traffic through the L1 transit area. These flood 375 reflectors can be hosted on virtual devices outside the forwarding 376 topology. 378 Third, astute readers will realize that flooding reflection may cause 379 the use of suboptimal paths. This is similar to the BGP route 380 reflection suboptimal routing problem described in 381 [ID.draft-ietf-idr-bgp-optimal-route-reflection-28]. The L2 382 computation determines the egress L1/L2 and with that can create 383 illusions of ECMP where there is none. And in certain scenarios lead 384 to an L1/L2 egress which is not globally optimal. This represents a 385 straightforward instance of the trade-off between the amount of 386 control plane state and the optimal use of paths through the network 387 often encountered when aggregating routing information. 389 One possible solution to this problem is to expose additional 390 topology information into the L2 flooding domains. In the example 391 network given, links from router 01 to router 02 can be exposed into 392 L2 even when 01 and 02 are participating in flood reflection. This 393 information would allow the L2 nodes to build 'shortcuts' when the L2 394 flood reflected part of the topology looks more expensive to cross 395 distance wise. 397 Another possible variation is for an implementation to approximate 398 with the tunnel cost the cost of the underlying topology. 400 Redundancy can be achieved by building multiple flood reflectors in a 401 L1 area. Multiple flood reflectors do not need any synchronization 402 mechanisms amongst themselves, except standard IS-IS flooding and 403 database maintenance procedures. 405 4. Encodings 406 4.1. Flood Reflection TLV 408 The Flood Reflection TLV is a new top-level TLV that MAY appear in L2 409 IIHs. The Flood Reflection TLV indicates the flood reflector cluster 410 (based on Flood Reflection Cluster ID) that a given router is 411 configured to participate in. It also indicates whether the router 412 is configured to play the role of either flood reflector or flood 413 reflector client. The Flood Reflection Cluster ID and flood 414 reflector roles advertised in the IIHs are used to ensure that flood 415 reflector adjacencies are only formed between a flood reflector and 416 flood reflector client, and that the Flood Reflection Cluster IDs 417 match. The Flood Reflection TLV has the following format: 419 0 1 2 3 420 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 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Type | Length |C| RESERVED | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | Flood Reflection Cluster ID | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | Sub-TLVs ... 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Type: TBD 431 Length: The length, in octets, of the following fields. 433 C (Client): This bit is set to indicate that the router acts as a 434 flood reflector client. When this bit is NOT set, the router acts 435 as a flood reflector. On a given router, the same value of the 436 C-bit MUST be advertised across all interfaces advertising the 437 Flood Reflection TLV in IIHs. 439 RESERVED: This field is reserved for future use. It MUST be set to 440 0 when sent and MUST be ignored when received. 442 Flood Reflection Cluster ID: Flood Reflection Cluster Identifier. 443 These same 32-bit value MUST be assigned to all of the flood 444 reflectors and flood reflector clients in the same L1 area. The 445 value MUST be unique across different L1 areas within the IGP 446 domain. In case of violation of those rules multiple L1 areas may 447 become a single cluster or a single area may split in flood 448 reflection sense and several mechanisms such as auto-discovery of 449 tunnels may not work correctly. On a given router, the same value 450 of the Flood Reflection Cluster ID MUST be advertised across all 451 interfaces advertising the Flood Reflection TLV in IIHs. When a 452 router discovers that a node is using multiple Cluster IDs based 453 on its advertised TLVs and IIHs, the node MAY adequately log such 454 violations subject to rate limiting. This implies that a flood 455 reflector MUST NOT participate in more than a single L1 area. In 456 case of Cluster ID value of 0, the TLV containing it MUST be 457 ignored. 459 Sub-TLVs: Optional sub-TLVs. For future extensibility, the format 460 of the Flood Reflection TLV allows for the possibility of 461 including optional sub-TLVs. No sub-TLVs of the Flood Reflection 462 TLV are defined in this document. 464 The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. 465 A router receiving multiple Flood Reflection TLVs in the same IIH 466 MUST use the values in the first TLV of the lowest numbered fragment 467 and it SHOULD adequately log such violations subject to rate 468 limiting. 470 4.2. Flood Reflection Discovery Sub-TLV 472 Flood Reflection Discovery sub-TLV is advertised as a sub-TLV of the 473 IS-IS Router Capability TLV-242, defined in [RFC7981]. The Flood 474 Reflection Discovery sub-TLV is advertised in L1 and L2 LSPs with 475 area flooding scope in order to enable the auto-discovery of flood 476 reflection capabilities. The Flood Reflection Discovery sub-TLV has 477 the following format: 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Type | Length |C| Reserved | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Flood Reflection Cluster ID | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 Type: TBD 489 Length: The length, in octets, of the following fields. 491 C (Client): This bit is set to indicate that the router acts as a 492 flood reflector client. When this bit is NOT set, the router acts 493 as a flood reflector. 495 RESERVED: This field is reserved for future use. It MUST be set to 496 0 when sent and MUST be ignored when received. 498 Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier 499 is the same as that defined in the Flood Reflection TLV and obeys 500 the same rules. 502 The Flood Reflection Discovery sub-TLV SHOULD NOT appear more than 503 once in TLV 242. A router receiving multiple Flood Reflection 504 Discovery sub-TLVs in TLV 242 MUST use the values in the first sub- 505 TLV of the lowest numbered fragment and it SHOULD adequately log such 506 violations subject to rate limiting. 508 4.3. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV 510 Flood Reflection Discovery Tunnel Type sub-sub-TLV is advertised 511 optionally as a sub-sub-TLV of the Flood Reflection Discovery Sub- 512 TLV, defined in Section 4.2. It allows the automatic creation of L2 513 tunnels to be used as flood reflector adjacencies and L1 shortcut 514 tunnels. The Flood Reflection Tunnel Type sub-sub-TLV has the 515 following format: 517 0 1 2 3 518 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 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 520 | Type | Length | Reserved |F| 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 522 | Tunnel Encapsulation Attribute | 523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 525 Type: TBD 527 Length: The length, in octets, of zero or more of the following 528 fields. 530 Reserved: SHOULD be 0 on transmission and ignored on reception. 532 F Flag: When set indicates flood reflection tunnel endpoint, when 533 clear, indicates possible L1 shortcut tunnel endpoint. 535 Tunnel Encapsulation Attribute: Carries encapsulation type and 536 further attributes necessary for tunnel establishment as defined 537 in [RFC9012]. Protocol type sub-TLV as defined in [RFC9012] MAY 538 be included but MUST when F flag is set include according type 539 that allows carrying of encapsulated IS-IS frames. Such tunnel 540 type MUST provide according mechanisms to carry up to 541 `originatingL2LSPBufferSize` sized IS-IS frames across. 543 A flood reflector receiving Flood Reflection Discovery Tunnel Type 544 sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F flag set 545 SHOULD use one or more of the specified tunnel endpoints to 546 automatically establish one or more tunnels that will serve as flood 547 reflection adjacency(-ies) to the clients advertising the endpoints. 549 A flood reflection client receiving multiple Flood Reflection 550 Discovery Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub- 551 TLV with F flag clear from other leaves MAY use one or more of the 552 specified tunnel endpoints to automatically establish one or more 553 tunnels that will serve as L1 tunnel shortcuts to the clients 554 advertising the endpoints. 556 In case of automatic flood reflection adjacency tunnels and in case 557 IS-IS adjacencies are being formed across L1 shortcuts all the 558 aforementioned rules in Section 4.5 apply as well. 560 Optional address validation procedures as defined in [RFC9012] MUST 561 be disregarded. 563 4.4. Flood Reflection Adjacency Sub-TLV 565 The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of 566 TLVs 22, 23, 25, 141, 222, and 223. Its presence indicates that a 567 given adjacency is a flood reflector adjacency. It is included in L2 568 area scope flooded LSPs. Flood Reflection Adjacency sub-TLV has the 569 following format: 571 0 1 2 3 572 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 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 574 | Type | Length |C| Reserved | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 576 | Flood Reflection Cluster ID | 577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 Type: TBD 581 Length: The length, in octets, of the following fields. 583 C (Client): This bit is set to indicate that the router advertising 584 this adjacency is a flood reflector client. When this bit is NOT 585 set, the router advertising this adjacency is a flood reflector. 587 RESERVED: This field is reserved for future use. It MUST be set to 588 0 when sent and MUST be ignored when received. 590 Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier 591 is the same as that defined in the Flood Reflection TLV and obeys 592 the same rules. 594 The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than 595 once in a given TLV. A router receiving multiple Flood Reflection 596 Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV 597 of the lowest numbered fragment and it SHOULD adequately log such 598 violations subject to rate limiting. 600 4.5. Flood Reflection Discovery 602 A router participating in flood reflection as client or reflector 603 MUST be configured as an L1/L2 router. It SHOULD originate the Flood 604 Reflection Discovery sub-TLV with area flooding scope in L1 and L2. 605 Normally, all routers on the edge of the L1 area (those having 606 traditional L2 adjacencies) will advertise themselves as route 607 reflector clients. Therefore, a flood reflector client will have 608 both traditional L2 adjacencies and flood reflector L2 adjacencies. 610 A router acting as a flood reflector MUST NOT have any traditional L2 611 adjacencies except with flood reflector clients. It will be an L1/L2 612 router only by virtue of having flood reflector L2 adjacencies. A 613 router desiring to act as a flood reflector SHOULD advertise itself 614 as such using the Flood Reflection Discovery sub-TLV in L1 and L2. 616 A given flood reflector or flood reflector client can only 617 participate in a single cluster, as determined by the value of its 618 Flood Reflection Cluster ID and should disregard other routers' TLVs 619 for flood reflection purposes if the cluster ID is not matching. 621 Upon reception of Flood Reflection Discovery sub-TLVs, a router 622 acting as flood reflector client SHOULD initiate a tunnel towards 623 each flood reflector with which it shares an Flood Reflection Cluster 624 ID using one or more of the tunnel encapsulations provided with F 625 flag being set. The L2 adjacencies formed over such tunnels MUST be 626 marked as flood reflector adjacencies. If the client or reflector 627 has a direct L2 adjacency with the according remote side it SHOULD 628 use it instead of instantiating a new tunnel. 630 In absence of auto-discovery an implementation MAY use statically 631 configured tunnels to create flood reflection adjacencies. 633 The IS-IS metrics for all flood reflection adjacencies in a cluster 634 SHOULD be uniform. 636 Upon reception of Flood Reflection Discover TLVs, a router acting as 637 a flood reflector client MAY initiate tunnels with L1-only 638 adjacencies towards any of the other flood reflector clients with 639 lower router IDs in its cluster using encapsulations with F flag 640 clear. These tunnels MAY be used for forwarding to improve the load- 641 balancing characteristics of the L1 area. If the clients have a 642 direct L2 adjacency they SHOULD use it instead of instantiating a new 643 tunnel. 645 4.6. Flood Reflection Adjacency Formation 647 In order to simplify both implementations and network deployments, 648 this draft does not allow the formation of complex hierarchies of 649 flood reflectors and clients or allow multiple clusters in a single 650 L1 area. Consequently, all flood reflectors and flood reflector 651 clients in the same L1 area MUST share the same Flood Reflector 652 Cluster ID. Deployment of multiple cluster IDs in the same L1 area 653 are outside the scope of this document. 655 A flood reflector MUST only form flood reflection adjacencies with 656 flood reflector clients with matching Cluster ID. A flood reflector 657 MUST NOT form any traditional L2 adjacencies. 659 Flood reflector clients MUST only form flood reflection adjacencies 660 with flood reflectors with matching Cluster ID. 662 Flood reflector clients MAY form traditional L2 adjacencies with 663 flood reflector clients or nodes not participating in flood 664 reflection. When two clients form traditional L2 adjacency Cluster 665 ID is disregarded. 667 The Flood Reflector Cluster ID and flood reflector roles advertised 668 in the Flood Reflection TLVs in IIHs are used to ensure that flood 669 reflection adjacencies that are established meet the above criteria. 671 On change in either flood reflection role or cluster ID on IIH on the 672 local or remote side the adjacency has to be reset and re-established 673 if possible. 675 Once a flood reflection adjacency is established, the flood reflector 676 and the flood reflector client MUST advertise the adjacency by 677 including the Flood Reflection Adjacency Sub-TLV in the Extended IS 678 reachability TLV or MT-ISN TLV. 680 5. Route Computation 682 To ensure loop-free routing, the route reflection client MUST follow 683 the normal L2 computation to determine L2 routes. This is because 684 nodes outside the L1 area will generally not be aware that flood 685 reflection is being performed. The flood reflection clients need to 686 produce the same result for the L2 route computation as a router not 687 participating in flood reflection. 689 5.1. Tunnel Based Deployment 691 In tunnel based option the reflection client, after L2 and L1 692 computation, MUST examine all L2 routes and replace all flood 693 reflector adjacencies with the correct underlying tunnel next-hop to 694 the egress. 696 5.2. No Tunnel Deployment 698 In case of deployment without underlying tunnels, the necessary L2 699 routes are distributed into the area, normally as L2->L1 routes. Due 700 to the rules in Section 4.6 the computation in the resulting topology 701 is relatively simple, the L2 SPF from a flood reflector client is 702 guaranteed to reach within a hop the Flood Reflector and in the 703 following hop the L2 egress to which it has a forwarding tunnel 704 again. All the flood reflector tunnel nexthops in the according L2 705 route can hence be removed and if the L2 route has no other ECMP L2 706 nexthops, the L2 route MUST be suppressed in the RIB by some means to 707 allow the less preferred L2->L1 route to be used to forward traffic 708 towards the advertising egress. 710 In the particular case the client has L2 routes which are not route 711 reflected, those will be naturally preferred (such routes normally 712 "hot-potato" route of the L1 area). However in the case the L2 route 713 through the flood reflector egress is "shorter" than such present non 714 flood reflected L2 routes, the node SHOULD ensure that such routes 715 are suppressed so the L2->L1 towards the egress still takes 716 preference. Observe that operationally this can be resolved in a 717 relatively simple way by configuring flood reflector adjacencies to 718 have a high metric, i.e. the flood reflector topology becomes "last 719 resort" and the leaves will try to "hot-potato" out the area as fast 720 as possible which is normally the desirable behavior. 722 In deployment scenarios where tunnels are not used, all L1/L2 edge 723 nodes MUST be ultimately flood reflector clients except during during 724 transition phase. 726 6. Redistribution of Prefixes 728 When L2 prefixes need to be redistributed into L1 by the route 729 reflector clients a client that does not have any L2 flood reflector 730 adjacencies MUST NOT redistribute those routes into the area in case 731 of application of Section 5.2. The L2 prefixes advertisements 732 redistributed into L1 with flood reflectors SHOULD be normally 733 limited to L2 intra-area routes (as defined in [RFC7775]), if the 734 information exists to distinguish them from other other L2 prefix 735 advertisements. 737 On the other hand, in topologies that make use of flood reflection to 738 hide the structure of L1 areas while still providing transit 739 forwarding across them using tunnels, we generally do not need to 740 redistribute L1 prefixes advertisements into L2. 742 7. Special Considerations 744 In pathological cases setting the overload bit in L1 (but not in L2) 745 can partition L1 forwarding, while allowing L2 reachability through 746 flood reflector adjacencies to exist. In such a case a node cannot 747 replace a route through a flood reflector adjacency with a L1 748 shortcut and the client can use the L2 tunnel to the flood reflector 749 for forwarding while it MUST initiate an alarm and declare 750 misconfiguration. 752 A flood reflector with directly L2 attached prefixes should advertise 753 those in L1 as well since based on preference of L1 routes the 754 clients will not try to use the L2 flood reflector adjacency to route 755 the packet towards them. A very, very corner case is when the flood 756 reflector is reachable via L2 flood reflector adjacency (due to 757 underlying L1 partition) only in which case the client can use the L2 758 tunnel to the flood reflector for forwarding towards those prefixes 759 while it MUST initiate an alarm and declare misconfiguration. 761 A flood reflector SHOULD NOT set the attached bit on its LSPs. 763 Instead of modifying the computation procedures one could imagine a 764 flood reflector solution where the Flood Reflector would re-advertise 765 the L2 prefixes with a 'third-party' next-hop but that would have 766 less desirable convergence properties than the solution proposed and 767 force a fork-lift of all L2 routers to make sure they disregard such 768 prefixes unless in the same L1 domain as the Flood Reflector. 770 Depending on pseudo-node choice in case of a broadcast domain with 771 multiple flood reflectors attached this can lead to a partitioned LAN 772 and hence a router discovering such a condition MUST initiate an 773 alarm and declare misconfiguration. 775 8. IANA Considerations 777 This document requests allocation for the following IS-IS TLVs and 778 Sub-TLVs. 780 8.1. New IS-IS TLV Codepoint 782 This document requests the following IS-IS TLV: 784 Value Name IIH LSP SNP Purge 785 ----- --------------------------------- --- --- --- ----- 786 TBD1 Flood Reflection y n n n 788 Suggested value for TBD1 is 161. 790 8.2. Sub TLVs for TLV 242 792 This document request the following registration in the "sub-TLVs for 793 TLV 242" registry. 795 Type Description 796 ---- ----------- 797 TBD2 Flood Reflection Discovery 799 Suggested value for TBD2 is 161. 801 8.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV 803 This document request the following registration in the "sub-sub-TLVs 804 for Flood Reflection Discovery sub-TLV" registry. 806 Type Description 807 ---- ----------- 808 TBD3 Flood Reflection Discovery Tunnel Encapsulation Attribute 810 Suggested value for TBD3 is 161. 812 8.4. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 814 This document requests the following registration in the "sub-TLVs 815 for TLV 22, 23, 25, 141, 222, and 223" registry. 817 Type Description 22 23 25 141 222 223 818 ---- -------------------------------- --- --- --- --- --- --- 819 TBD4 Flood Reflector Adjacency y y n y y y 820 Suggested value for TBD4 is 161. 822 9. Security Considerations 824 This document introduces tunnels carrying IS-IS control traffic via 825 tunnels. In case of statically configured tunnels a deployment 826 SHOULD provide enough security protection to prevent malicious 827 attackers from using the tunnel endpoints. For information used to 828 form dynamically discovered tunnels, it SHOULD be protected by the 829 the deployed IS-IS security mechanism preventing malicious nodes from 830 spoofing rogue information on behalf of other members. 832 10. Acknowledgements 834 The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem, Robert 835 Raszuk and Les Ginsberg for their thorough review and detailed 836 discussions. Thanks are also extended to Michael Richardson for an 837 excellent routing directorate review. 839 11. References 841 11.1. Informative References 843 [ID.draft-ietf-idr-bgp-optimal-route-reflection-28] 844 Raszuk et al., R., "BGP Optimal Route Reflection", July 845 2019, . 848 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 849 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 850 DOI 10.17487/RFC4271, January 2006, 851 . 853 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 854 Reflection: An Alternative to Full Mesh Internal BGP 855 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 856 . 858 [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 859 Topology-Transparent Zone", RFC 8099, 860 DOI 10.17487/RFC8099, February 2017, 861 . 863 11.2. Normative References 865 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 866 Requirement Levels", BCP 14, RFC 2119, 867 DOI 10.17487/RFC2119, March 1997, 868 . 870 [RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route 871 Preference for Extended IP and IPv6 Reachability", 872 RFC 7775, DOI 10.17487/RFC7775, February 2016, 873 . 875 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 876 for Advertising Router Information", RFC 7981, 877 DOI 10.17487/RFC7981, October 2016, 878 . 880 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 881 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 882 DOI 10.17487/RFC9012, April 2021, 883 . 885 Authors' Addresses 887 Tony Przygienda (editor) 888 Juniper 889 1137 Innovation Way 890 Sunnyvale, CA 891 United States of America 893 Email: prz@juniper.net 895 Chris Bowers 896 Juniper 897 1137 Innovation Way 898 Sunnyvale, CA 899 United States of America 901 Email: cbowers@juniper.net 903 Yiu Lee 904 Comcast 905 1800 Bishops Gate Blvd 906 Mount Laurel, NJ 08054 907 United States of America 909 Email: Yiu_Lee@comcast.com 910 Alankar Sharma 911 Comcast 912 1800 Bishops Gate Blvd 913 Mount Laurel, NJ 08054 914 United States of America 916 Email: Alankar_Sharma@comcast.com 918 Russ White 919 Juniper 920 1137 Innovation Way 921 Sunnyvale, CA 922 United States of America 924 Email: russw@juniper.net