idnits 2.17.1 draft-ietf-isis-segment-routing-msd-17.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 (September 26, 2018) is 2038 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) == Outdated reference: A later version (-18) exists of draft-ietf-idr-bgp-ls-segment-routing-msd-02 == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-06 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-12 -- Obsolete informational reference (is this intentional?): RFC 7752 (Obsoleted by RFC 9552) Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IS-IS Working Group J. Tantsura 3 Internet-Draft Nuage Networks 4 Intended status: Standards Track U. Chunduri 5 Expires: March 30, 2019 Huawei Technologies 6 S. Aldrin 7 Google, Inc 8 L. Ginsberg 9 Cisco Systems 10 September 26, 2018 12 Signaling MSD (Maximum SID Depth) using IS-IS 13 draft-ietf-isis-segment-routing-msd-17 15 Abstract 17 This document defines a way for an Intermediate System to 18 Intermediate System (IS-IS) router to advertise multiple types of 19 supported Maximum SID Depths (MSDs) at node and/or link granularity. 20 Such advertisements allow entities (e.g., centralized controllers) to 21 determine whether a particular SID stack can be supported in a given 22 network. This document only defines one type of MSD (Base MPLS 23 Imposition), but defines an encoding that can support other MSD 24 types. This document focuses on MSD use in a Segment Routing enabled 25 network, but MSD may also be useful when Segment Routing is not 26 enabled. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on March 30, 2019. 45 Copyright Notice 47 Copyright (c) 2018 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 66 3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 5 67 4. Procedures for using Node and Link MSD Advertisements . . . . 6 68 5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 71 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 75 10.2. Informative References . . . . . . . . . . . . . . . . . 9 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 78 1. Introduction 80 When Segment Routing (SR) paths are computed by a centralized 81 controller, it is critical that the controller learns the Maximum SID 82 Depth (MSD) that can be imposed at each node/link of a given SR path 83 to ensure that the Segment Identifier (SID) stack depth of a computed 84 path does not exceed the number of SIDs the node is capable of 85 imposing. 87 [I-D.ietf-pce-segment-routing] defines how to signal MSD in the Path 88 Computation Element Protocol (PCEP). However, if PCEP is not 89 supported/configured on the head-end of an SR tunnel or a Binding-SID 90 anchor node and controller does not participate in IGP routing, it 91 has no way to learn the MSD of nodes and links. BGP-LS (Distribution 92 of Link-State and TE Information using Border Gateway Protocol) 94 [RFC7752] defines a way to expose topology and associated attributes 95 and capabilities of the nodes in that topology to a centralized 96 controller. MSD signaling by BGP-LS has been defined in 97 [I-D.ietf-idr-bgp-ls-segment-routing-msd]. Typically, BGP-LS is 98 configured on a small number of nodes that do not necessarily act as 99 head-ends. In order for BGP-LS to signal MSD for all the nodes and 100 links in the network MSD is relevant, MSD capabilities SHOULD be 101 advertised by every Intermediate System to Intermediate System(IS-IS) 102 router in the network. 104 Other types of MSD are known to be useful. For example, 105 [I-D.ietf-isis-mpls-elc] defines Readable Label Depth Capability 106 (RLDC) that is used by a head-end to insert an Entropy Label (EL) at 107 a depth, that could be read by transit nodes. 109 This document defines an extension to IS-IS used to advertise one or 110 more types of MSD at node and/or link granularity. It also creates 111 an IANA registry for assigning MSD-type identifiers. It also defines 112 the Base MPLS Imposition MSD-type. In the future it is expected that 113 new MSD-types will be defined to signal additional capabilities e.g., 114 entropy labels, SIDs that can be imposed through recirculation, or 115 SIDs associated with another dataplane e.g., IPv6. 117 MSD advertisements MAY be useful even if Segment Routing itself is 118 not enabled. For example, in a non-SR MPLS network, MSD defines the 119 maximum label depth. 121 1.1. Terminology 123 BMI: Base MPLS Imposition is the number of MPLS labels which can be 124 imposed inclusive of all service/transport/special labels 126 MSD: Maximum SID Depth - the number of SIDs supported by a node or a 127 link on a node 129 SID: Segment Identifier as defined in [RFC8402] 131 1.2. Requirements Language 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 135 "OPTIONAL" in this document are to be interpreted as described in BCP 136 14 [RFC2119] [RFC8174] when, and only when, they appear in all 137 capitals, as shown here . 139 2. Node MSD Advertisement 141 The node MSD sub-TLV is defined within the body of the IS-IS Router 142 Capability TLV [RFC7981], to carry the provisioned SID depth of the 143 router originating the Router Capability TLV. Node MSD is the 144 smallest MSD supported by the node on the set of interfaces 145 configured for use by the advertising IGP instance. MSD values may 146 be learned via a hardware API or may be provisioned. 148 0 1 149 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Type | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | MSD-Type | MSD-Value | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 // ................... // 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | MSD-Type | MSD-Value | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 Figure 1: Node MSD Sub-TLV 163 Type: 23 (allocated by IANA via the early assignment process) 165 Length: variable (multiple of 2 octets) and represents the total 166 length of value field. 168 Value: field consists of one or more pairs of a 1 octet MSD-Type and 169 1 octet MSD-Value. 171 MSD-Type is a value defined in the IGP MSD-Types registry created by 172 the IANA Section of this document. 174 MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 175 represents lack of the ability to support SID stack of any depth; any 176 other value represents that of the node. This value MUST represent 177 the lowest value supported by any link configured for use by the 178 advertising IS-IS instance. 180 This sub-TLV is optional. The scope of the advertisement is specific 181 to the deployment. 183 If there exist multiple Node MSD advertisements for the same MSD-Type 184 originated by the same router, the procedures defined in [RFC7981] 185 apply. These procedures may result in different MSD values being 186 used by (for example) different controllers - but this does not 187 create any interoperability issue. 189 3. Link MSD Advertisement 191 The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 192 223 to carry the MSD of the interface associated with the link. MSD 193 values may be signaled by the forwarding plane or may be provisioned. 195 0 1 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Type | Length | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | MSD-Type | MSD-Value | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 // ................... // 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | MSD-Type | MSD-Value | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 Figure 2: Link MSD Sub-TLV 210 Type: 15 (allocated by IANA via the early assignment process) 212 Length: variable (multiple of 2 octets) and represents the total 213 length of value field. 215 Value: consists of one or more pairs of a 1 octet MSD-Type and 1 216 octet MSD-Value. 218 MSD-Type is a value defined in the MSD-Types registry created by the 219 IANA Section of this document. 221 MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 222 represents lack of the ability to support SID stack of any depth; any 223 other value represents that of the link. 225 This sub-TLV is optional. 227 If multiple Link MSD advertisements for the same MSD-Type and the 228 same link are received, the procedure used to select which copy is 229 used is undefined. 231 4. Procedures for using Node and Link MSD Advertisements 233 When Link MSD is present for a given MSD-type, the value of the Link 234 MSD MUST take precedence over the Node MSD. When a Link MSD-type is 235 not signaled but the Node MSD-type is, then the Node MSD-type value 236 MUST be considered as the MSD value for that link. 238 In order to increase flooding efficiency, it is RECOMMENDED that 239 routers with homogenous link MSD values advertise just the Node MSD 240 value. 242 The meaning of the absence of both Node and Link MSD advertisements 243 for a given MSD-type is specific to the MSD-type. Generally it can 244 only be inferred that the advertising node does not support 245 advertisement of that MSD-type. However, in some cases the lack of 246 advertisement might imply that the functionality associated with the 247 MSD-type is not supported. The correct interpretation MUST be 248 specified when an MSD-type is defined. 250 5. Base MPLS Imposition MSD 252 Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS 253 labels which can be imposed, including all service/transport/special 254 labels. The value advertised MUST indicate what can be imposed under 255 all conditions e.g., if label popping/swapping affects the number of 256 labels which can be imposed this MUST be accounted for in the value 257 which is advertised. 259 If the advertising router performs label imposition in the context of 260 the ingress interface, it is not possible to meaningfully advertise 261 per link values. In such a case only the Node MSD SHOULD be 262 advertised. 264 Absence of BMI-MSD advertisements indicates solely that the 265 advertising node does not support advertisement of this capability. 267 6. IANA Considerations 269 This document requests IANA to allocate a sub-TLV type for the new 270 sub TLV proposed in Section 2 of this document from IS-IS Router 271 Capability TLV Registry as defined by [RFC7981]. 273 IANA has allocated the following value through the early assignment 274 process: 276 Value Description Reference 277 ----- --------------- ------------- 278 23 Node MSD This document 280 Figure 3: Node MSD 282 This document requests IANA to allocate a sub-TLV type as defined in 283 Section 3 from Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 284 registry. 286 IANA has allocated the following value through the early assignment 287 process: 289 Value Description Reference 290 ----- --------------- ------------- 291 15 Link MSD This document 293 Figure 4: Link MSD 295 Per TLV information where Link MSD sub-TLV can be part of: 297 TLV 22 23 25 141 222 223 298 --- -------------------- 299 y y y y y y 301 Figure 5: TLVs where LINK MSD Sub-TLV can be present 303 This document requests creation of an IANA managed registry under the 304 category of "Interior Gateway Protocol (IGP) Parameters" IANA 305 registries to identify MSD-types as proposed in Section 2 and 306 Section 3. The registration procedure is "Expert Review" as defined 307 in [RFC8126]. Suggested registry name is "IGP MSD-Types". Types are 308 an unsigned 8 bit number. The following values are defined by this 309 document: 311 Value Name Reference 312 ----- --------------------- ------------- 313 0 Reserved This document 314 1 Base MPLS Imposition MSD This document 315 2-250 Unassigned This document 316 251-254 Experimental Use This document 317 255 Reserved This document 319 Figure 6: MSD-Types Codepoints Registry 321 General guidance for the Designated Experts is as defined in 322 [RFC7370] 324 7. Security Considerations 326 Security considerations as specified by [RFC7981] are applicable to 327 this document. 329 Advertisement of the additional information defined in this document 330 that is false, e.g., an MSD that is incorrect, may result in a path 331 computation failing, having a service unavailable, or calculation of 332 a path that cannot be supported by the head-end (the node performing 333 the imposition). 335 The presence of this information also may inform an attacker of how 336 to induce any of the aforementioned conditions. 338 8. Contributors 340 The following people contributed to this document: 342 Peter Psenak 344 Email: ppsenak@cisco.com 346 9. Acknowledgements 348 The authors would like to thank Acee Lindem, Ketan Talaulikar, 349 Stephane Litkowski and Bruno Decraene for their reviews and valuable 350 comments. 352 10. References 354 10.1. Normative References 356 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 357 Requirement Levels", BCP 14, RFC 2119, 358 DOI 10.17487/RFC2119, March 1997, 359 . 361 [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints 362 Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, 363 . 365 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 366 for Advertising Router Information", RFC 7981, 367 DOI 10.17487/RFC7981, October 2016, 368 . 370 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 371 Writing an IANA Considerations Section in RFCs", BCP 26, 372 RFC 8126, DOI 10.17487/RFC8126, June 2017, 373 . 375 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 376 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 377 May 2017, . 379 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 380 Decraene, B., Litkowski, S., and R. Shakir, "Segment 381 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 382 July 2018, . 384 10.2. Informative References 386 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 387 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 388 "Signaling MSD (Maximum SID Depth) using Border Gateway 389 Protocol Link-State", draft-ietf-idr-bgp-ls-segment- 390 routing-msd-02 (work in progress), August 2018. 392 [I-D.ietf-isis-mpls-elc] 393 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 394 Litkowski, "Signaling Entropy Label Capability and Entropy 395 Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- 396 elc-06 (work in progress), September 2018. 398 [I-D.ietf-pce-segment-routing] 399 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 400 and J. Hardwick, "PCEP Extensions for Segment Routing", 401 draft-ietf-pce-segment-routing-12 (work in progress), June 402 2018. 404 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 405 S. Ray, "North-Bound Distribution of Link-State and 406 Traffic Engineering (TE) Information Using BGP", RFC 7752, 407 DOI 10.17487/RFC7752, March 2016, 408 . 410 Authors' Addresses 412 Jeff Tantsura 413 Nuage Networks 415 Email: jefftant.ietf@gmail.com 416 Uma Chunduri 417 Huawei Technologies 419 Email: uma.chunduri@huawei.com 421 Sam Aldrin 422 Google, Inc 424 Email: aldrin.ietf@gmail.com 426 Les Ginsberg 427 Cisco Systems 429 Email: ginsberg@cisco.com