idnits 2.17.1 draft-ietf-isis-segment-routing-msd-18.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 (October 4, 2018) is 2002 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: April 7, 2019 Huawei Technologies 6 S. Aldrin 7 Google, Inc 8 L. Ginsberg 9 Cisco Systems 10 October 4, 2018 12 Signaling MSD (Maximum SID Depth) using IS-IS 13 draft-ietf-isis-segment-routing-msd-18 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 (Segment ID) stack can be 22 supported in a given network. This document only defines one type of 23 MSD (Base MPLS Imposition), but defines an encoding that can support 24 other MSD types. This document focuses on MSD use in a Segment 25 Routing enabled network, but MSD may also be useful when Segment 26 Routing is not 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 April 7, 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 . . . . . . . . . . . . . . . . . . 4 65 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 66 3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 5 67 4. Procedures for Defining and Using Node and Link MSD 68 Advertisements . . . . . . . . . . . . . . . . . . . . . . . 6 69 5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 76 10.2. Informative References . . . . . . . . . . . . . . . . . 9 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 When Segment Routing (SR) paths are computed by a centralized 82 controller, it is critical that the controller learns the Maximum SID 83 Depth (MSD) that can be imposed at each node/link of a given SR path 84 to ensure that the Segment Identifier (SID) stack depth of a computed 85 path does not exceed the number of SIDs the node is capable of 86 imposing. 88 [I-D.ietf-pce-segment-routing] defines how to signal MSD in the Path 89 Computation Element communication Protocol (PCEP). However, if PCEP 90 is not supported/configured on the head-end of an SR tunnel or a 91 Binding-SID anchor node and controller does not participate in IGP 92 routing, it has no way to learn the MSD of nodes and links. BGP-LS 93 (Distribution of Link-State and TE Information using Border Gateway 94 Protocol) [RFC7752] defines a way to expose topology and associated 95 attributes and capabilities of the nodes in that topology to a 96 centralized 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 Label Imposition: Imposition is the act of modifying and/or adding 132 labels to the outgoing label stack associated with a packet. This 133 includes: 135 o replacing the label at the top of the label stack with a new label 137 o pushing one or more new labels onto the label stack 138 The number of labels imposed is then the sum of the number of labels 139 which are replaced and the number of labels which are pushed. See 140 [RFC3031] for further details. 142 1.2. Requirements Language 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 146 "OPTIONAL" in this document are to be interpreted as described in BCP 147 14 [RFC2119] [RFC8174] when, and only when, they appear in all 148 capitals, as shown here . 150 2. Node MSD Advertisement 152 The node MSD sub-TLV is defined within the body of the IS-IS Router 153 Capability TLV [RFC7981], to carry the provisioned SID depth of the 154 router originating the Router Capability TLV. Node MSD is the 155 smallest MSD supported by the node on the set of interfaces 156 configured for use by the advertising IGP instance. MSD values may 157 be learned via a hardware API or may be provisioned. 159 0 1 160 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Type | Length | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | MSD-Type | MSD-Value | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 // ................... // 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | MSD-Type | MSD-Value | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 Figure 1: Node MSD Sub-TLV 174 Type: 23 (allocated by IANA via the early assignment process) 176 Length: variable (multiple of 2 octets) and represents the total 177 length of value field. 179 Value: field consists of one or more pairs of a 1 octet MSD-Type and 180 1 octet MSD-Value. 182 MSD-Type is a value defined in the IGP MSD-Types registry created by 183 the IANA Section of this document. 185 MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 186 represents lack of the ability to support SID stack of any depth; any 187 other value represents that of the node. This value MUST represent 188 the lowest value supported by any link configured for use by the 189 advertising IS-IS instance. 191 This sub-TLV is optional. The scope of the advertisement is specific 192 to the deployment. 194 If there exist multiple Node MSD advertisements for the same MSD-Type 195 originated by the same router, the procedures defined in [RFC7981] 196 apply. These procedures may result in different MSD values being 197 used by (for example) different controllers - but this does not 198 create any interoperability issue. 200 3. Link MSD Advertisement 202 The link MSD sub-TLV is defined for TLVs 22, 23, 25, 141, 222, and 203 223 to carry the MSD of the interface associated with the link. MSD 204 values may be signaled by the forwarding plane or may be provisioned. 206 0 1 207 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Type | Length | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | MSD-Type | MSD-Value | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 // ................... // 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | MSD-Type | MSD-Value | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 Figure 2: Link MSD Sub-TLV 221 Type: 15 (allocated by IANA via the early assignment process) 223 Length: variable (multiple of 2 octets) and represents the total 224 length of value field. 226 Value: consists of one or more pairs of a 1 octet MSD-Type and 1 227 octet MSD-Value. 229 MSD-Type is a value defined in the MSD-Types registry created by the 230 IANA Section of this document. 232 MSD-Value is a number in the range of 0-255. For all MSD-Types, 0 233 represents lack of the ability to support SID stack of any depth; any 234 other value represents that of the particular link when used as an 235 outgoing interface. 237 This sub-TLV is optional. 239 If multiple Link MSD advertisements for the same MSD-Type and the 240 same link are received, the procedure used to select which copy is 241 used is undefined. 243 If the advertising router performs label imposition in the context of 244 the ingress interface, it is not possible to meaningfully advertise 245 per link values. In such a case only the Node MSD SHOULD be 246 advertised. 248 4. Procedures for Defining and Using Node and Link MSD Advertisements 250 When Link MSD is present for a given MSD-type, the value of the Link 251 MSD MUST take precedence over the Node MSD. When a Link MSD-type is 252 not signaled but the Node MSD-type is, then the Node MSD-type value 253 MUST be considered as the MSD value for that link. 255 In order to increase flooding efficiency, it is RECOMMENDED that 256 routers with homogenous link MSD values advertise just the Node MSD 257 value. 259 The meaning of the absence of both Node and Link MSD advertisements 260 for a given MSD-type is specific to the MSD-type. Generally it can 261 only be inferred that the advertising node does not support 262 advertisement of that MSD-type. However, in some cases the lack of 263 advertisement might imply that the functionality associated with the 264 MSD-type is not supported. The correct interpretation MUST be 265 specified when an MSD-type is defined. 267 5. Base MPLS Imposition MSD 269 Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS 270 labels which can be imposed, including all service/transport/special 271 labels. 273 Absence of BMI-MSD advertisements indicates solely that the 274 advertising node does not support advertisement of this capability. 276 6. IANA Considerations 278 This document requests IANA to allocate a sub-TLV type for the new 279 sub TLV proposed in Section 2 of this document from IS-IS Router 280 Capability TLV Registry as defined by [RFC7981]. 282 IANA has allocated the following value through the early assignment 283 process: 285 Value Description Reference 286 ----- --------------- ------------- 287 23 Node MSD This document 289 Figure 3: Node MSD 291 This document requests IANA to allocate a sub-TLV type as defined in 292 Section 3 from Sub-TLVs for TLVs 22, 23, 25, 141, 222, and 223 293 registry. 295 IANA has allocated the following value through the early assignment 296 process: 298 Value Description Reference 299 ----- --------------- ------------- 300 15 Link MSD This document 302 Figure 4: Link MSD 304 Per TLV information where Link MSD sub-TLV can be part of: 306 TLV 22 23 25 141 222 223 307 --- -------------------- 308 y y y y y y 310 Figure 5: TLVs where LINK MSD Sub-TLV can be present 312 This document requests creation of an IANA managed registry under the 313 category of "Interior Gateway Protocol (IGP) Parameters" IANA 314 registries to identify MSD-types as proposed in Section 2 and 315 Section 3. The registration procedure is "Expert Review" as defined 316 in [RFC8126]. Suggested registry name is "IGP MSD-Types". Types are 317 an unsigned 8 bit number. The following values are defined by this 318 document: 320 Value Name Reference 321 ----- --------------------- ------------- 322 0 Reserved This document 323 1 Base MPLS Imposition MSD This document 324 2-250 Unassigned This document 325 251-254 Experimental Use This document 326 255 Reserved This document 328 Figure 6: MSD-Types Codepoints Registry 330 General guidance for the Designated Experts is as defined in 331 [RFC7370] 333 7. Security Considerations 335 Security considerations as specified by [RFC7981] are applicable to 336 this document. 338 Advertisement of an incorrect MSD value may have negative 339 consequences. If the value is smaller than supported, path 340 computation may fail to compute a viable path. If the value is 341 larger than supported, an attempt to instantiate a path that can't be 342 supported by the head-end (the node performing the SID imposition) 343 may occur. 345 The presence of this information also may inform an attacker of how 346 to induce any of the aforementioned conditions. 348 8. Contributors 350 The following people contributed to this document: 352 Peter Psenak 354 Email: ppsenak@cisco.com 356 9. Acknowledgements 358 The authors would like to thank Acee Lindem, Ketan Talaulikar, 359 Stephane Litkowski and Bruno Decraene for their reviews and valuable 360 comments. 362 10. References 363 10.1. Normative References 365 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 366 Requirement Levels", BCP 14, RFC 2119, 367 DOI 10.17487/RFC2119, March 1997, 368 . 370 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 371 Label Switching Architecture", RFC 3031, 372 DOI 10.17487/RFC3031, January 2001, 373 . 375 [RFC7370] Ginsberg, L., "Updates to the IS-IS TLV Codepoints 376 Registry", RFC 7370, DOI 10.17487/RFC7370, September 2014, 377 . 379 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 380 for Advertising Router Information", RFC 7981, 381 DOI 10.17487/RFC7981, October 2016, 382 . 384 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 385 Writing an IANA Considerations Section in RFCs", BCP 26, 386 RFC 8126, DOI 10.17487/RFC8126, June 2017, 387 . 389 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 390 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 391 May 2017, . 393 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 394 Decraene, B., Litkowski, S., and R. Shakir, "Segment 395 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 396 July 2018, . 398 10.2. Informative References 400 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 401 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 402 "Signaling MSD (Maximum SID Depth) using Border Gateway 403 Protocol Link-State", draft-ietf-idr-bgp-ls-segment- 404 routing-msd-02 (work in progress), August 2018. 406 [I-D.ietf-isis-mpls-elc] 407 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 408 Litkowski, "Signaling Entropy Label Capability and Entropy 409 Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- 410 elc-06 (work in progress), September 2018. 412 [I-D.ietf-pce-segment-routing] 413 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 414 and J. Hardwick, "PCEP Extensions for Segment Routing", 415 draft-ietf-pce-segment-routing-12 (work in progress), June 416 2018. 418 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 419 S. Ray, "North-Bound Distribution of Link-State and 420 Traffic Engineering (TE) Information Using BGP", RFC 7752, 421 DOI 10.17487/RFC7752, March 2016, 422 . 424 Authors' Addresses 426 Jeff Tantsura 427 Nuage Networks 429 Email: jefftant.ietf@gmail.com 431 Uma Chunduri 432 Huawei Technologies 434 Email: uma.chunduri@huawei.com 436 Sam Aldrin 437 Google, Inc 439 Email: aldrin.ietf@gmail.com 441 Les Ginsberg 442 Cisco Systems 444 Email: ginsberg@cisco.com