idnits 2.17.00 (12 Aug 2021) /tmp/idnits61685/draft-ietf-ospf-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 (February 26, 2018) is 1545 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) ** Obsolete normative reference: RFC 4970 (Obsoleted by RFC 7770) == Outdated reference: draft-ietf-idr-bgp-ls-segment-routing-msd has been published as RFC 8814 == Outdated reference: draft-ietf-ospf-mpls-elc has been published as RFC 9089 == Outdated reference: draft-ietf-ospf-ospfv3-lsa-extend has been published as RFC 8362 == Outdated reference: draft-ietf-pce-segment-routing has been published as RFC 8664 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF Working Group J. Tantsura 3 Internet-Draft Nuage Networks 4 Intended status: Standards Track U. Chunduri 5 Expires: August 30, 2018 Huawei Technologies 6 S. Aldrin 7 Google, Inc 8 P. Psenak 9 Cisco Systems 10 February 26, 2018 12 Signaling MSD (Maximum SID Depth) using OSPF 13 draft-ietf-ospf-segment-routing-msd-09 15 Abstract 17 This document defines a way for an OSPF 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. Here the term OSPF means both OSPFv2 and 24 OSPFv3. 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 August 30, 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. Link MSD sub-TLV . . . . . . . . . . . . . . . . . . . . . . 5 67 5. Using Node and Link MSD Advertisements . . . . . . . . . . . 5 68 6. Base MPLS Imposition MSD . . . . . . . . . . . . . . . . . . 6 69 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 71 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 73 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 74 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 75 11.2. Informative References . . . . . . . . . . . . . . . . . 7 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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) which can be imposed at the node/link a given SR path is 83 applied so as to insure that the SID stack depth of a computed path 84 doesn't exceed the number of SIDs the node is capable of imposing. 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 OSPF router in the network. 100 Other types of MSD are known to be useful. For example, 101 [I-D.ietf-ospf-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. 105 This document defines an extension to OSPF used to advertise one or 106 more types of MSD at node and/or link granularity. It also creates 107 an IANA registry for assigning MSD type identifiers. It also defines 108 one MSD type called Base MPLS Imposition MSD. In the future it is 109 expected that new MSD types will be defined to signal additional 110 capabilities e.g., entropy labels, SIDs that can be imposed through 111 recirculation, or SIDs associated with another dataplane e.g., IPv6. 113 1.1. Conventions used in this document 115 1.1.1. Terminology 117 BGP-LS: Distribution of Link-State and TE Information using Border 118 Gateway Protocol 120 BMI: Base MPLS Imposition is the number of MPLS labels which can be 121 imposed inclusive of any service/transport labels 123 OSPF: Open Shortest Path First 125 MSD: Maximum SID Depth - the number of SIDs a node or a link on a 126 node can support 128 PCC: Path Computation Client 130 PCE: Path Computation Element 132 PCEP: Path Computation Element Protocol 134 SID: Segment Identifier 136 SR: Segment Routing 138 1.2. Requirements Language 140 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 141 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 142 document are to be interpreted as described in RFC 2119 [RFC2119]. 144 2. Terminology 146 This memo makes use of the terms defined in [RFC4970]. 148 3. Node MSD TLV 150 A new TLV within the body of the OSPF RI Opaque LSA, called Node MSD 151 TLV is defined to carry the provisioned SID depth of the router 152 originating the RI LSA. Node MSD is the lowest MSD supported by the 153 node. 155 0 1 2 3 156 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Type | Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Sub-Type and Value ... 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 164 Figure 1: Node MSD TLV 166 The Type (2 bytes) of this TLV has value of 12. 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 a 1 octet sub-type (IANA Registry) and 1 172 octet value. 174 Sub-Type 1 (IANA Section), MSD and the Value field contains maximum 175 MSD of the router originating the RI LSA. Node Maximum MSD is a 176 number in the range of 0-254. 0 represents lack of the ability to 177 impose MSD stack of any depth; any other value represents that of the 178 node. This value SHOULD represent the lowest value supported by 179 node. 181 Other Sub-types other than defined above are reserved for future 182 extensions. 184 This TLV is applicable to OSPFv2 and to OSPFv3 [RFC5838] and is 185 optional. The scope of the advertisement is specific to the 186 deployment. 188 4. Link MSD sub-TLV 190 A new sub-TLV called Link MSD sub-TLV is defined to carry the 191 provisioned SID depth of the interface associated with the link. 193 0 1 2 3 194 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Type | Length | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Sub-Type and Value ... 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 202 Figure 2: Link MSD Sub-TLV 204 The Type (2 bytes) of this TLV: 206 For OSPFv2, the Link level MSD value is advertised as an optional 207 Sub-TLV of OSPFv2 Extended Link TLV as defined in [RFC7684], and has 208 value of 6. 210 For OSPFv3, the Link level MSD value is advertised as an optional 211 Sub-TLV of the Router-Link TLV as defined in 212 [I-D.ietf-ospf-ospfv3-lsa-extend], and has value of 16 (Suggested 213 value - to be assigned by IANA). 215 Length is variable and similar to what is defined in Section 3. 217 Value field consists of a 1 octet sub-type (IANA Registry) and 1 218 octet value. 220 Sub-Type 1 (IANA Section), MSD and the Value field contains Link MSD 221 of the router originating the corresponding LSA as specified for 222 OSPFv2 and OSPFv3. Link MSD is a number in the range of 0-254. 0 223 represents lack of the ability to impose MSD stack of any depth; any 224 other value represents that of the particular link MSD value. 226 Other Sub-types other than defined above are reserved for future 227 extensions. 229 5. Using Node and Link MSD Advertisements 231 When Link MSD is present for a given MSD type, the value of the Link 232 MSD MUST be used in preference to the Node MSD. 234 The meaning of the absence of both Node and Link MSD advertisements 235 for a given MSD type is specific to the MSD type. Generally it can 236 only be inferred that the advertising node does not support 237 advertisement of that MSD type. However, in some cases the lack of 238 advertisement might imply that the functionality associated with the 239 MSD type is not supported. The correct interpretation MUST be 240 specified when an MSD type is defined. 242 6. Base MPLS Imposition MSD 244 Base MPLS Imposition MSD (BMI-MSD) signals the total number of MPLS 245 labels a node is capable of imposing, including any service/transport 246 labels. 248 Absence of BMI-MSD advertisements indicates only that the advertising 249 node does not support advertisement of this capability. 251 7. IANA Considerations 253 This document includes a request to IANA to allocate TLV type codes 254 for the new TLV proposed in Section 3 of this document from OSPF 255 Router Information (RI) TLVs Registry as defined by [RFC4970]. For 256 the link MSD, we request IANA to allocate new sub-TLV codes as 257 proposed in Section 4 from OSPFv2 Extended Link TLV Sub-TLVs registry 258 and from Router-Link TLV defined in OSPFv3 Extend-LSA Sub-TLV 259 registry. 261 This document requests creation of a new IANA managed registry under 262 a new category of "Interior Gateway Protocol (IGP) Parameters" IANA 263 registries to identify MSD types as proposed in Section 3, Section 4. 264 The registration procedure is "Expert Review" as defined in 265 [RFC8126]. Suggested registry name is "MSD types". Types are an 266 unsigned 8 bit number. The following values are defined by this 267 document 269 Value Name Reference 270 ----- --------------------- ------------- 271 0 Reserved This document 272 1 Base MPLS Imposition MSD This document 273 2-250 Unassigned This document 274 251-254 Experimental This document 275 255 Reserved This document 277 Figure 3: MSD Types Codepoints Registry 279 8. Security Considerations 281 Security considerations, as specified by [RFC7770] are applicable to 282 this document 284 9. Contributors 286 The following people contributed to this document: 288 Les Ginsberg 290 Email: ginsberg@cisco.com 292 10. Acknowledgements 294 The authors would like to thank Stephane Litkowski and Bruno Decraene 295 for their reviews and valuable comments. 297 11. References 299 11.1. Normative References 301 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 302 Requirement Levels", BCP 14, RFC 2119, 303 DOI 10.17487/RFC2119, March 1997, 304 . 306 [RFC4970] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 307 S. Shaffer, "Extensions to OSPF for Advertising Optional 308 Router Capabilities", RFC 4970, DOI 10.17487/RFC4970, July 309 2007, . 311 [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and 312 S. Shaffer, "Extensions to OSPF for Advertising Optional 313 Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, 314 February 2016, . 316 11.2. Informative References 318 [I-D.ietf-idr-bgp-ls-segment-routing-msd] 319 Tantsura, J., Chunduri, U., Mirsky, G., and S. Sivabalan, 320 "Signaling Maximum SID Depth using Border Gateway Protocol 321 Link-State", draft-ietf-idr-bgp-ls-segment-routing-msd-01 322 (work in progress), October 2017. 324 [I-D.ietf-ospf-mpls-elc] 325 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 326 Litkowski, "Signaling Entropy Label Capability and 327 Readable Label-stack Depth Using OSPF", draft-ietf-ospf- 328 mpls-elc-05 (work in progress), January 2018. 330 [I-D.ietf-ospf-ospfv3-lsa-extend] 331 Lindem, A., Roy, A., Goethals, D., Vallem, V., and F. 332 Baker, "OSPFv3 LSA Extendibility", draft-ietf-ospf-ospfv3- 333 lsa-extend-23 (work in progress), January 2018. 335 [I-D.ietf-pce-segment-routing] 336 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 337 and J. Hardwick, "PCEP Extensions for Segment Routing", 338 draft-ietf-pce-segment-routing-11 (work in progress), 339 November 2017. 341 [RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and 342 R. Aggarwal, "Support of Address Families in OSPFv3", 343 RFC 5838, DOI 10.17487/RFC5838, April 2010, 344 . 346 [RFC7684] Psenak, P., Gredler, H., Shakir, R., Henderickx, W., 347 Tantsura, J., and A. Lindem, "OSPFv2 Prefix/Link Attribute 348 Advertisement", RFC 7684, DOI 10.17487/RFC7684, November 349 2015, . 351 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 352 S. Ray, "North-Bound Distribution of Link-State and 353 Traffic Engineering (TE) Information Using BGP", RFC 7752, 354 DOI 10.17487/RFC7752, March 2016, 355 . 357 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 358 Writing an IANA Considerations Section in RFCs", BCP 26, 359 RFC 8126, DOI 10.17487/RFC8126, June 2017, 360 . 362 Authors' Addresses 364 Jeff Tantsura 365 Nuage Networks 367 Email: jefftant.ietf@gmail.com 368 Uma Chunduri 369 Huawei Technologies 371 Email: uma.chunduri@huawei.com 373 Sam Aldrin 374 Google, Inc 376 Email: aldrin.ietf@gmail.com 378 Peter Psenak 379 Cisco Systems 381 Email: ppsenak@cisco.com