idnits 2.17.1 draft-peng-pce-entropy-label-position-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 (August 12, 2020) is 1345 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 362, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-xiong-pce-lsp-flag-02 Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE S. Peng 3 Internet-Draft Q. Xiong 4 Intended status: Standards Track ZTE Corporation 5 Expires: February 13, 2021 F. Qin 6 China Mobile 7 August 12, 2020 9 PCEP Extension for SR-MPLS Entropy Label Position 10 draft-peng-pce-entropy-label-position-04 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 February 13, 2021. 34 Copyright Notice 36 Copyright (c) 2020 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 41 (https://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Internet-DrafPCEP Extension for SR-MPLS Entropy Label Positi August 2020 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions used in this document . . . . . . . . . . . . . . 3 55 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 57 3. Entropy Labels in SR-MPLS Scenario with PCE . . . . . . . . . 3 58 4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 59 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. The LSP-EXTENDED-FLAG TLV . . . . . . . . . . . . . . . . 5 61 4.3. The ERO Object . . . . . . . . . . . . . . . . . . . . . 6 62 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 66 8.1. New SR PCE Capability Flag Registry . . . . . . . . . . . 7 67 8.2. New LSP-EXTENDED-FLAG Flag Registry . . . . . . . . . . . 7 68 8.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 7 69 9. Normative References . . . . . . . . . . . . . . . . . . . . 8 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 72 1. Introduction 74 [RFC5440] describes the Path Computation Element Protocol (PCEP) 75 which is used between a Path Computation Element (PCE) and a Path 76 Computation Client (PCC) (or other PCE) to enable computation of 77 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 78 Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model 79 [RFC8231] describes a set of extensions to PCEP to enable active 80 control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. [RFC8281] 81 describes the setup and teardown of PCE-initiated LSPs under the 82 active stateful PCE model, without the need for local configuration 83 on the PCC, thus allowing for dynamic centralized control of a 84 network. 86 Segment Routing (SR) leverages the source routing paradigm. Segment 87 Routing can be instantiated on MPLS data plane which is referred to 88 as SR-MPLS [RFC8660]. SR-MPLS leverages the MPLS label stack to 89 construct the SR path. PCEP Extensions for Segment Routing [RFC8664] 90 specifies extensions to the PCEP that allow a stateful PCE to compute 91 and initiate TE paths, as well as a PCC to request a path subject to 92 certain constraint(s) and optimization criteria in SR networks. 94 Entropy label (EL) [RFC6790] is a technique used in the MPLS data 95 plane to improve load-balancing. Entropy Label Indicator (ELI) can 96 be immediately preceding an EL in the MPLS label stack. The idea 97 behind the EL is that the ingress router computes a hash based on 98 several fields from a given packet and places the result in an 100 Internet-DrafPCEP Extension for SR-MPLS Entropy Label Positi August 2020 102 additional label, named "entropy label". Then, this entropy label 103 can be used as part of the hash keys used by an LSR. Using the 104 entropy label as part of the hash keys reduces the need for deep 105 packet inspection in the LSR while keeping a good level of entropy in 106 the load-balancing. When the entropy label is used, the keys used in 107 the hashing functions are still a local configuration matter and an 108 LSR may use solely the entropy label or a combination of multiple 109 fields from the incoming packet. 111 [RFC8662] proposes to use entropy labels for SR-MPLS networks and 112 mutiple pairs SHOULD be inserted in the SR-MPLS label 113 stack. The ingress node may decide the number and place of the ELI/ 114 ELs which need to be inserted into the label stack. But in some 115 cases, the the controller (e.g. PCE) could be used to perform the TE 116 path computation as well as the Entropy Label Position (ELP) which is 117 useful for inter-domain scenarios. This document proposes a set of 118 extensions for PCEP to configure the ELP information for SR-MPLS 119 networks. 121 2. Conventions used in this document 123 2.1. Terminology 125 The terminology is defined as [RFC5440], [RFC6790], [RFC8664] and 126 [RFC8662]. 128 2.2. Requirements Language 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 132 "OPTIONAL" in this document are to be interpreted as described in BCP 133 14 [RFC2119] [RFC8174] when, and only when, they appear in all 134 capitals, as shown here. 136 3. Entropy Labels in SR-MPLS Scenario with PCE 138 [RFC8662] proposes to use entropy labels for SR-MPLS networks. The 139 Entropy Readable Label Depth (ERLD) is defined as the number of 140 labels which means that the router will perform load-balancing using 141 the ELI/EL. An appropriate algorithm should consider the following 142 criteria: 144 o a limited number of pairs SHOULD be inserted in the SR- 145 MPLS label stack; 147 o the inserted positions SHOULD be whithin the ERLD of a maximize 148 number of transit LSRs; 150 Internet-DrafPCEP Extension for SR-MPLS Entropy Label Positi August 2020 152 o a minimum number of pairs SHOULD be inserted while 153 satisfying the above criteria. 155 As the Figure 1 shown, in SR-MPLS inter-domain scenario, the ingress 156 node of the first domain could not get the ERLD information of other 157 nodes of other domains. The PCE MUST perform the computation of the 158 end-to-end path as well as the the Entropy Label Position (ELP) 159 including the number and the place of the ELI/ELs. The PCEs has the 160 capability to get the ERLD information of all nodes in inter-domain 161 scenarios. 163 +-----+ +-----+ +-----+ 164 |PCE-1| |PCE-2| |PCE-3| 165 +--+--+ +--+--+ +--+--+ 166 | | | 167 .........+.......... .........+.......... .........+........... 168 . . . . . . 169 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 170 .| A |-------| B |------ | C |------| X |-------| Y |------| Z | . 171 .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . 172 . SR-AS 1 . . SR-AS 2 . . SR-AS 3 . 173 .................... .................... ..................... 175 Figure 1: Entropy Labels in SR-MPLS Inter-Domain Scenario 177 4. PCEP Extensions 179 4.1. The OPEN Object 181 As defined in [RFC8664], PCEP speakers use SR PCE Capability sub-TLV 182 to exchange information about their SR capability when PST=1 in the 183 PST List of the PATH-SETUP-TYPE-CAPABILITY TLV carried in Open 184 object. This document defined a new flag (E-flag) for SR PCE 185 Capability sub-TLV as shown in Figure 2. 187 Internet-DrafPCEP Extension for SR-MPLS Entropy Label Positi August 2020 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type=TBD11 | Length=4 | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Reserved | Flags |E|N|X| MSD | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 Figure 2: E-flag in SR-PCE-CAPABILITY sub-TLV 199 E (Entropy Label Configuration is supported) : A PCE sets this flag 200 bit to 1 carried in Open message to indicate that it supports the 201 computation of SR path with ELP information. A PCC sets this flag to 202 1 to indicate that it supports the capability of inserting multiple 203 ELI/EL pairs and and supports the results of SR path with ELP from 204 PCE. 206 4.2. The LSP-EXTENDED-FLAG TLV 208 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 209 defiend a new flag (E-flag) for the LSP-EXTENDED-FLAG TLV carried in 210 LSP Object as defined in [I-D.xiong-pce-lsp-flag]. The format is 211 shown as Figure 3: 213 0 1 2 3 214 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 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Type=TBD | Length | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | |E| 219 // LSP Extended Flags // 220 | | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 3: E-flag in LSP-EXTENDED-FLAG TLV 225 E (Request for ELP Configuration) : If the bit is set to 1, it 226 indicates that the PCC requests PCE to compute the SR path with ELP 227 information. A PCE would also set this bit to 1 to indicate that the 228 ELP information is included by PCE and encoded in the PCRep, PCUpd or 229 PCInitiate message. 231 Internet-DrafPCEP Extension for SR-MPLS Entropy Label Positi August 2020 233 4.3. The ERO Object 235 SR-ERO subobject is used for SR-TE path which consists of one or more 236 SIDs as defined in [RFC8664]. This document defiend a new flag 237 (E-flag) for the SR-ERO subobject as Figure 4 shown: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 |L| Type=36 | Length | NT | Flags |E|F|S|C|M| 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | SID (optional) | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 // NAI (variable, optional) // 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 Figure 4: E-flag in SR-ERO subobject 251 E (ELP Configuration) : If this flag is set, it means that the 252 position after this SR-ERO subobject is the position to insert , otherwise it cannot insert after this segment. 255 5. Operations 257 The SR path is initiated by PCE or PCC with PCReq, PCInitiated or 258 PCUpd messages and the E bit is set to 1 in LSP object to request the 259 ELP configuration. The SR-TE path being recieved by PCC with SR-ERO 260 segment list, for example, , especially S3 261 and S6 with E-flag set. It indicates that two pairs MUST 262 be inserted into the label stack of the SR-TE forwarding entry, 263 repectively after the label for S3 and label for S6. With EL 264 information, the label stack for SR-MPLS would be . 267 6. Security Considerations 269 TBA 271 7. Acknowledgements 273 TBA 275 Internet-DrafPCEP Extension for SR-MPLS Entropy Label Positi August 2020 277 8. IANA Considerations 279 8.1. New SR PCE Capability Flag Registry 281 SR PCE Capability TLV is defined in [RFC8664], and the registry to 282 manage the Flag field of the SR PCE Capability TLV is requested in 283 [RFC8664]. IANA is requested to make allocations from the registry, 284 as follows: 286 +--------+-----------------------------------------+----------------+ 287 | Value | Name | Reference | 288 +--------+-----------------------------------------+----------------+ 289 | TBD11 | Entropy Label Configuration is | [this | 290 | | supported (E) | document] | 291 +--------+-----------------------------------------+----------------+ 293 Table 1 295 8.2. New LSP-EXTENDED-FLAG Flag Registry 297 [I-D.xiong-pce-lsp-flag] defines the LSP-EXTENDED-FLAG TLV. IANA is 298 requested to make allocations from the Flag field registry, as 299 follows: 301 +---------+-------------------------------------+------------------+ 302 | Value | Name | Reference | 303 +---------+-------------------------------------+------------------+ 304 | TBD | Request for ELP Configuration (E) | [this document] | 305 +---------+-------------------------------------+------------------+ 307 Table 2 309 8.3. New SR-ERO Flag Registry 311 SR-ERO subobject is defined in [RFC8664], and the registry to manage 312 the Flag field of SR-ERO is requested in [RFC8664]. IANA is 313 requested to make allocations from the registry, as follows: 315 +---------+-------------------------+------------------+ 316 | Value | Name | Reference | 317 +---------+-------------------------+------------------+ 318 | 36 | ELP Configuration (E) | [this document] | 319 +---------+-------------------------+------------------+ 321 Table 3 323 Internet-DrafPCEP Extension for SR-MPLS Entropy Label Positi August 2020 325 9. Normative References 327 [I-D.xiong-pce-lsp-flag] 328 Xiong, Q., "LSP Object Flag Extension of Stateful PCE", 329 draft-xiong-pce-lsp-flag-02 (work in progress), May 2020. 331 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 332 Requirement Levels", BCP 14, RFC 2119, 333 DOI 10.17487/RFC2119, March 1997, 334 . 336 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 337 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 338 DOI 10.17487/RFC5440, March 2009, 339 . 341 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 342 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 343 RFC 6790, DOI 10.17487/RFC6790, November 2012, 344 . 346 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 347 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 348 May 2017, . 350 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 351 Computation Element Communication Protocol (PCEP) 352 Extensions for Stateful PCE", RFC 8231, 353 DOI 10.17487/RFC8231, September 2017, 354 . 356 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 357 Computation Element Communication Protocol (PCEP) 358 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 359 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 360 . 362 [RFC8623] Palle, U., Dhody, D., Tanaka, Y., and V. Beeram, "Stateful 363 Path Computation Element (PCE) Protocol Extensions for 364 Usage with Point-to-Multipoint TE Label Switched Paths 365 (LSPs)", RFC 8623, DOI 10.17487/RFC8623, June 2019, 366 . 368 [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., 369 Decraene, B., Litkowski, S., and R. Shakir, "Segment 370 Routing with the MPLS Data Plane", RFC 8660, 371 DOI 10.17487/RFC8660, December 2019, 372 . 374 Internet-DrafPCEP Extension for SR-MPLS Entropy Label Positi August 2020 376 [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 377 Shakir, R., and J. Tantsura, "Entropy Label for Source 378 Packet Routing in Networking (SPRING) Tunnels", RFC 8662, 379 DOI 10.17487/RFC8662, December 2019, 380 . 382 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 383 and J. Hardwick, "Path Computation Element Communication 384 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 385 DOI 10.17487/RFC8664, December 2019, 386 . 388 Authors' Addresses 390 Shaofu Peng 391 ZTE Corporation 392 No.50 Software Avenue 393 Nanjing, Jiangsu 210012 394 China 396 Email: peng.shaofu@zte.com.cn 398 Quan Xiong 399 ZTE Corporation 400 No.6 Huashi Park Rd 401 Wuhan, Hubei 430223 402 China 404 Email: xiong.quan@zte.com.cn 406 Fengwei Qin 407 China Mobile 408 Beijing 409 China 411 Email: qinfengwei@chinamobile.com