idnits 2.17.1 draft-ietf-isis-segment-routing-msd-09.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 10, 2018) is 2290 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-01 == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-03 == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 -- 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 Individual 4 Intended status: Standards Track U. Chunduri 5 Expires: July 14, 2018 Huawei Technologies 6 S. Aldrin 7 Google, Inc 8 L. Ginsberg 9 Cisco Systems 10 January 10, 2018 12 Signaling MSD (Maximum SID Depth) using IS-IS 13 draft-ietf-isis-segment-routing-msd-09 15 Abstract 17 This document defines a way for an IS-IS Router to advertise multiple 18 types of supported Maximum SID Depths (MSDs) at node and/or link 19 granularity. Such advertisements allow entities (e.g., centralized 20 controllers) to determine whether a particular SID stack is 21 supportable in a given network. This document only defines one type 22 of MSD (maximum label imposition) - but defines an encoding which can 23 support other MSD types. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on July 14, 2018. 42 Copyright Notice 44 Copyright (c) 2018 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 1.1. Conventions used in this document . . . . . . . . . . . . 3 61 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 62 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 63 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 64 3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 65 4. Using Node and Link MSD Advertisements . . . . . . . . . . . 5 66 5. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 70 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 10.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 10.2. Informative References . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 When Segment Routing(SR) paths are computed by a centralized 79 controller, it is critical that the controller learns the Maximum SID 80 Depth(MSD) which can be imposed at the node/link a given SR path is 81 applied so as to insure that the SID stack depth of a computed path 82 doesn't exceed the number of SIDs the node is capable of imposing. 84 PCEP SR extensions draft [I-D.ietf-pce-segment-routing] signals MSD 85 in SR PCE Capability TLV and METRIC Object. However, if PCEP is not 86 supported/configured on the head-end of a SR tunnel or a Binding-SID 87 anchor node and controller does not participate in IGP routing, it 88 has no way to learn the MSD of nodes and links which has been 89 configured. BGP-LS [RFC7752] defines a way to expose topology and 90 associated attributes and capabilities of the nodes in that topology 91 to a centralized controller. MSD signaling by BGP-LS has been 92 defined in [I-D.ietf-idr-bgp-ls-segment-routing-msd]. Typically, 93 BGP-LS is configured on a small number of nodes, that do not 94 necessarily act as head-ends. In order, for BGP-LS to signal MSD for 95 all the nodes and links in the network MSD is relevant, MSD 96 capabilites should be advertised to every IS-IS router in the 97 network. 99 Other types of MSD are known to be useful. For example, 100 [I-D.ietf-isis-mpls-elc] defines Readable Label Depth Capability 101 (RLDC) that is used by a head-end to insert Entropy Label (EL) at 102 appropriate depth, so it could be read by transit nodes. 104 This document defines an extension to IS-IS used to advertise one or 105 more types of MSD at node and/or link granularity. It also creates 106 an IANA registry for assigning MSD type identifiers. It also defines 107 one MSD type called Base MPLS Imposition MSD. In the future it is 108 expected that new MSD types will be defined to signal additional 109 capabilities e.g., entropy labels, SIDs that can be imposed through 110 recirculation, or SIDs associated with another dataplane e.g., IPv6. 112 1.1. Conventions used in this document 114 1.1.1. Terminology 116 BGP-LS: Distribution of Link-State and TE Information using Border 117 Gateway Protocol 119 BMI: Base MPLS Imposition is the number of MPLS labels which can be 120 imposed inclusive of any service/transport labels 122 IS-IS: Intermediate System to Intermediate System 124 MSD: Maximum SID Depth - the number of SIDs a node or a link on a 125 node can support 127 PCC: Path Computation Client 129 PCE: Path Computation Element 131 PCEP: Path Computation Element Protocol 133 SID: Segment Identifier 135 SR: Segment Routing 137 1.2. Requirements Language 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in RFC 2119 [RFC2119]. 143 2. Node MSD Advertisement 145 A new sub-TLV "Node MSD sub-TLV" is defined within the body of the 146 IS-IS Router Capability TLV [RFC7981], to carry the provisioned 147 MSD(s) of the router originating the Router Capability TLV. Node MSD 148 is the lowest MSD supported by the node on any interface. MSD values 149 may be learned via a hardware API or may be provisioned. 151 0 1 152 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type | Length | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | MSD-Type | MSD Value | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 // ................... // 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | MSD-Type | MSD Value | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 Figure 1: Node MSD Sub-TLV 166 The Type (1 byte) of this sub-TLV has value of 23. 168 Length is variable (minimum of 2, multiple of 2 octets) and 169 represents the total length of value field. 171 Value field consists of one or more pairs of a 1 octet MSD-Type (IANA 172 Registry) and 1 octet Value. 174 Node MSD value is a number in the range of 0-255. 0 represents lack 175 of the ability to support SID stack of any depth; any other value 176 represents that of the node. This value MUST represent the lowest 177 value supported by any link associated with the node. 179 This sub-TLV is optional. The scope of the advertisement is specific 180 to the deployment. 182 3. Link MSD Advertisement 184 A new sub-TLV - Link MSD sub-TLV is defined for TLVs 22, 23, 141, 185 222, and 223 to carry the MSD of the interface associated with the 186 link. MSD values may be learned via a hardware API or may be 187 provisioned. 189 0 1 190 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | MSD-Type | MSD Value | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 // ................... // 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | MSD-Type | MSD Value | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Figure 2: Link MSD Sub-TLV 204 The Type (1 byte) of this sub-TLV has value of 15. 206 Length is variable (minimum of 2, multiple of 2 octets) and 207 represents the total length of value field. 209 Value field consists of one or more pairs of a 1 octet MSD-Type (IANA 210 Registry) and 1 octet Value. 212 Link MSD value is a number in the range of 0-255. 0 represents lack 213 of the ability to support SID stack of any depth; any other value 214 represents that of the link when used as an outgoing link. 216 This sub-TLV is optional. The scope of the advertisement is specific 217 to the deployment. 219 4. Using Node and Link MSD Advertisements 221 When Link MSD is present for a given MSD type, the value of the Link 222 MSD MUST be used in preference to the Node MSD. 224 The meaning of the absence of both Node and Link MSD advertisements 225 for a given MSD type is specific to the MSD type. Generally it can 226 only be inferred that the advertising node does not support 227 advertisement of that MSD type. However, in some cases the lack of 228 advertisement might imply that the functionality associated with the 229 MSD type is not supported. The correct interpretation MUST be 230 specified when an MSD type is defined. 232 5. Base MPLS Imposition MSD 234 Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS 235 labels a node is capable of imposing, including any service/transport 236 labels. 238 Absence of BMI-MSD advertisements indicates only that the advertising 239 node does not support advertisement of this capability. 241 6. IANA Considerations 243 This document requests IANA to allocate a sub-TLV type code for the 244 new sub TLV proposed in Section 2 of this document from IS-IS Router 245 Capability TLV Registry as defined by [RFC7981]. 247 The following value has been allocated by IANA: 249 Value Description Reference 250 ----- --------------- ------------- 251 23 Node MSD This document 253 Figure 3: Node MSD 255 This document requests IANA to allocate a sub-TLV type code as 256 defined in Section 3 from Sub-TLVs for TLVs 22, 23, 141, 222 and 223 257 registry. 259 The following value has been allocated by IANA: 261 Value Description Reference 262 ----- --------------- ------------- 263 15 Link MSD This document 265 Figure 4: Link MSD 267 Per TLV information where Link MSD sub-TLV can be part of: 269 TLV 22 23 25 141 222 223 270 --- -------------------- 271 y y y y y y 273 Figure 5: TLVs where LINK MSD Sub-TLV can be present 275 This document requests creation of a new IANA managed registry under 276 a new category of "Interior Gateway Protocol (IGP) Parameters" IANA 277 registries to identify MSD types as proposed in Section 2 and 278 Section 3. The registration procedure is "Expert Review" as defined 279 in [RFC8126]. Suggested registry name is "MSD types". Types are an 280 unsigned 8 bit number. The following values are defined by this 281 document 283 Value Name Reference 284 ----- --------------------- ------------- 285 0 Reserved This document 286 1 Base MPLS Imposition MSD This document 287 2-250 Unassigned This document 288 251-254 Experimental This document 289 255 Reserved This document 291 Figure 6: MSD Types Codepoints Registry 293 7. Security Considerations 295 Security considerations, as specified by [RFC7981] are applicable to 296 this document 298 8. Contributors 300 The following people contributed to this document: 302 Peter Psenak 304 Email: ppsenak@cisco.com 306 9. Acknowledgements 308 The authors would like to thank Stephane Litkowski and Bruno Decraene 309 for their reviews and valuable comments. 311 10. References 313 10.1. Normative References 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 321 for Advertising Router Information", RFC 7981, 322 DOI 10.17487/RFC7981, October 2016, 323 . 325 10.2. Informative References 327 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 328 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 329 "Signaling Maximum SID Depth using Border Gateway Protocol 330 Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01 331 (work in progress), October 2017. 333 [I-D.ietf-isis-mpls-elc] 334 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 335 Litkowski, "Signaling Entropy Label Capability and 336 Readable Label-stack Depth Using IS-IS", draft-ietf-isis- 337 mpls-elc-03 (work in progress), January 2018. 339 [I-D.ietf-pce-segment-routing] 340 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 341 and J. Hardwick, "PCEP Extensions for Segment Routing", 342 draft-ietf-pce-segment-routing-11 (work in progress), 343 November 2017. 345 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 346 S. Ray, "North-Bound Distribution of Link-State and 347 Traffic Engineering (TE) Information Using BGP", RFC 7752, 348 DOI 10.17487/RFC7752, March 2016, 349 . 351 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 352 Writing an IANA Considerations Section in RFCs", BCP 26, 353 RFC 8126, DOI 10.17487/RFC8126, June 2017, 354 . 356 Authors' Addresses 358 Jeff Tantsura 359 Individual 361 Email: jefftant.ietf@gmail.com 363 Uma Chunduri 364 Huawei Technologies 366 Email: uma.chunduri@huawei.com 367 Sam Aldrin 368 Google, Inc 370 Email: aldrin.ietf@gmail.com 372 Les Ginsberg 373 Cisco Systems 375 Email: ginsberg@cisco.com