idnits 2.17.1 draft-ietf-idr-bgp-ls-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 : ---------------------------------------------------------------------------- ** There are 6 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (May 8, 2020) is 1442 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 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-17) exists of draft-ietf-idr-bgp-model-08 == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-11 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-mpls-elc-13 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group J. Tantsura 3 Internet-Draft Apstra, Inc. 4 Intended status: Standards Track U. Chunduri 5 Expires: November 9, 2020 Futurewei Technologies 6 K. Talaulikar 7 Cisco Systems 8 G. Mirsky 9 ZTE Corp. 10 N. Triantafillis 11 Amazon Web Services 12 May 8, 2020 14 Signaling MSD (Maximum SID Depth) using Border Gateway Protocol - Link 15 State 16 draft-ietf-idr-bgp-ls-segment-routing-msd-18 18 Abstract 20 This document defines a way for a Border Gateway Protocol - Link 21 State (BGP-LS) speaker to advertise multiple types of supported 22 Maximum SID Depths (MSDs) at node and/or link granularity. 24 Such advertisements allow entities (e.g., centralized controllers) to 25 determine whether a particular Segment Identifier (SID) stack can be 26 supported in a given network. 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 November 9, 2020. 45 Copyright Notice 47 Copyright (c) 2020 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. Conventions used in this document . . . . . . . . . . . . 3 64 1.1.1. Terminology . . . . . . . . . . . . . . . . . . . . . 3 65 1.1.2. Requirements Language . . . . . . . . . . . . . . . . 4 66 2. Advertisement of MSD via BGP-LS . . . . . . . . . . . . . . . 4 67 3. Node MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 4 68 4. Link MSD TLV . . . . . . . . . . . . . . . . . . . . . . . . 5 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 70 6. Manageability Considerations . . . . . . . . . . . . . . . . 6 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 7 73 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 74 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 76 10.2. Informative References . . . . . . . . . . . . . . . . . 8 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 79 1. Introduction 81 When Segment Routing (SR) [RFC8402] paths are computed by a 82 centralized controller, it is critical that the controller learns the 83 Maximum SID Depth (MSD) that can be imposed at each node/link on a 84 given SR path. This ensures that the Segment Identifier (SID) stack 85 depth of a computed path doesn't exceed the number of SIDs the node 86 is capable of imposing. 88 [RFC8664] defines how to signal MSD in the Path Computation Element 89 Protocol (PCEP). The OSPF and IS-IS extensions for signaling of MSD 90 are defined in [RFC8476] and [RFC8491] respectively. 92 However, if PCEP is not supported/configured on the head-end of a SR 93 tunnel or a Binding-SID anchor node, and the controller does not 94 participate in IGP routing, it has no way of learning the MSD of 95 nodes and links. BGP-LS [RFC7752] defines a way to expose topology 96 and associated attributes and capabilities of the nodes in that 97 topology to a centralized controller. 99 This document defines extensions to BGP-LS to advertise one or more 100 types of MSDs at node and/or link granularity. Other types of MSD 101 are known to be useful. For example, [I-D.ietf-ospf-mpls-elc] and 102 [I-D.ietf-isis-mpls-elc] define Readable Label Depth Capability 103 (RLDC) that is used by a head-end to insert an Entropy Label (EL) at 104 a depth that can be read by transit nodes. 106 In the future, it is expected that new MSD-Types will be defined to 107 signal additional capabilities, e.g., ELs, SIDs that can be imposed 108 through recirculation, or SIDs associated with another data plane 109 such as IPv6. MSD advertisements may be useful even if SR itself is 110 not enabled. For example, in a non-SR MPLS network, MSD defines the 111 maximum label depth. 113 1.1. Conventions used in this document 115 1.1.1. Terminology 117 MSD: Maximum SID Depth - the number of SIDs supported by a node or a 118 link on a node 120 PCE: Path Computation Element 122 PCEP: Path Computation Element Protocol 124 SID: Segment Identifier as defined in [RFC8402] 126 SR: Segment Routing 128 Label Imposition: Imposition is the act of modifying and/or adding 129 labels to the outgoing label stack associated with a packet. This 130 includes: 132 o replacing the label at the top of the label stack with a new 133 label. 135 o pushing one or more new labels onto the label stack. 137 o The number of labels imposed is then the sum of the number of 138 labels that are replaced and the number of labels that are pushed. 139 See [RFC3031] for further details. 141 1.1.2. Requirements Language 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 145 "OPTIONAL" in this document are to be interpreted as described in BCP 146 14 [RFC2119] [RFC8174] when, and only when, they appear in all 147 capitals, as shown here . 149 2. Advertisement of MSD via BGP-LS 151 This document describes extensions that enable BGP-LS speakers to 152 signal the MSD capabilities ([RFC8491] ) of nodes and their links in 153 a network to a BGP-LS consumer of network topology such as a 154 centralized controller. The centralized controller can leverage this 155 information in computation of SR paths based on their MSD 156 capabilities. When a BGP-LS speaker is originating the topology 157 learnt via link-state routing protocols such as OSPF or IS-IS, the 158 MSD information for the nodes and their links is sourced from the 159 underlying extensions as defined in [RFC8476] and [RFC8491] 160 respectively. 162 The extensions introduced in this document allow for advertisement of 163 different MSD-Types, which are defined elsewhere and were introduced 164 in [RFC8491]. This enables sharing of MSD-Types that may be defined 165 in the future by the IGPs in BGP-LS. 167 3. Node MSD TLV 169 The Node MSD ([RFC8476] [RFC8491]) is encoded in a new Node Attribute 170 TLV [RFC7752] to carry the provisioned SID depth of the router 171 identified by the corresponding Router-ID. Node MSD is the smallest 172 MSD supported by the node on the set of interfaces configured for 173 use. MSD values may be learned via a hardware API or may be 174 provisioned. The following format is used: 176 0 1 2 3 177 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 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Type | Length | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 Figure 1: Node MSD TLV Format 186 Where: 188 o Type: 266 189 o Length: variable (multiple of 2); represents the total length of 190 the value field in octets. 192 o Value : consists of one or more pairs of a 1-octet MSD-Type and 193 1-octet MSD-Value. 195 * MSD-Type : one of the values defined in the "IGP MSD-Types" 196 registry defined in [RFC8491]. 198 * MSD-Value : a number in the range of 0-255. For all MSD-Types, 199 0 represents the lack of ability to impose an MSD stack of any 200 depth; any other value represents that of the node. This value 201 MUST represent the lowest value supported by any link 202 configured for use by the advertising protocol instance. 204 4. Link MSD TLV 206 The Link MSD ([RFC8476] [RFC8491]) is defined to carry the MSD of the 207 interface associated with the link. It is encoded in a new Link 208 Attribute TLV [RFC7752] using the following format: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type | Length | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | MSD-Type | MSD-Value | MSD-Type... | MSD-Value... | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 Figure 2: Link MSD TLV Format 220 Where: 222 o Type: 267 224 o Length: variable (multiple of 2); represents the total length of 225 the value field in octets. 227 o Value : consists of one or more pairs of a 1-octet MSD-Type and 228 1-octet MSD-Value. 230 * MSD-Type : MSD-Type : one of the values defined in the "IGP 231 MSD-Types" registry defined in [RFC8491]. 233 * MSD-Value : a number in the range of 0-255. For all MSD-Types, 234 0 represents the lack of ability to impose an MSD stack of any 235 depth; any other value represents that of the link when used as 236 an outgoing interface. 238 5. IANA Considerations 240 This document requests assigning code-points from the registry "BGP- 241 LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute 242 TLVs" based on table below. Early allocation for these code-points 243 have been done by IANA. 245 +------------+-----------------+---------------------------+-------------------+ 246 | Code Point | Description | IS-IS TLV/Sub-TLV | Reference | 247 +------------+-----------------+---------------------------+-------------------+ 248 | 266 | Node MSD | 242/23 | This document | 249 | 267 | Link MSD | (22,23,25,141,222,223)/15 | This document | 250 +------------+-----------------+---------------------------+-------------------+ 252 6. Manageability Considerations 254 The new protocol extensions introduced in this document augment the 255 existing IGP topology information that is distributed via [RFC7752]. 256 Procedures and protocol extensions defined in this document do not 257 affect the BGP protocol operations and management other than as 258 discussed in the Manageability Considerations section of [RFC7752]. 259 Specifically, the malformed attribute tests for syntactic checks in 260 the Fault Management section of [RFC7752] now encompass the new BGP- 261 LS Attribute TLVs defined in this document. The semantic or content 262 checking for the TLVs specified in this document and their 263 association with the BGP-LS NLRI types or their BGP-LS Attribute is 264 left to the consumer of the BGP-LS information (e.g. an application 265 or a controller) and not the BGP protocol. 267 A consumer of the BGP-LS information retrieves this information over 268 a BGP-LS session (refer Section 1 and 2 of [RFC7752]). 270 This document only introduces new Attribute TLVs and any syntactic 271 error in them would result in the BGP-LS Attribute being discarded 272 [RFC7752]. The MSD information introduced in BGP-LS by this 273 specification, may be used by BGP-LS consumer applications like a SR 274 PCE to learn the SR SID stack handling capabilities of the nodes in 275 the topology. This can enable the SR PCE to perform path 276 computations taking into consideration the size of SID stack that the 277 specific head-end node may be able to impose. Errors in the encoding 278 or decoding of the MSD information may result in the unavailability 279 of such information to the SR PCE or incorrect information being made 280 available to it. This may result in the head-end node not being able 281 to instantiate the desired SR path in its forwarding and provide the 282 SR based optimization functionality. The handling of such errors by 283 applications like SR PCE may be implementation specific and out of 284 scope of this document. 286 The extensions specified in this document do not specify any new 287 configuration or monitoring aspects in BGP or BGP-LS. The 288 specification of BGP models is an ongoing work based on the 289 [I-D.ietf-idr-bgp-model]. 291 7. Security Considerations 293 The advertisement of an incorrect MSD value may have negative 294 consequences. If the value is smaller than supported, path 295 computation may fail to compute a viable path. If the value is 296 larger than supported, an attempt to instantiate a path that can't be 297 supported by the head-end (the node performing the SID imposition) 298 may occur. The presence of this information may also inform an 299 attacker of how to induce any of the aforementioned conditions. 301 The procedures and protocol extensions defined in this document do 302 not affect the BGP security model. See the "Security Considerations" 303 section of [RFC4271] for a discussion of BGP security. Also, refer 304 to [RFC4272] and [RFC6952] for analyses of security issues for BGP. 305 Security considerations for acquiring and distributing BGP-LS 306 information are discussed in [RFC7752]. The TLVs introduced in this 307 document are used to propagate the MSD IGP extensions defined in 308 [RFC8476] [RFC8491]. It is assumed that the IGP instances 309 originating these TLVs will support all the required security (as 310 described in [RFC8476] [RFC8491]) in order to prevent any security 311 issues when propagating the TLVs into BGP-LS. The advertisement of 312 the node and link attribute information defined in this document 313 presents no significant additional risk beyond that associated with 314 the existing node and link attribute information already supported in 315 [RFC7752]. 317 8. Contributors 319 Siva Sivabalan 320 Cisco Systems Inc. 321 Canada 323 Email: msiva@cisco.com 325 9. Acknowledgements 327 We like to thank Acee Lindem, Stephane Litkowski, Bruno Decraene and 328 Alvaro Retana for their reviews and valuable comments. 330 10. References 332 10.1. Normative References 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 340 S. Ray, "North-Bound Distribution of Link-State and 341 Traffic Engineering (TE) Information Using BGP", RFC 7752, 342 DOI 10.17487/RFC7752, March 2016, 343 . 345 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 346 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 347 May 2017, . 349 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 350 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 351 DOI 10.17487/RFC8476, December 2018, 352 . 354 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 355 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 356 DOI 10.17487/RFC8491, November 2018, 357 . 359 10.2. Informative References 361 [I-D.ietf-idr-bgp-model] 362 Jethanandani, M., Patel, K., Hares, S., and J. Haas, "BGP 363 YANG Model for Service Provider Networks", draft-ietf-idr- 364 bgp-model-08 (work in progress), February 2020. 366 [I-D.ietf-isis-mpls-elc] 367 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 368 and M. Bocci, "Signaling Entropy Label Capability and 369 Entropy Readable Label Depth Using IS-IS", draft-ietf- 370 isis-mpls-elc-11 (work in progress), March 2020. 372 [I-D.ietf-ospf-mpls-elc] 373 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 374 and M. Bocci, "Signaling Entropy Label Capability and 375 Entropy Readable Label Depth Using OSPF", draft-ietf-ospf- 376 mpls-elc-13 (work in progress), April 2020. 378 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 379 Label Switching Architecture", RFC 3031, 380 DOI 10.17487/RFC3031, January 2001, 381 . 383 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 384 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 385 DOI 10.17487/RFC4271, January 2006, 386 . 388 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", 389 RFC 4272, DOI 10.17487/RFC4272, January 2006, 390 . 392 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 393 BGP, LDP, PCEP, and MSDP Issues According to the Keying 394 and Authentication for Routing Protocols (KARP) Design 395 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 396 . 398 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 399 Decraene, B., Litkowski, S., and R. Shakir, "Segment 400 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 401 July 2018, . 403 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 404 and J. Hardwick, "Path Computation Element Communication 405 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 406 DOI 10.17487/RFC8664, December 2019, 407 . 409 Authors' Addresses 411 Jeff Tantsura 412 Apstra, Inc. 414 Email: jefftant.ietf@gmail.com 416 Uma Chunduri 417 Futurewei Technologies 419 Email: umac.ietf@gmail.com 420 Ketan Talaulikar 421 Cisco Systems 423 Email: ketant@cisco.com 425 Greg Mirsky 426 ZTE Corp. 428 Email: gregimirsky@gmail.com 430 Nikos Triantafillis 431 Amazon Web Services 433 Email: nikost@amazon.com