idnits 2.17.1 draft-ietf-lsr-isis-flood-reflection-03.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 (July 11, 2021) is 1020 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: January 12, 2022 Y. Lee 6 A. Sharma 7 Comcast 8 R. White 9 Juniper 10 July 11, 2021 12 IS-IS Flood Reflection 13 draft-ietf-lsr-isis-flood-reflection-03 15 Abstract 17 This document describes an optional ISIS extension that allows the 18 creation of IS-IS flood reflection topologies. Flood reflection 19 allows the creation of topologies where L1 areas provide transit 20 forwarding for L2 destinations within an L2 topology. It 21 accomplishes this by creating L2 flood reflection adjacencies within 22 each L1 area. The L2 flood reflection 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. This arrangement gives the L2 25 topology better scaling properties. In addition, only those routers 26 directly participating in flood reflection have to support the 27 feature. This allows for the incremental deployment of scalable L1 28 transit areas in an existing network, without the necessity of 29 upgrading other routers in the network. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 35 document are to be interpreted as described in RFC 2119 [RFC2119]. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on January 12, 2022. 54 Copyright Notice 56 Copyright (c) 2021 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Description . . . . . . . . . . . . . . . . . . . . . . . . . 2 72 2. Further Details . . . . . . . . . . . . . . . . . . . . . . . 8 73 3. Flood Reflection TLV . . . . . . . . . . . . . . . . . . . . 9 74 4. Flood Reflection Discovery Sub-TLV . . . . . . . . . . . . . 10 75 5. Flood Reflection Adjacency Sub-TLV . . . . . . . . . . . . . 11 76 6. Flood Reflection Discovery . . . . . . . . . . . . . . . . . 11 77 7. Flood Reflection Adjacency Formation . . . . . . . . . . . . 12 78 8. Redistribution of Prefixes . . . . . . . . . . . . . . . . . 13 79 9. Route Computation . . . . . . . . . . . . . . . . . . . . . . 13 80 10. Special Considerations . . . . . . . . . . . . . . . . . . . 14 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 11.1. New IS-IS TLV Codepoint . . . . . . . . . . . . . . . . 14 83 11.2. Sub TLVs for TLV 242 . . . . . . . . . . . . . . . . . . 15 84 11.3. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 . . . . . 15 85 12. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 87 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 14.1. Informative References . . . . . . . . . . . . . . . . . 15 89 14.2. Normative References . . . . . . . . . . . . . . . . . . 16 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Description 94 Due to the inherent properties of link-state protocols the number of 95 IS-IS routers within a flooding domain is limited by processing and 96 flooding overhead on each node. While that number can be maximized 97 by well written implementations and techniques such as exponential 98 back-offs, IS-IS will still reach a saturation point where no further 99 routers can be added to a single flooding domain. In some L2 100 backbone deployment scenarios, this limit presents a significant 101 challenge. 103 The traditional approach to increasing the scale of an IS-IS 104 deployement is to break it up into multiple L1 flooding domains and a 105 single L2 backbone. This works well for designs where an L2 backbone 106 connects L1 access topologies, but it is limiting where a large L2 is 107 supposed to span large number of routers. In such scenarios, an 108 alternative approach is to consider multiple L2 flooding domains 109 connected together via L1 flooding domains. In other words, L2 110 flooding domains are connected by "L1/L2 lanes" through the L1 areas 111 to form a single L2 backbone again. Unfortunately, in its simplest 112 implementation, this requires the inclusion of most, or all, of the 113 transit L1 routers as L1/L2 to allow traffic to flow along optimal 114 paths through such transit areas. Consequently, this approach fails 115 to reduce the number of L2 routers involved, so it fails to increase 116 the scalability of the L2 backbone. 118 +----+ +-------+ +-------+ +-------+ +----+ 119 | R1 | | R10 +------------+ R20 +---------------+ R30 | | R4 | 120 | L2 +--+ L1/L2 | | L1 | | L1/L2 +--+ L2 | 121 | | | +--------+ +-+ | +------------+ | | | 122 +----+ ++-+--+-+ | | +---+---+----------+ +-+--+-++ +----+ 123 | | | | | | | | | | | | | 124 | | | | | | | | | +-----------+ | | 125 | | +-------+ | | | | | | | | | | 126 | | | | | | | | | | | +------+ | 127 | +------+ +--------+ | +-------+ | | | 128 | | | | | | | | | | | | | 129 +----+ ++------+---+ | +---+---+---+--+ | +-------+------++ +----+ 130 | R2 | | R11 | | | | | R21 | | | | | R31 | | R5 | 131 | L2 +--+ L1/L2 +------------+ L1 +---------------+ L1/L2 +--+ L2 | 132 | | | | | | | | | | | | | | | | 133 +----+ ++------+---+ | | +---+--++ | +-------+------++ +----+ 134 | | | | | | | | | | | | | 135 | +---------------+ | | | | | | | | 136 | | | | | | | | | | | | | 137 | | +--------------+ | +-----------------+ | 138 | | | | | | | | | | | | | 139 +----+ ++-+--+-+ | | +------+---+---+-----+ | | | ++-----++ +----+ 140 | R3 | | R12 | +----------| R22 | | +----+ R32 | | R6 | 141 | L2 +--+ L1/L2 | +--------| L1 +-------+ | | L1/L2 +--+ L2 | 142 | | | +------------+ |---------------+ | | | 143 +----+ +-------+ +-------+-------------+ +-------+ +----+ 145 Figure 1: Example topology 147 Figure 1 is an example of a network where a topologically rich L1 148 area is used to provide transit between six different L2-only routers 149 (R1-R6). Note that the six L2-only routers do not have connectivity 150 to one another over L2 links. To take advantage of the abundance of 151 paths in the L1 transit area, all the intermediate systems could be 152 placed into both L1 and L2, but this essentially combines the 153 separate L2 flooding domains into a single one, triggering again 154 maximum L2 scale limitation we try to address in first place. 156 A more effective solution would allow to reduce the number of links 157 and routers exposed in L2, while still utilizing the full L1 topology 158 when forwarding through the network. 160 [RFC8099] describes Topology Transparent Zones (TTZ) for OSPF. The 161 TTZ mechanism represents a group of OSPF routers as a full mesh of 162 adjacencies between the routers at the edge of the group. A similar 163 mechanism could be applied to ISIS as well. However, a full mesh of 164 adjacencies between edge routers (or L1/L2 nodes) significantly 165 limits the scale of the topology. The topology in Figure 1 has 6 L1/ 166 L2 nodes. Figure 2 illustrates a full mesh of L2 adjacencies between 167 the 6 L1/L2 nodes, resulting in (5 * 6)/2 = 15 L2 adjacencies. In a 168 somewhat larger topology containing 20 L1/L2 nodes, the number of L2 169 adjacencies in a full mesh rises to 190. 171 +----+ +-------+ +-------------------------------+-------+ +----+ 172 | R1 | | R10 | | | R30 | | R4 | 173 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 174 | | | | | | | | | 175 +----+ ++-+-+--+-+ | +-+--+---++ +----+ 176 | | | | | | | | 177 | +----------------------------------------------+ | 178 | | | | | | | | 179 | +-----------------------------------+ | | | | 180 | | | | | | | | 181 | +----------------------------------------+ | | 182 | | | | | | | | 183 +----+ ++-----+- | | | | -----+-++ +----+ 184 | R2 | | R11 | | | | | | R31 | | R5 | 185 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 186 | | | | | | | | | | | | 187 +----+ ++------+------------------------------+ | | +----+-++ +----+ 188 | | | | | | | | 189 | | | | | | | | 190 | +-------------------------------------------+ | 191 | | | | | | | | 192 | | | | +----------+ | 193 | | | | | | | | 194 | | | | +-----+ | | 195 | | | | | | | | 196 +----+ ++----+-+-+ | +-+-+--+-++ +----+ 197 | R3 | | R12 | | L2 adjacency | R32 | | R6 | 198 | L2 +--+ L1/L2 +------------------------------------+ L1/L2 +--+ L2 | 199 | | | | | | | | | 200 +----+ +-------+----+ +-------+ +----+ 202 Figure 2: Example topology represented in L2 with a full mesh of L2 203 adjacencies between L1/L2 nodes 205 BGP, as specified in [RFC4271], faced a similar scaling problem, 206 which has been solved in many networks by deploying BGP route 207 reflectors [RFC4456]. We note that BGP route reflectors do not 208 necessarily have to be in the forwarding path of the traffic. This 209 incongruity of forwarding and control path for BGP route reflectors 210 allows the control plane to scale independently of the forwarding 211 plane. 213 We propose here a similar solution for IS-IS. A simple example of 214 what a flood reflector control plane approach would look like is 215 shown in Figure 3, where router R21 plays the role of a flood 216 reflector. Each L1/L2 ingress/egress router builds a tunnel to the 217 flood reflector, and an L2 adjacency is built over each tunnel. In 218 this solution, we need only 6 L2 adjacencies, instead of the 15 219 needed for a full mesh. In a somewhat larger topology containing 20 220 L1/L2 nodes, this solution requires only 20 L2 adjacencies, instead 221 of the 190 need for a full mesh. Multiple flood reflectors can be 222 used, allowing the network operator to balance between resilience, 223 path utilization, and state in the control plane. The resulting L2 224 adjacency scale is R*n, where R is the number of flood reflectors 225 used and n is the number of L1/L2 nodes. This compares quite 226 favorably with n*(n-1)/2 L2 adjacencies required in a fully meshed L2 227 solution. 229 +----+ +-------+ +-------+ +----+ 230 | R1 | | R10 | | R30 | | R4 | 231 | L2 +--+ L1/L2 +--------------+ +-----------------+ L1/L2 +--+ L2 | 232 | | | | L2 adj | | L2 adj | | | | 233 +----+ +-------+ over | | over +-------+ +----+ 234 tunnel | | tunnel 235 +----+ +-------+ +--+---+--+ +-------+ +----+ 236 | R2 | | R11 | | R21 | | R31 | | R5 | 237 | L2 +--+ L1/L2 +-----------+ L1/L2 +--------------+ L1/L2 +--+ L2 | 238 | | | | L2 adj | flood | L2 adj | | | | 239 +----+ +-------+ over |reflector| over +-------+ +----+ 240 tunnel +--+---+--+ tunnel 241 +----+ +-------+ | | +-------+ +----+ 242 | R3 | | R12 +--------------+ +-----------------+ R32 | | R6 | 243 | L2 +--+ L1/L2 | L2 adj L2 adj | L1/L2 +--+ L2 | 244 | | | | over over | | | | 245 +----+ +-------+ tunnel tunnel +-------+ +----+ 247 Figure 3: Example topology represented in L2 with L2 adjacencies from 248 each L1/L2 node to a single flood reflector 250 As illustrated in Figure 3, when R21 plays the role of flood 251 reflector, it provides L2 connectivity among all of the previously 252 disconnected L2 islands by reflooding all L2 LSPDUs. At the same 253 time, R20 and R22 remain L1-only routers. L1-only routers and 254 L1-only links are not visible in L2. In this manner, the flood 255 reflector allows us provide L2 control plane connectivity in a 256 scalable manner. 258 As described so far, the solution illustrated in Figure 3 relies only 259 on currently standardized ISIS functionality. Without new 260 functionality, however, the data traffic will traverse only R21. 261 This will unnecessarily create a bottleneck at R21 since there is 262 still available capacity in the paths crossing the L1-only routers 263 R20 and R22. 265 Hence, some new functionality is necessary to allow the L1/L2 edge 266 nodes (R10-12 and R30-32 in Figure 3) to recognize that the L2 267 adjacency to R21 should not be used for forwarding. The L1/L2 edge 268 nodes should forward traffic that would normally be forwarded over 269 the L2 adjacency to R21 over L1 links instead. This would allow the 270 forwarding within the L1 area to use the L1-only nodes and links 271 shown in Figure 1 as well. It allows networks to be built that use 272 the entire forwarding capacity of the L1 areas, while at the same 273 time introducing control plane scaling benefits provided by L2 flood 274 reflectors. 276 This document defines all extensions necessary to support flood 277 reflector deployment: 279 o A 'flood reflector adjacency' for all the adjacencies built for 280 the purpose of reflecting flooding information. This allows these 281 'flood reflectors' to participate in the IS-IS control plane 282 without being used in the forwarding plane. This is a purely 283 local operation on the L1/L2 ingress; it does not require 284 replacing or modifying any routers not involved in the reflection 285 process. Deployment-wise, it is far less tricky to just upgrade 286 the routers involved in flood reflection rather than have a flag 287 day on the whole ISIS domain. 289 o A full mesh of L1 tunnels between the L1/L2 routers, ideally load- 290 balancing across all available L1 links. This harnesses all 291 forwarding paths between the L1/L2 edge nodes without injecting 292 unneeded state into the L2 flooding domain or creating 'choke 293 points' at the 'flood reflectors' themselves. A solution without 294 tunnels is also possible by judicious scoping of reachability 295 information between the levels. 297 o Some way to support reflector redundancy, and potentially some way 298 to auto-discover and advertise such adjacencies as flood reflector 299 adjacencies. Such advertisements may allow L2 nodes outside the 300 L1 to perform optimizations in the future based on this 301 information. 303 2. Further Details 305 Several considerations should be noted in relation to such a flood 306 reflection mechanism. 308 First, this allows multi-area IS-IS deployments to scale without any 309 major modifications in the IS-IS implementation on most of the nodes 310 deployed in the network. Unmodified (traditional) L2 routers will 311 compute reachability across the transit L1 area using the flood 312 reflector adjacencies. 314 Second, the flood reflectors are not required to participate in 315 forwarding traffic through the L1 transit area. These flood 316 reflectors can be hosted on virtual devices outside the forwarding 317 topology. 319 Third, astute readers will realize that flooding reflection may cause 320 the use of suboptimal paths. This is similar to the BGP route 321 reflection suboptimal routing problem described in 322 [ID.draft-ietf-idr-bgp-optimal-route-reflection-19]. The L2 323 computation determines the egress L1/L2 and with that can create 324 illusions of ECMP where there is none. And in certain scenarios lead 325 to an L1/L2 egress which is not globally optimal. This represents a 326 straightforward instance of the trade-off between the amount of 327 control plane state and the optimal use of paths through the network 328 often encountered when aggregating routing information. 330 One possible solution to this problem is to expose additional 331 topology information into the L2 flooding domains. In the example 332 network given, links from router 01 to router 02 can be exposed into 333 L2 even when 01 and 02 are participating in flood reflection. This 334 information would allow the L2 nodes to build 'shortcuts' when the L2 335 flood reflected part of the topology looks more expensive to cross 336 distance wise. 338 Another possible variation is for an implementation to approximate 339 with the L1 tunnel cost the cost of the underlying topology. 341 Redundancy can be achieved by building multiple flood reflectors in 342 the L1 area. Multiple flood reflectors do not need any 343 synchronization mechanisms amongst themselves, except standard ISIS 344 flooding and database maintenance procedures. 346 On change in either flood reflection role or cluster ID on IIH the 347 adjacency has to be reset. 349 3. Flood Reflection TLV 351 The Flood Reflection TLV is a new top-level TLV that MAY appear in 352 IIHs. The Flood Reflection TLV indicates the flood reflector cluster 353 (based on Flood Reflection Cluster ID) that a given router is 354 configured to participate in. It also indicates whether the router 355 is configured to play the role of either flood reflector or flood 356 reflector client. The Flood Reflection Cluster ID and flood 357 reflector roles advertised in the IIHs are used to ensure that flood 358 reflector adjacencies are only formed between a flood reflector and 359 flood reflector client, and that the Flood Reflection Cluster IDs 360 match. The Flood Reflection TLV has the following format: 362 0 1 2 3 363 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 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Type | Length |C| RESERVED | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Flood Reflection Cluster ID | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 | Sub-TLVs ... 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Type: TBD 374 Length: The length, in octets, of the following fields. 376 C (Client): This bit is set to indicate that the router acts as a 377 flood reflector client. When this bit is NOT set, the router acts 378 as a flood reflector. On a given router, the same value of the 379 C-bit MUST be advertised across all interfaces advertising the 380 Flood Reflection TLV in IIHs. 382 RESERVED: This field is reserved for future use. It MUST be set to 383 0 when sent and MUST be ignored when received. 385 Flood Reflection Cluster ID: Flood Reflection Cluster Identifier. 386 These same 32-bit value MUST be assigned to all of the flood 387 reflectors and flood reflector clients in the L1 area. The value 388 MUST be unique across different L1 areas within the IGP domain. 389 On a given router, the same value of the Flood Reflection Cluster 390 ID MUST be advertised across all interfaces advertising the Flood 391 Reflection TLV in IIHs. This implies that a flood reflector can 392 participate in a single L1 area only. 394 Sub-TLVs: Optional sub-TLVs. For future extensibility, the format 395 of the Flood Reflection TLV allows for the possibility of 396 including optional sub-TLVs. No sub-TLVs of the Flood Reflection 397 TLV are defined in this document. 399 The Flood Reflection TLV MUST NOT appear more than once in an IIH. A 400 router receiving multiple Flood Reflection TLVs in the same IIH 401 SHOULD use the values in the first TLV. 403 4. Flood Reflection Discovery Sub-TLV 405 Flood Reflection Discovery sub-TLV is advertised as a sub-TLV of the 406 IS-IS Router Capability TLV-242, defined in [RFC7981]. The Flood 407 Reflection Discovery sub-TLV is advertised in L1 LSPs with area 408 flooding scope in order to enable the auto-discovery of flood 409 reflection capabilities and the automatic creation of L2 tunnels to 410 be used as flood reflector adjacencies. The Flood Reflection 411 Discovery sub-TLV has the following format: 413 0 1 2 3 414 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 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length |C| Reserved | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Flood Reflection Cluster ID | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Type: TBD 423 Length: The length, in octets, of the following fields. 425 C (Client): This bit is set to indicate that the router acts as a 426 flood reflector client. When this bit is NOT set, the router acts 427 as a flood reflector. 429 RESERVED: This field is reserved for future use. It MUST be set to 430 0 when sent and MUST be ignored when received. 432 Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier 433 is the same as that defined in the Flood Reflection TLV. 435 The Flood Reflection Discovery sub-TLV MUST NOT appear more than once 436 in TLV 242. A router receiving multiple Flood Reflection Discovery 437 sub-TLVs in TLV 242 SHOULD use the values in the first sub-TLV. 439 5. Flood Reflection Adjacency Sub-TLV 441 The Flood Reflection Adjacency sub-TLV is advertised as a sub-TLV of 442 TLVs 22, 23, 25, 141, 222, and 223. Its presence indicates that a 443 given adjacency is a flood reflector adjacency. It is included in L2 444 area scope flooded LSPs. Flood Reflection Adjacency sub-TLV has the 445 following format: 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Type | Length |C| Reserved | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Flood Reflection Cluster ID | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Type: TBD 457 Length: The length, in octets, of the following fields. 459 C (Client): This bit is set to indicate that the router advertising 460 this adjacency is a flood reflector client. When this bit is NOT 461 set, the router advertising this adjacency is a flood reflector. 463 RESERVED: This field is reserved for future use. It MUST be set to 464 0 when sent and MUST be ignored when received. 466 Flood Reflection Cluster ID: The Flood Reflection Cluster Identifier 467 is the same as that defined in the Flood Reflection TLV. 469 The Flood Reflection Adjacency sub-TLV MUST NOT appear more than once 470 in a given TLV. A router receiving multiple Flood Reflection 471 Adjacency sub-TLVs in a TLV SHOULD use the values in the first sub- 472 TLV. 474 6. Flood Reflection Discovery 476 A router participating in flood reflection MUST be configured as an 477 L1/L2 router. It originates the Flood Reflection Discovery sub-TLV 478 with area flooding scope in L1 only. Normally, all routers on the 479 edge of the L1 area (those having traditional L2 adjacencies) will 480 advertise themselves as route reflector clients. Therefore, a flood 481 reflector client will have both traditional L2 adjacencies and flood 482 reflector L2 adjacencies. 484 A router acting as a flood reflector MUST NOT have any traditional L2 485 adjacencies. It will be an L1/L2 router only by virtue of having 486 flood reflector L2 adjacencies. A router desiring to act as a flood 487 reflector will advertise itself as such using the Flood Reflection 488 Discovery sub-TLV in L1. 490 A given flood reflector or flood reflector client can only 491 participate in a single cluster, as determined by the value of its 492 Flood Reflection Cluster ID. 494 Upon reception of Flood Reflection Discovery sub-TLVs, a router 495 acting as flood reflector client MUST initiate a tunnel towards each 496 flood reflector with which it shares an Flood Reflection Cluster ID. 497 The L2 adjacencies formed over such tunnels MUST be marked as flood 498 reflector adjacencies. If the client has a direct L2 adjacency with 499 the flood reflector it SHOULD use it instead of instantiating a new 500 tunnel. 502 Upon reception of Flood Reflection Discover TLVs, a router acting as 503 a flood reflector client MAY initiate tunnels with L1-only 504 adjacencies towards all the other flood reflector clients in its 505 cluster. These tunnels MAY be used for forwarding to improve the 506 load-balancing characteristics of the L1 area. 508 7. Flood Reflection Adjacency Formation 510 In order to simplify both implementations and network deployments, we 511 do not allow the formation of complex hierarchies of flood reflectors 512 and clients. All flood reflectors and flood reflector clients in the 513 same L1 area MUST share the same Flood Reflector Cluster ID. A flood 514 reflector MUST only form flood reflection adjacencies with flood 515 reflector clients. A flood reflector MUST NOT form any traditional 516 L2 adjacencies. Flood reflector clients MUST only form flood 517 reflection adjacencies with flood reflectors. Flood reflector 518 clients MAY form traditional L2 adjacencies with flood reflector 519 clients or nodes not participating in flood reflection. 521 The Flood Reflector Cluster ID and flood reflector roles advertised 522 in the Flood Reflection TLVs in IIHs are used to ensure that flood 523 reflection adjacencies that are established meet the above criteria. 525 Once a flood reflection adjacency is established, the flood reflector 526 and the flood reflector client MUST advertise the adjacency by 527 including the Flood Reflection Adjacency Sub-TLV in the Extended IS 528 reachability TLV or MT-ISN TLV. 530 8. Redistribution of Prefixes 532 In some scenarios, L2 prefixes need to be redistributed into L1 by 533 the route reflector clients. However, if a L1 area edge router 534 doesn't have any L2 flood reflector adjacencies, then it cannot be 535 the shortest path egress in the L2 topology. Therefore, flood 536 reflector client SHOULD only redistribute L2 prefixes into L1 if it 537 has an L2 flood reflector adjacency. The L2 prefixes advertisements 538 redistributed into L1 SHOULD be normally limited to L2 intra-area 539 routes (as defined in [RFC7775]), if the information exists to 540 distinguish them from other L2 prefix advertisements. 542 On the other hand, in topologies that make use of flood reflection to 543 hide the structure of L1 areas while still providing transit 544 forwarding across them, we generally do not need to redistribute L1 545 prefixes advertisements into L2. 547 In deployment scenarios where L1 tunnels are not used, all L1/L2 edge 548 nodes MUST be flood reflector clients. 550 9. Route Computation 552 To ensure loop-free routing, the route reflection client MUST follow 553 the normal L2 computation to determine L2 routes. This is because 554 nodes outside the L1 area will generally not be aware that flood 555 reflection is being performed. The flood reflection clients need to 556 produce the same result for the L2 route computation as a router not 557 participating in flood reflection. However, a flood reflector client 558 will not necessarily use a given L2 route for forwarding. For an L2 559 route that uses a flood reflection adjacency as a next-hop, the flood 560 reflection client may use the next-hop from an L1 route instead. 562 On the reflection client, after L2 and L1 computation, all flood 563 reflector adjacencies used as next-hops for L2 routes MUST be 564 examined and replaced with the correct L1 tunnel next-hop to the 565 egress. Alternatively, if the ingress has adequate reachability 566 information to ensure forwarding towards destination via L1 routes, 567 L2 routes using flood reflector adjacencies as next-hops can be 568 omitted entirely. Due to the rules in Section 7 the computation in 569 the resulting topology is relatively simple, the L2 SPF from a flood 570 reflector client is guaranteed to reach within a hop the Flood 571 Reflector and in the following hop the L2 egress to which it has a L1 572 forwarding tunnel. However, if the topology has L2 paths which are 573 not route reflected and look "shorter" than the path through the 574 Flood Reflector then the computation will have to track the egress 575 out of the L1 domain by a more advanced algorithm. 577 10. Special Considerations 579 In pathological cases setting the overload bit in L1 (but not in L2) 580 can partition L1 forwarding, while allowing L2 reachability through 581 flood reflector adjacencies to exist. In such a case a node cannot 582 replace a route through a flood reflector adjacency with a L1 583 shortcut and the client can use the L2 tunnel to the flood reflector 584 for forwarding while it MUST initiate an alarm and declare 585 misconfiguration. 587 A flood reflector with directly L2 attached prefixes should advertise 588 those in L1 as well since based on preference of L1 routes the 589 clients will not try to use the L2 flood reflector adjacency to route 590 the packet towards them. A very, very corner case is when the flood 591 reflector is reachable via L2 flood reflector adjacency (due to 592 underlying L1 partition) only in which case the client can use the L2 593 tunnel to the flood reflector for forwarding towards those prefixes 594 while it MUST initiate an alarm and declare misconfiguration. 596 A flood reflector SHOULD NOT set the attached bit on its LSPs. 598 Instead of modifying the computation procedures one could imagine a 599 flood reflector solution where the Flood Reflector would re-advertise 600 the L2 prefixes with a 'third-party' next-hop but that would have 601 less desirable convergence properties than the solution proposed and 602 force a fork-lift of all L2 routers to make sure they disregard such 603 prefixes unless in the same L1 domain as the Flood Reflector. 605 Depending on pseudo-node choice in case of a broadcast domain with 606 multiple flood reflectors attached this can lead to a partitioned LAN 607 and hence a router discovering such a condition MUST initiate an 608 alarm and declare misconfiguration. 610 11. IANA Considerations 612 This document requests allocation for the following IS-IS TLVs and 613 Sub-TLVs. 615 11.1. New IS-IS TLV Codepoint 617 This document requests the following IS-IS TLV: 619 Value Name IIH LSP SNP Purge 620 ----- --------------------------------- --- --- --- ----- 621 TBD1 Flood Reflection y n n n 623 Suggested value for TBD1 is 161. 625 11.2. Sub TLVs for TLV 242 627 This document request the following registration in the "sub-TLVs for 628 TLV 242" registry. 630 Type Description 631 ---- ----------- 632 TBD2 Flood Reflection Discovery 634 Suggested value for TBD2 is 161. 636 11.3. Sub TLVs for TLV 22, 23, 25, 141, 222, and 223 638 This document requests the following registration in the "sub-TLVs 639 for TLV 22, 23, 25, 141, 222, and 223" registry. 641 Type Description 22 23 25 141 222 223 642 ---- -------------------------------- --- --- --- --- --- --- 643 TBD3 Flood Reflector Adjacency y y n y y y 645 Suggested value for TBD3 is 161. 647 12. Security Considerations 649 This document introduces no new security concerns to ISIS or other 650 specifications referenced in this document. 652 13. Acknowledgements 654 The authors thank Shraddha Hegde, Peter Psenak, and Les Ginsberg for 655 their thorough review and detailed discussions. 657 14. References 659 14.1. Informative References 661 [ID.draft-ietf-idr-bgp-optimal-route-reflection-19] 662 Raszuk et al., R., "BGP Optimal Route Reflection", July 663 2019. 665 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 666 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 667 DOI 10.17487/RFC4271, January 2006, 668 . 670 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 671 Reflection: An Alternative to Full Mesh Internal BGP 672 (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, 673 . 675 [RFC8099] Chen, H., Li, R., Retana, A., Yang, Y., and Z. Liu, "OSPF 676 Topology-Transparent Zone", RFC 8099, 677 DOI 10.17487/RFC8099, February 2017, 678 . 680 14.2. Normative References 682 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 683 Requirement Levels", BCP 14, RFC 2119, 684 DOI 10.17487/RFC2119, March 1997, 685 . 687 [RFC7775] Ginsberg, L., Litkowski, S., and S. Previdi, "IS-IS Route 688 Preference for Extended IP and IPv6 Reachability", 689 RFC 7775, DOI 10.17487/RFC7775, February 2016, 690 . 692 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 693 for Advertising Router Information", RFC 7981, 694 DOI 10.17487/RFC7981, October 2016, 695 . 697 Authors' Addresses 699 Tony Przygienda 700 Juniper 701 1137 Innovation Way 703 Sunnyvale, CA 705 USA 707 Email: prz@juniper.net 708 Chris Bowers 709 Juniper 710 1137 Innovation Way 712 Sunnyvale, CA 714 USA 716 Email: cbowers@juniper.net 718 Yiu Lee 719 Comcast 720 1800 Bishops Gate Blvd 721 Mount Laurel, NJ 08054 722 US 724 Email: Yiu_Lee@comcast.com 726 Alankar Sharma 727 Comcast 728 1800 Bishops Gate Blvd 729 Mount Laurel, NJ 08054 730 US 732 Email: Alankar_Sharma@comcast.com 734 Russ White 735 Juniper 736 1137 Innovation Way 738 Sunnyvale, CA 740 USA 742 Email: russw@juniper.net