idnits 2.17.1 draft-zhou-idr-bgp-srmpls-elp-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 date (1 March 2022) is 780 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: 'RFC4360' is defined on line 254, but no explicit reference was found in the text == Unused Reference: 'RFC8174' is defined on line 263, but no explicit reference was found in the text == Unused Reference: 'RFC8476' is defined on line 291, but no explicit reference was found in the text == Unused Reference: 'RFC8491' is defined on line 296, but no explicit reference was found in the text == Outdated reference: A later version (-26) exists of draft-ietf-idr-segment-routing-te-policy-14 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Y. Liu 3 Internet-Draft S. Peng 4 Intended status: Standards Track ZTE 5 Expires: 2 September 2022 1 March 2022 7 BGP Extension for SR-MPLS Entropy Label Position 8 draft-zhou-idr-bgp-srmpls-elp-04 10 Abstract 12 This document proposes extensions for BGP to indicate the entropy 13 label position in the SR-MPLS label stack when delivering SR Policy 14 via BGP. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at https://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on 2 September 2022. 33 Copyright Notice 35 Copyright (c) 2022 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 40 license-info) in effect on the date of publication of this document. 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. Code Components 43 extracted from this document must include Revised BSD License text as 44 described in Section 4.e of the Trust Legal Provisions and are 45 provided without warranty as described in the Revised BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions used in this document . . . . . . . . . . . . . . 3 51 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2.2. Terminology and Acronyms . . . . . . . . . . . . . . . . 3 53 3. Entropy Label Position in SR-MPLS with the Controller . . . . 3 54 4. BGP Extensions for ELP in SR Policy . . . . . . . . . . . . . 5 55 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 60 8.2. Informative References . . . . . . . . . . . . . . . . . 6 61 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 Segment Routing (SR) leverages the source routing paradigm. Segment 66 Routing can be instantiated on MPLS data plane which is referred to 67 as SR-MPLS [RFC8660]. SR-MPLS leverages the MPLS label stack to 68 construct the SR path. 70 Entropy labels (ELs) [RFC6790] are used in the MPLS data plane to 71 provide entropy for load-balancing. The idea behind the entropy 72 label is that the ingress router computes a hash based on several 73 fields from a given packet and places the result in an additional 74 label named "entropy label". Then, this entropy label can be used as 75 part of the hash keys used by an LSR. Using the entropy label as 76 part of the hash keys reduces the need for deep packet inspection in 77 the LSR while keeping a good level of entropy in the load-balancing. 79 [RFC8662] proposes to use entropy labels for SR-MPLS networks and 80 multiple pairs may be inserted in the SR-MPLS label stack. 81 The ingress node may decide the number and position of the ELI/ELs 82 which need to be inserted into the label stack, that is termed as ELP 83 (Entropy Label Position) in this document. But in some cases, the 84 controller (e.g. PCE) can be used to perform the TE path computation 85 as well as the Entropy Label Position which is useful for inter- 86 domain scenarios. 88 [I-D.ietf-idr-segment-routing-te-policy] specifies the way to use BGP 89 to distribute one or more of the candidate paths of an SR Policy to 90 the headend of that policy. 92 This document proposes extensions for BGP to indicate the ELP in the 93 segment list when delivering SR Policy via BGP in SR-MPLS networks. 95 2. Conventions used in this document 97 2.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 2.2. Terminology and Acronyms 105 EL: Entropy Label 107 ELI: Entropy Label Indicator 109 ELC: Entropy Label Capability 111 ERLD: Entropy Readable Label Depth 113 ELP: Entropy Label Position 115 MSD: Maximum SID Depth 117 3. Entropy Label Position in SR-MPLS with the Controller 119 As described in [RFC8662] section 7, ELI/EL placement is not an easy 120 decision, multiple criteria may be taken into account. 122 First is the Maximum SID Depth (MSD), it defines the maximum number 123 of labels that a particular node can impose on a packet, and it is a 124 limit when the ingress node imposing ELI/EL pairs on the SR label 125 stack. 127 The Entropy Readable Label Depth(ERLD) value is another important 128 parameter to consider when inserting an ELI/EL. The ERLD is defined 129 as the number of labels a router can both read in an MPLS packet 130 received on its incoming interface(s) and use in its load-balancing 131 function. An ELI/EL pair must be within the ERLD of the LSR in order 132 for the LSR to use the EL during load-balancing. It's necessary to 133 get the ERLD of the nodes along the SR path to achieve efficient 134 load-balancing. 136 An implementation MAY try to evaluate if load-balancing is really 137 expected at a particular node based on the segment type of its label, 138 which also influences the ELP of a segment list. 140 Other criteria includes maximizing number of LSRs that will load- 141 balance, preference for a part of the path, and etc. Using which 142 criteria and how to decide the ELP based on the criteria is a matter 143 of implementation. 145 As shown in Figure 1, in the inter-domain scenario, a path from A to 146 Z is required, a centralized controller performs the computation of 147 the end-to-end path, along which traffic load-balancing is required. 149 .................... .................... ..................... 150 . . . . . . 151 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 152 .| A |-------| B |------ | C |------| X |-------| Y |------| Z | . 153 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 154 . domain 1 . . domain 2 . . domain 3 . 155 .................... .................... ..................... 157 Figure 1: Entropy Labels in SR-MPLS Inter-Domain Scenario 159 When the headend node in the first domain can't get the information 160 of the nodes/SIDs in other domains, e.g, the ERLD of each node or the 161 type of the SID bounded to a node/link, it's difficult for the 162 headend node to decide the ELP of the segment list for the path. 164 Performing the computation of the ELP by the controller is an 165 alternate, since it's easier for the controller to get the required 166 information along the segment list prescribed by itself. 168 For example, the ERLD value can be advertised via IS- 169 IS[I-D.ietf-isis-mpls-elc] and OSPF[I-D.ietf-ospf-mpls-elc] within 170 the domain, in each domain, one or more nodes are configured with 171 BGP-LS so the controller can get the ERLD value of all the nodes 172 through BGP-LS[RFC9085]. The controller can acquire the MSD of the 173 headend node or the Binding SID anchor node via BGP-LS[RFC8814] or 174 PCEP[RFC8664]. 176 Another benefit of utilizing the controller to calculate ELP is that 177 if the criteria or calculation algorithm is changed, the 178 corresponding modification only needs to be made on the controller 179 instead of each headend node in the network. 181 When the controller performs the computation of the the ELP for a 182 segment list, the considerations for the placement of ELI/ELs 183 introduced in [RFC8662] are still applicable. How the controller 184 computes the ELP is out of scope of the document. 186 After the ELP of an SR path is decided, the controller SHOULD inform 187 the result to the headend node of the path, so the node knows where 188 to insert the ELI/ELs when needed. Section 4 proposes the detailed 189 extensions for BGP to carry this information. 191 4. BGP Extensions for ELP in SR Policy 193 The Segment Flags for Segment Sub-TLVs are defined in 194 Section 2.4.4.2.12 of [I-D.ietf-idr-segment-routing-te-policy]. In 195 this document, the ELP information is transmitted by extending the 196 flags of Segment Sub-TLVs. 198 0 1 2 3 4 5 6 7 199 +-+-+-+-+-+-+-+-+ 200 |V|A|S|B|E| | 201 +-+-+-+-+-+-+-+-+ 203 E-Flag: This flag, when set, indicates that presence of < ELI, EL> 204 label pairs which are inserted after this segment. E-Flag is 205 applicable to Segment Types A, C, D, E, F, G and H. If E-Flag 206 appears with Segment Types B, I, J and K, it MUST be ignored. 208 5. Operations 210 Node A receives an SR Policy NLRI with an Segment List sub-TLV from 211 the controller. The Segment List sub-TLV contains multiple Segment 212 sub-TLVs, e.g, , the E-Flags of S3 and S6 are 213 set, it indicates that if load-balancing is required, two 214 pairs SHOULD be inserted into the label stack of the SR-TE forwarding 215 entry, respectively after the Label for S3 and Label for S6. 217 The value of EL is supplemented by the ingress node according to 218 load-balancing function of the appropriate keys extracted from a 219 given packet. After inserting ELI/ELs, the label stack on the 220 ingress node would be . 222 6. IANA Considerations 224 This document requests bit 4 for Entropy Label Flag in "SR Policy 225 Segment Flags" under the "BGP Tunnel Encapsulation" registry. 227 Bit Description Reference 228 ------------------------------------------------------------------ 229 4 Entropy Label Position Flag(E-Flag) This document 231 7. Security Considerations 233 Procedures and protocol extensions defined in this document do not 234 introduce any new security considerations beyond those already listed 235 in [RFC8662] and [I-D.ietf-idr-segment-routing-te-policy]. 237 8. References 239 8.1. Normative References 241 [I-D.ietf-idr-segment-routing-te-policy] 242 Previdi, S., Filsfils, C., Talaulikar, K., Mattes, P., 243 Jain, D., and S. Lin, "Advertising Segment Routing 244 Policies in BGP", Work in Progress, Internet-Draft, draft- 245 ietf-idr-segment-routing-te-policy-14, 10 November 2021, 246 . 249 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 250 Requirement Levels", BCP 14, RFC 2119, 251 DOI 10.17487/RFC2119, March 1997, 252 . 254 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 255 Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, 256 February 2006, . 258 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 259 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 260 RFC 6790, DOI 10.17487/RFC6790, November 2012, 261 . 263 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 264 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 265 May 2017, . 267 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 268 Shakir, R., and J. Tantsura, "Entropy Label for Source 269 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 270 DOI 10.17487/RFC8662, December 2019, 271 . 273 8.2. Informative References 275 [I-D.ietf-isis-mpls-elc] 276 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 277 and M. Bocci, "Signaling Entropy Label Capability and 278 Entropy Readable Label Depth Using IS-IS", Work in 279 Progress, Internet-Draft, draft-ietf-isis-mpls-elc-13, 28 280 May 2020, . 283 [I-D.ietf-ospf-mpls-elc] 284 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 285 and M. Bocci, "Signaling Entropy Label Capability and 286 Entropy Readable Label Depth Using OSPF", Work in 287 Progress, Internet-Draft, draft-ietf-ospf-mpls-elc-15, 1 288 June 2020, . 291 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 292 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 293 DOI 10.17487/RFC8476, December 2018, 294 . 296 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 297 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 298 DOI 10.17487/RFC8491, November 2018, 299 . 301 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 302 Decraene, B., Litkowski, S., and R. Shakir, "Segment 303 Routing with the MPLS Data Plane", RFC 8660, 304 DOI 10.17487/RFC8660, December 2019, 305 . 307 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 308 and J. Hardwick, "Path Computation Element Communication 309 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 310 DOI 10.17487/RFC8664, December 2019, 311 . 313 [RFC8814] Tantsura, J., Chunduri, U., Talaulikar, K., Mirsky, G., 314 and N. Triantafillis, "Signaling Maximum SID Depth (MSD) 315 Using the Border Gateway Protocol - Link State", RFC 8814, 316 DOI 10.17487/RFC8814, August 2020, 317 . 319 [RFC9085] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Gredler, 320 H., and M. Chen, "Border Gateway Protocol - Link State 321 (BGP-LS) Extensions for Segment Routing", RFC 9085, 322 DOI 10.17487/RFC9085, August 2021, 323 . 325 Authors' Addresses 326 Yao Liu 327 ZTE 328 Nanjing 329 China 330 Email: liu.yao71@zte.com.cn 332 Shaofu Peng 333 ZTE 334 Nanjing 335 China 336 Email: peng.shaofu@zte.com.cn