idnits 2.17.1 draft-li-hierarchical-isis-00.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 28, 2018) is 2101 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force T. Li 3 Internet-Draft Arista Networks 4 Intended status: Informational June 28, 2018 5 Expires: December 30, 2018 7 Hierarchical IS-IS 8 draft-li-hierarchical-isis-00 10 Abstract 12 The IS-IS routing protocol was originally defined with a two level 13 hierarchical structure. This was adequate for the networks at the 14 time. As we continue to expand the scale of our networks, it is 15 apparent that additional hierarchy would be a welcome degree of 16 flexibility in network design. 18 This document defines IS-IS Levels 3 through 8. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on December 30, 2018. 37 Copyright Notice 39 Copyright (c) 2018 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 56 2. PDU changes . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Circuit Type . . . . . . . . . . . . . . . . . . . . . . 3 58 2.2. PDU Type . . . . . . . . . . . . . . . . . . . . . . . . 4 59 3. Additional PDUs . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. LAN IS to IS hello PDU (LAN-HELLO-PDU) . . . . . . . . . 4 61 3.2. Point-to-point IS to IS hello PDU (P2P-HELLO-PDU) . . . . 4 62 3.3. Level n Link State PDU (Ln-LSP-PDU) . . . . . . . . . . . 4 63 3.4. Level n complete sequence numbers PDU (Ln-CSNP-PDU) . . . 5 64 3.5. Level n partial sequence numbers PDU (Ln-PSNP-PDU) . . . 5 65 4. Inheritance of TLVs . . . . . . . . . . . . . . . . . . . . . 5 66 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 6.1. PDU Type . . . . . . . . . . . . . . . . . . . . . . . . 6 69 6.2. New PDUs . . . . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 72 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 74 1. Introduction 76 The IS-IS routing protocol IS-IS [ISO10589] currently supports a two 77 level hierarchy of abstraction. The fundamental unit of abstraction 78 is the 'area', which is a (hopefully) connected set of systems 79 running IS-IS at the same level. Level 1, the lowest level, is 80 abstracted by routers that participate in both Level 1 and Level 2. 82 Practical considerations, such as the size of an area's link state 83 database, cause network designers to restrict the number of routers 84 in any given area. Concurrently, the dominance of scale-out 85 architectures based around small routers has created a situation 86 where the scalability limits of the protocol are going to become 87 critical in the foreseeable future. 89 The goal of this document is to enable additional hierarchy within 90 IS-IS by creating additional hierarchy. Each additional level of 91 hierarchy has a multiplicative effect on scale, so the addtion of six 92 levels should be a significant improvement. While all six levels may 93 not be needed in the short term, it is apparent that the original 94 designers of IS-IS reserved enough space for these levels, and 95 defining six additional levels is only slightly harder than adding a 96 single level, so it makes some sense to expand the design for the 97 future. 99 The modifications described herein are designed to be fully backward 100 compatible. 102 Section references in this document are references to sections of IS- 103 IS [ISO10589]. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. PDU changes 113 In this section, we enumerate all of the redefinitions of protocol 114 header fields necessary to add additional levels. 116 2.1. Circuit Type 118 In the fixed header of some IS-IS PDUs, a field is named 'Reserved/ 119 Circuit Type' (Section 9.5). The high order six bits are reserved, 120 with the low order two bits indicating Level 1 (bit 1) and Level 2 121 (bit 2). 123 This field is renamed to be 'Circuit Type'. The bits are redefined 124 as follows: 126 1. Level 1 128 2. Level 2 130 3. Level 3 132 4. Level 4 134 5. Level 5 136 6. Level 6 138 7. Level 7 140 8. Level 8 142 The value of zero (no bits set) is reserved. PDUs with a Circuit 143 Type of zero SHALL be ignored. 145 The set bits of the Circuit Type MUST be contiguous. If bit n and 146 bit m are set in the Circuit Type, then all bits in the interval 147 [n:m] must be set. 149 2.2. PDU Type 151 The fixed header of IS-IS PDUs contains an octet with three reserved 152 bits and the 'PDU Type' field. The three reserved bits are 153 transmitted as zero and ignored on receipt. (Section 9.5) 155 To allow for additional PDU space, this entire octet is renamed the 156 'PDU Type' field. 158 3. Additional PDUs 160 3.1. LAN IS to IS hello PDU (LAN-HELLO-PDU) 162 The 'LAN IS to IS hello PDU' (LAN-HELLO-PDU) is identical in format 163 to the 'Level 2 LAN IS to IS hello PDU' (Section 9.6), except that 164 the PDU Type has value AAA. The LAN-HELLO-PDU MUST be used instead 165 of the 'Level 1 LAN IS to IS hello PDU' (Section 9.5) or the 'Level 2 166 LAN IS to IS hello PDU' on any circuit that has one or more of Level 167 3 through Level 8 enabled. 169 3.2. Point-to-point IS to IS hello PDU (P2P-HELLO-PDU) 171 The 'Point-to-point IS to IS hello PDU' can be used on circuits of 172 any Level without modification. 174 3.3. Level n Link State PDU (Ln-LSP-PDU) 176 The 'Level n Link State PDU' (Ln-LSP-PDU) has the same format as the 177 'Level 2 Link State PDU' (Section 9.9), except for the PDU Type. The 178 PDU Types for Levels 3 through 8 are defined as follows: 180 Level 3 (L3-LSP-PDU): BBB 182 Level 4 (L4-LSP-PDU): CCC 184 Level 5 (L5-LSP-PDU): DDD 186 Level 6 (L6-LSP-PDU): EEE 188 Level 7 (L7-LSP-PDU): FFF 190 Level 8 (L8-LSP-PDU): GGG 192 3.4. Level n complete sequence numbers PDU (Ln-CSNP-PDU) 194 The 'Level n complete sequence numbers PDU' (Ln-CSNP-PDU) has the 195 same format as the 'Level 2 complete sequence numbers PDU' 196 (Section 9.11), except for the PDU Type. The PDU Types for Levels 3 197 through 8 are defined as follows: 199 Level 3 (L3-CSNP-PDU): HHH 201 Level 4 (L4-CSNP-PDU): III 203 Level 5 (L5-CSNP-PDU): JJJ 205 Level 6 (L6-CSNP-PDU): KKK 207 Level 7 (L7-CSNP-PDU): LLL 209 Level 8 (L8-CSNP-PDU): MMM 211 3.5. Level n partial sequence numbers PDU (Ln-PSNP-PDU) 213 The 'Level 2 partial sequence numbers PDU' (Ln-PSNP-PDU) has the same 214 format as the 'Level 2 partial sequence numbers PDU' (Section 9.13), 215 except for the PDU Type. The PDU Types for Levels 3 through 8 are 216 defined as follows: 218 Level 3 (L3-PSNP-PDU): NNN 220 Level 4 (L4-PSNP-PDU): OOO 222 Level 5 (L5-PSNP-PDU): PPP 224 Level 6 (L6-PSNP-PDU): QQQ 226 Level 7 (L7-PSNP-PDU): RRR 228 Level 8 (L8-PSNP-PDU): SSS 230 4. Inheritance of TLVs 232 All existing Level 2 TLVs may be used in the corresponding Level 3 233 through Level 8 PDUs. When used in a Level 3 through Level 8 PDU, 234 the semantics of these TLVs will be applied to the Level of the 235 containing PDU. If the original semantics of the PDU was carrying a 236 reference to Level 1 in a Level 2 TLV, then the semantics of the TLV 237 at level N will be a reference to level N-1. The intent is to retain 238 the original semantics of the TLV at the higher level. 240 5. Acknowledgements 242 The author would like to thank Dinesh Dutt for inspiring this 243 document. 245 6. IANA Considerations 247 This document makes many requests to IANA, as follows: 249 6.1. PDU Type 251 The existing IS-IS PDU registry currently supports values 0-31. This 252 should be expanded to support the values 0-255. The existing value 253 assignments should be retained. Value 255 should be reserved. 255 6.2. New PDUs 257 IANA is requested to allocate values from the IS-IS PDU registry for 258 the following: 260 LAN-HELLO-PDU: AAA 262 L3-LSP-PDU: BBB 264 L4-LSP-PDU: CCC 266 L5-LSP-PDU: DDD 268 L6-LSP-PDU: EEE 270 L7-LSP-PDU: FFF 272 L8-LSP-PDU: GGG 274 L3-CSNP-PDU: HHH 276 L4-CSNP-PDU: III 278 L5-CSNP-PDU: JJJ 280 L6-CSNP-PDU: KKK 282 L7-CSNP-PDU: LLL 284 L8-CSNP-PDU: MMM 286 L3-PSNP-PDU: NNN 287 L4-PSNP-PDU: OOO 289 L5-PSNP-PDU: PPP 291 L6-PSNP-PDU: QQQ 293 L7-PSNP-PDU: RRR 295 L8-PSNP-PDU: SSS 297 To allow for PDU types to be defined independent of this document, 298 the above values should be allocated from the range 32-254. 300 7. Security Considerations 302 This document introduces no new security issues. Security of routing 303 within a domain is already addressed as part of the routing protocols 304 themselves. This document proposes no changes to those security 305 architectures. 307 8. Normative References 309 [ISO10589] 310 International Organization for Standardization, 311 "Intermediate System to Intermediate System Intra-Domain 312 Routing Exchange Protocol for use in Conjunction with the 313 Protocol for Providing the Connectionless-mode Network 314 Service (ISO 8473)", ISO/IEC 10589:2002, Nov. 2002. 316 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, 318 DOI 10.17487/RFC2119, March 1997, 319 . 321 Author's Address 323 Tony Li 324 Arista Networks 325 5453 Great America Parkway 326 Santa Clara, California 95054 327 USA 329 Email: tony.li@tony.li