idnits 2.17.1 draft-li-lsr-isis-hierarchical-isis-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 (June 5, 2019) is 1784 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO10589' Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 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: December 7, 2019 P. Wells 6 Cisco Systems 7 June 5, 2019 9 Hierarchical IS-IS 10 draft-li-lsr-isis-hierarchical-isis-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 December 7, 2019. 39 Copyright Notice 41 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . 3 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) . . . . 4 63 3.2. Level n Point-to-point IS to IS hello PDU (Ln-P2P-HELLO- 64 PDU) . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. IS-IS Area Identifier TLV . . . . . . . . . . . . . . . . . . 5 66 5. New Flooding Scopes . . . . . . . . . . . . . . . . . . . . . 5 67 6. Inheritance of TLVs . . . . . . . . . . . . . . . . . . . . . 6 68 7. Relationship between levels . . . . . . . . . . . . . . . . . 7 69 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 70 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 9.1. PDU Type . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9.2. New PDUs . . . . . . . . . . . . . . . . . . . . . . . . 7 73 9.3. New TLVs . . . . . . . . . . . . . . . . . . . . . . . . 7 74 9.4. New Flooding Scopes . . . . . . . . . . . . . . . . . . . 8 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 11. Normative References . . . . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two 82 level hierarchy of abstraction. The fundamental unit of abstraction 83 is the 'area', which is a (hopefully) connected set of systems 84 running IS-IS at the same level. Level 1, the lowest level, is 85 abstracted by routers that participate in both Level 1 and Level 2. 87 Practical considerations, such as the size of an area's link state 88 database, cause network designers to restrict the number of routers 89 in any given area. Concurrently, the dominance of scale-out 90 architectures based around small routers has created a situation 91 where the scalability limits of the protocol are going to become 92 critical in the foreseeable future. 94 The goal of this document is to enable additional hierarchy within 95 IS-IS. Each additional level of hierarchy has a multiplicative 96 effect on scale, so the addition of six levels should be a 97 significant improvement. While all six levels may not be needed in 98 the short term, it is apparent that the original designers of IS-IS 99 reserved enough space for these levels, and defining six additional 100 levels is only slightly harder than adding a single level, so it 101 makes sense to expand the design for the future. 103 The modifications described herein are designed to be fully backward 104 compatible and have no effect on existing networks. The 105 modifications are also designed to have no effect whatsoever on 106 networks that only use Level 1 and/or Level 2. 108 Section references in this document are references to sections of IS- 109 IS [ISO10589]. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. PDU changes 119 In this section, we enumerate all of the redefinitions of protocol 120 header fields necessary to add additional levels. 122 2.1. Circuit Type 124 In the fixed header of some IS-IS PDUs, a field is named 'Reserved/ 125 Circuit Type' (Section 9.5). The high order six bits are reserved, 126 with the low order two bits indicating Level 1 (bit 1) and Level 2 127 (bit 2). 129 This field is renamed to be 'Circuit Type'. The bits are redefined 130 as follows: 132 1. Level 1 134 2. Level 2 136 3. Level 3 138 4. Level 4 140 5. Level 5 142 6. Level 6 144 7. Level 7 145 8. Level 8 147 The value of zero (no bits set) is reserved. PDUs with a Circuit 148 Type of zero SHALL be ignored. 150 The set bits of the Circuit Type MUST be contiguous. If bit n and 151 bit m are set in the Circuit Type, then all bits in the interval 152 [n:m] must be set. 154 2.2. PDU Type 156 The fixed header of IS-IS PDUs contains an octet with three reserved 157 bits and the 'PDU Type' field. The three reserved bits are 158 transmitted as zero and ignored on receipt. (Section 9.5) 160 To allow for additional PDU space, this entire octet is renamed the 161 'PDU Type' field. 163 3. Additional PDUs 165 3.1. Level n LAN IS to IS hello PDU (Ln-LAN-HELLO-PDU) 167 The 'Level n LAN IS to IS hello PDU' (Ln-LAN-HELLO-PDU) is identical 168 in format to the 'Level 2 LAN IS to IS hello PDU' (Section 9.6), 169 except that the PDU Types are defined as follows: 171 Level 3 (L3-LAN-HELLO-PDU): AA3 173 Level 4 (L4-LAN-HELLO-PDU): AA4 175 Level 5 (L5-LAN-HELLO-PDU): AA5 177 Level 6 (L6-LAN-HELLO-PDU): AA6 179 Level 7 (L7-LAN-HELLO-PDU): AA7 181 Level 8 (L8-LAN-HELLO-PDU): AA8 183 3.2. Level n Point-to-point IS to IS hello PDU (Ln-P2P-HELLO-PDU) 185 The 'Point-to-point IS to IS hello PDU' (Section 9.7) is used on 186 Level 1 and Level 2 circuits. Legacy systems will not expect the 187 circuit type field to indiate other levels, so a new PDU is used if 188 the circuit supports other levels. The additional PDU is the 'Level 189 n Point-to-point IS to IS hello PDU' (Ln-P2P-HELLO-PDU) and has PDU 190 Type TTT with the same format. Both PDUs may be used on the same 191 circuit. 193 4. IS-IS Area Identifier TLV 195 The Area Identifier TLV is added to IS-IS to allow nodes to indicate 196 which areas they participate in. Area Identifiers are locally 197 administered 32 bit numbers. The format of the TLV is: 199 0 1 2 3 200 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 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | TLV Type | TLV Length | Level | Area | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Identifier | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 TLV Type: ZZZ 209 TLV Length: 7 211 Level: The level number of the area. 213 Area Identifier: The identifier associated with the area. 215 The Area Identifier TLV may appear in IIHs or in LSPs. When the Area 216 Identifier TLV appears in a PDU, it indicates that the system is 217 participating in the specified area at the indicated level. When the 218 Area Identifier TLV appears in a IIH, the receiving system MUST NOT 219 form an adjacency unless an Area Identifier TLV corresponds to the 220 receiver's own Area Identifier for the given level. 222 5. New Flooding Scopes 224 For levels 3-8, all link state information, PSNPs, and CSNPs are 225 relayed in conformance with RFC 7356 [RFC7356]. Additional flooding 226 scopes are defined for each new level, for both circuit flooding 227 scope and level flooding scope. Level flooding scopes are defined 228 for both Standard and Extended TLV formats. The list of additional 229 flooding scopes is: 231 FS LSP ID Format/ 232 Value Description TLV Format 233 ----- ------------------------------ ----------------- 234 6 Level 3 Circuit Flooding Scope Extended/Standard 235 7 Level 4 Circuit Flooding Scope Extended/Standard 236 8 Level 5 Circuit Flooding Scope Extended/Standard 237 9 Level 6 Circuit Flooding Scope Extended/Standard 238 10 Level 7 Circuit Flooding Scope Extended/Standard 239 11 Level 8 Circuit Flooding Scope Extended/Standard 240 12 Level 3 Flooding Scope Extended/Standard 241 13 Level 4 Flooding Scope Extended/Standard 242 14 Level 5 Flooding Scope Extended/Standard 243 15 Level 6 Flooding Scope Extended/Standard 244 16 Level 7 Flooding Scope Extended/Standard 245 17 Level 8 Flooding Scope Extended/Standard 246 18 Level 3 Flooding Scope Standard/Standard 247 19 Level 4 Flooding Scope Standard/Standard 248 20 Level 5 Flooding Scope Standard/Standard 249 21 Level 6 Flooding Scope Standard/Standard 250 22 Level 7 Flooding Scope Standard/Standard 251 23 Level 8 Flooding Scope Standard/Standard 252 70 Level 3 Circuit Flooding Scope Extended/Extended 253 71 Level 4 Circuit Flooding Scope Extended/Extended 254 72 Level 5 Circuit Flooding Scope Extended/Extended 255 73 Level 6 Circuit Flooding Scope Extended/Extended 256 74 Level 7 Circuit Flooding Scope Extended/Extended 257 75 Level 8 Circuit Flooding Scope Extended/Extended 258 76 Level 3 Flooding Scope Extended/Extended 259 77 Level 4 Flooding Scope Extended/Extended 260 78 Level 5 Flooding Scope Extended/Extended 261 79 Level 6 Flooding Scope Extended/Extended 262 80 Level 7 Flooding Scope Extended/Extended 263 81 Level 8 Flooding Scope Extended/Extended 265 6. Inheritance of TLVs 267 All existing Level 2 TLVs may be used in the corresponding Level 3 268 through Level 8 PDUs. When used in a Level 3 through Level 8 PDU, 269 the semantics of these TLVs will be applied to the Level of the 270 containing PDU. If the original semantics of the PDU was carrying a 271 reference to Level 1 in a Level 2 TLV, then the semantics of the TLV 272 at level N will be a reference to level N-1. The intent is to retain 273 the original semantics of the TLV at the higher level. 275 7. Relationship between levels 277 The relationship between Level n and Level n-1 is analogous to the 278 relationship between Level 2 and Level 1. 280 8. Acknowledgements 282 The author would like to thank Dinesh Dutt for inspiring this 283 document. The author would also like to thank Les Ginsberg and Paul 284 Wells for their helpful comments. 286 9. IANA Considerations 288 This document makes many requests to IANA, as follows: 290 9.1. PDU Type 292 The existing IS-IS PDU registry currently supports values 0-31. This 293 should be expanded to support the values 0-255. The existing value 294 assignments should be retained. Value 255 should be reserved. 296 9.2. New PDUs 298 IANA is requested to allocate values from the IS-IS PDU registry for 299 the following: 301 L3-LAN-HELLO-PDU: AA3 303 L4-LAN-HELLO-PDU: AA4 305 L5-LAN-HELLO-PDU: AA5 307 L6-LAN-HELLO-PDU: AA6 309 L7-LAN-HELLO-PDU: AA7 311 L8-LAN-HELLO-PDU: AA8 313 Ln-P2P-HELLO-PDU: TTT 315 To allow for PDU types to be defined independent of this document, 316 the above values should be allocated from the range 32-254. 318 9.3. New TLVs 320 IANA is requested to allocate values from the IS-IS TLV registry for 321 the following: 323 Area Identifier: ZZZ 325 9.4. New Flooding Scopes 327 IANA is requested to allocate the following values from the IS-IS 328 Flooding Scope Identifier Registry. 330 FS LSP ID Format/ IIH Announce 331 Value Description TLV Format Lx-P2P Lx-LAN 332 ----- ------------------------------ ----------------- ------ ------ 333 6 Level 3 Circuit Flooding Scope Extended/Standard Y Y 334 7 Level 4 Circuit Flooding Scope Extended/Standard Y Y 335 8 Level 5 Circuit Flooding Scope Extended/Standard Y Y 336 9 Level 6 Circuit Flooding Scope Extended/Standard Y Y 337 10 Level 7 Circuit Flooding Scope Extended/Standard Y Y 338 11 Level 8 Circuit Flooding Scope Extended/Standard Y Y 339 12 Level 3 Flooding Scope Extended/Standard Y Y 340 13 Level 4 Flooding Scope Extended/Standard Y Y 341 14 Level 5 Flooding Scope Extended/Standard Y Y 342 15 Level 6 Flooding Scope Extended/Standard Y Y 343 16 Level 7 Flooding Scope Extended/Standard Y Y 344 17 Level 8 Flooding Scope Extended/Standard Y Y 345 18 Level 3 Flooding Scope Standard/Standard Y Y 346 19 Level 4 Flooding Scope Standard/Standard Y Y 347 20 Level 5 Flooding Scope Standard/Standard Y Y 348 21 Level 6 Flooding Scope Standard/Standard Y Y 349 22 Level 7 Flooding Scope Standard/Standard Y Y 350 23 Level 8 Flooding Scope Standard/Standard Y Y 351 70 Level 3 Circuit Flooding Scope Extended/Extended Y Y 352 71 Level 4 Circuit Flooding Scope Extended/Extended Y Y 353 72 Level 5 Circuit Flooding Scope Extended/Extended Y Y 354 73 Level 6 Circuit Flooding Scope Extended/Extended Y Y 355 74 Level 7 Circuit Flooding Scope Extended/Extended Y Y 356 75 Level 8 Circuit Flooding Scope Extended/Extended Y Y 357 76 Level 3 Flooding Scope Extended/Extended Y Y 358 77 Level 4 Flooding Scope Extended/Extended Y Y 359 78 Level 5 Flooding Scope Extended/Extended Y Y 360 79 Level 6 Flooding Scope Extended/Extended Y Y 361 80 Level 7 Flooding Scope Extended/Extended Y Y 362 81 Level 8 Flooding Scope Extended/Extended Y Y 364 10. Security Considerations 366 This document introduces no new security issues. Security of routing 367 within a domain is already addressed as part of the routing protocols 368 themselves. This document proposes no changes to those security 369 architectures. 371 11. Normative References 373 [ISO10589] 374 International Organization for Standardization, 375 "Intermediate System to Intermediate System Intra-Domain 376 Routing Exchange Protocol for use in Conjunction with the 377 Protocol for Providing the Connectionless-mode Network 378 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, 382 DOI 10.17487/RFC2119, March 1997, 383 . 385 [RFC7356] Ginsberg, L., Previdi, S., and Y. Yang, "IS-IS Flooding 386 Scope Link State PDUs (LSPs)", RFC 7356, 387 DOI 10.17487/RFC7356, September 2014, 388 . 390 Authors' Addresses 392 Tony Li 393 Arista Networks 394 5453 Great America Parkway 395 Santa Clara, California 95054 396 United States of America 398 Email: tony.li@tony.li 400 Les Ginsberg 401 Cisco Systems 402 United States of America 404 Email: ginsberg@cisco.com 406 Paul Wells 407 Cisco Systems 408 United States of America 410 Email: pauwells@cisco.com