idnits 2.17.1 draft-ietf-idr-bgp-ls-segment-routing-msd-04.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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (February 19, 2019) is 1891 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: 'I-D.ietf-isis-segment-routing-extensions' is defined on line 256, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ospf-segment-routing-extensions' is defined on line 268, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-spring-segment-routing-mpls' is defined on line 274, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-15 ** Obsolete normative reference: RFC 7752 (Obsoleted by RFC 9552) == Outdated reference: A later version (-13) exists of draft-ietf-isis-mpls-elc-06 == Outdated reference: A later version (-25) exists of draft-ietf-isis-segment-routing-extensions-22 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-mpls-elc-07 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-mpls-18 Summary: 1 error (**), 0 flaws (~~), 10 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: August 23, 2019 Huawei USA 6 G. Mirsky 7 ZTE Corp. 8 S. Sivabalan 9 Cisco 10 N. Triantafillis 11 Apstra, Inc. 12 February 19, 2019 14 Signaling MSD (Maximum SID Depth) using Border Gateway Protocol Link- 15 State 16 draft-ietf-idr-bgp-ls-segment-routing-msd-04 18 Abstract 20 This document defines a way for a Border Gateway Protocol Link-State 21 (BGP-LS) speaker to advertise multiple types of supported Maximum SID 22 Depths (MSDs) at node and/or link granularity. 24 Such advertisements allow logically centralized entities (e.g., 25 centralized controllers) to determine whether a particular SID stack 26 can be 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 August 23, 2019. 45 Copyright Notice 47 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . 3 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 3. MSD supported by a node . . . . . . . . . . . . . . . . . . . 4 68 4. MSD supported on a link . . . . . . . . . . . . . . . . . . . 4 69 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 70 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 71 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 8.1. Normative References . . . . . . . . . . . . . . . . . . 5 74 8.2. Informative References . . . . . . . . . . . . . . . . . 6 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 When Segment Routing tunnels are computed by a centralized 80 controller, it is critical that the controller learns the MSD 81 "Maximum SID Depth" of the node or link SR tunnel exits over, so the 82 SID stack depth of a path computed doesn't exceed the number of SIDs 83 the node is capable of imposing. This document describes how to use 84 BGP-LS to signal the MSD of a node or link to a centralized 85 controller. 87 PCEP SR extensions draft [I-D.ietf-pce-segment-routing] signals MSD 88 in SR PCE Capability TLV and METRIC Object. However, if PCEP is not 89 supported/configured on the head-end of a SR tunnel or a Binding-SID 90 anchor node and controller does not participate in IGP routing, it 91 has no way to learn the MSD of nodes and links which has been 92 configured. BGP-LS [RFC7752] defines a way to expose topology and 93 associated attributes and capabilities of the nodes in that topology 94 to a centralized controller. 96 Other types of MSD are known to be useful. For example, 97 [I-D.ietf-ospf-mpls-elc] and [I-D.ietf-isis-mpls-elc] define Readable 98 Label Depth Capability (RLDC) that is used by a head-end to insert an 99 Entropy Label (EL) at a depth that can be read by transit nodes. 101 1.1. Conventions used in this document 103 1.1.1. Terminology 105 BGP-LS: Distribution of Link-State and TE Information using Border 106 Gateway Protocol 108 MSD: Maximum SID Depth 110 PCC: Path Computation Client 112 PCE: Path Computation Element 114 PCEP: Path Computation Element Protocol 116 SID: Segment Identifier 118 SR: Segment routing 120 1.1.2. Requirements Language 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 124 "OPTIONAL" in this document are to be interpreted as described in BCP 125 14 [RFC2119] [RFC8174] when, and only when, they appear in all 126 capitals, as shown here . 128 2. Problem Statement 130 In existing technology only PCEP has extension to signal the MSD (SR 131 PCE Capability TLV/ METRIC Object as defined in 132 [I-D.ietf-pce-segment-routing],If PCEP is not supported by the node 133 (head-end of the SR tunnel) controller has no way to learn the MSD of 134 the node/link configured. OSPF and IS-IS extensions are defined in: 136 [RFC8476], [RFC8491] 138 3. MSD supported by a node 140 Node MSD is encoded in a new Node Attribute TLV, as defined in 141 [RFC7752] 143 0 1 2 3 144 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 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Type | Length | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Sub-Type and Value ... 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 151 Figure 1: Node attribute format 153 Type : A 2-octet field specifying code-point of the new TLV type. 154 Code-point:(TBD1) from BGP-LS Node Descriptor, Link Descriptor, 155 Prefix Descriptor, and Attribute TLVs registry 157 Length: A 2-octet field that indicates the length of the value 158 portion 160 Sub-Type and value fields are as defined in corresponding OSPF 161 [RFC8476] and IS-IS [RFC8491] extensions. 163 4. MSD supported on a link 165 Link MSD is encoded in a New Link Attribute TLV, as defined in 166 [RFC7752] 168 0 1 2 3 169 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 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Type | Length | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Sub-Type and Value ... 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... 176 Figure 2: Link attribute format 178 Type : A 2-octet field specifying code-point of the new TLV type. 179 Code-point:(TBD2) from BGP-LS Node Descriptor, Link Descriptor, 180 Prefix Descriptor, and Attribute TLVs registry 182 Length: A 2-octet field that indicates the length of the value 183 portion 184 Sub-Type and value fields are as defined in corresponding OSPF 185 [RFC8476] and IS-IS [RFC8491] extensions. 187 5. IANA Considerations 189 We request IANA assign code points from the registry BGP-LS Node 190 Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs, 191 as follows: TLV Code Point Description IS-IS TLV/Sub-TLV Reference 192 TBD1 Node MSD 242/23 (this document) TBD2 Link MSD 193 (22,23,25,141,222,223)/15 (this document) 195 6. Security Considerations 197 The advertisement of an incorrect MSD value may have negative 198 consequences. If the value is smaller than supported, path 199 computation may fail to compute a viable path. If the value is 200 larger than supported, an attempt to instantiate a path that can't be 201 supported by the head-end (the node performing the SID imposition) 202 may occur. The presence of this information may also inform an 203 attacker of how to induce any of the aforementioned conditions. 205 This document does not introduce security issues beyond those 206 discussed in [RFC7752], [RFC8476] and [RFC8491] 208 7. Acknowledgements 210 We like to thank Acee Lindem, Ketan Talaulikar, Stephane Litkowski 211 and Bruno Decraene for their reviews and valuable comments. 213 8. References 215 8.1. Normative References 217 [I-D.ietf-pce-segment-routing] 218 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 219 and J. Hardwick, "PCEP Extensions for Segment Routing", 220 draft-ietf-pce-segment-routing-15 (work in progress), 221 February 2019. 223 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 224 Requirement Levels", BCP 14, RFC 2119, 225 DOI 10.17487/RFC2119, March 1997, 226 . 228 [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and 229 S. Ray, "North-Bound Distribution of Link-State and 230 Traffic Engineering (TE) Information Using BGP", RFC 7752, 231 DOI 10.17487/RFC7752, March 2016, 232 . 234 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 235 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 236 May 2017, . 238 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 239 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 240 DOI 10.17487/RFC8476, December 2018, 241 . 243 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 244 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 245 DOI 10.17487/RFC8491, November 2018, 246 . 248 8.2. Informative References 250 [I-D.ietf-isis-mpls-elc] 251 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 252 Litkowski, "Signaling Entropy Label Capability and Entropy 253 Readable Label Depth Using IS-IS", draft-ietf-isis-mpls- 254 elc-06 (work in progress), September 2018. 256 [I-D.ietf-isis-segment-routing-extensions] 257 Previdi, S., Ginsberg, L., Filsfils, C., Bashandy, A., 258 Gredler, H., and B. Decraene, "IS-IS Extensions for 259 Segment Routing", draft-ietf-isis-segment-routing- 260 extensions-22 (work in progress), December 2018. 262 [I-D.ietf-ospf-mpls-elc] 263 Xu, X., Kini, S., Sivabalan, S., Filsfils, C., and S. 264 Litkowski, "Signaling Entropy Label Capability and Entropy 265 Readable Label-stack Depth Using OSPF", draft-ietf-ospf- 266 mpls-elc-07 (work in progress), September 2018. 268 [I-D.ietf-ospf-segment-routing-extensions] 269 Psenak, P., Previdi, S., Filsfils, C., Gredler, H., 270 Shakir, R., Henderickx, W., and J. Tantsura, "OSPF 271 Extensions for Segment Routing", draft-ietf-ospf-segment- 272 routing-extensions-27 (work in progress), December 2018. 274 [I-D.ietf-spring-segment-routing-mpls] 275 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 276 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 277 data plane", draft-ietf-spring-segment-routing-mpls-18 278 (work in progress), December 2018. 280 Authors' Addresses 282 Jeff Tantsura 283 Apstra, Inc. 285 Email: jefftant.ietf@gmail.com 287 Uma Chunduri 288 Huawei USA 290 Email: uma.chunduri@huawei.com 292 Greg Mirsky 293 ZTE Corp. 295 Email: gregimirsky@gmail.com 297 Siva Sivabalan 298 Cisco 300 Email: msiva@cisco.com 302 Nikos Triantafillis 303 Apstra, Inc. 305 Email: nikos@apstra.com