idnits 2.17.1 draft-peng-pce-entropy-label-position-00.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 (July 22, 2019) is 1730 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: January 23, 2020 July 22, 2019 7 PCEP Extension for SR-MPLS Entropy Label Position 8 draft-peng-pce-entropy-label-position-00 10 Abstract 12 This document proposes a set of extensions for PCEP to configure the 13 entropy label position for SR-MPLS networks. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at https://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 23, 2020. 32 Copyright Notice 34 Copyright (c) 2019 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (https://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions used in this document . . . . . . . . . . . . . . 3 51 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 3 53 3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. The LSP Object . . . . . . . . . . . . . . . . . . . . . 4 56 3.3. The ERO Object . . . . . . . . . . . . . . . . . . . . . 5 57 4. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 61 7.1. New SR PCE Capability Flag Registry . . . . . . . . . . . 6 62 7.2. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 6 63 7.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 6 64 8. Normative References . . . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 67 1. Introduction 69 [RFC5440] describes the Path Computation Element Protocol (PCEP) 70 which is used between a Path Computation Element (PCE) and a Path 71 Computation Client (PCC) (or other PCE) to enable computation of 72 Multi-protocol Label Switching (MPLS) for Traffic Engineering Label 73 Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model 74 [RFC8231] describes a set of extensions to PCEP to enable active 75 control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. [RFC8281] 76 describes the setup and teardown of PCE-initiated LSPs under the 77 active stateful PCE model, without the need for local configuration 78 on the PCC, thus allowing for dynamic centralized control of a 79 network. 81 Segment Routing (SR) leverages the source routing paradigm. Segment 82 Routing can be instantiated on MPLS data plane which is referred to 83 as SR-MPLS [I-D.ietf-spring-segment-routing-mpls]. SR-MPLS leverages 84 the MPLS label stack to construct the SR path. PCEP Extensions for 85 Segment Routing [I-D.ietf-pce-segment-routing] specifies extensions 86 to the PCEP that allow a stateful PCE to compute and initiate TE 87 paths, as well as a PCC to request a path subject to certain 88 constraint(s) and optimization criteria in SR networks. 90 Entropy label (EL) [RFC6790] is a technique used in the MPLS data 91 plane to provide entropy for load-balancing. Entropy Label Indicator 92 (ELI) can be immediately preceding an EL in the MPLS label stack. 93 The idea behind the EL is that the ingress router computes a hash 94 based on several fields from a given packet and places the result in 95 an additional label, named "entropy label". Then, this entropy label 96 can be used as part of the hash keys used by an LSR. Using the 97 entropy label as part of the hash keys reduces the need for deep 98 packet inspection in the LSR while keeping a good level of entropy in 99 the load-balancing. When the entropy label is used, the keys used in 100 the hashing functions are still a local configuration matter and an 101 LSR may use solely the entropy label or a combination of multiple 102 fields from the incoming packet. 104 [I-D.ietf-mpls-spring-entropy-label] proposes to use entropy labels 105 for SR-MPLS networks. The Entropy Readable Label Depth (ERLD) is 106 defined as the number of labels which means that the router will 107 perform load-balancing using the ELI/EL. An appropriate algorithm 108 would consider the following goals: 110 o a limited number of pairs should be inserted deeper in 111 the label-stack. 113 o the inserted position should be whithin the ERLD of most transit 114 nodes. 116 o a minimum number of to satisfy the above criteria. 118 In some cases, It is required for the controller (e.g. PCE) to 119 perform the TE path computation as well as the Entropy Label Position 120 (ELP), because the contoller has the ERLD information of all nodes, 121 especially for inter-domain scenarios. This document proposes a set 122 of extensions for PCEP to configure the ELP information for SR-MPLS 123 networks. 125 2. Conventions used in this document 127 2.1. Terminology 129 The terminology is defined as [RFC5440], [RFC6790], 130 [I-D.ietf-pce-segment-routing] and 131 [I-D.ietf-mpls-spring-entropy-label]. 133 2.2. Requirements Language 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 137 "OPTIONAL" in this document are to be interpreted as described in BCP 138 14 [RFC2119] [RFC8174] when, and only when, they appear in all 139 capitals, as shown here. 141 3. PCEP Extensions 143 3.1. The OPEN Object 145 As defined in [I-D.ietf-pce-segment-routing], PCEP speakers use SR 146 PCE Capability sub-TLV to exchange information about their SR 147 capability when PST=1 in the PST List of the PATH-SETUP-TYPE- 148 CAPABILITY TLV carried in Open object. This document defined a new 149 flag (E-flag) for SR PCE Capability sub-TLV as shown in Figure 1. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Type=TBD11 | Length=4 | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Reserved | Flags |E|N|X| MSD | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Figure 1: E-flag in SR-PCE-CAPABILITY sub-TLV 161 E (ELP Configuration is supported) : A PCC or PCE sets this flag bit 162 to 1 carried in Open message to indicate that it supports the SR path 163 with ELP configuration. 165 3.2. The LSP Object 167 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 168 defiend a new flag (E-flag) for the LSP Object as Figure 2 shown: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | PLSP-ID | Flag|E|C| O |A|R|S|D| 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 // TLVs // 176 | | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 Figure 2: E-flag in LSP Object 181 E (Request for ELP Configuration) : If the bit is set to 1, it 182 indicates that the PCC requests PCE to compute the SR path with ELP 183 information. A PCE would also set this bit to 1 to indicate that the 184 ELP information is included by PCE and encoded in the PCRep, PCUpd or 185 PCInitiate message. 187 3.3. The ERO Object 189 SR-ERO subobject is used for SR-TE path which consists of one or more 190 SIDs as defined in [I-D.ietf-pce-segment-routing]. This document 191 defiend a new flag (E-flag) for the SR-ERO subobject as Figure 3 192 shown: 194 0 1 2 3 195 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 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 |L| Type=36 | Length | NT | Flags |E|F|S|C|M| 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | SID (optional) | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 // NAI (variable, optional) // 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 Figure 3: E-flag in SR-ERO subobject 206 E (ELP Configuration) : If this flag is set, it means that the 207 position after this SR-ERO subobject is the position to insert , otherwise it cannot insert after this segment. 210 4. Operations 212 The SR path is initiated by PCE or PCC with PCReq, PCInitiated or 213 PCUpd messages and the E bit is set to 1 in LSP object to request the 214 ELP configuration. The SR-TE path being recieved by PCC with SR-ERO 215 segment list, for example, , especially S3 216 and S6 with E-flag set. It indicates that two pairs MUST 217 be inserted into the label stack of the SR-TE forwarding entry, 218 repectively after the label for S3 and label for S6. With EL 219 information, the label stack for SR-MPLS would be . 222 5. Security Considerations 224 TBA 226 6. Acknowledgements 228 TBA 230 7. IANA Considerations 232 7.1. New SR PCE Capability Flag Registry 234 SR PCE Capability TLV is defined in [I-D.ietf-pce-segment-routing], 235 and the registry to manage the Flag field of the SR PCE Capability 236 TLV is requested in [I-D.ietf-pce-segment-routing]. IANA is 237 requested to make allocations from the registry, as follows: 239 +--------+-------------------------------------+------------------+ 240 | Value | Name | Reference | 241 +--------+-------------------------------------+------------------+ 242 | TBA1 | ELP Configuration is supported (E) | [this document] | 243 +--------+-------------------------------------+------------------+ 245 Table 1 247 7.2. New LSP Flag Registry 249 [RFC8231] defines the LSP object; per that RFC, IANA created a 250 registry to manage the value of the LSP object's Flag field. IANA is 251 requested to make allocations from the registry, as follows: 253 +--------+------------------------------------+------------------+ 254 | Value | Name | Reference | 255 +--------+------------------------------------+------------------+ 256 | TBA2 | Request for ELP Configuration (E) | [this document] | 257 +--------+------------------------------------+------------------+ 259 Table 2 261 7.3. New SR-ERO Flag Registry 263 SR-ERO subobject is defined in [I-D.ietf-pce-segment-routing], and 264 the registry to manage the Flag field of SR-ERO is requested in 265 [I-D.ietf-pce-segment-routing]. IANA is requested to make 266 allocations from the registry, as follows: 268 +--------+------------------------+------------------+ 269 | Value | Name | Reference | 270 +--------+------------------------+------------------+ 271 | TBA3 | ELP Configuration (E) | [this document] | 272 +--------+------------------------+------------------+ 274 Table 3 276 8. Normative References 278 [I-D.ietf-mpls-spring-entropy-label] 279 Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., 280 Shakir, R., and J. Tantsura, "Entropy label for SPRING 281 tunnels", draft-ietf-mpls-spring-entropy-label-12 (work in 282 progress), July 2018. 284 [I-D.ietf-pce-segment-routing] 285 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 286 and J. Hardwick, "PCEP Extensions for Segment Routing", 287 draft-ietf-pce-segment-routing-16 (work in progress), 288 March 2019. 290 [I-D.ietf-spring-segment-routing-mpls] 291 Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., 292 Litkowski, S., and R. Shakir, "Segment Routing with MPLS 293 data plane", draft-ietf-spring-segment-routing-mpls-22 294 (work in progress), May 2019. 296 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 297 Requirement Levels", BCP 14, RFC 2119, 298 DOI 10.17487/RFC2119, March 1997, 299 . 301 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 302 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 303 DOI 10.17487/RFC5440, March 2009, 304 . 306 [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and 307 L. Yong, "The Use of Entropy Labels in MPLS Forwarding", 308 RFC 6790, DOI 10.17487/RFC6790, November 2012, 309 . 311 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 312 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 313 May 2017, . 315 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 316 Computation Element Communication Protocol (PCEP) 317 Extensions for Stateful PCE", RFC 8231, 318 DOI 10.17487/RFC8231, September 2017, 319 . 321 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 322 Computation Element Communication Protocol (PCEP) 323 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 324 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 325 . 327 Authors' Addresses 329 Shaofu Peng 330 ZTE Corporation 331 No.50 Software Avenue 332 Nanjing, Jiangsu 210012 333 China 335 Email: peng.shaofu@zte.com.cn 337 Quan Xiong 338 ZTE Corporation 339 No.6 Huashi Park Rd 340 Wuhan, Hubei 430223 341 China 343 Email: xiong.quan@zte.com.cn