idnits 2.17.1 draft-ietf-pce-sr-path-segment-02.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 (November 2, 2020) is 1270 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) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-25) exists of draft-ietf-pce-segment-routing-ipv6-06 == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-08 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-08 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-03 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-07 == Outdated reference: A later version (-23) exists of draft-ietf-pce-pcep-yang-15 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: May 6, 2021 W. Cheng 6 China Mobile 7 R. Gandhi 8 Cisco Systems, Inc. 9 Q. Xiong 10 ZTE Corporation 11 November 2, 2020 13 Path Computation Element Communication Protocol (PCEP) Extension for 14 Path Segment in Segment Routing (SR) 15 draft-ietf-pce-sr-path-segment-02 17 Abstract 19 The Path Computation Element (PCE) provides path computation 20 functions in support of traffic engineering in Multiprotocol Label 21 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 23 The Source Packet Routing in Networking (SPRING) architecture 24 describes how Segment Routing (SR) can be used to steer packets 25 through an IPv6 or MPLS network using the source routing paradigm. A 26 Segment Routed Path can be derived from a variety of mechanisms, 27 including an IGP Shortest Path Tree (SPT), explicit configuration, or 28 a Path Computation Element (PCE). 30 Path identification is needed for several use cases such as 31 performance measurement in Segment Routing (SR) network. This 32 document specifies extensions to the Path Computation Element 33 Communication Protocol (PCEP) to support requesting, replying, 34 reporting and updating the Path Segment ID (Path SID) between PCEP 35 speakers. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on May 6, 2021. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 72 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 74 3. Overview of Path Segment Extensions in PCEP . . . . . . . . . 4 75 4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5 76 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 5 77 4.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 5 78 4.1.2. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 6 79 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 6 80 4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7 81 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 9 83 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 5.1. Stateful PCE Operation . . . . . . . . . . . . . . . . . 10 85 5.1.1. Ingress PCC-Initiated Path Segment Allocation . . . . 10 86 5.1.2. PCE Initiated Path Segment Allocation . . . . . . . . 12 87 5.2. PCECC Based Operation . . . . . . . . . . . . . . . . . . 13 88 5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 13 89 5.2.2. PCECC based Path Segment Allocation . . . . . . . . . 13 90 6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 15 91 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 92 7.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 16 93 7.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 17 94 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 95 8.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 17 96 8.2. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 17 97 8.3. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 17 98 8.3.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 18 99 8.4. New FEC Type Registry . . . . . . . . . . . . . . . . . . 18 100 8.5. PCEP Error Type and Value . . . . . . . . . . . . . . . . 18 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 102 10. Manageability Considerations . . . . . . . . . . . . . . . . 19 103 10.1. Control of Function and Policy . . . . . . . . . . . . . 19 104 10.2. Information and Data Models . . . . . . . . . . . . . . 19 105 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 20 106 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 20 107 10.5. Requirements On Other Protocols . . . . . . . . . . . . 20 108 10.6. Impact On Network Operations . . . . . . . . . . . . . . 20 109 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 110 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 111 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 112 12.2. Informative References . . . . . . . . . . . . . . . . . 22 113 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 23 114 Appendix B. SRv6 extensions . . . . . . . . . . . . . . . . . . 24 115 B.1. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . . . 24 116 B.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 25 117 B.3. Path Segment TLV . . . . . . . . . . . . . . . . . . . . 25 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 120 1. Introduction 122 [RFC5440] describes the Path Computation Element (PCE) Communication 123 Protocol (PCEP). PCEP enables the communication between a Path 124 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 125 purpose of computation of Multiprotocol Label Switching (MPLS) as 126 well as Generalized MPLS (GMPLS) Traffic Engineering Label Switched 127 Path (TE LSP) characteristics. 129 [RFC8231] specifies a set of extensions to PCEP to enable stateful 130 control of TE LSPs within and across PCEP sessions in compliance with 131 [RFC4657]. It includes mechanisms to effect LSP State 132 Synchronization between PCCs and PCEs, delegation of control over 133 LSPs to PCEs, and PCE control of timing and sequence of path 134 computations within and across PCEP sessions. The model of operation 135 where LSPs are initiated from the PCE is described in [RFC8281]. 137 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 138 procedures and PCEP protocol extensions for using the PCE as the 139 central controller for static LSPs, where LSPs can be provisioned as 140 explicit label instructions at each hop on the end-to-end path. 142 Segment routing (SR) [RFC8402] leverages the source routing and 143 tunneling paradigms and supports steering packets into an explicit 144 forwarding path at the ingress node. 146 An SR path needs to be identified in some use cases such as 147 performance measurement. For identifying an SR path, 148 [I-D.ietf-spring-mpls-path-segment] introduces a new segment that is 149 referred to as Path Segment. 151 [RFC8664] specifies extensions to the Path Computation Element 152 Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE 153 to compute and initiate SR-TE paths, as well as a PCC to request, 154 report or delegate SR paths. 156 [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the 157 procedures and PCEP protocol extensions when a PCE-based controller 158 is also responsible for configuring the forwarding actions on the 159 routers (SR SID distribution in this case), in addition to computing 160 the paths for packet flows in a segment routing network and telling 161 the edge routers what instructions to attach to packets as they enter 162 the network. 164 This document specifies a mechanism to carry the SR path 165 identification information in PCEP messages [RFC5440] [RFC8231] 166 [RFC8281]. The SR path identifier can be a Path Segment in SR-MPLS 167 [I-D.ietf-spring-mpls-path-segment], or other IDs that can identify 168 an SR path. This document also extends the PCECC-SR mechanism to 169 inform the Path Segment to the egress PCC. 171 2. Terminology 173 This memo makes use of the terms defined in [RFC4655], [RFC8664], and 174 [RFC8402]. 176 2.1. Requirements Language 178 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 179 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 180 "OPTIONAL" in this document are to be interpreted as described in BCP 181 14 [RFC2119] [RFC8174] when, and only when, they appear in all 182 capitals, as shown here. 184 3. Overview of Path Segment Extensions in PCEP 186 This document specifies a mechanism of allocating Path Segment and 187 extends PCEP to encode it in PCEP messages. For supporting Path 188 Segment in PCEP, several TLVs and flags are defined. The formats of 189 the objects and TLVs are described in Section 4. The procedures of 190 Path Segment allocation are described in Section 5. 192 There are various modes of operations, such as - 193 o The Path Segment can be allocated by Egress PCC. The PCE should 194 request the Path Segment from Egress PCC. 196 o The PCE can allocate a Path Segment on its own accord and inform 197 the ingress/egress PCC, useful for PCE-initiated LSPs. 199 o Ingress PCC can also request PCE to allocate the Path Segment, in 200 this case, the PCE would either allocate and inform the assigned 201 Path Segment to the ingress/egress PCC using PCEP messages, or 202 first request egress PCC for Path Segment and then inform it to 203 the ingress PCC. 205 The path information to the ingress PCC and PCE is exchanged via an 206 extension to [RFC8664] and [I-D.ietf-pce-segment-routing-ipv6]. The 207 Path Segment information (for SR-MPLS) to the egress PCC can be 208 informed via an extension to the PCECC-SR procedures 209 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 211 For the PCE to allocate a Path Segment on its own, the PCE needs to 212 be aware of the MPLS label space from the PCCs. This is done via 213 mechanism as described in [I-D.li-pce-controlled-id-space]. 214 Otherwise, the PCE should request the egress PCC for Path Segment 215 allocation. 217 4. Objects and TLVs 219 4.1. The OPEN Object 221 4.1.1. The SR PCE Capability sub-TLV 223 [RFC8664] defined a new Path Setup Type (PST) and SR-PCE-CAPABILITY 224 sub-TLV for SR-MPLS. PCEP speakers use this sub-TLV to exchange 225 information about their SR capability. The TLV defines a Flags field 226 [RFC8664]. 228 This document adds an additional flag for Path Segment allocation, as 229 follows - 231 o P (Path Segment Identification bit): A PCEP speaker sets this flag 232 to 1 to indicate that it has the capability to encode SR path 233 identification (Path Segment, as per 234 [I-D.ietf-spring-mpls-path-segment]). 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type=TBD11 | Length=4 | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Reserved | Flags |P|N|X| MSD | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 Figure 1: P-flag in SR-PCE-CAPABILITY TLV 246 The figure is included for the ease of the reader and will be removed 247 at the time of publication. 249 4.1.2. PCECC-CAPABILITY sub-TLV 251 Along with the SR sub-TLVs, the PCECC Capability as per 252 [I-D.zhao-pce-pcep-extension-pce-controller-sr] should be advertised 253 if the PCE allocates the Path Segment and acts as a Central 254 Controller that manages the Label space. 256 The PCECC Capability should be advertised on the egress PCEP session, 257 along with the SR sub-TLVs. This is needed to ensure that the PCE 258 can use the PCECC objects/mechanism to request/inform the egress PCC 259 of the Path Segment as described in Section 5.2. 261 4.2. LSP Object 263 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 264 adds a flag in the LSP Object: 266 o P (PCE Allocation bit): If the bit is set to 1, it indicates that 267 the PCC requests PCE to make allocations for this LSP. The TLV in 268 LSP object identifies what should be allocated, such as Path 269 Segment or Binding Segment. A PCC would set this bit to 1 and 270 include a PATH-SEGMENT TLV in the LSP object to request for 271 allocation of Path Segment by the PCE in the PCEP message. A PCE 272 would also set this bit to 1 and include a PATH-SEGMENT TLV to 273 indicate that the Path Segment is allocated by PCE and encoded in 274 the PCEP message towards PCC. Further, a PCE would set this bit 275 to 0 and include a PATH-SEGMENT TLV in the LSP object to indicate 276 that the Path Segment should be allocated by the PCC as described 277 in Section 5.1.1. 279 0 1 2 3 280 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 281 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 | PLSP-ID | Flag|P|C| O |A|R|S|D| 283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 284 // TLVs // 285 | | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 Figure 2: P-flag in LSP Object 290 The figure is included for the ease of the reader and will be removed 291 at the time of publication. 293 4.2.1. Path Segment TLV 295 The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object for 296 Path Segment allocation. The type of this TLV is to be allocated by 297 IANA (TBA4). The format is as shown below. 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | Type | Length | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | ST | Flag |L| Reserved | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 ~ (Variable length) Path Segment ~ 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 Figure 3: The PATH-SEGMENT TLV Format 311 The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The 312 length (16-bit) has a variable length. The value contains the 313 following fields: 315 o ST (The Segment type - 8 bits): The ST field specifies the type of 316 the Path Segment field, which carries a Path Segment corresponding 317 to the SR path. 319 * 0: MPLS Path Segment, which is an MPLS label as defined in 320 [I-D.ietf-spring-mpls-path-segment]. The PST type MUST be set 321 to SR (MPLS). 323 * 1-255: Reserved for future use. 325 o Flags (8 bits): One flag is currently defined: 327 * L-Bit (Local/Global - 1 bit): If set, then the Path Segment 328 carried by the PATH-SEGMENT TLV has local significance. If not 329 set, then the Path Segment carried by this TLV has global 330 significance (i.e. Path Segment is global within an SR 331 domain). 333 * The unassigned bits MUST be set to 0 and MUST be ignored at 334 receipt. 336 o Reserved (16 bits): MUST be set to 0 and MUST be ignored at 337 receipt. 339 o Path Segment: The Path Segment of an SR path. The Path Segment 340 type is indicated by the ST field. When the ST is 0, it is a MPLS 341 Path Segment [I-D.ietf-spring-mpls-path-segment] in the MPLS label 342 format. 344 In general, only one instance of PATH-SEGMENT TLV will be included in 345 LSP object. If more than one PATH-SEGMENT TLV is included, the first 346 one is processed and others MUST be ignored. Multiple Path Segment 347 allocation for use cases like alternate-making will be considered in 348 future version of this draft. 350 When the Path Segment allocation is enabled, a PATH-SEGMENT TLV MUST 351 be included in the LSP object. 353 If the label space is maintained by PCC itself, and the Path Segment 354 is allocated by Egress PCC, then the PCE should request the Path 355 Segment from Egress PCC as described in Section 5.1.1. In this case, 356 the PCE should send a PCUpdate or PCInitiate message to the egress 357 PCC to request the Path Segment. The P-flag in LSP should be unset 358 in this case. 360 If a PCEP node does not recognize the PATH-SEGMENT TLV, it would 361 behave in accordance with [RFC5440] and ignore the TLV. If a PCEP 362 node recognizes the TLV but does not support the TLV, it MUST send 363 PCErr with Error-Type = 2 (Capability not supported). 365 4.3. FEC Object 367 The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is 368 used to specify the FEC information and carried within PCInitiate or 369 PCRpt message for the PCECC-SR operations. The PCE MUST inform the 370 Path Identification information to the Egress PCC. To do this, this 371 document extends the procedures of 372 [I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC 373 object type for Path. 375 FEC Object-Type is TBA6 'Path'. 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | | 381 // TLV(s) // 382 | | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 4: The path FEC object Format 387 One or more following TLV(s) are allowed in the 'path' FEC object - 389 o SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human- 390 readable string that identifies an LSP in the network. 392 o LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for 393 SR, but could be used to encode the source, destination and other 394 identification information for the path. 396 o SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique 397 identifier for the PCEP speaker, it is used to identify the 398 Ingress PCC. 400 Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be 401 included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of 402 each TLV is processed, if more than one TLV of each type is included, 403 the first one is processed and others MUST be ignored. 405 4.4. CCI Object 407 The Central Control Instructions (CCI) Object is used by the PCE to 408 specify the forwarding instructions is defined in 409 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further 410 [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object 411 type for SR. 413 The Path Segment information is encoded directly in the CCI SR 414 object. The Path Segment TLV as described in the Section 4.2.1, MUST 415 also be included in the CCI SR object as the TLV (as it includes 416 additional information regarding the Path Segment identifier). The C 417 flag in CCI object is used to indicate if the allocation needs to be 418 done by the PCC. 420 5. Operations 422 The Path Segment allocation and encoding is as per the Stateful PCE 423 operations for segment routing. The procedures are as per the 424 corresponding extensions defined in [RFC8664] and 425 [I-D.ietf-pce-segment-routing-ipv6] (which are further based on 426 [RFC8231] and [RFC8281]). The additional operations for Path Segment 427 are defined in this section. 429 To notify (or request) the Path Segment to the Egress PCC, the 430 procedures are as per the PCECC-SR 431 [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which is based on 432 [I-D.ietf-pce-pcep-extension-for-pce-controller]). The additional 433 operations are defined in this section. 435 5.1. Stateful PCE Operation 437 As defined in [I-D.ietf-spring-mpls-path-segment], a Path Segment can 438 be allocated by the egress PCC. In this case, the label space is 439 maintained on the PCC itself. 441 This section describes the mechanism of Path Segment allocation by 442 using PCInitiate and PCUpd message in Stateful PCE model. 444 5.1.1. Ingress PCC-Initiated Path Segment Allocation 446 The ingress PCC could request the Path Segment to be allocated by the 447 PCE via PCRpt message. The delegate flag (D-flag) MUST also be set 448 for this LSP. Also, the P-flag in the LSP object MUST be set. 450 On receiving a delegation request with Path Segment allocation 451 request from an ingress PCC, a stateful PCE requests the egress PCC 452 to allocate a Path Segment. 454 The PATH-SEGMENT TLV MUST be included in an LSP object in the 455 PCInitiate message sent from the PCE to the egress to request Path 456 Segment allocation by the egress PCC. The P flag in LSP object MUST 457 be set to 0. This PCInitiate message to egress PCC would be the 458 similar to the one sent to ingress PCC as per [RFC8664], but the 459 egress PCC would only allocate the Path Segment and would not trigger 460 the LSP initiation operation (as it would be the egress for this 461 LSP). 463 If the value of Path Segment is 0x0, it indicates that the PCE is 464 requesting a Path Segment for this LSP. If the Path Segment is set 465 to a value 'n' and the P flag is unset in the LSP object, it 466 indicates that the PCE requests a specific value 'n' of Path Segment. 467 If the Path Segment is allocated successfully, the egress PCC reports 468 the Path Segment via PCRpt message with PATH-SEGMENT TLV in LSP 469 object. Else, it MUST send a PCErr message with Error-Type = TBA7 470 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the 471 value of Path Segment is valid, but the PCC is unable to allocate the 472 Path Segment, it MUST send a PCErr message with Error-Type = TBA7 473 ("Path SID failure") and Error Value = 2 ("Unable to allocate the 474 specified label/SID"). 476 Once the PCE receives the PCRpt message, it can obtain the Path 477 Segment information from the egress PCC and then update the path with 478 Path Segment by sending PCUpd message to the ingress PCC. 480 If the Path Segment is updated successfully, the ingress PCC will 481 acknowledge with a PCRpt message to the PCE. In case of error, an 482 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 483 Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST 484 roll back the Path Segment value to the previous value (if any) by 485 sending a PCUpd message to synchronize with the egress PCC. 487 Ingress Egress 488 +-+-+ +-+-+ +-+-+ 489 |PCC| |PCE| |PCC| 490 +-+-+ +-+-+ +-+-+ 491 1) LSP State | ---- PCRpt ----> | | 492 Delegate | Delegate=1 | | 493 | P=1 |2) PCE update | 494 | | the LSP-DB and | 495 | | request Path SID | 496 | | | 497 | | --- PCInitiate ---> | Egress 498 | | PATH-SEGMENT | allocates 499 | | TLV in LSP | a Path-SID 500 | | | from its 501 | | <----- PCRpt ------ | space 502 | | Path SID | 503 | | | 504 |<---- PCUpd ---- |3)Paths update with | 505 | PATH-SEGMENT TLV | Path SID | 506 | | | 507 4) LSP State | ----- PCRpt ---> | | 508 Report | | | 509 | | | 511 Figure 5: Ingress PCC-Initiated Path Segment Allocation 513 If the ingress PCC wishes to withdraw or modify a previously reported 514 Path Segment value, it MUST send a PCRpt message without any PATH- 515 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 516 Segment respectively. In this case, the PCE should synchronize with 517 egress PCC via PCUpd message. 519 The Path Segment MUST be withdrawn when the corresponding LSP is 520 removed. When the LSP is deleted, the PCE MUST request the egress 521 PCC to withdraw the LSP and associated Path Segment via PCInitiate 522 message with the R flag is set in the SRP object. 524 If an egress PCC receives a valid Path Segment value from a PCE which 525 is different than the current Path Segment, it MUST try to allocate 526 the new value. If the new Path Segment is successfully allocated, 527 the egress PCC MUST report the new value to the PCE. Otherwise, it 528 MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID 529 failure") and Error Value = 2 ("Unable to allocate the specified 530 label/SID"). 532 5.1.2. PCE Initiated Path Segment Allocation 534 A stateful PCE also can initiate or update an LSP with Path Segment 535 actively via requesting the egress PCC to allocate a Path Segment. 537 If a PCE wishes to modify a previously requested Path Segment value 538 or allocate a Path Segment for an PCE-Initiated LSP, it MUST request 539 the egress PCC to allocate a new value by sending a PCUpd message to 540 the egress PCC with PATH-SEGMENT TLV containing the new Path Segment 541 value. Also, the P flag in LSP object is unset. Absence of the 542 PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to 543 withdraw the Path Segment. 545 The mechanism of requesting Path Segment is as per Section 5.1.1. 547 Once the PCE receives the PCRpt message, it can obtain the Path 548 Segment information from the egress PCC and then update or initiate 549 an LSP with Path Segment. 551 If the SR-Path is setup, the ingress PCC will acknowledge with a 552 PCRpt message to the PCE. In case of error, as described in 553 [RFC8664], an PCErr message will be sent back to the PCE. The PCE 554 MUST request the egress PCC to withdraw the LSP and associated Path 555 Segment via PCInitiate message with the R flag is set in the SRP 556 object. 558 If the Path Segment is updated successfully, the ingress PCC will 559 acknowledge with a PCRpt message to the PCE. In case of error, an 560 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 561 Value = 1 ("Invalid SID") will be sent back to the PCE. The PCE MUST 562 roll back the Path Segment value to the previous value (if any) by 563 sending a PCUpd message to synchronize with the egress PCC. 565 Ingress Egress 566 +-+-+ +-+-+ +-+-+ 567 |PCC| |PCE| |PCC| 568 +-+-+ +-+-+ +-+-+ 569 1) LSP State | ---- PCRpt ----> | | 570 Delegate if| Delegate=1 | | 571 the LSP exists| |2)PCE actively update| 572 | | the LSP-DB and | 573 | | request Path SID | 574 | | | 575 | | --- PCInitiate ---> | Egress 576 | | PATH-SEGMENT | allocates 577 | | TLV in LSP | a Path-SID 578 | | | from its 579 | | <----- PCRpt ------ | space 580 | | Path SID | 581 | | | 582 |<-- PCUpd/PCInit -- |3)Paths update with | 583 | PATH-SEGMENT TLV | Path SID | 584 | | | 585 4) LSP State | ----- PCRpt ---> | | 586 Report | | | 587 | | | 589 Figure 6: Stateful PCE-Initiated Path Segment Allocation 591 5.2. PCECC Based Operation 593 5.2.1. PCE Controlled Label Spaces Advertisement 595 For allocating the Path Segments to SR paths by the PCEs, the PCE 596 controlled label space MUST be known at PCEs via configurations or 597 any other mechanisms. The PCE controlled label spaces MAY be 598 advertised as described in [I-D.li-pce-controlled-id-space]. 600 5.2.2. PCECC based Path Segment Allocation 602 5.2.2.1. PCECC-Initiated 604 The PCE could allocate the Path Segment on its own for a PCE- 605 Initiated (or delegated LSP). The allocated Path Segment needs to be 606 informed to the Ingress and Egress PCC. The PCE would use the 607 PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the 608 Ingress PCC and MUST include the PATH-SEGMENT TLV in the LSP object. 610 The PCE would further inform the egress PCC about the Path Segment 611 allocated by the PCE using the PCInitiate message as described in 612 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 614 Ingress Egress 615 +-+-+ +-+-+ +-+-+ 616 |PCC| |PCE| |PCC| 617 +-+-+ +-+-+ +-+-+ 618 | | | 619 | <--PCInitiate--- |1)Initiate LSP with | 620 | PATH-SEGMENT TLV | Path SID | 621 | | | 622 2)LSP delegation |---PCRpt, D=1---> | (Confirm) | 623 | | | 624 |3) PCE informs the | --- PCInitiate ---> | 625 | Path SID to Egress| FEC=Path | 626 | | | 627 | | <-------- PCRpt --- | 628 | | | 630 Figure 7: PCE allocated Path Segment on its own 632 5.2.2.2. Ingress PCC-Initiated PCECC 634 The ingress PCC could request the Path Segment to be allocated by the 635 PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) 636 MUST also be set for this LSP. Also, the P-flag in the LSP object 637 MUST be set. 639 A PATH-SEGMENT TLV MUST be included in the LSP object. If the value 640 of Path Segment is 0x0, it indicates that the Ingress PCC is 641 requesting a Path Segment for this LSP. If the Path Segment is set 642 to a value 'n', it indicates that the ingress PCC requests a specific 643 value 'n' of Path Segment. 645 If the Path Segment is allocated successfully, the PCE would further 646 respond to Ingress PCC with PCUpd message as per [RFC8231] and MUST 647 include the PATH-SEGMENT TLV in a LSP object. Else, it MUST send a 648 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 649 Value = 1 ("Invalid SID"). If the value of Path Segment is valid, 650 but the PCC is unable to allocate the Path Segment, it MUST send a 651 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 652 Value = 2 ("Unable to allocate the specified label/SID"). 654 The active PCE would allocate the Path Segment as per the PATH- 655 SEGMENT flags and in case PATH-SEGMENT is not included, the PCE MUST 656 act based on the local policy. 658 The PCE would further inform the egress PCC about the Path Segment 659 allocated by the PCE using the PCInitiate message as described in 660 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 662 Ingress Egress 663 +-+-+ +-+-+ +-+-+ 664 |PCC| |PCE| |PCC| 665 +-+-+ +-+-+ +-+-+ 666 1) LSP State | ---- PCRpt ----> | | 667 Delegate | Delegate=1 | | 668 | P=1 |2) PCE update | 669 | | the LSP-DB and | 670 | | allocate Path SID | 671 |<---- PCUpd ---- |3)Paths update with | 672 | PATH-SEGMENT TLV | Path SID | 673 | | | 674 4) LSP State Report | ----- PCRpt ---> | | 675 | | | 676 |5) PCE informs the | --- PCInitiate ---> | 677 | Path SID to Egress| FEC=Path | 678 | | | 679 | | <-------- PCRpt --- | 680 | | | 682 Figure 8: Ingress PCC request Path Segment to PCE 684 6. Dataplane Considerations 686 As described in [I-D.ietf-spring-mpls-path-segment], in an SR-MPLS 687 network, when a packet is transmitted along an SR path, the labels in 688 the MPLS label stack will be swapped or popped. So that no label or 689 only the last label may be left in the MPLS label stack when the 690 packet reaches the egress node. Thus, the egress node cannot 691 determine from which SR path the packet comes. For this reason, it 692 introduces the Path Segment. 694 Apart from allocation and encoding of the Path Segment (described in 695 this document) for the LSP, it would also be included in the SID/ 696 Label stack of the LSP (usually for processing by the egress). To 697 support this, the Path Segment MAY also be a part of SR-ERO as 698 prepared by the PCE as per [RFC8664]. The PCC MAY also include the 699 Path Segment while preparing the label stack based on the local 700 policy and use-case. 702 It is important that the PCE learns the Maximum SID Depth (MSD) that 703 can be imposed at each node/link of a given SR path to ensure that 704 the SID stack depth does not exceed the number of SIDs the node is 705 capable of imposing. As a new type of segment, Path Segment will be 706 inserted in the SID list just like other SIDs. Thus, the PCE needs 707 to consider the affect of Path Segment when computing a LSP with Path 708 Segment allocation. 710 7. Implementation Status 712 [Note to the RFC Editor - remove this section before publication, as 713 well as remove the reference to [RFC7942]. 715 This section records the status of known implementations of the 716 protocol defined by this specification at the time of posting of this 717 Internet-Draft, and is based on a proposal described in [RFC7942]. 718 The description of implementations in this section is intended to 719 assist the IETF in its decision processes in progressing drafts to 720 RFCs. Please note that the listing of any individual implementation 721 here does not imply endorsement by the IETF. Furthermore, no effort 722 has been spent to verify the information presented here that was 723 supplied by IETF contributors. This is not intended as, and must not 724 be construed to be, a catalog of available implementations or their 725 features. Readers are advised to note that other implementations may 726 exist. 728 According to [RFC7942], "this will allow reviewers and working groups 729 to assign due consideration to documents that have the benefit of 730 running code, which may serve as evidence of valuable experimentation 731 and feedback that have made the implemented protocols more mature. 732 It is up to the individual working groups to use this information as 733 they see fit". 735 7.1. Huawei's Commercial Delivery 737 The feature is developing based on Huawei VRP8. 739 o Organization: Huawei 741 o Implementation: Huawei's Commercial Delivery implementation based 742 on VRP8. 744 o Description: The implementation is under development and follows 745 the mechanism as defined in section-5.1.1. 747 o Maturity Level: Product 749 o Contact: tanren@huawei.com 751 7.2. ZTE's Commercial Delivery 753 o Organization: ZTE 755 o Implementation: ZTE's Commercial Delivery implementation based on 756 Rosng v8. 758 o Description: The implementation is under development and follows 759 the mechanism as defined in section-5.1.1. 761 o Maturity Level: Product 763 o Contact: zhan.shuangping@zte.com.cn 765 8. IANA Considerations 767 8.1. SR PCE Capability Flags 769 SR PCE Capability TLV is defined in [RFC8664], and the registry to 770 manage the Flag field of the SR PCE Capability TLV is requested in 771 [RFC8664]. IANA is requested to make the following allocation in the 772 "SR Capability Flag Field" sub-registry. 774 Bit Description Reference 776 TBA1 Path Segment Allocation is supported(P) This document 778 8.2. New LSP Flag Registry 780 [RFC8231] defines the LSP object; per that RFC, IANA created a 781 registry to manage the value of the LSP object's Flag field. IANA 782 has allocated a new bit in the "LSP Object Flag Field" sub-registry, 783 as follows: 785 Bit Description Reference 787 TBA3 Request for Path Segment Allocation(P) This document 789 8.3. New PCEP TLV 791 IANA is requested to add the assignment of a new allocation in the 792 existing "PCEP TLV Type Indicators" sub-registry as follows: 794 Value Description Reference 796 TBA4 PATH-SEGMENT TLV This document 798 8.3.1. Path Segment TLV 800 This document requests that a new sub-registry named "PATH-SEGMENT 801 TLV Segment Type (ST) Field" to be created to manage the value of the 802 ST field in the PATH-SEGMENT TLV. 804 Value Description Reference 806 0 MPLS Path Segment(MPLS label) This document 807 1-255 Reserved for future use This document 809 Further, this document also requests that a new sub-registry named 810 "PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field 811 in the PATH-SEGMENT TLV. New values are assigned by Standards Action 812 [RFC8126]. Each bit should be tracked with the following qualities: 814 o Bit number (counting from bit 0 as the most significant bit) 816 o Capability description 818 o Defining RFC 820 Bit Description Reference 822 7 Local Signification(L) This document 824 8.4. New FEC Type Registry 826 A new PCEP object called FEC is defined in 827 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested 828 to allocate a new Object-Type for FEC object in the "PCEP Objects" 829 sub-registry. 831 Value Description Reference 833 TBA6 Path This document 835 8.5. PCEP Error Type and Value 837 IANA is requested to allocate code-points in the "PCEP-ERROR Object 838 Error Types and Values" sub-registry for the following new error- 839 types and error-values: 841 Error-Type Meaning Reference 843 TBA7 Path SID failure: This document 844 Error-value = 1 845 Invalid SID 847 Error-value = 2 848 Unable to allocate 849 Path SID 851 9. Security Considerations 853 The security considerations described in [RFC5440]], [RFC8231], 854 [RFC8281] and [RFC8664] are applicable to this specification. No 855 additional security measure is required. 857 As described [RFC8664] and 858 [I-D.ietf-pce-pcep-extension-for-pce-controller], SR allows a network 859 controller to instantiate and control paths in the network. A rogue 860 PCE can manipulate Path SID allocations to have impact based on the 861 usage of Path SID such as accounting, bi-directional etc. 863 Thus, as per [RFC8231], it is RECOMMENDED that these PCEP extensions 864 only be activated on authenticated and encrypted sessions across PCEs 865 and PCCs belonging to the same administrative authority, using 866 Transport Layer Security (TLS) [RFC8253], as per the recommendations 867 and best current practices in [RFC7525] (unless explicitly set aside 868 in [RFC8253]). 870 10. Manageability Considerations 872 All manageability requirements and considerations listed in 873 [RFC5440], [RFC8231], and [RFC8664] apply to PCEP protocol extensions 874 defined in this document. In addition, requirements and 875 considerations listed in this section apply. 877 10.1. Control of Function and Policy 879 A PCEP implementation SHOULD allow the operator to configure the 880 policy based on which it allocates the Path SID. This includes the 881 Path SID scope. 883 10.2. Information and Data Models 885 The PCEP YANG module is defined in [I-D.ietf-pce-pcep-yang]. In 886 future, this YANG module should be extended or augmented to provide 887 the following additional information relating to Path SID. 889 An implementation SHOULD allow the operator to view the Path SID 890 allocated to the LSP as well as Path SID as part of the computed SID 891 list for the SR path. 893 10.3. Liveness Detection and Monitoring 895 Mechanisms defined in this document do not imply any new liveness 896 detection and monitoring requirements in addition to those already 897 listed in [RFC5440]. 899 10.4. Verify Correct Operations 901 Mechanisms defined in this document do not imply any new operation 902 verification requirements in addition to those already listed in 903 [RFC5440], [RFC8231], and [RFC8664] . 905 10.5. Requirements On Other Protocols 907 Mechanisms defined in this document do not imply any new requirements 908 on other protocols. 910 10.6. Impact On Network Operations 912 Mechanisms defined in [RFC5440], [RFC8231], and [RFC8664] also apply 913 to PCEP extensions defined in this document. Further, the mechanism 914 described in this document can help the operator to request control 915 of the LSPs at a particular PCE. 917 11. Acknowledgments 919 Many thanks for Jeff Tantsura, Khasanov Boris, Aijun Wang,Loa 920 Andersson,Greg Mirsky,Shunwan Zhuang, Huanan Chen, Fengwei Qin, 921 Julien Meuric's professional comements. Best wishes to them and 922 their families in this special period. 924 12. References 926 12.1. Normative References 928 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 929 Requirement Levels", BCP 14, RFC 2119, 930 DOI 10.17487/RFC2119, March 1997, 931 . 933 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 934 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 935 DOI 10.17487/RFC5440, March 2009, 936 . 938 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 939 Writing an IANA Considerations Section in RFCs", BCP 26, 940 RFC 8126, DOI 10.17487/RFC8126, June 2017, 941 . 943 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 944 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 945 May 2017, . 947 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 948 Computation Element Communication Protocol (PCEP) 949 Extensions for Stateful PCE", RFC 8231, 950 DOI 10.17487/RFC8231, September 2017, 951 . 953 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 954 and D. Dhody, "Optimizations of Label Switched Path State 955 Synchronization Procedures for a Stateful PCE", RFC 8232, 956 DOI 10.17487/RFC8232, September 2017, 957 . 959 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 960 "PCEPS: Usage of TLS to Provide a Secure Transport for the 961 Path Computation Element Communication Protocol (PCEP)", 962 RFC 8253, DOI 10.17487/RFC8253, October 2017, 963 . 965 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 966 "Recommendations for Secure Use of Transport Layer 967 Security (TLS) and Datagram Transport Layer Security 968 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 969 2015, . 971 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 972 Computation Element Communication Protocol (PCEP) 973 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 974 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 975 . 977 [RFC8664] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 978 and J. Hardwick, "Path Computation Element Communication 979 Protocol (PCEP) Extensions for Segment Routing", RFC 8664, 980 DOI 10.17487/RFC8664, December 2019, 981 . 983 [I-D.ietf-pce-segment-routing-ipv6] 984 Li, C., Negi, M., Koldychev, M., Kaladharan, P., and Y. 985 Zhu, "PCEP Extensions for Segment Routing leveraging the 986 IPv6 data plane", draft-ietf-pce-segment-routing-ipv6-06 987 (work in progress), July 2020. 989 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 990 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 991 Procedures and Protocol Extensions for Using PCE as a 992 Central Controller (PCECC) of SR-LSPs", draft-zhao-pce- 993 pcep-extension-pce-controller-sr-08 (work in progress), 994 November 2020. 996 [I-D.ietf-pce-pcep-extension-for-pce-controller] 997 Li, Z., Peng, S., Negi, M., Zhao, Q., and C. Zhou, "PCEP 998 Procedures and Protocol Extensions for Using PCE as a 999 Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1000 extension-for-pce-controller-08 (work in progress), 1001 November 2020. 1003 [I-D.ietf-spring-mpls-path-segment] 1004 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 1005 "Path Segment in MPLS Based Segment Routing Network", 1006 draft-ietf-spring-mpls-path-segment-03 (work in progress), 1007 September 2020. 1009 12.2. Informative References 1011 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1012 Element (PCE)-Based Architecture", RFC 4655, 1013 DOI 10.17487/RFC4655, August 2006, 1014 . 1016 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1017 Element (PCE) Communication Protocol Generic 1018 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1019 2006, . 1021 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1022 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1023 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1024 July 2018, . 1026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1027 Code: The Implementation Status Section", BCP 205, 1028 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1029 . 1031 [I-D.li-pce-controlled-id-space] 1032 Li, C., Chen, M., Wang, A., Cheng, W., and C. Zhou, "PCE 1033 Controlled ID Space", draft-li-pce-controlled-id-space-07 1034 (work in progress), October 2020. 1036 [I-D.ietf-pce-pcep-yang] 1037 Dhody, D., Hardwick, J., Beeram, V., and J. Tantsura, "A 1038 YANG Data Model for Path Computation Element 1039 Communications Protocol (PCEP)", draft-ietf-pce-pcep- 1040 yang-15 (work in progress), October 2020. 1042 [I-D.li-spring-srv6-path-segment] 1043 Li, C., Cheng, W., Chen, M., Dhody, D., and R. Gandhi, 1044 "Path Segment for SRv6 (Segment Routing in IPv6)", draft- 1045 li-spring-srv6-path-segment-07 (work in progress), October 1046 2020. 1048 Appendix A. Contributors 1050 The following people have substantially contributed to this document: 1052 Dhruv Dhody 1053 Huawei Technologies 1054 Divyashree Techno Park, Whitefield 1055 Bangalore, Karnataka 560066 1056 India 1058 Email: dhruv.ietf@gmail.com 1060 Jie Dong 1061 Huawei Technologies 1062 Huawei Campus, No. 156 Beiqing Rd. 1063 Beijing 100095 1064 China 1066 Email: jie.dong@huawei.com 1068 Zhenbin Li 1069 Huawei Technologies 1070 Huawei Campus, No. 156 Beiqing Rd. 1071 Beijing 100095 1072 China 1074 Email: lizhenbin@huawei.com 1076 Zafar Ali 1077 Cisco Systems, Inc. 1079 Email: zali@cisco.com 1081 Appendix B. SRv6 extensions 1083 This section would be rolled into the document once the SPRING WG 1084 adopts SRv6 path segment. 1086 B.1. The SRv6 PCE Capability sub-TLV 1088 [I-D.ietf-pce-segment-routing-ipv6] defined a new Path Setup Type 1089 (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use 1090 this sub-TLV to exchange information about their SRv6 capability. 1091 The TLV includes a Flags field and one bit (L-flag) was allocated in 1092 [I-D.ietf-pce-segment-routing-ipv6]. 1094 This document adds an additional flag for Path Segment allocation, as 1095 follows - 1096 o P (Path Segment Identification bit): A PCEP speaker sets this flag 1097 to 1 to indicate that it has the capability to encode SRv6 path 1098 identification.(Path Segment, as per 1099 [I-D.li-spring-srv6-path-segment]). 1101 0 1 2 3 1102 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 1103 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1104 | Type=TBD1 | Length | 1105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1106 | Reserved | Flags |P|L| 1107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1108 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 1109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1110 // ... // 1111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1112 | MSD-Type | MSD-Value | Padding | 1113 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1115 Figure 9: P-flag in SRv6-PCE-CAPABILITY TLV 1117 The figure is included for the ease of the reader and can be removed 1118 at the time of publication. 1120 B.2. SRv6 PCE Capability Flags 1122 SRv6 PCE Capability TLV is defined in defined in 1123 [I-D.ietf-pce-segment-routing-ipv6], and the registry to manage the 1124 Flag field of the SRv6 PCE Capability Flags is requested in 1125 [I-D.ietf-pce-segment-routing-ipv6]. IANA is requested to make the 1126 following allocation in the aforementioned registry. 1128 Bit Description Reference 1130 TBA2 Path Segment Allocation is supported(P) This document 1132 B.3. Path Segment TLV 1134 A new assignment should be done to the "PATH-SEGMENT TLV Segment Type 1135 (ST) Field" sub-registry for SRv6. 1137 Value Description Reference 1139 1 SRv6 Path Segment (IPv6 addr) This document 1140 2-255 Reserved for future use This document 1142 Authors' Addresses 1144 Cheng Li 1145 Huawei Technologies 1146 Huawei Campus, No. 156 Beiqing Rd. 1147 Beijing 100095 1148 China 1150 Email: c.l@huawei.com 1152 Mach(Guoyi) Chen 1153 Huawei Technologies 1154 Huawei Campus, No. 156 Beiqing Rd. 1155 Beijing 100095 1156 China 1158 Email: Mach.chen@huawei.com 1160 Weiqiang Cheng 1161 China Mobile 1162 China 1164 Email: chengweiqiang@chinamobile.com 1166 Rakesh Gandhi 1167 Cisco Systems, Inc. 1168 Canada 1170 Email: rgandhi@cisco.com 1172 Quan Xiong 1173 ZTE Corporation 1174 China 1176 Email: xiong.quan@zte.com.cn