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