idnits 2.17.1 draft-li-pce-sr-path-segment-05.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 23, 2019) is 1859 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 (-25) exists of draft-ietf-pce-segment-routing-ipv6-00 == 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 == Outdated reference: A later version (-22) exists of draft-ietf-spring-mpls-path-segment-00 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group C. Li 3 Internet-Draft M. Chen 4 Intended status: Standards Track Huawei Technologies 5 Expires: September 24, 2019 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 March 23, 2019 16 Path Computation Element Communication Protocol (PCEP) Extension for 17 Path Segment in Segment Routing (SR) 18 draft-li-pce-sr-path-segment-05 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 Protocol (PCEP) to support requesting, replying, reporting and 37 updating the Path Segment ID (Path SID) between PCEP speakers. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on September 24, 2019. 56 Copyright Notice 58 Copyright (c) 2019 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 76 3. Overview of Path Segment Extensions in PCEP . . . . . . . . . 4 77 4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5 78 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 5 79 4.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 5 80 4.1.2. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 6 81 4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 6 82 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7 84 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 9 85 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 86 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11 87 5.1. PCC Allocated Path Segment . . . . . . . . . . . . . . . 11 88 5.1.1. Egress PCC Allocated Path Segment . . . . . . . . . . 11 89 5.2. PCE Allocated Path Segment . . . . . . . . . . . . . . . 15 90 5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 15 91 5.2.2. Ingress PCC request Path Segment to PCE . . . . . . . 15 92 5.2.3. PCE allocated Path Segment on its own . . . . . . . . 17 93 6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 17 94 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 95 7.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 18 96 7.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18 97 7.3. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 18 98 7.4. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 19 99 7.4.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 19 100 7.5. New CCI Flag Registry . . . . . . . . . . . . . . . . . . 19 101 7.6. New FEC Type Registry . . . . . . . . . . . . . . . . . . 20 102 7.7. PCEP Error Type and Value . . . . . . . . . . . . . . . . 20 103 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 104 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 105 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 108 11.2. Informative References . . . . . . . . . . . . . . . . . 22 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 111 1. Introduction 113 [RFC5440] describes the Path Computation Element (PCE) Communication 114 Protocol (PCEP). PCEP enables the communication between a Path 115 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 116 purpose of computation of Multiprotocol Label Switching (MPLS) as 117 well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched 118 Path (TE LSP) characteristics. 120 [RFC8231] specifies a set of extensions to PCEP to enable stateful 121 control of TE LSPs within and across PCEP sessions in compliance with 122 [RFC4657]. It includes mechanisms to effect LSP State 123 Synchronization between PCCs and PCEs, delegation of control over 124 LSPs to PCEs, and PCE control of timing and sequence of path 125 computations within and across PCEP sessions. The model of operation 126 where LSPs are initiated from the PCE is described in [RFC8281]. 128 [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the 129 procedures and PCEP protocol extensions for using the PCE as the 130 central controller for static LSPs, where LSPs can be provisioned as 131 explicit label instructions at each hop on the end-to-end path. 133 Segment routing (SR) [RFC8402] leverages the source routing and 134 tunneling paradigms and supports steering packets into an explicit 135 forwarding path at the ingress node. 137 An SR path needs to be identified in some use cases such as 138 performance measurement. For identifying an SR path, 139 [I-D.ietf-spring-mpls-path-segment] introduces a new segment that is 140 referred to as Path Segment. 142 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 143 Computation Element Protocol (PCEP) [RFC5440] for SR networks, that 144 allow a stateful PCE to compute and initiate SR-TE paths, as well as 145 a PCC to request, report or delegate SR paths. 146 [I-D.ietf-pce-segment-routing-ipv6] extend PCEP to support SR paths 147 for IPv6 data plane. 149 [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the 150 procedures and PCEP protocol extensions when a PCE-based controller 151 is also responsible for configuring the forwarding actions on the 152 routers (SR SID distribution in this case), in addition to computing 153 the paths for packet flows in a segment routing network and telling 154 the edge routers what instructions to attach to packets as they enter 155 the network. 157 This document specifies a mechanism to carry the SR path 158 identification information in PCEP messages [RFC5440] [RFC8231] 159 [RFC8281]. The SR path identifier can be a Path Segment in SR-MPLS 160 [I-D.ietf-spring-mpls-path-segment], or a Path Segment in SRv6 161 [I-D.li-spring-srv6-path-segment] or other IDs that can identify an 162 SR path. This document also extends the PCECC-SR mechanism to inform 163 the Path Segment to the egress PCC. 165 2. Terminology 167 This memo makes use of the terms defined in [RFC4655], 168 [I-D.ietf-pce-segment-routing], and [RFC8402]. 170 2.1. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 174 "OPTIONAL" in this document are to be interpreted as described in BCP 175 14 [RFC2119] [RFC8174] when, and only when, they appear in all 176 capitals, as shown here. 178 3. Overview of Path Segment Extensions in PCEP 180 This document specifies a mechanism of encoding (and allocating) Path 181 Segment in PCEP extensions. For supporting Path Segment in PCEP, 182 several TLVs and flags are defined. The formats of the objects and 183 TLVs are described in Section 4. The procedures of Path Segment 184 allocation are described in Section 5. 186 There are various modes of operations, such as - 188 o The Path Segment can be allocated by Egress PCC. The PCE should 189 request the Path Segment from Egress PCC. 191 o The PCE can allocate a Path Segment on its own accord and inform 192 the ingress/egress PCC, useful for PCE-initiated LSPs. 194 o Ingress PCC can also request PCE to allocate the Path Segment, in 195 this case, the PCE would either allocate and inform the assigned 196 Path Segment to the ingress/egress PCC using PCEP messages, or 197 first request egress PCC for Path Segment and then inform it to 198 the ingress PCC. 200 The path information to the ingress PCC and PCE is exchanged via an 201 extension to [I-D.ietf-pce-segment-routing] and 202 [I-D.ietf-pce-segment-routing-ipv6]. The Path Segment information to 203 the egress PCC can be informed via an extension to the PCECC-SR 204 procedures [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 206 For the PCE to allocate a Path Segment, the PCE SHOULD be aware of 207 the MPLS label space from the PCCs. This is done via mechanism as 208 described in [I-D.li-pce-controlled-id-space]. Otherwise, the PCE 209 should request the egress PCC for Path Segment allocation. 211 4. Objects and TLVs 213 4.1. The OPEN Object 215 4.1.1. The SR PCE Capability sub-TLV 217 [I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST) 218 and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers use this sub-TLV 219 to exchange information about their SR capability. The TLV defines a 220 Flags field that includes one bit (L-flag) to indicate Local 221 Significance [I-D.ietf-pce-segment-routing]. 223 This document adds an additional flag for Path Segment allocation, as 224 follows - 226 P (Path Segment Identification bit): A PCEP speaker sets this flag 227 to 1 to indicate that it has the capability to encode SR path 228 identification (Path Segment, as per 229 [I-D.ietf-spring-mpls-path-segment]). 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Type=TBD11 | Length=4 | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | Reserved | Flags |P|N|X| MSD | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 1: P-flag in SR-PCE-CAPABILITY TLV 241 The figure is included for the ease of the reader and can be removed 242 at the time of publication. 244 4.1.2. The SRv6 PCE Capability sub-TLV 246 [I-D.ietf-pce-segment-routing-ipv6] defined a new Path Setup Type 247 (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use 248 this sub-TLV to exchange information about their SRv6 capability. 249 The TLV includes a Flags field and one bit (L-flag) was allocated in 250 [I-D.ietf-pce-segment-routing-ipv6]. 252 This document adds an additional flag for Path Segment allocation, as 253 follows - 255 P (Path Segment Identification bit): A PCEP speaker sets this flag 256 to 1 to indicate that it has the capability to encode SRv6 path 257 identification.(Path Segment, as per 258 [I-D.li-spring-srv6-path-segment]). 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Type=TBD1 | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Reserved | Flags |P|L| 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | MSD-Type | MSD-Value | MSD-Type | MSD-Value | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 // ... // 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | MSD-Type | MSD-Value | Padding | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 Figure 2: P-flag in SRv6-PCE-CAPABILITY TLV 276 The figure is included for the ease of the reader and can be removed 277 at the time of publication. 279 4.1.3. PCECC-CAPABILITY sub-TLV 281 Along with the SR sub-TLVs, the PCECC Capability as per 282 [I-D.zhao-pce-pcep-extension-pce-controller-sr] should be advertised 283 if the PCE allocates the Path Segment and acts as a Central 284 Controller that manages the Label space. 286 The PCECC Capability should also be advertised on the egress PCEP 287 session, along with the SR sub-TLVs. This is needed to ensure that 288 the PCE can use the PCECC objects/mechanism to request/inform the 289 egress PCC of the Path Segment as described in this document. 291 4.2. LSP Object 293 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 294 adds the following flags to the LSP Object: 296 P (PCE Allocation bit): If the bit is set to 1, it indicates that 297 the PCC requests PCE to allocate resource for this LSP. With the 298 resource TLV, a PCE can undertsand what kind of resource should be 299 allocated, such as Path Segment and Binding Segment. A PCC would 300 set this bit to 1 and include a PATH-SEGMENT TLV in the LSP object 301 to request for allocation of Path Segment by the PCE in the PCReq 302 or PCRpt message. A PCE would also set this bit to 1 and include 303 a PATH-SEGMENT TLV to indicate that the Path Segment is allocated 304 by PCE and encoded in the PCRep, PCUpd or PCInitiate message. 305 Further, a PCE would set this bit to 0 and include a PATH-SEGMENT 306 TLV in the LSP object to indicate that the Path Segment should be 307 allocated by the PCC as described in Section 5.1.1. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | PLSP-ID | Flag|P|C| O |A|R|S|D| 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 // TLVs // 315 | | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 3: P-flag in LSP Object 320 The figure is included for the ease of the reader and can be removed 321 at the time of publication. 323 4.2.1. Path Segment TLV 325 The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object for 326 Path Segment allocation. The type of this TLV is to be allocated by 327 IANA (TBA4). The format is shown below. 329 0 1 2 3 330 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 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | Type | Length | 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 334 | ST | Flag |L| Reserved | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 ~ (Variable length) Path Segment ~ 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 Figure 4: The PATH-SEGMENT TLV Format 341 The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The 342 length (16-bit) has a fixed value of 8 octets. The value contains 343 the following fields: 345 ST (The Segment type - 8 bits): The ST field specifies the type of 346 the Path Segment field, which carries a Path Segment corresponding 347 to the SR path. 349 * 0: MPLS Path Segment, which is an MPLS label as defined in 350 [I-D.ietf-spring-mpls-path-segment]. The PST type MUST be set 351 to SR (MPLS). 353 * 1: SRv6 Path Segment, which is a 128 bit IPv6 address as 354 defined in [I-D.li-spring-srv6-path-segment]. The PST type 355 MUST be set to SRv6. 357 Flags (8 bits): Two flags are currently defined: 359 * L-Bit (Local/Global - 1 bit): If set, then the Path Segment 360 carried by the PATH-SEGMENT TLV has local significance. If not 361 set, then the Path Segment carried by this TLV has global 362 significance (i.e. Path Segment is global within an SR 363 domain). 365 * The unassigned bits MUST be set to 0 and MUST be ignored at 366 receipt. 368 Reserved (16 bits): MUST be set to 0 and MUST be ignored at 369 receipt. 371 Path Segment: The Path Segment of an SR path. The Path Segment 372 type is indicated by the ST field. When the ST is 0, it is a MPLS 373 Path Segment [I-D.ietf-spring-mpls-path-segment] in the MPLS label 374 format. When the ST field is 1, it is a 128-bit SRv6 Path Segment 375 as defined in [I-D.li-spring-srv6-path-segment]. 377 In general, only one instance of PATH-SEGMENT TLV will be included in 378 LSP object. If more than one PATH-SEGMENT TLV is included, the first 379 one is processed and others MUST be ignored. Multiple Path Segment 380 allocation for use cases like alternate-making will be considered in 381 future version of this draft. 383 When the Path Segment allocation is enable, a PATH-SEGMENT TLV MUST 384 be included in the LSP object. 386 If the label space is maintained by PCC itself, and the Path Segment 387 is allocated by Egress PCC, then the PCE should request the Path 388 Segment from Egress PCC as described in Section 5.1.1. In this case, 389 the PCE should send a PCUpdate or PCInitiate message to the egress 390 PCC to request the Path Segment. The P-flag in LSP should be unset 391 in this case. 393 If a PCEP node does not recognize the PATH-SEGMENT TLV, it would 394 behave in accordance with [RFC5440] and ignore the TLV. If a PCEP 395 node recognizes the TLV but does not support the TLV, it MUST send 396 PCErr with Error-Type = 2 (Capability not supported). 398 4.3. FEC Object 400 The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is 401 used to specify the FEC information and MAY be carried within 402 PCInitiate or PCRpt message for the PCECC-SR operations. The PCE 403 MUST inform the Path Identification information to the Egress PCC. 404 To do this, this document extends the procedures of 405 [I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC 406 object type for Path. 408 FEC Object-Type is TBA6 'Path'. 410 0 1 2 3 411 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 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | | 414 // TLV(s) // 415 | | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 5: The path FEC object Format 420 One or more following TLV(s) are allowed in the 'path' FEC object - 422 o SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human- 423 readable string that identifies an LSP in the network. 425 o LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for 426 SR, but could be used to encode the source, destination and other 427 identification information for the path. 429 o SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique 430 identifier for the PCEP speaker, it is used to identify the 431 Ingress PCC. 433 Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be 434 included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of 435 each TLV is processed, if more than one TLV of each type is included, 436 the first one is processed and others MUST be ignored. 438 4.4. CCI Object 440 The Central Control Instructions (CCI) Object is used by the PCE to 441 specify the forwarding instructions is defined in 442 [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further 443 [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object 444 type for SR. 446 The Path Segment information is encoded directly in the CCI SR 447 object. The Path Segment TLV as described in the Section 4.2.1, MUST 448 also be included in the CCI SR object as the TLV (as it includes 449 additional information regarding the Path Segment identifier). 451 This document adds the following flags to the CCI Object: 453 o C (PCC Allocation bit): If the bit is set to 1, it indicates that 454 the allocation needs to be done by the PCC for this central 455 controller instruction. A PCE set this bit to request the PCC to 456 make an allocation from its SR label space. A PCC would set this 457 bit to indicate that it has allocated the CC-ID and report it to 458 the PCE. 460 0 1 2 3 461 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 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | CC-ID | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | MT-ID | Algorithm | Flags |C|N|E|V|L|O| 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 // SID/Label/Index (variable) // 468 +---------------------------------------------------------------+ 469 | | 470 // Optional TLV // 471 | | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 Figure 6: The CCI object for SR 476 (Editor's Note - An update is planned for 477 [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision 478 detailing this procedure, and the above text might move there.) 480 5. Operations 482 The Path Segment allocation and encoding is as per the stateful PCE 483 operations for segment routing. The procedures are as per the 484 corresponding extensions defined in [I-D.ietf-pce-segment-routing] 485 and [I-D.ietf-pce-segment-routing-ipv6] (which are further based on 486 [RFC8231] and [RFC8281]). The additional operations for Path Segment 487 are defined in this section. 489 To notify (or request) the Path Segment to the Egress PCC, the 490 procedures are as per the PCECC-SR 491 [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which is based on 492 [I-D.ietf-pce-pcep-extension-for-pce-controller]). The additional 493 operations are defined in this section. 495 5.1. PCC Allocated Path Segment 497 5.1.1. Egress PCC Allocated Path Segment 499 As defined in [I-D.ietf-spring-mpls-path-segment], a Path Segment can 500 be allocated by the egress PCC. In this case, the label space may be 501 maintained on the PCC itself. 503 On receiving a stateful path computation request with Path Segment 504 allocation request from an ingress PCC, or by initiating or updating 505 an LSP with Path Segment actively, a PCE can request the egress PCC 506 to allocate a Path Segment. This is needed if the PCE does not 507 control the Path Segment allocation for the egress PCC or the label 508 space is maintained by the egress PCC itself. 510 The mechanism of Path Segment request and reply may be achieved by 511 using PCInitiate and PCUpd message as described in this section. 513 5.1.1.1. Using CCI and FEC objects (PCECC) 515 The PCE can request the egress to allocate the Path Segment using the 516 PCInitiate message as described in 517 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The C flag in the 518 CCI object is set to 1 and the CC-ID is set to a special value of 519 0x0000 to indicate that the allocation needs to be done by the PCC. 520 The PATH-SEGMENT TLV is also be included in CCI object along with the 521 FEC object identifying the SR-Path. The egress PCC would allocate 522 the Path Segment and would report to the PCE using the PCRpt message 523 as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr] with 524 the allocated Path Segment in the CC-ID field as well as in the PATH- 525 SEGMENT TLV. 527 (Editor's Note - An update is planned for 528 [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision 529 detailing this procedure) 531 If the value of CC-ID/Path Segment is 0 and the C flag is set, it 532 indicates that the PCE is requesting a Path Segment for this LSP. If 533 the CC-ID/Path Segment is set to a value 'n' and the C flag is set in 534 the CCI object, it indicates that the PCE requests a specific value 535 'n' of Path Segment. If the Path Segment is allocated successfully, 536 the egress PCC should report the Path Segment via PCRpt message with 537 the CCI object along with the PATH-SEGMENT TLV. Else, it MUST send a 538 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 539 Value = 1 ("Invalid SID"). If the value of Path Segment in CCI 540 object is valid, but the PCC is unable to allocate the Path Segment, 541 it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID 542 failure") and Error Value = 2 ("Unable to allocate the specified 543 label/SID"). 545 Once the PCE receives the PCRpt message with the CCI object, it can 546 obtain the Path Segment information from the egress PCC and then 547 update the path with Path Segment or reply to the ingress PCC, the 548 path information with Path Segment. 550 If the SR-Path is setup the ingress PCC will acknowledge with a PCRpt 551 message to the PCE. In case of error, as described in 552 [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to 553 the PCE. The PCE MUST request the withdraw of the Path Segment 554 allocation by sending a PCInitiate message to remove the central 555 controller instruction as per 556 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. When the LSP is 557 deleted or the Path Segment is removed, the PCE should synchronize 558 with the egress PCC. 560 If the egress PCC wishes to withdraw or modify a previously reported 561 Path Segment value, it MUST send a PCRpt message without any PATH- 562 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 563 Segment respectively in the CCI object. The PCE would further 564 trigger the removal of the central controller instruction as per 565 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 567 If a PCE wishes to modify a previously requested Path Segment value, 568 it MUST send a new PCInitiate message with an allocation request CC- 569 ID/PATH-SEGMENT TLV containing the new Path Segment value and C flag 570 is set. The PCE should trigger the removal of the older Path Segment 571 next as per [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 573 Ingress Egress 574 +-+-+ +-+-+ +-+-+ 575 |PCC| |PCE| |PCC| 576 +-+-+ +-+-+ +-+-+ 577 1) LSP State | ---- PCRpt ----> | | 578 Delegate | Delegate=1 | | 579 | P=1 |2) PCE update | 580 | | the LSP-DB and | 581 | | request Path SID | 582 | | | 583 | | --- PCInitiate ---> | Egress 584 | | CC-ID=0 | allocates 585 | | FEC=Path | a Path-SID 586 | | | from its 587 | | <----- PCRpt ------ | space 588 | | CC-ID= | 589 | | Path SID | 590 | | | 591 |<---- PCUpd ---- |3)Paths update with | 592 | PATH-SEGMENT TLV | Path SID | 593 | | | 594 4) LSP State | ----- PCRpt ---> | | 595 Report | | | 596 | | | 598 Figure 7: Egress PCC Allocated Path Segment 600 5.1.1.2. Using LSP objects (PCEP-SR) 602 The PATH-SEGMENT TLV MUST be included in an LSP object in the 603 PCInitiate message sent from the PCE to the egress to request path 604 identification allocation by the egress PCC. The P flag in LSP 605 object MUST be set to 0. This PCInitiate message to egress PCC would 606 be the similar to the one sent to ingress PCC as per 607 [I-D.ietf-pce-segment-routing], but the egress PCC would only 608 allocate the Path Segment and would not trigger the initiation/update 609 operation. 611 If the value of Path Segment is 0x0 it indicates that the PCE is 612 requesting a Path Segment for this LSP. If the Path Segment is set 613 to a value 'n' and the P flag is unset in the LSP object, it 614 indicates that the PCE requests a specific value 'n' of Path Segment. 615 If the Path Segment is allocated successfully, the egress PCC should 616 report the Path Segment via PCRpt message with PATH-SEGMENT TLV in 617 LSP object. Else, it MUST send a PCErr message with Error-Type = 618 TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If 619 the value of Path Segment is valid, but the PCC is unable to allocate 620 the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 621 ("Path label/SID failure") and Error Value = 2 ("Unable to allocate 622 the specified label/SID"). 624 Once the PCE receives the PCRpt message, it can obtain the Path 625 Segment information from the egress PCC and then update the path with 626 Path Segment or reply to the ingress PCC, the path information with 627 Path Segment. 629 If the SR-Path is setup, the ingress PCC will acknowledge with a 630 PCRpt message to the PCE. In case of error, as described in 631 [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to 632 the PCE. The PCE MUST request the withdraw of the Path Segment 633 allocation by sending a PCUpd message to remove the LSP and 634 associated Path Segment by setting the R flag in the SRP object. 635 When the LSP is deleted or the Path Segment is removed, the PCE 636 should send a PCUpd message to synchronize with the egress PCC. 638 If the egress PCC wishes to withdraw or modify a previously reported 639 Path Segment value, it MUST send a PCRpt message without any PATH- 640 SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path 641 Segment respectively. 643 If a PCE wishes to modify a previously requested Path Segment value, 644 it MUST send a PCUpd message with PATH-SEGMENT TLV containing the new 645 Path Segment value and P flag is LSP object would be unset. Absence 646 of the PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to 647 withdraw the Path Segment. 649 If a PCC receives a valid Path Segment value from a PCE which is 650 different than the current Path Segment, it MUST try to allocate the 651 new value. If the new Path Segment is successfully allocated, the 652 PCC MUST report the new value to the PCE. Otherwise, it MUST send a 653 PCErr message with Error-Type = TBA7 ("Path label/SID failure") and 654 Error Value = 2 ("Unable to allocate the specified label/SID"). 656 Ingress Egress 657 +-+-+ +-+-+ +-+-+ 658 |PCC| |PCE| |PCC| 659 +-+-+ +-+-+ +-+-+ 660 1) LSP State | ---- PCRpt ----> | | 661 Delegate | Delegate=1 | | 662 | P=1 |2) PCE update | 663 | | the LSP-DB and | 664 | | request Path SID | 665 | | | 666 | | --- PCInitiate ---> | Egress 667 | | PATH-SEGMENT | allocates 668 | | TLV in LSP | a Path-SID 669 | | | from its 670 | | <----- PCRpt ------ | space 671 | | Path SID | 672 | | | 673 |<---- PCUpd ---- |3)Paths update with | 674 | PATH-SEGMENT TLV | Path SID | 675 | | | 676 4) LSP State | ----- PCRpt ---> | | 677 Report | | | 678 | | | 680 Figure 8: Egress PCC Allocated Path Segment 682 5.2. PCE Allocated Path Segment 684 5.2.1. PCE Controlled Label Spaces Advertisement 686 For allocating the Path Segments to SR paths by the PCEs, the PCE 687 controlled label space MUST be known at PCEs via configurations or 688 any other mechanism. The PCE controlled label spaces MAY be 689 advertised as described in [I-D.li-pce-controlled-id-space]. 691 5.2.2. Ingress PCC request Path Segment to PCE 693 The ingress PCC could request the Path Segment to be allocated by the 694 PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) 695 MUST also be set for this LSP. Also, the P-flag in the LSP object 696 MUST be set. 698 A PATH-SEGMENT TLV MUST be included in the LSP object. If the value 699 of Path Segment is 0x0, it indicates that the Ingress PCC is 700 requesting a Path Segment for this LSP. If the Path Segment is set 701 to a value 'n', it indicates that the ingress PCC requests a specific 702 value 'n' of Path Segment. 704 If the Path Segment is allocated successfully, the PCE would further 705 respond to Ingress PCC with PCUpd message as per [RFC8231] and MUST 706 include the PATH-SEGMENT TLV in a LSP object. Else, it MUST send a 707 PCErr message with Error-Type = TBA7 ("Path SID failure") and Error 708 Value = 1 ("Invalid SID"). If the value of Path Segment is valid, 709 but the PCC is unable to allocate the Path Segment, it MUST send a 710 PCErr message with Error-Type = TBA7 ("Path label/SID failure") and 711 Error Value = 2 ("Unable to allocate the specified label/SID"). 713 The active PCE would allocate the Path Segment as per the PATH- 714 SEGMENT flags and in case PATH-SEGMENT is not included, the PCE MUST 715 act based on the local policy. 717 The PCE would further inform the egress PCC about the Path Segment 718 allocated by the PCE using the PCInitiate message as described in 719 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 721 Ingress Egress 722 +-+-+ +-+-+ +-+-+ 723 |PCC| |PCE| |PCC| 724 +-+-+ +-+-+ +-+-+ 725 1) LSP State | ---- PCRpt ----> | | 726 Delegate | Delegate=1 | | 727 | P=1 |2) PCE update | 728 | | the LSP-DB and | 729 | | allocate Path SID | 730 |<---- PCUpd ---- |3)Paths update with | 731 | PATH-SEGMENT TLV | Path SID | 732 | | | 733 4) LSP State Report | ----- PCRpt ---> | | 734 | | | 735 |5) PCE informs the | --- PCInitiate ---> | 736 | Path SID to Egress| FEC=Path | 737 | | | 738 | | <-------- PCRpt --- | 739 | | | 741 Figure 9: Ingress PCC request Path Segment to PCE 743 5.2.3. PCE allocated Path Segment on its own 745 The PCE could allocate the Path Segment on its own for a PCE- 746 Initiated (or delegated LSP). The allocated Path Segment needs to be 747 informed to the Ingress and Egress PCC. The PCE would use the 748 PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the 749 Ingress PCC and MUST include the PATH-SEGMENT TLV in the LSP object. 750 The PCE would further inform the egress PCC about the Path Segment 751 allocated by the PCE using the PCInitiate message as described in 752 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 754 Ingress Egress 755 +-+-+ +-+-+ +-+-+ 756 |PCC| |PCE| |PCC| 757 +-+-+ +-+-+ +-+-+ 758 | | | 759 | <--PCInitiate--- |1)Initiate LSP with | 760 | PATH-SEGMENT TLV | Path SID | 761 | | | 762 2)LSP delegation |---PCRpt, D=1---> | (Confirm) | 763 | | | 764 |3) PCE informs the | --- PCInitiate ---> | 765 | Path SID to Egress| FEC=Path | 766 | | | 767 | | <-------- PCRpt --- | 768 | | | 770 Figure 10: PCE allocated Path Segment on its own 772 6. Dataplane Considerations 774 As described in [I-D.ietf-spring-mpls-path-segment], in an SR-MPLS 775 network, when a packet is transmitted along an SR path, the labels in 776 the MPLS label stack will be swapped or popped. So that no label or 777 only the last label may be left in the MPLS label stack when the 778 packet reaches the egress node. Thus, the egress node cannot 779 determine from which SR path the packet comes. For this reason, it 780 introduces the Path Segment. 782 Apart from allocation and encoding of the Path Segment (described in 783 this document) for the LSP, it would also be included in the SID/ 784 Label stack of the LSP (usually for processing by the egress). To 785 support this, the Path Segment MAY also be a part of SR-ERO as 786 prepared by the PCE as per [I-D.ietf-pce-segment-routing]. The PCC 787 MAY also include the Path Segment while preparing the label stack 788 based on the local policy and use-case. 790 It is important that the PCE learns the Maximum SID Depth (MSD) that 791 can be imposed at each node/link of a given SR path to ensure that 792 the SID stack depth does not exceed the number of SIDs the node is 793 capable of imposing. As a new type of segment, Path Segment will be 794 inserted in the SID list just like other SIDs. Thus, the PCE needs 795 to consider the affect of Path Segment when computing a LSP with Path 796 Segment allocation. 798 7. IANA Considerations 800 7.1. SR PCE Capability Flags 802 SR PCE Capability TLV is defined in [I-D.ietf-pce-segment-routing], 803 and the registry to manage the Flag field of the SR PCE Capability 804 TLV is requested in [I-D.ietf-pce-segment-routing]. IANA is 805 requested to make the following allocation in the aforementioned 806 registry. 808 Bit Description Reference 810 TBA1 Path Segment Allocation is supported(P) This document 812 7.2. SRv6 PCE Capability Flags 814 SRv6 PCE Capability TLV is defined in defined in 815 [I-D.ietf-pce-segment-routing-ipv6], and the registry to manage the 816 Flag field of the SRv6 PCE Capability Flags is requested in 817 [I-D.ietf-pce-segment-routing-ipv6]. IANA is requested to make the 818 following allocation in the aforementioned registry. 820 Bit Description Reference 822 TBA2 Path Segment Allocation is supported(P) This document 824 7.3. New LSP Flag Registry 826 [RFC8231] defines the LSP object; per that RFC, IANA created a 827 registry to manage the value of the LSP object's Flag field. IANA 828 has allocated a new bit in the "LSP Object Flag Field" subregistry, 829 as follows: 831 Bit Description Reference 833 TBA3 Request for Path Segment Allocation(P) This document 835 7.4. New PCEP TLV 837 IANA is requested to add the assignment of a new allocation in the 838 existing "PCEP TLV Type Indicators" subregistry as follows: 840 Value Description Reference 842 TBA4 PATH-SEGMENT TLV This document 844 7.4.1. Path Segment TLV 846 This document requests that a new subregistry named "PATH-SEGMENT TLV 847 Segment Type (ST) Field" to be created to manage the value of the ST 848 field in the PATH-SEGMENT TLV. 850 Value Description Reference 852 0 MPLS Path Segment(MPLS label) This document 853 1 SRv6 Path Segment(IPv6 address) This document 855 Further, this document also requests that a new subregistry named 856 "PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field 857 in the PATH-SEGMENT TLV. New values are assigned by Standards Action 858 [RFC8126]. Each bit should be tracked with the following qualities: 860 o Bit number (counting from bit 0 as the most significant bit) 862 o Capability description 864 o Defining RFC 866 Bit Description Reference 868 7 Local Signification(L) This document 870 7.5. New CCI Flag Registry 872 CCI object is defined in defined in 873 [I-D.ietf-pce-pcep-extension-for-pce-controller], further 874 [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object 875 type for SR. and the subregistry to manage the Flag field of the CCI 876 object for SR is requested in 877 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested 878 to make the following allocation in the aforementioned subregistry. 880 Bit Description Reference 882 TBA5 PCC is requested to This document 883 allocate resource(C) 885 7.6. New FEC Type Registry 887 A new PCEP object called FEC is defined in 888 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested 889 to allocate a new Object-Type for FEC object in the "PCEP Objects" 890 subregistry. 892 Value Description Reference 894 TBA6 SR path This document 896 7.7. PCEP Error Type and Value 898 IANA is requested to allocate code-points in the "PCEP-ERROR Object 899 Error Types and Values" subregistry for the following new error-types 900 and error-values: 902 Error-Type Meaning Reference 904 TBA7 Path SID failure: This document 905 Error-value = 1 906 Invalid SID 908 Error-value = 2 909 Unable to allocate 910 Path SID 912 8. Security Considerations 914 TBA 916 9. Acknowledgments 918 10. Contributors 920 The following people have substantially contributed to this document: 922 Dhruv Dhody 923 Huawei Technologies 924 Divyashree Techno Park, Whitefield 925 Bangalore, Karnataka 560066 926 India 928 Email: dhruv.ietf@gmail.com 930 Zafar Ali 931 Cisco Systems, Inc. 933 Email: zali@cisco.com 935 11. References 937 11.1. Normative References 939 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 940 Requirement Levels", BCP 14, RFC 2119, 941 DOI 10.17487/RFC2119, March 1997, 942 . 944 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 945 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 946 DOI 10.17487/RFC5440, March 2009, 947 . 949 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 950 Writing an IANA Considerations Section in RFCs", BCP 26, 951 RFC 8126, DOI 10.17487/RFC8126, June 2017, 952 . 954 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 955 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 956 May 2017, . 958 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 959 Computation Element Communication Protocol (PCEP) 960 Extensions for Stateful PCE", RFC 8231, 961 DOI 10.17487/RFC8231, September 2017, 962 . 964 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 965 and D. Dhody, "Optimizations of Label Switched Path State 966 Synchronization Procedures for a Stateful PCE", RFC 8232, 967 DOI 10.17487/RFC8232, September 2017, 968 . 970 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 971 Computation Element Communication Protocol (PCEP) 972 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 973 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 974 . 976 [I-D.ietf-pce-segment-routing] 977 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 978 and J. Hardwick, "PCEP Extensions for Segment Routing", 979 draft-ietf-pce-segment-routing-16 (work in progress), 980 March 2019. 982 [I-D.ietf-pce-segment-routing-ipv6] 983 Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP 984 Extensions for Segment Routing leveraging the IPv6 data 985 plane", draft-ietf-pce-segment-routing-ipv6-00 (work in 986 progress), March 2019. 988 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 989 Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures 990 and Protocol Extensions for Using PCE as a Central 991 Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- 992 extension-pce-controller-sr-04 (work in progress), 993 February 2019. 995 [I-D.ietf-pce-pcep-extension-for-pce-controller] 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 LSPs", draft-ietf-pce-pcep- 999 extension-for-pce-controller-01 (work in progress), 1000 February 2019. 1002 [I-D.li-spring-srv6-path-segment] 1003 Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. 1004 Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", 1005 draft-li-spring-srv6-path-segment-00 (work in progress), 1006 October 2018. 1008 11.2. Informative References 1010 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1011 Element (PCE)-Based Architecture", RFC 4655, 1012 DOI 10.17487/RFC4655, August 2006, 1013 . 1015 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 1016 Element (PCE) Communication Protocol Generic 1017 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 1018 2006, . 1020 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., 1021 Decraene, B., Litkowski, S., and R. Shakir, "Segment 1022 Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, 1023 July 2018, . 1025 [I-D.li-pce-controlled-id-space] 1026 Li, C., Chen, M., Dong, J., Li, Z., Wang, A., and C. Zhou, 1027 "PCE Controlled ID Space", draft-li-pce-controlled-id- 1028 space-02 (work in progress), March 2019. 1030 [I-D.ietf-spring-mpls-path-segment] 1031 Cheng, W., Li, H., Chen, M., Gandhi, R., and R. Zigler, 1032 "Path Segment in MPLS Based Segment Routing Network", 1033 draft-ietf-spring-mpls-path-segment-00 (work in progress), 1034 March 2019. 1036 Authors' Addresses 1038 Cheng Li 1039 Huawei Technologies 1040 Huawei Campus, No. 156 Beiqing Rd. 1041 Beijing 100095 1042 China 1044 Email: chengli13@huawei.com 1046 Mach(Guoyi) Chen 1047 Huawei Technologies 1048 Huawei Campus, No. 156 Beiqing Rd. 1049 Beijing 100095 1050 China 1052 Email: Mach.chen@huawei.com 1054 Weiqiang Cheng 1055 China Mobile 1056 China 1058 Email: chengweiqiang@chinamobile.com 1059 Jie Dong 1060 Huawei Technologies 1061 Huawei Campus, No. 156 Beiqing Rd. 1062 Beijing 100095 1063 China 1065 Email: jie.dong@huawei.com 1067 Zhenbin Li 1068 Huawei Technologies 1069 Huawei Campus, No. 156 Beiqing Rd. 1070 Beijing 100095 1071 China 1073 Email: lizhenbin@huawei.com 1075 Rakesh Gandhi 1076 Cisco Systems, Inc. 1077 Canada 1079 Email: rgandhi@cisco.com 1081 Quan Xiong 1082 ZTE Corporation 1083 China 1085 Email: xiong.quan@zte.com.cn