idnits 2.17.1 draft-ietf-lsr-isis-flood-reflection-04.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (21 October 2021) is 919 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 1 error (**), 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 3 Internet-Draft C. Bowers 4 Intended status: Standards Track Juniper 5 Expires: 24 April 2022 Y. Lee 6 A. Sharma 7 Comcast 8 R. White 9 Juniper 10 21 October 2021 12 IS-IS Flood Reflection 13 draft-ietf-lsr-isis-flood-reflection-04 15 Abstract 17 This document describes a backwards compatible, optional ISIS 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 24 April 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 Simplified BSD License text 66 as described in Section 4.e of the Trust Legal Provisions and are 67 provided without warranty as described in the Simplified BSD License. 69 Table of Contents 71 1. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Description . . . . . . . . . . . . . . . . . . . . . . . . . 3 73 3. Further Details . . . . . . . . . . . . . . . . . . . . . . . 8 74 4. Flood Reflection TLV . . . . . . . . . . . . . . . . . . . . 9 75 5. Flood Reflection Discovery Sub-TLV . . . . . . . . . . . . . 10 76 6. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV . . . . . 11 77 7. Flood Reflection Adjacency Sub-TLV . . . . . . . . . . . . . 12 78 8. Flood Reflection Discovery . . . . . . . . . . . . . . . . . 13 79 9. Flood Reflection Adjacency Formation . . . . . . . . . . . . 14 80 10. Route Computation . . . . . . . . . . . . . . . . . . . . . . 14 81 10.1. Tunnel Based Deployment . . . . . . . . . . . . . . . . 15 82 10.2. No Tunnel Deployment . . . . . . . . . . . . . . . . . . 15 83 11. Redistribution of Prefixes . . . . . . . . . . . . . . . . . 15 84 12. Special Considerations . . . . . . . . . . . . . . . . . . . 16 85 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 86 13.1. New IS-IS TLV Codepoint . . . . . . . . . . . . . . . . 16 87 13.2. Sub TLVs for TLV 242 . . . . . . . . . . . . . . . . . . 17 88 13.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV . . 17 89 13.4. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 . . . . . 17 90 14. Security Considerations . . . . . . . . . . . . . . . . . . . 17 91 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 92 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 93 16.1. Informative References . . . . . . . . . . . . . . . . . 18 94 16.2. Normative References . . . . . . . . . . . . . . . . . . 18 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 97 1. Glossary 99 This section is introduced first with the intention of allowing quick 100 reference later in the document to terms introduced 102 Flood Reflector: 103 Node configured to connect L2 only to flood reflector clients and 104 reflect (reflood) ISIS L2 LSPs amongst them. 106 Flood Reflector Client: 107 Node configured to build flood reflector adjacencies and normal L2 108 nodes. 110 Flood Reflector Adjacency: 111 ISIS L2 adjacency limited by one end being client and the other 112 reflector and agreeing on the same Flood Reflector Cluster ID. 114 Flood Reflector Cluster: 115 Collection of clients and flood reflectors configured with the 116 same cluster identifier. 118 Tunnel Deployment: 119 Deployment where flood reflector clients build a full mesh of 120 tunnels in L1 to "shortcut" forwarding of L2 traffic through the 121 cluster. 123 No Tunnel Deployment: 124 Deployment where flood reflector clients redistribute L2 125 reachability into L1 to allow forwarding through the cluster 126 without underlying tunnels. 128 2. Description 130 Due to the inherent properties of link-state protocols the number of 131 IS-IS routers within a flooding domain is limited by processing and 132 flooding overhead on each node. While that number can be maximized 133 by well written implementations and techniques such as exponential 134 back-offs, IS-IS will still reach a saturation point where no further 135 routers can be added to a single flooding domain. In some L2 136 backbone deployment scenarios, this limit presents a significant 137 challenge. 139 The traditional approach to increasing the scale of an IS-IS 140 deployement is to break it up into multiple L1 flooding domains and a 141 single L2 backbone. This works well for designs where an L2 backbone 142 connects L1 access topologies, but it is limiting where a large L2 is 143 supposed to span large number of routers. In such scenarios, an 144 alternative approach is to consider multiple L2 flooding domains 145 connected together via L1 flooding domains. In other words, L2 146 flooding domains are connected by "L1/L2 lanes" through the L1 areas 147 to form a single L2 backbone again. Unfortunately, in its simplest 148 implementation, this requires the inclusion of most, or all, of the 149 transit L1 routers as L1/L2 to allow traffic to flow along optimal 150 paths through such transit areas. Consequently, this approach fails 151 to reduce the number of L2 routers involved, so it fails to increase 152 the scalability of the L2 backbone. 154 +----+ +-------+ +-------+ +-------+ +----+ 155 | R1 | | R10 +------------+ R20 +---------------+ R30 | | R4 | 156 | L2 +--+ L1/L2 | | L1 | | L1/L2 +--+ L2 | 157 | | | +--------+ +-+ | +------------+ | | | 158 +----+ ++-+--+-+ | | +---+---+----------+ +-+--+-++ +----+ 159 | | | | | | | | | | | | | 160 | | | | | | | | | +-----------+ | | 161 | | +-------+ | | | | | | | | | | 162 | | | | | | | | | | | +------+ | 163 | +------+ +--------+ | +-------+ | | | 164 | | | | | | | | | | | | | 165 +----+ ++------+---+ | +---+---+---+--+ | +-------+------++ +----+ 166 | R2 | | R11 | | | | | R21 | | | | | R31 | | R5 | 167 | L2 +--+ L1/L2 +------------+ L1 +---------------+ L1/L2 +--+ L2 | 168 | | | | | | | | | | | | | | | | 169 +----+ ++------+---+ | | +---+--++ | +-------+------++ +----+ 170 | | | | | | | | | | | | | 171 | +---------------+ | | | | | | | | 172 | | | | | | | | | | | | | 173 | | +--------------+ | +-----------------+ | 174 | | | | | | | | | | | | | 175 +----+ ++-+--+-+ | | +------+---+---+-----+ | | | ++-----++ +----+ 176 | R3 | | R12 | +----------| R22 | | +----+ R32 | | R6 | 177 | L2 +--+ L1/L2 | +--------| L1 +-------+ | | L1/L2 +--+ L2 | 178 | | | +------------+ |---------------+ | | | 179 +----+ +-------+ +-------+-------------+ +-------+ +----+ 181 Figure 1: Example topology 183 Figure 1 is an example of a network where a topologically rich L1 184 area is used to provide transit between six different L2-only routers 185 (R1-R6). Note that the six L2-only routers do not have connectivity 186 to one another over L2 links. To take advantage of the abundance of 187 paths in the L1 transit area, all the intermediate systems could be 188 placed into both L1 and L2, but this essentially combines the 189 separate L2 flooding domains into a single one, triggering again 190 maximum L2 scale limitation we try to address in first place. 192 A more effective solution would allow to reduce the number of links 193 and routers exposed in L2, while still utilizing the full L1 topology 194 when forwarding through the network. 196 [RFC8099] describes Topology Transparent Zones (TTZ) for OSPF. The 197 TTZ mechanism represents a group of OSPF routers as a full mesh of 198 adjacencies between the routers at the edge of the group. A similar 199 mechanism could be applied to ISIS as well. However, a full mesh of 200 adjacencies between edge routers (or L1/L2 nodes) significantly 201 limits the scale of the topology. The topology in Figure 1 has 6 L1/ 202 L2 nodes. Figure 2 illustrates a full mesh of L2 adjacencies between 203 the 6 L1/L2 nodes, resulting in (5 * 6)/2 = 15 L2 adjacencies. In a 204 somewhat larger topology containing 20 L1/L2 nodes, the number of L2 205 adjacencies in a full mesh rises to 190. 207 +----+ +-------+ +-------------------------------+-------+ +----+ 208 | R1 | | R10 | | | R30 | | R4 | 209 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 210 | | | | | | | | | 211 +----+ ++-+-+--+-+ | +-+--+---++ +----+ 212 | | | | | | | | 213 | +----------------------------------------------+ | 214 | | | | | | | | 215 | +-----------------------------------+ | | | | 216 | | | | | | | | 217 | +----------------------------------------+ | | 218 | | | | | | | | 219 +----+ ++-----+- | | | | -----+-++ +----+ 220 | R2 | | R11 | | | | | | R31 | | R5 | 221 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 222 | | | | | | | | | | | | 223 +----+ ++------+------------------------------+ | | +----+-++ +----+ 224 | | | | | | | | 225 | | | | | | | | 226 | +-------------------------------------------+ | 227 | | | | | | | | 228 | | | | +----------+ | 229 | | | | | | | | 230 | | | | +-----+ | | 231 | | | | | | | | 232 +----+ ++----+-+-+ | +-+-+--+-++ +----+ 233 | R3 | | R12 | | L2 adjacency | R32 | | R6 | 234 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 235 | | | | | | | | | 236 +----+ +-------+----+ +-------+ +----+ 237 Figure 2: Example topology represented in L2 with a full mesh of 238 L2 adjacencies between L1/L2 nodes 240 BGP, as specified in [RFC4271], faced a similar scaling problem, 241 which has been solved in many networks by deploying BGP route 242 reflectors [RFC4456]. We note that BGP route reflectors do not 243 necessarily have to be in the forwarding path of the traffic. This 244 incongruity of forwarding and control path for BGP route reflectors 245 allows the control plane to scale independently of the forwarding 246 plane. 248 We propose here a similar solution for IS-IS. A simple example of 249 what a flood reflector control plane approach would look like is 250 shown in Figure 3, where router R21 plays the role of a flood 251 reflector. Each L1/L2 ingress/egress router builds a tunnel to the 252 flood reflector, and an L2 adjacency is built over each tunnel. In 253 this solution, we need only 6 L2 adjacencies, instead of the 15 254 needed for a full mesh. In a somewhat larger topology containing 20 255 L1/L2 nodes, this solution requires only 20 L2 adjacencies, instead 256 of the 190 need for a full mesh. Multiple flood reflectors can be 257 used, allowing the network operator to balance between resilience, 258 path utilization, and state in the control plane. The resulting L2 259 adjacency scale is R*n, where R is the number of flood reflectors 260 used and n is the number of L1/L2 nodes. This compares quite 261 favorably with n*(n-1)/2 L2 adjacencies required in a fully meshed L2 262 solution. 264 +----+ +-------+ +-------+ +----+ 265 | R1 | | R10 | | R30 | | R4 | 266 | L2 +--+ L1/L2 +--------------+ +-----------------+ L1/L2 +--+ L2 | 267 | | | | L2 adj | | L2 adj | | | | 268 +----+ +-------+ over | | over +-------+ +----+ 269 tunnel | | tunnel 270 +----+ +-------+ +--+---+--+ +-------+ +----+ 271 | R2 | | R11 | | R21 | | R31 | | R5 | 272 | L2 +--+ L1/L2 +-----------+ L1/L2 +--------------+ L1/L2 +--+ L2 | 273 | | | | L2 adj | flood | L2 adj | | | | 274 +----+ +-------+ over |reflector| over +-------+ +----+ 275 tunnel +--+---+--+ tunnel 276 +----+ +-------+ | | +-------+ +----+ 277 | R3 | | R12 +--------------+ +-----------------+ R32 | | R6 | 278 | L2 +--+ L1/L2 | L2 adj L2 adj | L1/L2 +--+ L2 | 279 | | | | over over | | | | 280 +----+ +-------+ tunnel tunnel +-------+ +----+ 282 Figure 3: Example topology represented in L2 with L2 adjacencies 283 from each L1/ L2 node to a single flood reflector 285 As illustrated in Figure 3, when R21 plays the role of flood 286 reflector, it provides L2 connectivity among all of the previously 287 disconnected L2 islands by reflooding all L2 LSPDUs. At the same 288 time, R20 and R22 remain L1-only routers. L1-only routers and 289 L1-only links are not visible in L2. In this manner, the flood 290 reflector allows us provide L2 control plane connectivity in a 291 scalable manner. 293 As described so far, the solution illustrated in Figure 3 relies only 294 on currently standardized ISIS functionality. Without new 295 functionality, however, the data traffic will traverse only R21. 296 This will unnecessarily create a bottleneck at R21 since there is 297 still available capacity in the paths crossing the L1-only routers 298 R20 and R22. 300 Hence, some new functionality is necessary to allow the L1/L2 edge 301 nodes (R10-12 and R30-32 in Figure 3) to recognize that the L2 302 adjacency to R21 should not be used for forwarding. The L1/L2 edge 303 nodes should forward traffic that would normally be forwarded over 304 the L2 adjacency to R21 over L1 links instead. This would allow the 305 forwarding within the L1 area to use the L1-only nodes and links 306 shown in Figure 1 as well. It allows networks to be built that use 307 the entire forwarding capacity of the L1 areas, while at the same 308 time introducing control plane scaling benefits provided by L2 flood 309 reflectors. 311 This document defines all extensions necessary to support flood 312 reflector deployment: 314 * A 'flood reflector adjacency' for all the adjacencies built for 315 the purpose of reflecting flooding information. This allows these 316 'flood reflectors' to participate in the IS-IS control plane 317 without being used in the forwarding plane. This is a purely 318 local operation on the L1/L2 ingress; it does not require 319 replacing or modifying any routers not involved in the reflection 320 process. Deployment-wise, it is far less tricky to just upgrade 321 the routers involved in flood reflection rather than have a flag 322 day on the whole ISIS domain. 324 * An (optional) full mesh of tunnels between the L1/L2 routers, 325 ideally load-balancing across all available L1 links. This 326 harnesses all forwarding paths between the L1/L2 edge nodes 327 without injecting unneeded state into the L2 flooding domain or 328 creating 'choke points' at the 'flood reflectors' themselves. The 329 draft is agnostic as to the tunneling technology used but provides 330 enough information for automatic establishment of such tunnels. 331 The discussion of ISIS adjacency formation and/or liveness 332 discovery on such tunnels is outside the scope of this draft and 333 is largely choice of the underlying implementation. A solution 334 without tunnels is also possible by applying judicious scoping of 335 reachability information between the levels as described in more 336 details later. 338 * Some way to support reflector redundancy, and potentially some way 339 to auto-discover and advertise such adjacencies as flood reflector 340 adjacencies. Such advertisements may allow L2 nodes outside the 341 L1 to perform optimizations in the future based on this 342 information. 344 3. Further Details 346 Several considerations should be noted in relation to such a flood 347 reflection mechanism. 349 First, this allows multi-area IS-IS deployments to scale without any 350 major modifications in the IS-IS implementation on most of the nodes 351 deployed in the network. Unmodified (traditional) L2 routers will 352 compute reachability across the transit L1 area using the flood 353 reflector adjacencies. 355 Second, the flood reflectors are not required to participate in 356 forwarding traffic through the L1 transit area. These flood 357 reflectors can be hosted on virtual devices outside the forwarding 358 topology. 360 Third, astute readers will realize that flooding reflection may cause 361 the use of suboptimal paths. This is similar to the BGP route 362 reflection suboptimal routing problem described in 363 [ID.draft-ietf-idr-bgp-optimal-route-reflection-28]. The L2 364 computation determines the egress L1/L2 and with that can create 365 illusions of ECMP where there is none. And in certain scenarios lead 366 to an L1/L2 egress which is not globally optimal. This represents a 367 straightforward instance of the trade-off between the amount of 368 control plane state and the optimal use of paths through the network 369 often encountered when aggregating routing information. 371 One possible solution to this problem is to expose additional 372 topology information into the L2 flooding domains. In the example 373 network given, links from router 01 to router 02 can be exposed into 374 L2 even when 01 and 02 are participating in flood reflection. This 375 information would allow the L2 nodes to build 'shortcuts' when the L2 376 flood reflected part of the topology looks more expensive to cross 377 distance wise. 379 Another possible variation is for an implementation to approximate 380 with the tunnel cost the cost of the underlying topology. 382 Redundancy can be achieved by building multiple flood reflectors in a 383 L1 area. Multiple flood reflectors do not need any synchronization 384 mechanisms amongst themselves, except standard ISIS flooding and 385 database maintenance procedures. 387 4. Flood Reflection TLV 389 The Flood Reflection TLV is a new top-level TLV that MAY appear in L2 390 IIHs. The Flood Reflection TLV indicates the flood reflector cluster 391 (based on Flood Reflection Cluster ID) that a given router is 392 configured to participate in. It also indicates whether the router 393 is configured to play the role of either flood reflector or flood 394 reflector client. The Flood Reflection Cluster ID and flood 395 reflector roles advertised in the IIHs are used to ensure that flood 396 reflector adjacencies are only formed between a flood reflector and 397 flood reflector client, and that the Flood Reflection Cluster IDs 398 match. The Flood Reflection TLV has the following format: 400 0 1 2 3 401 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 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | Type | Length |C| RESERVED | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Flood Reflection Cluster ID | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Sub-TLVs ... 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 Type: TBD 412 Length: The length, in octets, of the following fields. 414 C (Client): This bit is set to indicate that the router acts as a 415 flood reflector client. When this bit is NOT set, the router acts 416 as a flood reflector. On a given router, the same value of the 417 C-bit MUST be advertised across all interfaces advertising the 418 Flood Reflection TLV in IIHs. 420 RESERVED: This field is reserved for future use. It MUST be set to 421 0 when sent and MUST be ignored when received. 423 Flood Reflection Cluster ID: Flood Reflection Cluster Identifier. 424 These same 32-bit value MUST be assigned to all of the flood 425 reflectors and flood reflector clients in the same L1 area. The 426 value MUST be unique across different L1 areas within the IGP 427 domain. On a given router, the same value of the Flood Reflection 428 Cluster ID MUST be advertised across all interfaces advertising 429 the Flood Reflection TLV in IIHs. This implies that a flood 430 reflector can participate in a single L1 area only. 432 Sub-TLVs: Optional sub-TLVs. For future extensibility, the format 433 of the Flood Reflection TLV allows for the possibility of 434 including optional sub-TLVs. No sub-TLVs of the Flood Reflection 435 TLV are defined in this document. 437 The Flood Reflection TLV SHOULD NOT appear more than once in an IIH. 438 A router receiving multiple Flood Reflection TLVs in the same IIH 439 MUST use the values in the first TLV and it SHOULD adequately log 440 such violations subject to rate limiting. 442 5. Flood Reflection Discovery Sub-TLV 444 Flood Reflection Discovery sub-TLV is advertised as a sub-TLV of the 445 IS-IS Router Capability TLV-242, defined in [RFC7981]. The Flood 446 Reflection Discovery sub-TLV is advertised in L1 and L2 LSPs with 447 area flooding scope in order to enable the auto-discovery of flood 448 reflection capabilities. The Flood Reflection Discovery sub-TLV has 449 the following format: 451 0 1 2 3 452 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 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Type | Length |C| Reserved | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | Flood Reflection Cluster ID | 457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 Type: TBD 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. 467 RESERVED: This field is reserved for future use. It MUST be set to 468 0 when sent and MUST be ignored when received. 470 Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier 471 is the same as that defined in the Flood Reflection TLV. 473 The Flood Reflection Discovery sub-TLV SHOULD NOT appear more than 474 once in TLV 242. A router receiving multiple Flood Reflection 475 Discovery sub-TLVs in TLV 242 MUST use the values in the first sub- 476 TLV and it SHOULD adequately log such violations subject to rate 477 limiting. 479 6. Flood Reflection Discovery Tunnel Type Sub-Sub-TLV 481 Flood Reflection Discovery Tunnel Type sub-sub-TLV is advertised 482 optionally as a sub-sub-TLV of the Flood Reflection Discovery Sub- 483 TLV, defined in Section 5. It allows the automatic creation of L2 484 tunnels to be used as flood reflector adjacencies and L1 shortcut 485 tunnels. The Flood Reflection Tunnel Type sub-sub-TLV has the 486 following format: 488 0 1 2 3 489 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 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+ 491 | Type | Length | Reserved |F| 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 493 | Tunnel Encapsulation Attribute | 494 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 Type: TBD 498 Length: The length, in octets, of zero or more of the following 499 fields. 501 Reserved: SHOULD be 0 on transmission and ignored on reception. 503 F Flag: When set indicates flood reflection tunnel endpoint, when 504 clear, indicates possible L1 shortcut tunnel endpoint. 506 Tunnel Encapsulation Attribute: Carries encapsulation type and 507 further attributes necessary for tunnel establishment as defined 508 in [RFC9012]. Protocol type sub-TLV as defined in [RFC9012] MAY 509 be included but MUST when F flag is set include according type 510 that allows carrying of encapsulated ISIS frames. Such tunnel 511 type MUST provide according mechanisms to carry up to 512 `originatingL2LSPBufferSize` sized ISIS frames across. 514 A flood reflector receiving multiple Flood Reflection Discovery 515 Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub-TLV with F 516 flag set SHOULD use one or more of the specified tunnel endpoints to 517 automatically establish one or more tunnels that will serve as flood 518 reflection adjacency(-ies). 520 A flood reflection client receiving multiple Flood Reflection 521 Discovery Tunnel Type sub-sub-TLVs in Flood Reflection Discovery sub- 522 TLV with F flag clear from other leaves MAY use one or more of the 523 specified tunnel endpoints to automatically establish one or more 524 tunnels that will serve as L1 tunnel shortcuts. 526 Optional address validation procedures as defined in [RFC9012] MUST 527 be disregarded. 529 7. Flood Reflection Adjacency Sub-TLV 531 The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of 532 TLVs 22, 23, 25, 141, 222, and 223. Its presence indicates that a 533 given adjacency is a flood reflector adjacency. It is included in L2 534 area scope flooded LSPs. Flood Reflection Adjacency sub-TLV has the 535 following format: 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Type | Length |C| Reserved | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 | Flood Reflection Cluster ID | 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 Type: TBD 547 Length: The length, in octets, of the following fields. 549 C (Client): This bit is set to indicate that the router advertising 550 this adjacency is a flood reflector client. When this bit is NOT 551 set, the router advertising this adjacency is a flood reflector. 553 RESERVED: This field is reserved for future use. It MUST be set to 554 0 when sent and MUST be ignored when received. 556 Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier 557 is the same as that defined in the Flood Reflection TLV. 559 The Flood Reflection Adjacency sub-TLV SHOULD NOT appear more than 560 once in a given TLV. A router receiving multiple Flood Reflection 561 Adjacency sub-TLVs in a TLV MUST use the values in the first sub-TLV 562 and it SHOULD adequately log such violations subject to rate 563 limiting. 565 8. Flood Reflection Discovery 567 A router participating in flood reflection MUST be configured as an 568 L1/L2 router. It SHOULD originate the Flood Reflection Discovery 569 sub-TLV with area flooding scope in L1 and L2. Normally, all routers 570 on the edge of the L1 area (those having traditional L2 adjacencies) 571 will advertise themselves as route reflector clients. Therefore, a 572 flood reflector client will have both traditional L2 adjacencies and 573 flood reflector L2 adjacencies. 575 A router acting as a flood reflector MUST NOT have any traditional L2 576 adjacencies. It will be an L1/L2 router only by virtue of having 577 flood reflector L2 adjacencies. A router desiring to act as a flood 578 reflector will advertise itself as such using the Flood Reflection 579 Discovery sub-TLV in L1 and L2. 581 A given flood reflector or flood reflector client can only 582 participate in a single cluster, as determined by the value of its 583 Flood Reflection Cluster ID and should disregard other routers' TLVs 584 for flood reflection purposes if the cluster ID is not matching. 586 Upon reception of Flood Reflection Discovery sub-TLVs, a router 587 acting as flood reflector client SHOULD initiate a tunnel towards 588 each flood reflector with which it shares an Flood Reflection Cluster 589 ID using one or more of the tunnel encapsulations provided with F 590 flag being set. The L2 adjacencies formed over such tunnels MUST be 591 marked as flood reflector adjacencies. If the client or reflector 592 has a direct L2 adjacency with the according remote side it SHOULD 593 use it instead of instantiating a new tunnel. 595 In absence of auto-discovery an implementation MAY use statically 596 configured tunnels to create flood reflection adjacencies. 598 The ISIS metrics for all flood reflection adjacencies in a cluster 599 SHOULD be uniform. 601 Upon reception of Flood Reflection Discover TLVs, a router acting as 602 a flood reflector client MAY initiate tunnels with L1-only 603 adjacencies towards any of the other flood reflector clients with 604 lower router IDs in its cluster using encapsulations with F flag 605 clear. These tunnels MAY be used for forwarding to improve the load- 606 balancing characteristics of the L1 area. If the clients have a 607 direct L2 adjacency they SHOULD use it instead of instantiating a new 608 tunnel. 610 9. Flood Reflection Adjacency Formation 612 In order to simplify both implementations and network deployments, 613 this draft does not allow the formation of complex hierarchies of 614 flood reflectors and clients or allow multiple clusters in a single 615 L1 area. Consequently, all flood reflectors and flood reflector 616 clients in the same L1 area MUST share the same Flood Reflector 617 Cluster ID. 619 A flood reflector MUST only form flood reflection adjacencies with 620 flood reflector clients with matching Cluster ID. A flood reflector 621 MUST NOT form any traditional L2 adjacencies. 623 Flood reflector clients MUST only form flood reflection adjacencies 624 with flood reflectors with matching Cluster ID. 626 Flood reflector clients MAY form traditional L2 adjacencies with 627 flood reflector clients or nodes not participating in flood 628 reflection. When two clients form traditional L2 adjacency Cluster 629 ID is disregarded. 631 The Flood Reflector Cluster ID and flood reflector roles advertised 632 in the Flood Reflection TLVs in IIHs are used to ensure that flood 633 reflection adjacencies that are established meet the above criteria. 635 On change in either flood reflection role or cluster ID on IIH on the 636 local or remote side the adjacency has to be reset and re-established 637 if possible. 639 Once a flood reflection adjacency is established, the flood reflector 640 and the flood reflector client MUST advertise the adjacency by 641 including the Flood Reflection Adjacency Sub-TLV in the Extended IS 642 reachability TLV or MT-ISN TLV. 644 10. Route Computation 646 To ensure loop-free routing, the route reflection client MUST follow 647 the normal L2 computation to determine L2 routes. This is because 648 nodes outside the L1 area will generally not be aware that flood 649 reflection is being performed. The flood reflection clients need to 650 produce the same result for the L2 route computation as a router not 651 participating in flood reflection. 653 10.1. Tunnel Based Deployment 655 In tunnel based option the reflection client, after L2 and L1 656 computation, MUST examine all L2 routes and replace all flood 657 reflector adjacencies with the correct underlying tunnel next-hop to 658 the egress. 660 10.2. No Tunnel Deployment 662 In case of deployment without underlying tunnels, the necessary L2 663 routes are distributed into the area, normally as L2->L1 routes. Due 664 to the rules in Section 9 the computation in the resulting topology 665 is relatively simple, the L2 SPF from a flood reflector client is 666 guaranteed to reach within a hop the Flood Reflector and in the 667 following hop the L2 egress to which it has a forwarding tunnel 668 again. All the flood reflector tunnel nexthops in the according L2 669 route can hence be removed and if the L2 route has no other ECMP L2 670 nexthops, the L2 route MUST be suppressed in the RIB by some means to 671 allow the less preferred L2->L1 route to be used to forward traffic 672 towards the advertising egress. 674 In the particular case the client has L2 routes which are not route 675 reflected, those will be naturally preferred (such routes normally 676 "hot-potato" route of the L1 area). However in the case the L2 route 677 through the flood reflector egress is "shorter" than such present non 678 flood reflected L2 routes, the node SHOULD ensure that such routes 679 are suppressed so the L2->L1 towards the egress still takes 680 preference. Observe that operationally this can be resolved in a 681 relatively simple way by configuring flood reflector adjacencies to 682 have a high metric, i.e. the flood reflector topology becomes "last 683 resort" and the leaves will try to "hot-potato" out the area as fast 684 as possible which is normally the desirable behavior. 686 In deployment scenarios where tunnels are not used, all L1/L2 edge 687 nodes MUST be ultimately flood reflector clients except during during 688 transition phase. 690 11. Redistribution of Prefixes 692 When L2 prefixes need to be redistributed into L1 by the route 693 reflector clients a client that does not have any L2 flood reflector 694 adjacencies MUST NOT redistribute those routes into the area in case 695 of application of Section 10.2. The L2 prefixes advertisements 696 redistributed into L1 with flood reflectors SHOULD be normally 697 limited to L2 intra-area routes (as defined in [RFC7775]), if the 698 information exists to distinguish them from other other L2 prefix 699 advertisements. 701 On the other hand, in topologies that make use of flood reflection to 702 hide the structure of L1 areas while still providing transit 703 forwarding across them using tunnels, we generally do not need to 704 redistribute L1 prefixes advertisements into L2. 706 12. Special Considerations 708 In pathological cases setting the overload bit in L1 (but not in L2) 709 can partition L1 forwarding, while allowing L2 reachability through 710 flood reflector adjacencies to exist. In such a case a node cannot 711 replace a route through a flood reflector adjacency with a L1 712 shortcut and the client can use the L2 tunnel to the flood reflector 713 for forwarding while it MUST initiate an alarm and declare 714 misconfiguration. 716 A flood reflector with directly L2 attached prefixes should advertise 717 those in L1 as well since based on preference of L1 routes the 718 clients will not try to use the L2 flood reflector adjacency to route 719 the packet towards them. A very, very corner case is when the flood 720 reflector is reachable via L2 flood reflector adjacency (due to 721 underlying L1 partition) only in which case the client can use the L2 722 tunnel to the flood reflector for forwarding towards those prefixes 723 while it MUST initiate an alarm and declare misconfiguration. 725 A flood reflector SHOULD NOT set the attached bit on its LSPs. 727 Instead of modifying the computation procedures one could imagine a 728 flood reflector solution where the Flood Reflector would re-advertise 729 the L2 prefixes with a 'third-party' next-hop but that would have 730 less desirable convergence properties than the solution proposed and 731 force a fork-lift of all L2 routers to make sure they disregard such 732 prefixes unless in the same L1 domain as the Flood Reflector. 734 Depending on pseudo-node choice in case of a broadcast domain with 735 multiple flood reflectors attached this can lead to a partitioned LAN 736 and hence a router discovering such a condition MUST initiate an 737 alarm and declare misconfiguration. 739 13. IANA Considerations 741 This document requests allocation for the following IS-IS TLVs and 742 Sub-TLVs. 744 13.1. New IS-IS TLV Codepoint 746 This document requests the following IS-IS TLV: 748 Value Name IIH LSP SNP Purge 749 ----- --------------------------------- --- --- --- ----- 750 TBD1 Flood Reflection y n n n 752 Suggested value for TBD1 is 161. 754 13.2. Sub TLVs for TLV 242 756 This document request the following registration in the "sub-TLVs for 757 TLV 242" registry. 759 Type Description 760 ---- ----------- 761 TBD2 Flood Reflection Discovery 763 Suggested value for TBD2 is 161. 765 13.3. Sub-sub TLVs for Flood Reflection Discovery sub-TLV 767 This document request the following registration in the "sub-sub-TLVs 768 for Flood Reflection Discovery sub-TLV" registry. 770 Type Description 771 ---- ----------- 772 TBD3 Flood Reflection Discovery Tunnel Encapsulation Attribute 774 Suggested value for TBD3 is 161. 776 13.4. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 778 This document requests the following registration in the "sub-TLVs 779 for TLV 22, 23, 25, 141, 222, and 223" registry. 781 Type Description 22 23 25 141 222 223 782 ---- -------------------------------- --- --- --- --- --- --- 783 TBD4 Flood Reflector Adjacency y y n y y y 785 Suggested value for TBD4 is 161. 787 14. Security Considerations 789 This document introduces no new security concerns to ISIS or other 790 specifications referenced in this document. 792 15. Acknowledgements 794 The authors thank Shraddha Hegde, Peter Psenak, Acee Lindem and Les 795 Ginsberg for their thorough review and detailed discussions. 797 16. References 799 16.1. Informative References 801 [ID.draft-ietf-idr-bgp-optimal-route-reflection-28] 802 Raszuk et al., R., "BGP Optimal Route Reflection", July 803 2019, . 806 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 807 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 808 DOI 10.17487/RFC4271, January 2006, 809 . 811 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 812 Reflection: An Alternative to Full Mesh Internal BGP 813 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 814 . 816 [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 817 Topology-Transparent Zone", RFC 8099, 818 DOI 10.17487/RFC8099, February 2017, 819 . 821 16.2. Normative References 823 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 824 Requirement Levels", BCP 14, RFC 2119, 825 DOI 10.17487/RFC2119, March 1997, 826 . 828 [RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route 829 Preference for Extended IP and IPv6 Reachability", 830 RFC 7775, DOI 10.17487/RFC7775, February 2016, 831 . 833 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 834 for Advertising Router Information", RFC 7981, 835 DOI 10.17487/RFC7981, October 2016, 836 . 838 [RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder, 839 "The BGP Tunnel Encapsulation Attribute", RFC 9012, 840 DOI 10.17487/RFC9012, April 2021, 841 . 843 Authors' Addresses 845 Tony Przygienda 846 Juniper 847 1137 Innovation Way 848 Sunnyvale, CA 849 United States of America 851 Email: prz@juniper.net 853 Chris Bowers 854 Juniper 855 1137 Innovation Way 856 Sunnyvale, CA 857 United States of America 859 Email: cbowers@juniper.net 861 Yiu Lee 862 Comcast 863 1800 Bishops Gate Blvd 864 Mount Laurel, NJ 08054 865 United States of America 867 Email: Yiu_Lee@comcast.com 869 Alankar Sharma 870 Comcast 871 1800 Bishops Gate Blvd 872 Mount Laurel, NJ 08054 873 United States of America 875 Email: Alankar_Sharma@comcast.com 876 Russ White 877 Juniper 878 1137 Innovation Way 879 Sunnyvale, CA 880 United States of America 882 Email: russw@juniper.net