idnits 2.17.00 (12 Aug 2021) /tmp/idnits60930/draft-ietf-isis-segment-routing-msd-08.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 04, 2018) is 1598 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) == Unused Reference: 'RFC5305' is defined on line 296, but no explicit reference was found in the text == Unused Reference: 'RFC1195' is defined on line 325, but no explicit reference was found in the text == Unused Reference: 'RFC5120' is defined on line 329, but no explicit reference was found in the text == Outdated reference: draft-ietf-idr-bgp-ls-segment-routing-msd has been published as RFC 8814 == Outdated reference: draft-ietf-isis-mpls-elc has been published as RFC 9088 == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). 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 8, 2018 Huawei Technologies 6 S. Aldrin 7 Google, Inc 8 L. Ginsberg 9 Cisco Systems 10 January 04, 2018 12 Signaling MSD (Maximum SID Depth) using IS-IS 13 draft-ietf-isis-segment-routing-msd-08 15 Abstract 17 This document proposes a way to signal Maximum SID Depth (MSD) 18 supported by a node and/or link granularity by an IS-IS Router. In a 19 Segment Routing (SR) enabled network a centralized controller that 20 programs SR tunnels needs to know the MSD supported by the head-end 21 at node and/or link granularity to impose the SID stack of an 22 appropriate depth. MSD is relevant to the head-end of a SR tunnel or 23 Binding-SID anchor node where Binding-SID expansions might result in 24 creation of a new SID stack. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on July 8, 2018. 43 Copyright Notice 45 Copyright (c) 2018 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Conventions used in this document . . . . . . . . . . . . 3 62 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 64 2. Node MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 65 3. Link MSD Advertisement . . . . . . . . . . . . . . . . . . . 4 66 4. Node MSD vs Link MSD conflict resolution . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 68 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 69 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 70 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 73 9.2. Informative References . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 When Segment Routing tunnels are computed by a centralized 79 controller, it is critical that the controller learns the MSD 80 "Maximum SID Depth" of the node or link SR tunnel exits over, so the 81 SID stack depth of a path computed doesn't exceed the number of SID's 82 the node is capable of imposing. This document describes how to use 83 IS-IS to signal the MSD of a node or link to a centralized 84 controller. 86 PCEP SR extensions draft [I-D.ietf-pce-segment-routing] signals MSD 87 in SR PCE Capability TLV and METRIC Object. However, if PCEP is not 88 supported/configured on the head-end of a SR tunnel or a Binding-SID 89 anchor node and controller does not participate in IGP routing, it 90 has no way to learn the MSD of nodes and links which has been 91 configured. BGP-LS [RFC7752] defines a way to expose topology and 92 associated attributes and capabilities of the nodes in that topology 93 to a centralized controller. MSD signaling by BGP-LS has been 94 defined in [I-D.ietf-idr-bgp-ls-segment-routing-msd]. Typically, 95 BGP-LS is configured on a small number of nodes, that do not 96 necessarily act as head-ends. In order, for BGP-LS to signal MSD for 97 all the nodes and links in the network MSD is relevant, MSD 98 capabilites should be advertised to every IS-IS router in the 99 network. 101 [I-D.ietf-isis-mpls-elc] defines Readable Label Depth Capability 102 (RLDC) that is used by a head-end to insert Entropy Label (EL) at 103 appropriate depth, so it could be read by transit nodes. MSD in 104 contrary signals ability to impose SID's stack of a particular depth. 106 MSD of type 1 (IANA Registry), called Base MSD, is used to signal the 107 total number of SID's a node is capable of imposing, to be used by a 108 path computation element/controller. In case, there are additional 109 SID's (e.g. service) that are to be imposed to the stack - this would 110 be signaled with an another MSD type (TBD), no adjustment to the Base 111 MSD should be made. In the future, new MSD types could be defined to 112 signal additional capabilities: entropy labels, SID's that can be 113 imposed thru recirculation, or another dataplane e.g IPv6. 115 1.1. Conventions used in this document 117 1.1.1. Terminology 119 BGP-LS: Distribution of Link-State and TE Information using Border 120 Gateway Protocol 122 IS-IS: Intermediate System to Intermediate System 124 MSD: Maximum SID Depth - a number of SID's a node or a link on a node 125 is capable of imposing 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 IS-IS 146 Router Capability TLV [RFC7981], to carry the provisioned MSD of the 147 router originating the Router Capability TLV. Node MSD is the lowest 148 MSD supported by the node of any interface and if not known throught 149 an API, can be provisioned in IS-IS instance. 151 0 1 2 3 152 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type | Length | Sub-Type and Value pair | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 Figure 1: Node MSD Sub-TLV 160 The Type (1 byte) of this sub-TLV has value of 23. 162 Length is variable (minimum of 2, multiple of 2 octets) and 163 represents the total length of value field. 165 Value field consists of a 1 octet Sub-Type (IANA Registry) and 1 166 octet Value. There could be one or more of the Sub-Type/Value pairs. 168 Sub-Type 1 (IANA Section), MSD and the Value field associated with 169 the Sub-Type contains maximum MSD of the router originating the 170 Router Capability TLV. 172 Node MSD value is a number in the range of 0-254. 0 represents lack 173 of the ability to impose SID stack of any depth; any other value 174 represents that of the node. This value SHOULD represent the lowest 175 value supported by node. 177 Other Sub-Types other than defined above are reserved for future 178 extensions. 180 This sub-TLV is optional. The scope of the advertisement is specific 181 to the deployment. 183 3. Link MSD Advertisement 185 A new sub-TLV - Link MSD sub-TLV is defined for TLVs 22, 23, 141, 186 222, and 223 to carry the provisioned MSD of the interface associated 187 with the link. 189 0 1 2 3 190 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | Sub-Type and Value pair | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 Figure 2: Link MSD Sub-TLV 198 The Type (1 byte) of this sub-TLV has value of 15. 200 Length is variable and similar to what is defined in Section 2. 202 Value field consists of a 1 octet sub-type (IANA Registry) and 1 203 octet value. There could be one or more of the Sub-Type/Value pairs. 205 Sub-Type 1 (IANA Section), MSD and the Value field associated with 206 the Sub-Type contains Link MSD of the router originating the 207 corresponding TLV's 22, 23, 141, 222, and 223. 209 The value of Link MSD represents MSD on the outgoing link. Link MSD 210 is a number in the range of 0-254. 0 represents lack of the ability 211 to impose SID stack of any depth; any other value represents that of 212 the particular link MSD value. 214 4. Node MSD vs Link MSD conflict resolution 216 When both Node MSD and Link MSD are present, the value of the Link 217 MSD MUST be used. 219 5. IANA Considerations 221 This document includes a request to IANA to allocate sub-TLV type 222 codes for the new sub TLV proposed in Section 2 of this document from 223 IS-IS Router Capability TLV Registry as defined by [RFC7981]. 225 Following values have been allocated by IANA: 227 Value Description Reference 228 ----- --------------- ------------- 229 23 Node MSD This document 231 Figure 3: Node MSD 233 For the Link MSD, we request IANA to allocate new sub-TLV codes as 234 defined in Section 3 from Sub-TLVs for TLVs 22, 23, 141, 222 and 223 235 registry. 237 Value Description Reference 238 ----- --------------- ------------- 239 15 Link MSD This document 241 Figure 4: Link MSD 243 Per TLV information where Link MSD sub-TLV can be part of: 245 TLV 22 23 25 141 222 223 246 --- -------------------- 247 y y y y y y 249 Figure 5: TLVs where LINK MSD Sub-TLV can be present 251 This document requests creation of a new IANA managed registry under 252 a new category of "Interior Gateway Protocol (IGP) Parameters" IANA 253 registries to identify MSD types as proposed in Section 2, Section 3. 254 The registration procedure is "Expert Review" as defined in 255 [RFC8126]. Suggested registry name is "MSD Sub-types". Types are an 256 unsigned 8 bit number. The following values are defined by this 257 document 259 Value Name Reference 260 ----- --------------------- ------------- 261 0 Reserved This document 262 1 Base MSD This document 263 2-250 Unassigned This document 264 251-254 Experimental This document 265 255 Reserved This document 267 Figure 6: MSD Sub-type Codepoints Registry 269 6. Security Considerations 271 Security considerations, as specified by [RFC7981] are applicable to 272 this document 274 7. Contributors 276 The following people contributed to this document: 278 Peter Psenak 280 Email: ppsenak@cisco.com 282 8. Acknowledgements 284 The authors would like to thank Stephane Litkowski and Bruno Decraene 285 for their reviews and valuable comments. 287 9. References 289 9.1. Normative References 291 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 292 Requirement Levels", BCP 14, RFC 2119, 293 DOI 10.17487/RFC2119, March 1997, 294 . 296 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 297 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 298 2008, . 300 [RFC7981] Ginsberg, L., Previdi, S., and M. Chen, "IS-IS Extensions 301 for Advertising Router Information", RFC 7981, 302 DOI 10.17487/RFC7981, October 2016, 303 . 305 9.2. Informative References 307 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 308 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 309 "Signaling Maximum SID Depth using Border Gateway Protocol 310 Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01 311 (work in progress), October 2017. 313 [I-D.ietf-isis-mpls-elc] 314 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 315 Litkowski, "Signaling Entropy Label Capability and 316 Readable Label-stack Depth Using IS-IS", draft-ietf-isis- 317 mpls-elc-03 (work in progress), January 2018. 319 [I-D.ietf-pce-segment-routing] 320 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 321 and J. Hardwick, "PCEP Extensions for Segment Routing", 322 draft-ietf-pce-segment-routing-11 (work in progress), 323 November 2017. 325 [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and 326 dual environments", RFC 1195, DOI 10.17487/RFC1195, 327 December 1990, . 329 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 330 Topology (MT) Routing in Intermediate System to 331 Intermediate Systems (IS-ISs)", RFC 5120, 332 DOI 10.17487/RFC5120, February 2008, 333 . 335 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 336 S. Ray, "North-Bound Distribution of Link-State and 337 Traffic Engineering (TE) Information Using BGP", RFC 7752, 338 DOI 10.17487/RFC7752, March 2016, 339 . 341 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 342 Writing an IANA Considerations Section in RFCs", BCP 26, 343 RFC 8126, DOI 10.17487/RFC8126, June 2017, 344 . 346 Authors' Addresses 348 Jeff Tantsura 349 Individual 351 Email: jefftant.ietf@gmail.com 353 Uma Chunduri 354 Huawei Technologies 356 Email: uma.chunduri@huawei.com 358 Sam Aldrin 359 Google, Inc 361 Email: aldrin.ietf@gmail.com 362 Les Ginsberg 363 Cisco Systems 365 Email: ginsberg@cisco.com