idnits 2.17.00 (12 Aug 2021) /tmp/idnits16464/draft-peng-pce-entropy-label-position-07.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 document date (March 2022) is 60 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: 'RFC8623' is defined on line 408, but no explicit reference was found in the text == Outdated reference: draft-ietf-isis-mpls-elc has been published as RFC 9088 == Outdated reference: draft-ietf-ospf-mpls-elc has been published as RFC 9089 == Outdated reference: A later version (-02) exists of draft-ietf-pce-lsp-extended-flags-01 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Q. Xiong 3 Internet-Draft S. Peng 4 Intended status: Standards Track ZTE Corporation 5 Expires: 3 September 2022 F. Qin 6 China Mobile 7 March 2022 9 PCEP Extension for SR-MPLS Entropy Label Position 10 draft-peng-pce-entropy-label-position-07 12 Abstract 14 This document proposes a set of extensions for PCEP to configure the 15 entropy label position for SR-MPLS networks. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 2 September 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions used in this document . . . . . . . . . . . . . . 3 52 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 3. Entropy Labels in SR-MPLS Scenario with PCE . . . . . . . . . 3 55 4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 5 57 4.2. The LSP-EXTENDED-FLAG TLV . . . . . . . . . . . . . . . . 5 58 4.3. The SR-ERO Object . . . . . . . . . . . . . . . . . . . . 6 59 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 62 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 8.1. New SR PCE Capability Flag Registry . . . . . . . . . . . 7 64 8.2. New LSP-EXTENDED-FLAG Flag Registry . . . . . . . . . . . 7 65 8.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 8 66 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 [RFC5440] describes the Path Computation Element Protocol (PCEP) 72 which is used between a Path Computation Element (PCE) and a Path 73 Computation Client (PCC) (or other PCE) to enable computation of 74 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 75 Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model 76 [RFC8231] describes a set of extensions to PCEP to enable active 77 control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. [RFC8281] 78 describes the setup and teardown of PCE-initiated LSPs under the 79 active stateful PCE model, without the need for local configuration 80 on the PCC, thus allowing for dynamic centralized control of a 81 network. 83 Segment Routing (SR) leverages the source routing paradigm. Segment 84 Routing can be instantiated on MPLS data plane which is referred to 85 as SR-MPLS [RFC8660]. SR-MPLS leverages the MPLS label stack to 86 construct the SR path. PCEP Extensions for Segment Routing [RFC8664] 87 specifies extensions to the PCEP that allow a stateful PCE to compute 88 and initiate TE paths, as well as a PCC to request a path subject to 89 certain constraint(s) and optimization criteria in SR networks. 91 Entropy label (EL) [RFC6790] is a technique used in the MPLS data 92 plane to improve load-balancing. Entropy Label Indicator (ELI) can 93 be immediately preceding an EL in the MPLS label stack. The idea 94 behind the EL is that the ingress router computes a hash based on 95 several fields from a given packet and places the result in an 96 additional label, named "entropy label". Then, this entropy label 97 can be used as part of the hash keys used by an LSR. Using the 98 entropy label as part of the hash keys reduces the need for deep 99 packet inspection in the LSR while keeping a good level of entropy in 100 the load-balancing. When the entropy label is used, the keys used in 101 the hashing functions are still a local configuration matter and an 102 LSR may use solely the entropy label or a combination of multiple 103 fields from the incoming packet. 105 [RFC8662] proposes to use entropy labels for SR-MPLS networks and 106 mutiple pairs SHOULD be inserted in the SR-MPLS label 107 stack. The ingress node may decide the number and place of the ELI/ 108 ELs which need to be inserted into the label stack. The extensions 109 for Border Gateway Protocol (BGP) to indicate the entropy label 110 position in the SR-MPLS label stack has been proposed in 111 [I-D.zhou-idr-bgp-srmpls-elp]. 113 In some cases, the the controller(e.g. PCE) could be used to perform 114 the TE path computation as well as the Entropy Label Position (ELP) 115 which is useful for inter-domain scenarios. This document proposes a 116 set of extensions for PCEP to configure the ELP information for SR- 117 MPLS networks. 119 2. Conventions used in this document 121 2.1. Terminology 123 The terminology is defined as [RFC5440], [RFC6790], [RFC8664] and 124 [RFC8662]. 126 2.2. Requirements Language 128 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 129 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 130 "OPTIONAL" in this document are to be interpreted as described in BCP 131 14 [RFC2119] [RFC8174] when, and only when, they appear in all 132 capitals, as shown here. 134 3. Entropy Labels in SR-MPLS Scenario with PCE 136 [RFC8662] proposes to use entropy labels for SR-MPLS networks. The 137 Entropy Readable Label Depth (ERLD) is defined as the number of 138 labels which means that the router will perform load-balancing using 139 the ELI/EL. An appropriate algorithm should consider the following 140 criteria: 142 * a limited number of pairs SHOULD be inserted in the SR- 143 MPLS label stack; 145 * the inserted positions SHOULD be whithin the ERLD of a maximize 146 number of transit LSRs; 148 * a minimum number of pairs SHOULD be inserted while 149 satisfying the above criteria. 151 As described in [RFC8662] section 7, the ERLD value is important for 152 inserting ELI/EL and the ingress node need to evaluate the minimum 153 ERLD value along the node segment path. But it will add complexity 154 in the ELI/EL insertion process. Moreover, the ingress node cannot 155 find the minimum ERLD along the path and does not support the 156 computation of the minimum ERLD especilly in inter-domain scenarios. 157 As the Figure 1 shown, in SR-MPLS inter-domain scenario, the ingress 158 node of the first domain could not get the ERLD information of other 159 nodes of other domains. 161 +-----+ +-----+ +-----+ 162 |PCE-1| |PCE-2| |PCE-3| 163 +--+--+ +--+--+ +--+--+ 164 | | | 165 .........+.......... .........+.......... .........+........... 166 . . . . . . 167 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 168 .| A |-------| B |------ | C |------| X |-------| Y |------| Z | . 169 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 170 . SR-AS 1 . . SR-AS 2 . . SR-AS 3 . 171 .................... .................... ..................... 173 Figure 1: Figure 1: Entropy Labels in SR-MPLS Inter-Domain Scenario 175 The PCEs could get the information of all nodes such as Maximum SID 176 Depth (MSD) and ERLD through Interior Gateway Protocol (IGP) and can 177 compute the minimum ERLD along the end-to-end path. For example, the 178 ERLD value can be collected via IS-IS [I-D.ietf-isis-mpls-elc], 179 OSPF[I-D.ietf-ospf-mpls-elc]. [RFC8476] and [RFC8491] provide 180 examples of advertisement of the MSD. Moreover, the PCEs also can 181 compute the Entropy Label Position (ELP) including the number and the 182 places of the ELI/ELs. Then the ingress nodes MAY be required to 183 support the capabilities of inserting multiple ELI/ELs and need to 184 advertise the capabilities to the PCEs. 186 This document proposes the extensions for PCE to perform the 187 computation of the end-to-end path as well as the positions of 188 entropy labels in SR-MPLS networks. The ingress nodes can directly 189 insert the ELI/ELs based on the positions. 191 4. PCEP Extensions 193 4.1. The OPEN Object 195 As defined in [RFC8664], PCEP speakers use SR PCE Capability sub-TLV 196 to exchange information about their SR capability when PST=1 in the 197 PST List of the PATH-SETUP-TYPE-CAPABILITY TLV carried in Open 198 object. This document defined a new flag (E-flag) for SR PCE 199 Capability sub-TLV as shown in Figure 2. 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type=TBD11 | Length=4 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Reserved | Flags |E|N|X| MSD | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: Figure 2: E-flag in SR-PCE-CAPABILITY sub-TLV 211 E (Entropy Label Configuration is supported) : A PCE sets this flag 212 bit to 1 carried in Open message to indicate that it supports the 213 computation of SR path with ELP information. A PCC sets this flag to 214 1 to indicate that it supports the capability of inserting multiple 215 ELI/EL pairs and and supports the results of SR path with ELP from 216 PCE. 218 4.2. The LSP-EXTENDED-FLAG TLV 220 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 221 defiend a new flag (E-flag) for the LSP-EXTENDED-FLAG TLV carried in 222 LSP Object as defined in [I-D.ietf-pce-lsp-extended-flags]. The 223 format is shown as Figure 3: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type=TBD | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | |E| 231 // LSP Extended Flags // 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 Figure 3: Figure 3: E-flag in LSP-EXTENDED-FLAG TLV 237 E (Request for ELP Configuration) : If the bit is set to 1, it 238 indicates that the PCC requests PCE to compute the SR path with ELP 239 information. A PCE would also set this bit to 1 to indicate that the 240 ELP information is included by PCE and encoded in the PCRep, PCUpd or 241 PCInitiate message. 243 4.3. The SR-ERO Object 245 SR-ERO subobject is used for SR-TE path which consists of one or more 246 SIDs as defined in [RFC8664]. This document defiend a new flag 247 (E-flag) for the SR-ERO subobject as Figure 4 shown: 249 0 1 2 3 250 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 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 |L| Type=36 | Length | NT | Flags |E|F|S|C|M| 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | SID (optional) | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 // NAI (variable, optional) // 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 Figure 4: Figure 4: E-flag in SR-ERO subobject 261 E (ELP Configuration) : If this flag is set, it means that the 262 position after this SR-ERO subobject is the position to insert , otherwise it cannot insert after this segment. 265 5. Operations 267 The SR path is initiated by PCE or PCC with PCReq, PCInitiated or 268 PCUpd messages and the E bit is set to 1 in LSP object to request the 269 ELP configuration. The SR-TE path being recieved by PCC with SR-ERO 270 segment list, for example, , especially S3 271 and S6 with E-flag set. It indicates that two pairs MUST 272 be inserted into the label stack of the SR-TE forwarding entry, 273 repectively after the label for S3 and label for S6. With EL 274 information, the label stack for SR-MPLS would be . 277 6. Security Considerations 279 Procedures and protocol extensions defined in this document do not 280 introduce any new security considerations beyond those already listed 281 in [RFC8662] and [RFC8664]. 283 7. Acknowledgements 285 The authors would like to thank Stephane Litkowski, Dhruv Dhody, 286 Tarek Saad, Zhenbin Li and Jeff Tantsura for their review, 287 suggestions and comments to this document. 289 8. IANA Considerations 291 8.1. New SR PCE Capability Flag Registry 293 SR PCE Capability TLV is defined in [RFC8664], and the registry to 294 manage the Flag field of the SR PCE Capability TLV is requested in 295 [RFC8664]. IANA is requested to make allocations from the registry, 296 as follows: 298 +=======+==============================================+===========+ 299 | Value | Name | Reference | 300 +=======+==============================================+===========+ 301 | TBD11 | Entropy Label Configuration is supported (E) | [this | 302 | | | document] | 303 +-------+----------------------------------------------+-----------+ 305 Table 1 307 8.2. New LSP-EXTENDED-FLAG Flag Registry 309 [I-D.ietf-pce-lsp-extended-flags] defines the LSP-EXTENDED-FLAG TLV. 310 IANA is requested to make allocations from the Flag field registry, 311 as follows: 313 +=======+===================================+=================+ 314 | Value | Name | Reference | 315 +=======+===================================+=================+ 316 | TBD | Request for ELP Configuration (E) | [this document] | 317 +-------+-----------------------------------+-----------------+ 319 Table 2 321 8.3. New SR-ERO Flag Registry 323 SR-ERO subobject is defined in [RFC8664], and the registry to manage 324 the Flag field of SR-ERO is requested in [RFC8664]. IANA is 325 requested to make allocations from the registry, as follows: 327 +=======+=======================+=================+ 328 | Value | Name | Reference | 329 +=======+=======================+=================+ 330 | 36 | ELP Configuration (E) | [this document] | 331 +-------+-----------------------+-----------------+ 333 Table 3 335 9. Normative References 337 [I-D.ietf-isis-mpls-elc] 338 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 339 and M. Bocci, "Signaling Entropy Label Capability and 340 Entropy Readable Label Depth Using IS-IS", Work in 341 Progress, Internet-Draft, draft-ietf-isis-mpls-elc-13, 28 342 May 2020, . 345 [I-D.ietf-ospf-mpls-elc] 346 Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., 347 and M. Bocci, "Signaling Entropy Label Capability and 348 Entropy Readable Label Depth Using OSPF", Work in 349 Progress, Internet-Draft, draft-ietf-ospf-mpls-elc-15, 1 350 June 2020, . 353 [I-D.ietf-pce-lsp-extended-flags] 354 Xiong, Q., "LSP Object Flag Extension of Stateful PCE", 355 Work in Progress, Internet-Draft, draft-ietf-pce-lsp- 356 extended-flags-01, 18 October 2021, 357 . 360 [I-D.zhou-idr-bgp-srmpls-elp] 361 Liu, Y. and S. Peng, "BGP Extension for SR-MPLS Entropy 362 Label Position", Work in Progress, Internet-Draft, draft- 363 zhou-idr-bgp-srmpls-elp-04, 1 March 2022, 364 . 367 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 368 Requirement Levels", BCP 14, RFC 2119, 369 DOI 10.17487/RFC2119, March 1997, 370 . 372 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 373 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 374 DOI 10.17487/RFC5440, March 2009, 375 . 377 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 378 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 379 RFC 6790, DOI 10.17487/RFC6790, November 2012, 380 . 382 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 383 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 384 May 2017, . 386 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 387 Computation Element Communication Protocol (PCEP) 388 Extensions for Stateful PCE", RFC 8231, 389 DOI 10.17487/RFC8231, September 2017, 390 . 392 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 393 Computation Element Communication Protocol (PCEP) 394 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 395 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 396 . 398 [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, 399 "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, 400 DOI 10.17487/RFC8476, December 2018, 401 . 403 [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, 404 "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, 405 DOI 10.17487/RFC8491, November 2018, 406 . 408 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 409 Path Computation Element (PCE) Protocol Extensions for 410 Usage with Point-to-Multipoint TE Label Switched Paths 411 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 412 . 414 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 415 Decraene, B., Litkowski, S., and R. Shakir, "Segment 416 Routing with the MPLS Data Plane", RFC 8660, 417 DOI 10.17487/RFC8660, December 2019, 418 . 420 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 421 Shakir, R., and J. Tantsura, "Entropy Label for Source 422 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 423 DOI 10.17487/RFC8662, December 2019, 424 . 426 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 427 and J. Hardwick, "Path Computation Element Communication 428 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 429 DOI 10.17487/RFC8664, December 2019, 430 . 432 Authors' Addresses 434 Quan Xiong 435 ZTE Corporation 436 No.6 Huashi Park Rd 437 Wuhan 438 Hubei, 430223 439 China 440 Email: xiong.quan@zte.com.cn 442 Shaofu Peng 443 ZTE Corporation 444 No.50 Software Avenue 445 Nanjing 446 Jiangsu, 210012 447 China 448 Email: peng.shaofu@zte.com.cn 450 Fengwei Qin 451 China Mobile 452 Beijing 453 China 454 Email: qinfengwei@chinamobile.com