idnits 2.17.1 draft-ietf-lsr-isis-extended-hierarchy-01.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 (January 8, 2020) is 1568 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' ** Downref: Normative reference to an Informational RFC: RFC 5309 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Li 3 Internet-Draft Arista Networks 4 Intended status: Standards Track L. Ginsberg 5 Expires: July 11, 2020 P. Wells 6 Cisco Systems 7 January 8, 2020 9 IS-IS Extended Hierarchy 10 draft-ietf-lsr-isis-extended-hierarchy-01 12 Abstract 14 The IS-IS routing protocol was originally defined with a two level 15 hierarchical structure. This was adequate for the networks at the 16 time. As we continue to expand the scale of our networks, it is 17 apparent that additional hierarchy would be a welcome degree of 18 flexibility in network design. 20 This document defines IS-IS Levels 3 through 8. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on July 11, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. PDU changes . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2.1. Circuit Type . . . . . . . . . . . . . . . . . . . . . . 4 60 2.2. PDU Type . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Additional PDUs . . . . . . . . . . . . . . . . . . . . . . . 4 62 3.1. Level n LAN IS to IS hello PDU (Ln-LAN-HELLO-PDU) . . . . 5 63 3.2. Level n Point-to-point IS to IS hello PDU (Ln-P2P-HELLO- 64 PDU) . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 4. Level Specific Area Identifiers . . . . . . . . . . . . . . . 5 66 4.1. IS-IS Area Hierarchy TLV . . . . . . . . . . . . . . . . 6 67 4.2. Adjacency Formation Rules . . . . . . . . . . . . . . . . 8 68 4.2.1. Level 3-8 Adjacency Formation Rules . . . . . . . . . 8 69 4.2.2. Special Level-1 and Level-2 Adjacency Formation Rules 9 70 4.2.2.1. Actions on a Point-to-Point Circuit . . . . . . . 9 71 4.2.2.2. Actions on a LAN Circuit . . . . . . . . . . . . 9 72 4.2.2.3. Reporting of Mismatched Area Hierarchies . . . . 9 73 5. New Flooding Scopes . . . . . . . . . . . . . . . . . . . . . 10 74 6. MAC Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 75 7. Inheritance of TLVs . . . . . . . . . . . . . . . . . . . . . 13 76 8. Behavior of Level n . . . . . . . . . . . . . . . . . . . . . 13 77 9. Relationship between levels . . . . . . . . . . . . . . . . . 13 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 79 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 80 11.1. PDU Type . . . . . . . . . . . . . . . . . . . . . . . . 13 81 11.2. New PDUs . . . . . . . . . . . . . . . . . . . . . . . . 13 82 11.3. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 14 83 11.4. New Flooding Scopes . . . . . . . . . . . . . . . . . . 14 84 11.5. New MAC Addresses . . . . . . . . . . . . . . . . . . . 15 85 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 86 13. Normative References . . . . . . . . . . . . . . . . . . . . 16 87 Appendix A. Preventing Cross Branching in the Hierarchy . . . . 16 88 Appendix B. Guidelines for Introducing a new level . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 91 1. Introduction 93 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two 94 level hierarchy of abstraction. The fundamental unit of abstraction 95 is the 'area', which is a (hopefully) connected set of systems 96 running IS-IS at the same level. Level 1, the lowest level, is 97 abstracted by routers that participate in both Level 1 and Level 2. 99 Practical considerations, such as the size of an area's link state 100 database, cause network designers to restrict the number of routers 101 in any given area. Concurrently, the dominance of scale-out 102 architectures based around small routers has created a situation 103 where the scalability limits of the protocol are going to become 104 critical in the foreseeable future. 106 The goal of this document is to enable additional hierarchy within 107 IS-IS. Each additional level of hierarchy has a multiplicative 108 effect on scale, so the addition of six levels should be a 109 significant improvement. While all six levels may not be needed in 110 the short term, it is apparent that the original designers of IS-IS 111 reserved enough space for these levels, and defining six additional 112 levels is only slightly harder than adding a single level, so it 113 makes sense to expand the design for the future. 115 The modifications described herein are designed to be fully backward 116 compatible and have no effect on existing networks. The 117 modifications are also designed to have no effect whatsoever on 118 networks that only use Level 1 and/or Level 2. 120 Section references in this document are references to sections of IS- 121 IS [ISO10589]. 123 Note that [ISO10589] uses a bit encoding convention where bit numbers 124 are 1 based and Bit 1 is the Least Significant Bit (LSB) of the 125 datatype. Traditionally IETF documents have used a bit encoding 126 convention where bit numbers are 0 based and Bit 0 is the Most 127 Significant Bit (MSB) of the datatype. This document uses [ISO10589] 128 conventions throughout. 130 1.1. Requirements Language 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 134 "OPTIONAL" in this document are to be interpreted as described in BCP 135 14 [RFC2119] [RFC8174] when, and only when, they appear in all 136 capitals, as shown here. 138 2. PDU changes 140 In this section, we enumerate all of the redefinitions of protocol 141 header fields necessary to add additional levels. 143 2.1. Circuit Type 145 In the fixed header of some IS-IS PDUs, a field is named 'Reserved/ 146 Circuit Type' (Section 9.5). The high order six bits are reserved, 147 with the low order two bits indicating Level 1 (bit 1) and Level 2 148 (bit 2). 150 This field is renamed to be 'Circuit Type'. The bits are redefined 151 as follows: 153 1. Level 1 155 2. Level 2 157 3. Level 3 159 4. Level 4 161 5. Level 5 163 6. Level 6 165 7. Level 7 167 8. Level 8 169 The value of zero (no bits set) is reserved. PDUs with a Circuit 170 Type of zero SHALL be ignored. 172 The set bits of the Circuit Type MUST be contiguous. If bit n and 173 bit m are set in the Circuit Type, then all bits in the interval 174 [n:m] must be set. 176 2.2. PDU Type 178 The fixed header of IS-IS PDUs contains an octet with three reserved 179 bits and the 'PDU Type' field. The three reserved bits are 180 transmitted as zero and ignored on receipt. (Section 9.5) 182 To allow for additional PDU space, this entire octet is renamed the 183 'PDU Type' field. 185 3. Additional PDUs 186 3.1. Level n LAN IS to IS hello PDU (Ln-LAN-HELLO-PDU) 188 The 'Level n LAN IS to IS hello PDU' (Ln-LAN-HELLO-PDU) is identical 189 in format to the 'Level 2 LAN IS to IS hello PDU' (Section 9.6), 190 except that the PDU Types are defined as follows: 192 Level 3 (L3-LAN-HELLO-PDU): 33 (Suggested - to be assigned by 193 IANA) 195 Level 4 (L4-LAN-HELLO-PDU): 34 (Suggested - to be assigned by 196 IANA) 198 Level 5 (L5-LAN-HELLO-PDU): 35 (Suggested - to be assigned by 199 IANA) 201 Level 6 (L6-LAN-HELLO-PDU): 36 (Suggested - to be assigned by 202 IANA) 204 Level 7 (L7-LAN-HELLO-PDU): 37 (Suggested - to be assigned by 205 IANA) 207 Level 8 (L8-LAN-HELLO-PDU): 38 (Suggested - to be assigned by 208 IANA) 210 The Circuit Type field MUST be set to indicate all levels supported 211 on that circuit - not just the level associated with the containing 212 PDU type. 214 3.2. Level n Point-to-point IS to IS hello PDU (Ln-P2P-HELLO-PDU) 216 The 'Point-to-point IS to IS hello PDU' (Section 9.7) is used on 217 Level 1 and Level 2 circuits. Legacy systems will not expect the 218 circuit type field to indicate other levels, so a new PDU is used if 219 the circuit supports other levels. The additional PDU is the 'Level 220 n Point-to-point IS to IS hello PDU' (Ln-P2P-HELLO-PDU) and has PDU 221 Type 39 (Suggested - to be assigned by IANA). The format of this PDU 222 is identical to the existing Point-to-Point IS to IS hello PDU. Both 223 PDUs may be used on the same circuit. 225 4. Level Specific Area Identifiers 227 [ISO10589] defines an Area Address to uniquely identify a Level-1 228 area. A given area may have multiple synonymous area addresses - 229 which is useful in support of hitless merging or splitting of areas. 230 Area address matching is part of the adjacency formation rules 231 defined in Section 8 which determine whether a given adjacency 232 supports Level-1, Level-2, or both. Area addresses are advertised in 233 IIHs and LSPs using the Area Address TLV. 235 With the extensions defined in this document, there is a need to 236 define an equivalent identifier for Levels 2-8. The Level Specific 237 Area Identifier (LSAI) is a 16 bit value and is advertised using the 238 new Area Hierarchy TLV defined in Section 4.1. There is no 239 relationship between a Level-1 Area Address and an LSAI. 241 Just as with Area Addresses, multiple synonomous LSAIs may be 242 assigned to a given level. This supports hitless merging or 243 splitting of the level specific area. Although it is legal to do so, 244 it is generally not useful to define more than two Area Identifiers 245 for a given level. 247 A node MAY support any set of contiguous levels. Support for non- 248 contiguous levels is undefined. 250 4.1. IS-IS Area Hierarchy TLV 252 The Area Hierarchy TLV specifies the set of LSAIs which comprise the 253 branch of the network hierarchy to which the advertising node is 254 connected. The TLV MUST include at least one LSAI for Levels 2-N, 255 where N is >= 2 and N represents the highest level supported in the 256 IS-IS domain. It is RECOMMENDED that N == 8 even when not all 8 257 levels are currently in use, but in cases where a network does not 258 support higher levels a number less than 8 MAY be used. 260 Note that the levels advertised MAY include levels which are not 261 supported by the advertising node. 263 The Area Hierarchy TLV has the following format: 265 8 7 6 5 4 3 2 1 266 +-+-+-+-+-+-+-+-+ 267 | TLV Type | 268 +-+-+-+-+-+-+-+-+ 269 | TLV Length | 270 +-+-+-+-+-+-+-+-+ 271 | Supp-Levels | 272 +-+-+-+-+-+-+-+-+ 274 Followed by one or more Level Specific Area ID Sets: 276 1 0 277 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Level | # of LSAIs | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 |Level Specific Area Id(s) | 282 ... 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 TLV Type: ZZZ (1 octet) 287 TLV Length: Variable (1 octet) 289 Supp-Levels: A contiguous bitmask representing the set of levels 290 supported by the advertising node (1 octet) 291 Bit #8 of this field is set if Level 8 is supported. 292 Bit #7 of this field is set if Level 7 is supported. 293 Bit #6 of this field is set if Level 6 is supported. 294 Bit #5 of this field is set if Level 5 is supported. 295 Bit #4 of this field is set if Level 4 is supported. 296 Bit #3 of this field is set if Level 3 is supported. 297 Bit #2 of this field is set if Level 2 is supported. 298 Bit #1 of this field is set if Level 1 is supported 300 If the Supp-level bit mask is non-contiguous all advertised LSAIs 301 are ignored. 303 Each Level Specific Area ID Set consists of: 305 Level: 2-8 (1 octet) 306 # of LSAI: >=1 (1 octet) 307 LSAIs: The set of synonomous LSAIs associated with this level 308 (2 * # of LSAIs octets) 310 The Area Hierarchy TLV MUST appear in all new IIH PDUs defined in 311 Section 3. It MAY appear in P2P-HELLO-PDUs, L1-LAN-HELLO-PDUs, or 312 L2-LAN-HELLO-PDUs. 314 The Area Hierarchy TLV MUST appear in LSP #0 of non-pseudo-node Level 315 3-8 Flooding Scoped LSPs defined in Section 5. It MAY appear in L1 316 or L2 LSP #0. It MUST NOT be present in any LSP with non-zero LSP 317 number. If present in an LSP with non-zero LSP number it MUST be 318 ignored on receipt. 320 Multiple Area Hierarchy TLVs MUST NOT be sent. In the event multiple 321 Area Hierarchy TLVs are received, the first such TLV in the PDU is 322 used. Subsequent TLVs in the same PDU MUST be ignored. 324 4.2. Adjacency Formation Rules 326 Adjacency formation rules for Levels 1 and 2 are defined in 327 [ISO10589] and are not altered by these extensions except where noted 328 below. 330 Adjacency Formation rules for Levels 3 and above are defined to 331 insure that adjacency support for a given level is only enabled when 332 there is a matching Area Identifier. Adjacency formation rules also 333 are defined so as to prevent interconnection of neighbors which will 334 connect to different areas at levels above any supported level. 336 The checks discussed below need to be performed on receipt of an IIH. 338 4.2.1. Level 3-8 Adjacency Formation Rules 340 The Area Hierarchy TLV MUST be present in a Level N Point-to-point IS 341 to IS hello PDU or a Level N LAN IS to IS Hello PDU and the TLV 342 content MUST adhere to the definition in Section 4.1. Beginning with 343 the lowest level supported by the receiving node on this circuit and 344 including all higher levels for which the receiver has an assigned 345 LSAI regardless as to whether the higher levels are supported on this 346 circuit, the set of LSAIs defined on the receiving node is compared 347 against the set of LSAIs advertised in the received TLV. A matching 348 LSAI MUST be found for each level. 350 If all of the checks pass then a new adjacency is formed or an 351 existing adjacency is maintained. 353 NOTE: The absence of the advertisement of an LSAI for a given level 354 is considered as a failure to find a matching LSAI. 356 On a Point-to-Point circuit, a single adjacency is formed which 357 supports all of the levels supported by both nodes on this circuit. 359 On a LAN circuit, an adjacency is formed supporting only the level 360 specified by the PDU type. 362 Note that (as previously specified) the set of levels advertised MUST 363 be contiguous. 365 4.2.2. Special Level-1 and Level-2 Adjacency Formation Rules 367 The Area Hierarchy TLV MAY appear in a Point-to-point IS to IS hello 368 PDU, Level 1 LAN IS to IS Hello PDU, or Level 2 LAN IS to IS Hello 369 PDU (PDUs specified in [ISO10589]). In such a case, the neighbor may 370 or may not support the Area Hierarchy TLV. The following sub- 371 sections define modified adjacency formation rules for point-to-point 372 and LAN circuits. 374 4.2.2.1. Actions on a Point-to-Point Circuit 376 If the Area Hierarchy TLV is present, then in addition to the checks 377 specified in [ISO10589] the checks specified in Section 4.2.1 MUST be 378 performed for all levels for which the receiver has an assigned LSAI 379 beginning with Level 2. If those checks fail an adjacency MUST NOT 380 be formed and any existing matching adjacency MUST transition to DOWN 381 state. 383 4.2.2.2. Actions on a LAN Circuit 385 Adjacency formation MUST follow the rules defined in [ISO10589]. If 386 the Area Hierarchy TLV is present in the Level 1 or Level 2 LAN IS to 387 IS Hello PDU then the checks specified in Section 4.2.1 SHOULD be 388 performed for all levels for which the receiver has an assigned LSAI 389 beginning with Level 2. If those checks fail an error SHOULD be 390 reported, but the level specific adjacency is still allowed. This 391 prevents violation of the assumption of transitivity on the LAN in 392 the presence of systems which do not support the extensions defined 393 in this document. 395 4.2.2.3. Reporting of Mismatched Area Hierarchies 397 When forming adjacencies at Level-1 and/or Level-2, it is possible to 398 have a mixture of legacy nodes (which do NOT support the extensions 399 defined in this document) and new nodes which do support the 400 extensions. 402 In Point-to-Point mode, legacy nodes will not advertise the new Area 403 Hierarchy TLV and will not have an assigned LSAI for Level-2. It 404 then becomes possible for new nodes with mismatched Area Hierarchies 405 to form adjacencies with legacy nodes and form an L1 or L2 area where 406 not all new nodes have a matching Area Hierarchy. This cannot be 407 detected when forming adjacencies if the new nodes are not directly 408 connected - but it can be detected after the adjacencies have been 409 formed by inspecting the set of Area Hierarchy TLVs in the level 410 specific LSPs of all routers in the area. 412 Similarly in LAN mode, the transitivity requirement means that new 413 nodes MUST form adjacencies with all nodes connected to the LAN even 414 when the Area Hierarchy TLV mismatch check fails (see 415 Section 4.2.2.2). This can occur both at Level-1 and Level-2. 417 New nodes MUST report these inconsistencies. 419 5. New Flooding Scopes 421 For levels 3-8, all link state information, PSNPs, and CSNPs are 422 relayed in conformance with [RFC7356]. Additional flooding scopes 423 are defined for each new level, for both circuit flooding scope and 424 level flooding scope. Level flooding scopes are defined for both 425 Standard and Extended TLV formats. The list of additional flooding 426 scopes is: 428 FS LSP ID Format/ 429 Value Description TLV Format 430 ----- ------------------------------ ----------------- 431 6 Level 3 Circuit Flooding Scope Extended/Standard 432 7 Level 4 Circuit Flooding Scope Extended/Standard 433 8 Level 5 Circuit Flooding Scope Extended/Standard 434 9 Level 6 Circuit Flooding Scope Extended/Standard 435 10 Level 7 Circuit Flooding Scope Extended/Standard 436 11 Level 8 Circuit Flooding Scope Extended/Standard 437 12 Level 3 Flooding Scope Extended/Standard 438 13 Level 4 Flooding Scope Extended/Standard 439 14 Level 5 Flooding Scope Extended/Standard 440 15 Level 6 Flooding Scope Extended/Standard 441 16 Level 7 Flooding Scope Extended/Standard 442 17 Level 8 Flooding Scope Extended/Standard 443 18 Level 3 Flooding Scope Standard/Standard 444 19 Level 4 Flooding Scope Standard/Standard 445 20 Level 5 Flooding Scope Standard/Standard 446 21 Level 6 Flooding Scope Standard/Standard 447 22 Level 7 Flooding Scope Standard/Standard 448 23 Level 8 Flooding Scope Standard/Standard 449 70 Level 3 Circuit Flooding Scope Extended/Extended 450 71 Level 4 Circuit Flooding Scope Extended/Extended 451 72 Level 5 Circuit Flooding Scope Extended/Extended 452 73 Level 6 Circuit Flooding Scope Extended/Extended 453 74 Level 7 Circuit Flooding Scope Extended/Extended 454 75 Level 8 Circuit Flooding Scope Extended/Extended 455 76 Level 3 Flooding Scope Extended/Extended 456 77 Level 4 Flooding Scope Extended/Extended 457 78 Level 5 Flooding Scope Extended/Extended 458 79 Level 6 Flooding Scope Extended/Extended 459 80 Level 7 Flooding Scope Extended/Extended 460 81 Level 8 Flooding Scope Extended/Extended 462 The final octet of the header of a Flooding Scoped LSP as defined in 463 [RFC7356] contains Reserved/LSPDBOL/IS Type information. This field 464 is redefined for the new flooding scopes defined in this document as 465 follows: 467 Reserved/ATT/LSPDBOL 469 Bits 8-5 Reserved 470 Transmitted as 0 and ignored on receipt 471 Bit 4 ATT 472 If set to 1 indicates that the sending IS is attached to 473 routers in other Level N areas via Level N+1 474 Bit 3 LSDBOL 475 As defined in RFC7356 476 Bits 2-1 477 Transmitted as 0 and ignored on receipt. 479 Note that the levels supported (analogous to the IS-type information 480 in L1 and L2 LSPs) can be obtained from the Area Hierarchy TLV 481 advertised in the associated LSP #0. 483 Note that the definition of the ATT bit specified above also applies 484 to L2 LSPs. Previously this bit would have no meaning as [ISO10589] 485 does not define support for Level 3. 487 6. MAC Addresses 489 On a broadcast network, PDUs are currently sent to the AllL1Iss or 490 AllL2Iss MAC addresses. We will need additional MAC addresses for 491 Levels 3-8. 493 AllL3ISs: MAC3 495 AllL4ISs: MAC4 497 AllL5ISs: MAC5 499 AllL6ISs: MAC6 501 AllL7ISs: MAC7 503 AllL8ISs: MAC8 505 When operating in Point-to-Point mode on a broadcast network 506 [RFC5309], a Level N Point-to-Point Hello PDU will be sent. Any of 507 the above MAC addresses could be used in this case, but it is 508 recommended to use the AllL3ISs MAC address. 510 7. Inheritance of TLVs 512 All existing Level 2 TLVs may be used in the corresponding Level 3 513 through Level 8 PDUs. When used in a Level 3 through Level 8 PDU, 514 the semantics of these TLVs will be applied to the Level of the 515 containing PDU. If the original semantics of the PDU was carrying a 516 reference to Level 1 in a Level 2 TLV, then the semantics of the TLV 517 at level N will be a reference to level N-1. The intent is to retain 518 the original semantics of the TLV at the higher level. 520 8. Behavior of Level n 522 The behavior of Level n is analogous to the behavior of Level 2. 524 9. Relationship between levels 526 The relationship between Level n and Level n-1 is analogous to the 527 relationship between Level 2 and Level 1. 529 An area at Level n has at most one parent at Level n+1. 531 10. Acknowledgements 533 The authors would like to thank Dinesh Dutt for inspiring this 534 document and Huaimo Chen for his comments. The authors would also 535 like to thank Tony Pryzienda for his careful review and excellent 536 suggestions. 538 11. IANA Considerations 540 This document makes many requests to IANA, as follows: 542 11.1. PDU Type 544 The existing IS-IS PDU registry currently supports values 0-31. This 545 should be expanded to support the values 0-255. The existing value 546 assignments should be retained. Value 255 should be reserved. 548 11.2. New PDUs 550 IANA is requested to allocate values from the IS-IS PDU registry for 551 the following: 553 L3-LAN-HELLO-PDU: 33 (Suggested - to be assigned by IANA) 555 L4-LAN-HELLO-PDU: 34 (Suggested - to be assigned by IANA) 557 L5-LAN-HELLO-PDU: 35 (Suggested - to be assigned by IANA) 558 L6-LAN-HELLO-PDU: 36 (Suggested - to be assigned by IANA) 560 L7-LAN-HELLO-PDU: 37 (Suggested - to be assigned by IANA) 562 L8-LAN-HELLO-PDU: 38 (Suggested - to be assigned by IANA) 564 Ln-P2P-HELLO-PDU: 39 (Suggested - to be assigned by IANA) 566 11.3. New TLVs 568 IANA is requested to allocate values from the IS-IS TLV registry for 569 the following: 571 Area Hierarchy: ZZZ 573 11.4. New Flooding Scopes 575 IANA is requested to allocate the following values from the IS-IS 576 Flooding Scope Identifier Registry. 578 FS LSP ID Format/ IIH Announce 579 Value Description TLV Format Lx-P2P Lx-LAN 580 ----- ------------------------------ ----------------- ------ ------ 581 6 Level 3 Circuit Flooding Scope Extended/Standard Y Y 582 7 Level 4 Circuit Flooding Scope Extended/Standard Y Y 583 8 Level 5 Circuit Flooding Scope Extended/Standard Y Y 584 9 Level 6 Circuit Flooding Scope Extended/Standard Y Y 585 10 Level 7 Circuit Flooding Scope Extended/Standard Y Y 586 11 Level 8 Circuit Flooding Scope Extended/Standard Y Y 587 12 Level 3 Flooding Scope Extended/Standard Y Y 588 13 Level 4 Flooding Scope Extended/Standard Y Y 589 14 Level 5 Flooding Scope Extended/Standard Y Y 590 15 Level 6 Flooding Scope Extended/Standard Y Y 591 16 Level 7 Flooding Scope Extended/Standard Y Y 592 17 Level 8 Flooding Scope Extended/Standard Y Y 593 18 Level 3 Flooding Scope Standard/Standard Y Y 594 19 Level 4 Flooding Scope Standard/Standard Y Y 595 20 Level 5 Flooding Scope Standard/Standard Y Y 596 21 Level 6 Flooding Scope Standard/Standard Y Y 597 22 Level 7 Flooding Scope Standard/Standard Y Y 598 23 Level 8 Flooding Scope Standard/Standard Y Y 599 70 Level 3 Circuit Flooding Scope Extended/Extended Y Y 600 71 Level 4 Circuit Flooding Scope Extended/Extended Y Y 601 72 Level 5 Circuit Flooding Scope Extended/Extended Y Y 602 73 Level 6 Circuit Flooding Scope Extended/Extended Y Y 603 74 Level 7 Circuit Flooding Scope Extended/Extended Y Y 604 75 Level 8 Circuit Flooding Scope Extended/Extended Y Y 605 76 Level 3 Flooding Scope Extended/Extended Y Y 606 77 Level 4 Flooding Scope Extended/Extended Y Y 607 78 Level 5 Flooding Scope Extended/Extended Y Y 608 79 Level 6 Flooding Scope Extended/Extended Y Y 609 80 Level 7 Flooding Scope Extended/Extended Y Y 610 81 Level 8 Flooding Scope Extended/Extended Y Y 612 11.5. New MAC Addresses 614 IANA is requested to allocate values from the IANA Multicast 48-bit 615 MAC Addresses block for the following: 617 AllL3Iss: MAC3 619 AllL4Iss: MAC4 621 AllL5Iss: MAC5 623 AllL6Iss: MAC6 625 AllL7Iss: MAC7 626 AllL8Iss: MAC8 628 12. Security Considerations 630 This document introduces no new security issues. Security of routing 631 within a domain is already addressed as part of the routing protocols 632 themselves. This document proposes no changes to those security 633 architectures. 635 13. Normative References 637 [ISO10589] 638 International Organization for Standardization, 639 "Intermediate System to Intermediate System Intra-Domain 640 Routing Exchange Protocol for use in Conjunction with the 641 Protocol for Providing the Connectionless-mode Network 642 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 644 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 645 Requirement Levels", BCP 14, RFC 2119, 646 DOI 10.17487/RFC2119, March 1997, 647 . 649 [RFC5309] Shen, N., Ed. and A. Zinin, Ed., "Point-to-Point Operation 650 over LAN in Link State Routing Protocols", RFC 5309, 651 DOI 10.17487/RFC5309, October 2008, 652 . 654 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 655 Scope Link State PDUs (LSPs)", RFC 7356, 656 DOI 10.17487/RFC7356, September 2014, 657 . 659 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 660 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 661 May 2017, . 663 Appendix A. Preventing Cross Branching in the Hierarchy 665 The use of additional levels requires careful interconnection of 666 routers which support multiple levels. Consistent association of 667 LSAIs is required not only for validating the connections between 668 routers in a level specific area but also for all levels above a 669 given level to which any of the routers may be connected (directly or 670 indirectly). Failure to do so can result in interconnecting 671 different branches of a tree leading to interarea loops. This leads 672 to the requirement that all routers advertise an LSAI for all levels 673 regardless of whether a given router is configured to participate in 674 a given level or not. 676 At first glance it may seem that it would be sufficient for each 677 router to advertise LSAIs only for the levels that the router is 678 configured to support. However, the following simple example 679 illustrates why this is problematic. 681 +------------+ +------------+ +------------+ 682 | Rtr A | | Rtr B | | Rtr C | 683 | L3 Area 30 |---| L3 Area 30 |---| L3 Area 30 | 684 | L4 Area 40 | | | | L4 Area 44 | 685 +------------+ +------------+ +------------+ 687 Since Router B does not support Level 4, it chose not to advertise 688 any Area for Level 4. This means that neither Router A nor Router C 689 can tell by inspecting hellos that not all routers in Level 3 area 30 690 have been configured to support the same Level 4 area. It is 691 possible for Rtr A and Rtr C to discover the LSAIs advertised by all 692 routers by inspecting the Level 3 LSPs - however this requires that 693 Level 3 adjacencies be formed and maintained even when routing cannot 694 be safely performed via all adjacencies in a given area. It then 695 needs to be decided how routing over existing adjacencies should be 696 limited. A number of possibilities exist: 698 Treat the area as if it were two partitions. In the example 699 Router A would be in one partition and Router C would be in 700 another partition. But Router B could belong to either partition. 702 Select a winning Level 4 Area among the set of Level 4 areas 703 advertised in L3 LSPs and only allow leaking of routes to/from 704 that level 706 But either of these options introduce the possibility that a 707 previously fully connected hierarchy becomes partially disconnected 708 as a result of a single configuration change on a single router and/ 709 or the bringup of a new router. 711 The choice made was then to require all routers suppporting the 712 extensions in this document to advertise an LSAI for all levels 713 regardless of what specific levels an individual router is configured 714 to support. This guarantees that any inconsistency between the 715 intended connectivity of a router at all levels - direct and indirect 716 - can be detected during exchange of hellos and therefore adjacency 717 bringup can always be blocked when necessary. 719 Appendix B. Guidelines for Introducing a new level 721 It is desirable to be able to introduce support for a new level 722 without disruption. This section discusses ways to do this. 724 Initial deployment may require only the support of one additional 725 level (Level 3). However, in the future increased network scale may 726 make introduction of an additional level (Level 4) desirable. It is 727 suggested that all routers be configured to advertise a single 728 candidate LSAI for Level 4 - for the purposes of the example let's 729 use LSAI 44. When ready to deploy Level 4, it is then only necessary 730 to enable Level 4 on those routers who will be participating in the 731 additional level. 733 However, perhaps at the time of deploying Level 3 the administrator 734 has no idea what LSAI will be used for Level 4 in the future. In 735 such a case a "dummy" LSAI should be configured for Level 4 on all 736 routers - let's use "0" in this example. In this case, what needs to 737 be done when ready to enable Level 4 is to go to every router 738 (regardless of whether it will actively participate in the new level) 739 and configure the intended LSAI for Level 4. If LSAI 45 is the 740 intended Level 4 area, then LSAI 45 is configured on each router. 741 Each router is then advertising two LSAIs for Level 4: (0, 45). Once 742 this is completed, go to every router and remove the "dummy" Level 4 743 LSAI (0) and the network is now ready to have this Level 4 area 744 enabled. 746 In the event that support for a new level needs to be introduced and 747 no LSAI was ever advertised for that level, the introduction of LSAI 748 for the new level will cause temporary adjacency flaps as the 749 advertisement of the LSAI for the new level is introduced. To avoid 750 this, implementations would need to introduce support for temporary 751 disablement of the LSAI check for the new level until the 752 configuration of the new LSAI is complete on all nodes. Support for 753 this transition mode is outside the scope of this document. The need 754 for a transition mode can be avoided if an LSAI is configured for 755 levels 2-8 from day one. 757 Authors' Addresses 759 Tony Li 760 Arista Networks 761 5453 Great America Parkway 762 Santa Clara, California 95054 763 United States of America 765 Email: tony.li@tony.li 766 Les Ginsberg 767 Cisco Systems 768 United States of America 770 Email: ginsberg@cisco.com 772 Paul Wells 773 Cisco Systems 774 United States of America 776 Email: pauwells@cisco.com