idnits 2.17.1 draft-li-pce-sr-path-segment-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 08, 2019) is 1869 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) == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-04 == Outdated reference: A later version (-14) exists of draft-ietf-pce-pcep-extension-for-pce-controller-01 == Outdated reference: A later version (-07) exists of draft-li-spring-srv6-path-segment-00 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-02 Summary: 0 errors (**), 0 flaws (~~), 5 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: September 9, 2019 W. Cheng 6 China Mobile 7 J. Dong 8 Z. Li 9 Huawei Technologies 10 R. Gandhi 11 Cisco Systems, Inc. 12 March 08, 2019 14 Path Computation Element Communication Protocol (PCEP) Extension for 15 Path Segment in Segment Routing (SR) 16 draft-li-pce-sr-path-segment-04 18 Abstract 20 The Path Computation Element (PCE) provides path computation 21 functions in support of traffic engineering in Multiprotocol Label 22 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 24 The Source Packet Routing in Networking (SPRING) architecture 25 describes how Segment Routing (SR) can be used to steer packets 26 through an IPv6 or MPLS network using the source routing paradigm. A 27 Segment Routed Path can be derived from a variety of mechanisms, 28 including an IGP Shortest Path Tree (SPT), explicit configuration, or 29 a Path Computation Element (PCE). 31 Path identification is needed for several use cases such as 32 performance measurement in Segment Routing (SR) network. This 33 document specifies extensions to the Path Computation Element 34 Protocol (PCEP) to support requesting, replying, reporting and 35 updating the Path Segment ID (Path SID) between PCEP 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 September 9, 2019. 54 Copyright Notice 56 Copyright (c) 2019 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. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 6 79 4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 6 80 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 7 81 4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7 82 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 9 83 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 84 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11 85 5.1. PCC Allocated Path Segment . . . . . . . . . . . . . . . 11 86 5.1.1. Egress PCC Allocated Path Segment . . . . . . . . . . 11 87 5.2. PCE Allocated Path Segment . . . . . . . . . . . . . . . 15 88 5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 15 89 5.2.2. Ingress PCC request Path Segment to PCE . . . . . . . 15 90 5.2.3. PCE allocated Path Segment on its own . . . . . . . . 17 91 6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 17 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 93 7.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 18 94 7.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18 95 7.3. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 18 96 7.4. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 19 97 7.4.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 19 98 7.5. New CCI Flag Registry . . . . . . . . . . . . . . . . . . 19 99 7.6. New FEC Type Registry . . . . . . . . . . . . . . . . . . 20 100 7.7. PCEP Error Type and Value . . . . . . . . . . . . . . . . 20 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 102 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 103 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 105 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 106 11.2. Informative References . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 109 1. Introduction 111 [RFC5440] describes the Path Computation Element (PCE) Communication 112 Protocol (PCEP). PCEP enables the communication between a Path 113 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 114 purpose of computation of Multiprotocol Label Switching (MPLS) as 115 well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched 116 Path (TE LSP) characteristics. 118 [RFC8231] specifies a set of extensions to PCEP to enable stateful 119 control of TE LSPs within and across PCEP sessions in compliance with 120 [RFC4657]. It includes mechanisms to effect LSP State 121 Synchronization between PCCs and PCEs, delegation of control over 122 LSPs to PCEs, and PCE control of timing and sequence of path 123 computations within and across PCEP sessions. The model of operation 124 where LSPs are initiated from the PCE is described in [RFC8281]. 126 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 127 procedures and PCEP protocol extensions for using the PCE as the 128 central controller for static LSPs, where LSPs can be provisioned as 129 explicit label instructions at each hop on the end-to-end path. 131 Segment routing (SR) [RFC8402] leverages the source routing and 132 tunneling paradigms and supports steering packets into an explicit 133 forwarding path at the ingress node. 135 An SR path needs to be identified in some use cases such as 136 performance measurement. For identifying an SR path, 137 [I-D.cheng-spring-mpls-path-segment] introduces a new segment that is 138 referred to as Path Segment. 140 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 141 Computation Element Protocol (PCEP) [RFC5440] for SR networks, that 142 allow a stateful PCE to compute and initiate SR-TE paths, as well as 143 a PCC to request, report or delegate SR paths. 145 [I-D.negi-pce-segment-routing-ipv6] extend PCEP to support SR paths 146 for IPv6 data plane. 148 [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the 149 procedures and PCEP protocol extensions when a PCE-based controller 150 is also responsible for configuring the forwarding actions on the 151 routers (SR SID distribution in this case), in addition to computing 152 the paths for packet flows in a segment routing network and telling 153 the edge routers what instructions to attach to packets as they enter 154 the network. 156 This document specifies a mechanism to carry the SR path 157 identification information in PCEP messages [RFC5440] [RFC8231] 158 [RFC8281]. The SR path identifier can be a Path Segment in SR-MPLS 159 [I-D.cheng-spring-mpls-path-segment], or a Path Segment in SRv6 160 [I-D.li-spring-srv6-path-segment] or other IDs that can identify an 161 SR path. This document also extends the PCECC-SR mechanism to inform 162 the Path Segment to the egress PCC. 164 2. Terminology 166 This memo makes use of the terms defined in [RFC4655], 167 [I-D.ietf-pce-segment-routing], and [RFC8402]. 169 2.1. Requirements Language 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 3. Overview of Path Segment Extensions in PCEP 179 This document specifies a mechanism of encoding (and allocating) Path 180 Segment in PCEP extensions. For supporting Path Segment in PCEP, 181 several TLVs and flags are defined. The formats of the objects and 182 TLVs are described in Section 4. The procedures of Path Segment 183 allocation are described in Section 5. 185 There are various modes of operations, such as - 187 o The Path Segment can be allocated by Egress PCC. The PCE should 188 request the Path Segment from Egress PCC. 190 o The PCE can allocate a Path Segment on its own accord and inform 191 the ingress/egress PCC, useful for PCE-initiated LSPs. 193 o Ingress PCC can also request PCE to allocate the Path Segment, in 194 this case, the PCE would either allocate and inform the assigned 195 Path Segment to the ingress/egress PCC using PCEP messages, or 196 first request egress PCC for Path Segment and then inform it to 197 the ingress PCC. 199 The path information to the ingress PCC and PCE is exchanged via an 200 extension to [I-D.ietf-pce-segment-routing] and 201 [I-D.negi-pce-segment-routing-ipv6]. The Path Segment information to 202 the egress PCC can be informed via an extension to the PCECC-SR 203 procedures [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 205 For the PCE to allocate a Path Segment, the PCE SHOULD be aware of 206 the MPLS label space from the PCCs. This is done via mechanism as 207 described in [I-D.li-pce-controlled-id-space]. Otherwise, the PCE 208 should request the egress PCC for Path Segment allocation. 210 4. Objects and TLVs 212 4.1. The OPEN Object 214 4.1.1. The SR PCE Capability sub-TLV 216 [I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST) 217 and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers use this sub-TLV 218 to exchange information about their SR capability. The TLV defines a 219 Flags field that includes one bit (L-flag) to indicate Local 220 Significance [I-D.ietf-pce-segment-routing]. 222 This document adds an additional flag for Path Segment allocation, as 223 follows - 225 P (Path Segment Identification bit): A PCEP speaker sets this flag 226 to 1 to indicate that it has the capability to encode SR path 227 identification (Path Segment, as per 228 [I-D.cheng-spring-mpls-path-segment]). 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | Type=TBD11 | Length=4 | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Reserved | Flags |P|N|X| MSD | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 Figure 1: P-flag in SR-PCE-CAPABILITY TLV 240 The figure is included for the ease of the reader and can be removed 241 at the time of publication. 243 4.1.2. The SRv6 PCE Capability sub-TLV 245 [I-D.negi-pce-segment-routing-ipv6] defined a new Path Setup Type 246 (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use 247 this sub-TLV to exchange information about their SRv6 capability. 248 The TLV includes a Flags field and one bit (L-flag) was allocated in 249 [I-D.negi-pce-segment-routing-ipv6]. 251 This document adds an additional flag for Path Segment allocation, as 252 follows - 254 P (Path Segment Identification bit): A PCEP speaker sets this flag 255 to 1 to indicate that it has the capability to encode SRv6 path 256 identification.(Path Segment, as per 257 [I-D.li-spring-srv6-path-segment]). 259 0 1 2 3 260 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 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Type=TBD1 | Length | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Reserved | Flags |P|L| 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 // ... // 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 | MSD-Type | MSD-Value | Padding | 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 Figure 2: P-flag in SRv6-PCE-CAPABILITY TLV 275 The figure is included for the ease of the reader and can be removed 276 at the time of publication. 278 4.1.3. PCECC-CAPABILITY sub-TLV 280 Along with the SR sub-TLVs, the PCECC Capability as per 281 [I-D.zhao-pce-pcep-extension-pce-controller-sr] should be advertised 282 if the PCE allocates the Path Segment and acts as a Central 283 Controller that manages the Label space. 285 The PCECC Capability should also be advertised on the egress PCEP 286 session, along with the SR sub-TLVs. This is needed to ensure that 287 the PCE can use the PCECC objects/mechanism to request/inform the 288 egress PCC of the Path Segment as described in this document. 290 4.2. LSP Object 292 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 293 adds the following flags to the LSP Object: 295 P (PCE Allocation bit): If the bit is set to 1, it indicates that 296 the PCC requests PCE to allocate resource for this LSP. With the 297 resource TLV, a PCE can undertsand what kind of resource should be 298 allocated, such as Path Segment and Binding Segment. A PCC would 299 set this bit to 1 and include a PATH-SEGMENT TLV in the LSP object 300 to request for allocation of Path Segment by the PCE in the PCReq 301 or PCRpt message. A PCE would also set this bit to 1 and include 302 a PATH-SEGMENT TLV to indicate that the Path Segment is allocated 303 by PCE and encoded in the PCRep, PCUpd or PCInitiate message. 304 Further, a PCE would set this bit to 0 and include a PATH-SEGMENT 305 TLV in the LSP object to indicate that the Path Segment should be 306 allocated by the PCC as described in Section 5.1.1. 308 0 1 2 3 309 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 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | PLSP-ID | Flag|P|C| O |A|R|S|D| 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 // TLVs // 314 | | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Figure 3: P-flag in LSP Object 319 The figure is included for the ease of the reader and can be removed 320 at the time of publication. 322 4.2.1. Path Segment TLV 324 The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object for 325 Path Segment allocation. The type of this TLV is to be allocated by 326 IANA (TBA4). The format is shown below. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | ST | Flag |L| Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 ~ (Variable length) Path Segment ~ 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 4: The PATH-SEGMENT TLV Format 340 The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The 341 length (16-bit) has a fixed value of 8 octets. The value contains 342 the following fields: 344 ST (The Segment type - 8 bits): The ST field specifies the type of 345 the Path Segment field, which carries a Path Segment corresponding 346 to the SR path. 348 * 0: MPLS Path Segment, which is an MPLS label as defined in 349 [I-D.cheng-spring-mpls-path-segment]. The PST type MUST be set 350 to SR (MPLS). 352 * 1: SRv6 Path Segment, which is a 128 bit IPv6 address as 353 defined in [I-D.li-spring-srv6-path-segment]. The PST type 354 MUST be set to SRv6. 356 Flags (8 bits): Two flags are currently defined: 358 * L-Bit (Local/Global - 1 bit): If set, then the Path Segment 359 carried by the PATH-SEGMENT TLV has local significance. If not 360 set, then the Path Segment carried by this TLV has global 361 significance (i.e. Path Segment is global within an SR 362 domain). 364 * The unassigned bits MUST be set to 0 and MUST be ignored at 365 receipt. 367 Reserved (16 bits): MUST be set to 0 and MUST be ignored at 368 receipt. 370 Path Segment: The Path Segment of an SR path. The Path Segment 371 type is indicated by the ST field. When the ST is 0, it is a MPLS 372 Path Segment [I-D.cheng-spring-mpls-path-segment] in the MPLS 373 label format. When the ST field is 1, it is a 128-bit SRv6 Path 374 Segment as defined in [I-D.li-spring-srv6-path-segment]. 376 In general, only one instance of PATH-SEGMENT TLV will be included in 377 LSP object. If more than one PATH-SEGMENT TLV is included, the first 378 one is processed and others MUST be ignored. Multiple Path Segment 379 allocation for use cases like alternate-making will be considered in 380 future version of this draft. 382 When the Path Segment allocation is enable, a PATH-SEGMENT TLV MUST 383 be included in the LSP object. 385 If the label space is maintained by PCC itself, and the Path Segment 386 is allocated by Egress PCC, then the PCE should request the Path 387 Segment from Egress PCC as described in Section 5.1.1. In this case, 388 the PCE should send a PCUpdate or PCInitiate message to the egress 389 PCC to request the Path Segment. The P-flag in LSP should be unset 390 in this case. 392 If a PCEP node does not recognize the PATH-SEGMENT TLV, it would 393 behave in accordance with [RFC5440] and ignore the TLV. If a PCEP 394 node recognizes the TLV but does not support the TLV, it MUST send 395 PCErr with Error-Type = 2 (Capability not supported). 397 4.3. FEC Object 399 The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is 400 used to specify the FEC information and MAY be carried within 401 PCInitiate or PCRpt message for the PCECC-SR operations. The PCE 402 MUST inform the Path Identification information to the Egress PCC. 403 To do this, this document extends the procedures of 404 [I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC 405 object type for Path. 407 FEC Object-Type is TBA6 'Path'. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 // TLV(s) // 414 | | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 Figure 5: The path FEC object Format 419 One or more following TLV(s) are allowed in the 'path' FEC object - 421 o SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human- 422 readable string that identifies an LSP in the network. 424 o LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for 425 SR, but could be used to encode the source, destination and other 426 identification information for the path. 428 o SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique 429 identifier for the PCEP speaker, it is used to identify the 430 Ingress PCC. 432 Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be 433 included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of 434 each TLV is processed, if more than one TLV of each type is included, 435 the first one is processed and others MUST be ignored. 437 4.4. CCI Object 439 The Central Control Instructions (CCI) Object is used by the PCE to 440 specify the forwarding instructions is defined in 441 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further 442 [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object 443 type for SR. 445 The Path Segment information is encoded directly in the CCI SR 446 object. The Path Segment TLV as described in the Section 4.2.1, MUST 447 also be included in the CCI SR object as the TLV (as it includes 448 additional information regarding the Path Segment identifier). 450 This document adds the following flags to the CCI Object: 452 o C (PCC Allocation bit): If the bit is set to 1, it indicates that 453 the allocation needs to be done by the PCC for this central 454 controller instruction. A PCE set this bit to request the PCC to 455 make an allocation from its SR label space. A PCC would set this 456 bit to indicate that it has allocated the CC-ID and report it to 457 the PCE. 459 0 1 2 3 460 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 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 462 | CC-ID | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | MT-ID | Algorithm | Flags |C|N|E|V|L|O| 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 // SID/Label/Index (variable) // 467 +---------------------------------------------------------------+ 468 | | 469 // Optional TLV // 470 | | 471 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 Figure 6: The CCI object for SR 475 (Editor's Note - An update is planned for 476 [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision 477 detailing this procedure, and the above text might move there.) 479 5. Operations 481 The Path Segment allocation and encoding is as per the stateful PCE 482 operations for segment routing. The procedures are as per the 483 corresponding extensions defined in [I-D.ietf-pce-segment-routing] 484 and [I-D.negi-pce-segment-routing-ipv6] (which are further based on 485 [RFC8231] and [RFC8281]). The additional operations for Path Segment 486 are defined in this section. 488 To notify (or request) the Path Segment to the Egress PCC, the 489 procedures are as per the PCECC-SR 490 [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which is based on 491 [I-D.ietf-pce-pcep-extension-for-pce-controller]). The additional 492 operations are defined in this section. 494 5.1. PCC Allocated Path Segment 496 5.1.1. Egress PCC Allocated Path Segment 498 As defined in [I-D.cheng-spring-mpls-path-segment], a Path Segment 499 can be allocated by the egress PCC. In this case, the label space 500 may be maintained on the PCC itself. 502 On receiving a stateful path computation request with Path Segment 503 allocation request from an ingress PCC, or by initiating or updating 504 an LSP with Path Segment actively, a PCE can request the egress PCC 505 to allocate a Path Segment. This is needed if the PCE does not 506 control the Path Segment allocation for the egress PCC or the label 507 space is maintained by the egress PCC itself. 509 The mechanism of Path Segment request and reply may be achieved by 510 using PCInitiate and PCUpd message as described in this section. 512 5.1.1.1. Using CCI and FEC objects (PCECC) 514 The PCE can request the egress to allocate the Path Segment using the 515 PCInitiate message as described in 516 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The C flag in the 517 CCI object is set to 1 and the CC-ID is set to a special value of 518 0x0000 to indicate that the allocation needs to be done by the PCC. 519 The PATH-SEGMENT TLV is also be included in CCI object along with the 520 FEC object identifying the SR-Path. The egress PCC would allocate 521 the Path Segment and would report to the PCE using the PCRpt message 522 as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr] with 523 the allocated Path Segment in the CC-ID field as well as in the PATH- 524 SEGMENT TLV. 526 (Editor's Note - An update is planned for 527 [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision 528 detailing this procedure) 530 If the value of CC-ID/Path Segment is 0 and the C flag is set, it 531 indicates that the PCE is requesting a Path Segment for this LSP. If 532 the CC-ID/Path Segment is set to a value 'n' and the C flag is set in 533 the CCI object, it indicates that the PCE requests a specific value 534 'n' of Path Segment. If the Path Segment is allocated successfully, 535 the egress PCC should report the Path Segment via PCRpt message with 536 the CCI object along with the PATH-SEGMENT TLV. Else, it MUST send a 537 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 538 Value = 1 ("Invalid SID"). If the value of Path Segment in CCI 539 object is valid, but the PCC is unable to allocate the Path Segment, 540 it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID 541 failure") and Error Value = 2 ("Unable to allocate the specified 542 label/SID"). 544 Once the PCE receives the PCRpt message with the CCI object, it can 545 obtain the Path Segment information from the egress PCC and then 546 update the path with Path Segment or reply to the ingress PCC, the 547 path information with Path Segment. 549 If the SR-Path is setup the ingress PCC will acknowledge with a PCRpt 550 message to the PCE. In case of error, as described in 551 [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to 552 the PCE. The PCE MUST request the withdraw of the Path Segment 553 allocation by sending a PCInitiate message to remove the central 554 controller instruction as per 555 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. When the LSP is 556 deleted or the Path Segment is removed, the PCE should synchronize 557 with the egress PCC. 559 If the egress PCC wishes to withdraw or modify a previously reported 560 Path Segment value, it MUST send a PCRpt message without any PATH- 561 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 562 Segment respectively in the CCI object. The PCE would further 563 trigger the removal of the central controller instruction as per 564 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 566 If a PCE wishes to modify a previously requested Path Segment value, 567 it MUST send a new PCInitiate message with an allocation request CC- 568 ID/PATH-SEGMENT TLV containing the new Path Segment value and C flag 569 is set. The PCE should trigger the removal of the older Path Segment 570 next as per [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 572 Ingress Egress 573 +-+-+ +-+-+ +-+-+ 574 |PCC| |PCE| |PCC| 575 +-+-+ +-+-+ +-+-+ 576 1) LSP State | ---- PCRpt ----> | | 577 Delegate | Delegate=1 | | 578 | P=1 |2) PCE update | 579 | | the LSP-DB and | 580 | | request Path SID | 581 | | | 582 | | --- PCInitiate ---> | Egress 583 | | CC-ID=0 | allocates 584 | | FEC=Path | a Path-SID 585 | | | from its 586 | | <----- PCRpt ------ | space 587 | | CC-ID= | 588 | | Path SID | 589 | | | 590 |<---- PCUpd ---- |3)Paths update with | 591 | PATH-SEGMENT TLV | Path SID | 592 | | | 593 4) LSP State | ----- PCRpt ---> | | 594 Report | | | 595 | | | 597 Figure 7: Egress PCC Allocated Path Segment 599 5.1.1.2. Using LSP objects (PCEP-SR) 601 The PATH-SEGMENT TLV MUST be included in an LSP object in the 602 PCInitiate message sent from the PCE to the egress to request path 603 identification allocation by the egress PCC. The P flag in LSP 604 object MUST be set to 0. This PCInitiate message to egress PCC would 605 be the similar to the one sent to ingress PCC as per 606 [I-D.ietf-pce-segment-routing], but the egress PCC would only 607 allocate the Path Segment and would not trigger the initiation/update 608 operation. 610 If the value of Path Segment is 0x0 it indicates that the PCE is 611 requesting a Path Segment for this LSP. If the Path Segment is set 612 to a value 'n' and the P flag is unset in the LSP object, it 613 indicates that the PCE requests a specific value 'n' of Path Segment. 614 If the Path Segment is allocated successfully, the egress PCC should 615 report the Path Segment via PCRpt message with PATH-SEGMENT TLV in 616 LSP object. Else, it MUST send a PCErr message with Error-Type = 617 TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If 618 the value of Path Segment is valid, but the PCC is unable to allocate 619 the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 620 ("Path label/SID failure") and Error Value = 2 ("Unable to allocate 621 the specified label/SID"). 623 Once the PCE receives the PCRpt message, it can obtain the Path 624 Segment information from the egress PCC and then update the path with 625 Path Segment or reply to the ingress PCC, the path information with 626 Path Segment. 628 If the SR-Path is setup, the ingress PCC will acknowledge with a 629 PCRpt message to the PCE. In case of error, as described in 630 [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to 631 the PCE. The PCE MUST request the withdraw of the Path Segment 632 allocation by sending a PCUpd message to remove the LSP and 633 associated Path Segment by setting the R flag in the SRP object. 634 When the LSP is deleted or the Path Segment is removed, the PCE 635 should send a PCUpd message to synchronize with the egress PCC. 637 If the egress PCC wishes to withdraw or modify a previously reported 638 Path Segment value, it MUST send a PCRpt message without any PATH- 639 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 640 Segment respectively. 642 If a PCE wishes to modify a previously requested Path Segment value, 643 it MUST send a PCUpd message with PATH-SEGMENT TLV containing the new 644 Path Segment value and P flag is LSP object would be unset. Absence 645 of the PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to 646 withdraw the Path Segment. 648 If a PCC receives a valid Path Segment value from a PCE which is 649 different than the current Path Segment, it MUST try to allocate the 650 new value. If the new Path Segment is successfully allocated, the 651 PCC MUST report the new value to the PCE. Otherwise, it MUST send a 652 PCErr message with Error-Type = TBA7 ("Path label/SID failure") and 653 Error Value = 2 ("Unable to allocate the specified label/SID"). 655 Ingress Egress 656 +-+-+ +-+-+ +-+-+ 657 |PCC| |PCE| |PCC| 658 +-+-+ +-+-+ +-+-+ 659 1) LSP State | ---- PCRpt ----> | | 660 Delegate | Delegate=1 | | 661 | P=1 |2) PCE update | 662 | | the LSP-DB and | 663 | | request Path SID | 664 | | | 665 | | --- PCInitiate ---> | Egress 666 | | PATH-SEGMENT | allocates 667 | | TLV in LSP | a Path-SID 668 | | | from its 669 | | <----- PCRpt ------ | space 670 | | Path SID | 671 | | | 672 |<---- PCUpd ---- |3)Paths update with | 673 | PATH-SEGMENT TLV | Path SID | 674 | | | 675 4) LSP State | ----- PCRpt ---> | | 676 Report | | | 677 | | | 679 Figure 8: Egress PCC Allocated Path Segment 681 5.2. PCE Allocated Path Segment 683 5.2.1. PCE Controlled Label Spaces Advertisement 685 For allocating the Path Segments to SR paths by the PCEs, the PCE 686 controlled label space MUST be known at PCEs via configurations or 687 any other mechanism. The PCE controlled label spaces MAY be 688 advertised as described in [I-D.li-pce-controlled-id-space]. 690 5.2.2. Ingress PCC request Path Segment to PCE 692 The ingress PCC could request the Path Segment to be allocated by the 693 PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) 694 MUST also be set for this LSP. Also, the P-flag in the LSP object 695 MUST be set. 697 A PATH-SEGMENT TLV MUST be included in the LSP object. If the value 698 of Path Segment is 0x0, it indicates that the Ingress PCC is 699 requesting a Path Segment for this LSP. If the Path Segment is set 700 to a value 'n', it indicates that the ingress PCC requests a specific 701 value 'n' of Path Segment. 703 If the Path Segment is allocated successfully, the PCE would further 704 respond to Ingress PCC with PCUpd message as per [RFC8231] and MUST 705 include the PATH-SEGMENT TLV in a LSP object. Else, it MUST send a 706 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 707 Value = 1 ("Invalid SID"). If the value of Path Segment is valid, 708 but the PCC is unable to allocate the Path Segment, it MUST send a 709 PCErr message with Error-Type = TBA7 ("Path label/SID failure") and 710 Error Value = 2 ("Unable to allocate the specified label/SID"). 712 The active PCE would allocate the Path Segment as per the PATH- 713 SEGMENT flags and in case PATH-SEGMENT is not included, the PCE MUST 714 act based on the local policy. 716 The PCE would further inform the egress PCC about the Path Segment 717 allocated by the PCE using the PCInitiate message as described in 718 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 720 Ingress Egress 721 +-+-+ +-+-+ +-+-+ 722 |PCC| |PCE| |PCC| 723 +-+-+ +-+-+ +-+-+ 724 1) LSP State | ---- PCRpt ----> | | 725 Delegate | Delegate=1 | | 726 | P=1 |2) PCE update | 727 | | the LSP-DB and | 728 | | allocate Path SID | 729 |<---- PCUpd ---- |3)Paths update with | 730 | PATH-SEGMENT TLV | Path SID | 731 | | | 732 4) LSP State Report | ----- PCRpt ---> | | 733 | | | 734 |5) PCE informs the | --- PCInitiate ---> | 735 | Path SID to Egress| FEC=Path | 736 | | | 737 | | <-------- PCRpt --- | 738 | | | 740 Figure 9: Ingress PCC request Path Segment to PCE 742 5.2.3. PCE allocated Path Segment on its own 744 The PCE could allocate the Path Segment on its own for a PCE- 745 Initiated (or delegated LSP). The allocated Path Segment needs to be 746 informed to the Ingress and Egress PCC. The PCE would use the 747 PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the 748 Ingress PCC and MUST include the PATH-SEGMENT TLV in the LSP object. 749 The PCE would further inform the egress PCC about the Path Segment 750 allocated by the PCE using the PCInitiate message as described in 751 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 753 Ingress Egress 754 +-+-+ +-+-+ +-+-+ 755 |PCC| |PCE| |PCC| 756 +-+-+ +-+-+ +-+-+ 757 | | | 758 | <--PCInitiate--- |1)Initiate LSP with | 759 | PATH-SEGMENT TLV | Path SID | 760 | | | 761 2)LSP delegation |---PCRpt, D=1---> | (Confirm) | 762 | | | 763 |3) PCE informs the | --- PCInitiate ---> | 764 | Path SID to Egress| FEC=Path | 765 | | | 766 | | <-------- PCRpt --- | 767 | | | 769 Figure 10: PCE allocated Path Segment on its own 771 6. Dataplane Considerations 773 As described in [I-D.cheng-spring-mpls-path-segment], in an SR-MPLS 774 network, when a packet is transmitted along an SR path, the labels in 775 the MPLS label stack will be swapped or popped. So that no label or 776 only the last label may be left in the MPLS label stack when the 777 packet reaches the egress node. Thus, the egress node cannot 778 determine from which SR path the packet comes. For this reason, it 779 introduces the Path Segment. 781 Apart from allocation and encoding of the Path Segment (described in 782 this document) for the LSP, it would also be included in the SID/ 783 Label stack of the LSP (usually for processing by the egress). To 784 support this, the Path Segment MAY also be a part of SR-ERO as 785 prepared by the PCE as per [I-D.ietf-pce-segment-routing]. The PCC 786 MAY also include the Path Segment while preparing the label stack 787 based on the local policy and use-case. 789 It is important that the PCE learns the Maximum SID Depth (MSD) that 790 can be imposed at each node/link of a given SR path to ensure that 791 the SID stack depth does not exceed the number of SIDs the node is 792 capable of imposing. As a new type of segment, Path Segment will be 793 inserted in the SID list just like other SIDs. Thus, the PCE needs 794 to consider the affect of Path Segment when computing a LSP with Path 795 Segment allocation. 797 7. IANA Considerations 799 7.1. SR PCE Capability Flags 801 SR PCE Capability TLV is defined in [I-D.ietf-pce-segment-routing], 802 and the registry to manage the Flag field of the SR PCE Capability 803 TLV is requested in [I-D.ietf-pce-segment-routing]. IANA is 804 requested to make the following allocation in the aforementioned 805 registry. 807 Bit Description Reference 809 TBA1 Path Segment Allocation is supported(P) This document 811 7.2. SRv6 PCE Capability Flags 813 SRv6 PCE Capability TLV is defined in defined in 814 [I-D.negi-pce-segment-routing-ipv6], and the registry to manage the 815 Flag field of the SRv6 PCE Capability Flags is requested in 816 [I-D.negi-pce-segment-routing-ipv6]. IANA is requested to make the 817 following allocation in the aforementioned registry. 819 Bit Description Reference 821 TBA2 Path Segment Allocation is supported(P) This document 823 7.3. New LSP Flag Registry 825 [RFC8231] defines the LSP object; per that RFC, IANA created a 826 registry to manage the value of the LSP object's Flag field. IANA 827 has allocated a new bit in the "LSP Object Flag Field" subregistry, 828 as follows: 830 Bit Description Reference 832 TBA3 Request for Path Segment Allocation(P) This document 834 7.4. New PCEP TLV 836 IANA is requested to add the assignment of a new allocation in the 837 existing "PCEP TLV Type Indicators" subregistry as follows: 839 Value Description Reference 841 TBA4 PATH-SEGMENT TLV This document 843 7.4.1. Path Segment TLV 845 This document requests that a new subregistry named "PATH-SEGMENT TLV 846 Segment Type (ST) Field" to be created to manage the value of the ST 847 field in the PATH-SEGMENT TLV. 849 Value Description Reference 851 0 MPLS Path Segment(MPLS label) This document 852 1 SRv6 Path Segment(IPv6 address) This document 854 Further, this document also requests that a new subregistry named 855 "PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field 856 in the PATH-SEGMENT TLV. New values are assigned by Standards Action 857 [RFC8126]. Each bit should be tracked with the following qualities: 859 o Bit number (counting from bit 0 as the most significant bit) 861 o Capability description 863 o Defining RFC 865 Bit Description Reference 867 7 Local Signification(L) This document 869 7.5. New CCI Flag Registry 871 CCI object is defined in defined in 872 [I-D.ietf-pce-pcep-extension-for-pce-controller], further 873 [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object 874 type for SR. and the subregistry to manage the Flag field of the CCI 875 object for SR is requested in 876 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested 877 to make the following allocation in the aforementioned subregistry. 879 Bit Description Reference 881 TBA5 PCC is requested to This document 882 allocate resource(C) 884 7.6. New FEC Type Registry 886 A new PCEP object called FEC is defined in 887 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested 888 to allocate a new Object-Type for FEC object in the "PCEP Objects" 889 subregistry. 891 Value Description Reference 893 TBA6 SR path This document 895 7.7. PCEP Error Type and Value 897 IANA is requested to allocate code-points in the "PCEP-ERROR Object 898 Error Types and Values" subregistry for the following new error-types 899 and error-values: 901 Error-Type Meaning Reference 903 TBA7 Path SID failure: This document 904 Error-value = 1 905 Invalid SID 907 Error-value = 2 908 Unable to allocate 909 Path SID 911 8. Security Considerations 913 TBA 915 9. Acknowledgments 917 10. Contributors 919 The following people have substantially contributed to this document: 921 Dhruv Dhody 922 Huawei Technologies 923 Divyashree Techno Park, Whitefield 924 Bangalore, Karnataka 560066 925 India 927 Email: dhruv.ietf@gmail.com 929 Quan Xiong 930 ZTE Corporation 931 No.6 Huashi Park Rd 932 Wuhan, Hubei 430223 933 China 935 Email: xiong.quan@zte.com.cn 937 Zafar Ali 938 Cisco Systems, Inc. 940 Email: zali@cisco.com 942 11. References 944 11.1. Normative References 946 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 947 Requirement Levels", BCP 14, RFC 2119, 948 DOI 10.17487/RFC2119, March 1997, 949 . 951 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 952 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 953 DOI 10.17487/RFC5440, March 2009, 954 . 956 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 957 Writing an IANA Considerations Section in RFCs", BCP 26, 958 RFC 8126, DOI 10.17487/RFC8126, June 2017, 959 . 961 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 962 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 963 May 2017, . 965 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 966 Computation Element Communication Protocol (PCEP) 967 Extensions for Stateful PCE", RFC 8231, 968 DOI 10.17487/RFC8231, September 2017, 969 . 971 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 972 and D. Dhody, "Optimizations of Label Switched Path State 973 Synchronization Procedures for a Stateful PCE", RFC 8232, 974 DOI 10.17487/RFC8232, September 2017, 975 . 977 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 978 Computation Element Communication Protocol (PCEP) 979 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 980 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 981 . 983 [I-D.ietf-pce-segment-routing] 984 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 985 and J. Hardwick, "PCEP Extensions for Segment Routing", 986 draft-ietf-pce-segment-routing-16 (work in progress), 987 March 2019. 989 [I-D.negi-pce-segment-routing-ipv6] 990 Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP 991 Extensions for Segment Routing leveraging the IPv6 data 992 plane", draft-negi-pce-segment-routing-ipv6-04 (work in 993 progress), February 2019. 995 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 996 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 997 and Protocol Extensions for Using PCE as a Central 998 Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- 999 extension-pce-controller-sr-04 (work in progress), 1000 February 2019. 1002 [I-D.ietf-pce-pcep-extension-for-pce-controller] 1003 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 1004 and Protocol Extensions for Using PCE as a Central 1005 Controller (PCECC) of LSPs", draft-ietf-pce-pcep- 1006 extension-for-pce-controller-01 (work in progress), 1007 February 2019. 1009 [I-D.li-spring-srv6-path-segment] 1010 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 1011 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 1012 draft-li-spring-srv6-path-segment-00 (work in progress), 1013 October 2018. 1015 11.2. Informative References 1017 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1018 Element (PCE)-Based Architecture", RFC 4655, 1019 DOI 10.17487/RFC4655, August 2006, 1020 . 1022 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1023 Element (PCE) Communication Protocol Generic 1024 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1025 2006, . 1027 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1028 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1029 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1030 July 2018, . 1032 [I-D.li-pce-controlled-id-space] 1033 Li, C., Chen, M., Dong, J., Li, Z., Wang, A., and C. Zhou, 1034 "PCE Controlled ID Space", draft-li-pce-controlled-id- 1035 space-02 (work in progress), March 2019. 1037 [I-D.cheng-spring-mpls-path-segment] 1038 Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler, 1039 R., and S. Zhan, "Path Segment in MPLS Based Segment 1040 Routing Network", draft-cheng-spring-mpls-path-segment-03 1041 (work in progress), October 2018. 1043 Authors' Addresses 1045 Cheng Li 1046 Huawei Technologies 1047 Huawei Campus, No. 156 Beiqing Rd. 1048 Beijing 100095 1049 China 1051 Email: chengli13@huawei.com 1052 Mach(Guoyi) Chen 1053 Huawei Technologies 1054 Huawei Campus, No. 156 Beiqing Rd. 1055 Beijing 100095 1056 China 1058 Email: Mach.chen@huawei.com 1060 Weiqiang Cheng 1061 China Mobile 1062 China 1064 Email: chengweiqiang@chinamobile.com 1066 Jie Dong 1067 Huawei Technologies 1068 Huawei Campus, No. 156 Beiqing Rd. 1069 Beijing 100095 1070 China 1072 Email: jie.dong@huawei.com 1074 Zhenbin Li 1075 Huawei Technologies 1076 Huawei Campus, No. 156 Beiqing Rd. 1077 Beijing 100095 1078 China 1080 Email: lizhenbin@huawei.com 1082 Rakesh Gandhi 1083 Cisco Systems, Inc. 1084 Canada 1086 Email: rgandhi@cisco.com