idnits 2.17.1 draft-li-pce-sr-path-segment-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 20, 2018) is 2137 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 (-16) exists of draft-ietf-pce-segment-routing-11 == Outdated reference: A later version (-04) exists of draft-negi-pce-segment-routing-ipv6-01 == Outdated reference: A later version (-16) exists of draft-li-pce-controlled-id-space-00 ** Downref: Normative reference to an Experimental draft: draft-li-pce-controlled-id-space (ref. 'I-D.li-pce-controlled-id-space') == Outdated reference: A later version (-09) exists of draft-zhao-pce-pcep-extension-pce-controller-sr-03 == Outdated reference: A later version (-22) exists of draft-ietf-spring-segment-routing-policy-01 == Outdated reference: A later version (-03) exists of draft-cheng-spring-mpls-path-segment-01 == Outdated reference: A later version (-01) exists of draft-li-idr-sr-policy-path-segment-distribution-00 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 J. Dong 5 Expires: December 22, 2018 Z. Li 6 D. Dhody 7 Huawei Technologies 8 June 20, 2018 10 Path Computation Element Communication Protocol (PCEP) Extension for 11 Path Identification in Segment Routing (SR) 12 draft-li-pce-sr-path-segment-00 14 Abstract 16 The Path Computation Element (PCE) provides path computation 17 functions in support of traffic engineering in Multiprotocol Label 18 Switching (MPLS) and Generalized MPLS (GMPLS) networks. 20 The Source Packet Routing in Networking (SPRING) architecture 21 describes how Segment Routing (SR) can be used to steer packets 22 through an IPv6 or MPLS network using the source routing paradigm. A 23 Segment Routed Path can be derived from a variety of mechanisms, 24 including an IGP Shortest Path Tree (SPT), explicit configuration, or 25 a Path Computation Element (PCE). 27 Path identification is needed for several use cases such as 28 performance measurement in Segment Routing (SR) network. This 29 document specifies extensions to the Path Computation Element 30 Protocol (PCEP) to support requesting, replying, reporting and 31 updating the path identifier between PCEP speakers. 33 Requirements Language 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 37 "OPTIONAL" in this document are to be interpreted as described in BCP 38 14 [RFC2119] [RFC8174] when, and only when, they appear in all 39 capitals, as shown here. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at https://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on December 22, 2018. 58 Copyright Notice 60 Copyright (c) 2018 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (https://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 3. Overview of Path ID 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. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 5 82 4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 5 83 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 6 84 4.2.1. Path ID TLV . . . . . . . . . . . . . . . . . . . . . 6 85 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 8 86 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 9 87 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 5.1. PCC Allocated Path ID . . . . . . . . . . . . . . . . . . 9 89 5.1.1. Ingress PCC Allocated Path ID . . . . . . . . . . . . 9 90 5.2. PCE Allocated Path ID . . . . . . . . . . . . . . . . . . 10 91 5.2.1. PCE Controlled ID Spaces Advertisement . . . . . . . 10 92 5.2.2. Ingress PCC request Path ID to PCE . . . . . . . . . 10 93 5.2.3. PCE allocated Path ID on its own . . . . . . . . . . 11 94 5.3. Two Label Solution . . . . . . . . . . . . . . . . . . . 12 95 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 97 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 99 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 100 9.2. Informative References . . . . . . . . . . . . . . . . . 14 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 103 1. Introduction 105 [RFC5440] describes the Path Computation Element (PCE) Communication 106 Protocol (PCEP). PCEP enables the communication between a Path 107 Computation Client (PCC) and a PCE, or between PCE and PCE, for the 108 purpose of computation of Multiprotocol Label Switching (MPLS) as 109 well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched 110 Path (TE LSP) characteristics. 112 [RFC8231] specifies a set of extensions to PCEP to enable stateful 113 control of TE LSPs within and across PCEP sessions in compliance with 114 [RFC4657]. It includes mechanisms to effect LSP State 115 Synchronization between PCCs and PCEs, delegation of control over 116 LSPs to PCEs, and PCE control of timing and sequence of path 117 computations within and across PCEP sessions. The model of operation 118 where LSPs are initiated from the PCE is described in [RFC8281]. 120 [I-D.zhao-pce-pcep-extension-for-pce-controller] specify the 121 procedures and PCEP protocol extensions for using the PCE as the 122 central controller for static LSPs, where LSPs can be provisioned as 123 explicit label instructions at each hop on the end-to-end path. 125 Segment routing (SR) [I-D.ietf-spring-segment-routing] leverages the 126 source routing and tunneling paradigms. SR supports steering packets 127 into an explicit forwarding path according to the Segment Routing 128 Policy ( SR Policy) [I-D.ietf-spring-segment-routing-policy] at the 129 ingress node. 131 An SR path needs to be identified in some use cases such as 132 performance measurement. For identifying an SR path, 133 [I-D.cheng-spring-mpls-path-segment] introduces a new segment that is 134 referred to as Path Segment. 135 [I-D.li-idr-sr-policy-path-segment-distribution] defines extensions 136 to BGP to distribute SR policies carrying Path segment identifier. 138 [I-D.ietf-pce-segment-routing] specifies extensions to the Path 139 Computation Element Protocol (PCEP) [RFC5440] for SR networks, that 140 allow a stateful PCE to compute and initiate SR-TE paths, as well as 141 a PCC to request, report or delegate SR paths. 142 [I-D.negi-pce-segment-routing-ipv6] extend PCEP to support SR for 143 IPv6 data plane. 145 [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the 146 procedures and PCEP protocol extensions when a PCE-based controller 147 is also responsible for configuring the forwarding actions on the 148 routers (SR SID distribution in this case), in addition to computing 149 the paths for packet flows in a segment routing network and telling 150 the edge routers what instructions to attach to packets as they enter 151 the network. 153 This document specifies a mechanism to carry the SR path 154 identification information in PCEP messages [RFC5440] [RFC8231] 155 [RFC8281]. The path ID can be a path segment in SR-MPLS 156 [I-D.cheng-spring-mpls-path-segment], or a path ID in SRv6 157 [I-D.li-spring-passive-pm-for-srv6-np], or other IDs that can 158 identify the SR path. This document also extends the PCECC-SR 159 mechanism to inform the path ID to the egress PCC. 161 2. Terminology 163 This memo makes use of the terms defined in [RFC4655], 164 [I-D.ietf-pce-segment-routing], and 165 [I-D.ietf-spring-segment-routing]. 167 3. Overview of Path ID Extensions in PCEP 169 This document specifies a mechanism of encoding (and allocating) path 170 ID (path segment in case of MPLS, path ID in case of IPv6, etc) in 171 PCEP extensions. For supporting path ID in PCEP, several TLVs and 172 flags are defined. The formats of the objects and TLVs are described 173 in Section 4. The procedures of path ID allocation are described in 174 Section 5. 176 There are various modes of operations, such as - 178 o The path ID can be allocated by Ingress PCC itself and informed to 179 the PCE. The PCE can then inform the egress PCC. 181 o The PCC can also request PCE to allocate the path ID, in this 182 case, the PCE would allocate and inform the assigned path ID to 183 the ingress/egress PCC using PCEP messages. 185 o For PCE can allocate a path ID on its own accord and inform the 186 ingress/egress PCC , useful for PCE-initiated LSPs. 188 The path ID information to the ingress PCC and PCE is exchanged via 189 an extension to [I-D.ietf-pce-segment-routing] and 190 [I-D.negi-pce-segment-routing-ipv6]. The path ID information to the 191 egress PCC is informed via an extension to the PCECC-SR procedures 192 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 194 For the PCE to allocate a path ID, the PCE MUST be aware of the path 195 ID space from the PCCs. This is done via mechanism as described in 196 [I-D.li-pce-controlled-id-space]. 198 [Editor's note - There is currently no mechanism for the PCE to ask 199 PCC to allocate path ID. Further discussion is needed to check if 200 that would be useful in any way.] 202 4. Objects and TLVs 204 4.1. The OPEN Object 206 4.1.1. The SR PCE Capability sub-TLV 208 [I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST) 209 and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers use this sub-TLV 210 to exchange information about their SR capability. The TLV includes 211 a Flags field and one bit (L-flag) was allocated in 212 [I-D.ietf-pce-segment-routing]. 214 This document adds an additional flag for path ID allocation, as 215 follows - 217 P (Path Identification bit): A PCEP speaker sets this flag to 1 to 218 indicate that it has the capability to encode SR path 219 identification (path segment, as per 220 [I-D.cheng-spring-mpls-path-segment]). 222 4.1.2. The SRv6 PCE Capability sub-TLV 224 [I-D.negi-pce-segment-routing-ipv6] defined a new Path Setup Type 225 (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use 226 this sub-TLV to exchange information about their SRv6 capability. 227 The TLV includes a Flags field and one bit (L-flag) was allocated in 228 [I-D.negi-pce-segment-routing-ipv6]. 230 This document adds an additional flag for path ID allocation, as 231 follows - 233 P (Path Identification bit): A PCEP speaker sets this flag to 1 to 234 indicate that it has the capability to encode SRv6 path 235 identification. 237 4.1.3. PCECC-CAPABILITY sub-TLV 239 The PCECC Capability as per 240 [I-D.zhao-pce-pcep-extension-pce-controller-sr] MUST also be 241 advertised on the egress PCEP session, along with the SR sub-TLVs. 243 This is needed to ensure that the PCE can inform the egress PCC of 244 the path ID via PCECC mechanism as described in this document. 246 4.2. LSP Object 248 The LSP Object is defined in Section 7.3 of [RFC8231]. This document 249 adds the following flags to the LSP Object: 251 P (Path Identification Allocation bit): If the bit is set to 1, it 252 indicates that the path identifier needs to be allocated by the 253 PCE for this LSP. A PCC would set this bit to 1 to request for 254 allocation of path identifier by the PCE in the PCReq or PCRpt 255 message. A PCE would also set this bit to 1 to indicate that the 256 path identifier is allocated by PCE and encoded in the PCRep, 257 PCUpd or PCInitiate message (the PATH-ID TLV MUST be present in 258 LSP object). 260 4.2.1. Path ID TLV 262 The PATH-ID TLV is an optional TLV for use in the LSP Object for path 263 ID allocation. The type of this TLV is to be allocated by IANA. The 264 format is shown below. 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Type | Length | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | IDT | Flags |E|C|L| 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | Path ID | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 Figure 1: The PATH-ID TLV Format 278 The type (16-bit) of the TLV is TBA (to be allocated by IANA). The 279 length (16-bit) has a fixed value of 8 octets. The value contains 280 the following fields: 282 IDT (The ID type - 8 bits): The IDT field specifies the type of 283 the Path ID field, which carries a Path ID corresponding to the SR 284 path. 286 * 0: MPLS Path segment, which is an MPLS label as defined in 287 [I-D.cheng-spring-mpls-path-segment]. The PST type MUST be set 288 to SR (MPLS). 290 * 1: SRv6 Path ID, which is a 4-octet integer as defined in 291 [I-D.li-spring-passive-pm-for-srv6-np]. The PST type MUST be 292 set to SRv6. 294 Flags (24 bits): Three flag is currently defined: 296 * L-Bit (Local/Global - 1 bit): If set, then the Path ID carried 297 by the PATH-ID TLV has local significance. If not set, then 298 the Path ID carried by this TLV has global significance (i.e. 299 Path ID is global within an SR domain). 301 * C-bit (PCC/PCE - 1 bit): If set, then the Path ID carried by 302 the PATH-ID TLV has been allocated by the PCC. If not set, 303 then the Path ID carried by this TLV has been allocated by the 304 PCE. 306 * E-bit (Egress/Ingress - 1 bit): If set, then the Path ID 307 carried by the PATH-ID TLV has been allocated from the Egress 308 Path ID space. If not set, then the Path ID carried by this 309 TLV has been allocated from the Ingress Path ID space. 311 * The unassigned bits MUST be set to 0 and MUST be ignored at 312 receipt. 314 Path ID: The path ID of an SR path. The path ID type is indicated 315 by the ID Type field. It can be a path segment 316 [I-D.cheng-spring-mpls-path-segment] in MPLS label format. Or it 317 can be a 4 octets integer ID as defined in 318 [I-D.li-spring-passive-pm-for-srv6-np] or other IDs that can 319 identify a path. 321 Only one instance of each TLV is processed, if more than one TLV of 322 each type is included, the first one is processed and others MUST be 323 ignored. 325 When the path ID allocation is enable, a PATH-ID TLV SHOULD be 326 included in the LSP object. 328 If the path ID is allocated by the ingress node, a PATH-ID TLV MUST 329 be included in a LSP object (with C-bit set and E-bit is unset) in 330 the PCEP message from PCC. In this case the P flag in LSP object is 331 set to 0. 333 If the PCC request the path ID to be allocated by the PCE, P flag in 334 LSP object is set to 1 and Path ID TLV MAY be skipped. After the PCE 335 has allocated a path ID, it MUST include the PATH-ID TLV in a LSP 336 object (with C-bit unset), the E-bit is set by PCE based on the path 337 ID space from which the allocation is made. 339 If the PCE allocated the path ID on its own accord, a PATH-ID TLV 340 MUST be included in a LSP object (with C-bit unset), the E-bit is set 341 by PCE based on the path ID space from which the allocation is made. 343 4.3. FEC Object 345 The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is 346 used to specify the FEC information and MAY be carried within 347 PCInitiate or PCRpt message for the PCECC-SR operations. The PCE 348 MUST inform the Path Identification information to the Egress PCC. 349 To do this, this document extends the procedures of 350 [I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC 351 object type for Path. 353 FEC Object-Type is TBD 'Path'. 355 0 1 2 3 356 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 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | | 359 // TLV(s) // 360 | | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 Figure 2: The path FEC object Format 365 One or more following TLV(s) are allowed in the 'path' FEC object - 367 o SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human- 368 readable string that identifies an LSP in the network. 370 o LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for 371 SR, but could be used to encode the source, destination and other 372 identification information for the path. 374 o SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique 375 identifier for the PCEP speaker, it is used to identify the 376 Ingress PCC. 378 Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be 379 included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of 380 each TLV is processed, if more than one TLV of each type is included, 381 the first one is processed and others MUST be ignored. 383 4.4. CCI Object 385 The Central Control Instructions (CCI) Object is used by the PCE to 386 specify the forwarding instructions is defined in 387 [I-D.zhao-pce-pcep-extension-for-pce-controller]. Further 388 [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object 389 type for SR. 391 The Path ID information is encoded directly in the CCI SR object. 392 The Path ID TLV as described in the Section 4.2.1, MAY also be 393 included in the CCI SR object. 395 5. Operations 397 The path ID allocation and encoding is as per the stateful PCE 398 operations for segment routing. The procedures are as per the 399 corresponding extensions defined in [I-D.ietf-pce-segment-routing] 400 and [I-D.negi-pce-segment-routing-ipv6] (which are further based on 401 [RFC8231] and [RFC8281]). The additional operations for path 402 identification are defined in this section. 404 To notify the path ID to the Egress PCC, the procedures are as per 405 the PCECC-SR [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which 406 is based on [I-D.zhao-pce-pcep-extension-for-pce-controller]). The 407 additional operations are defined in this section. 409 5.1. PCC Allocated Path ID 411 5.1.1. Ingress PCC Allocated Path ID 413 The Ingress PCC could allocate the Path ID and inform the PCE via the 414 PCRpt message as per [RFC8231]. The PATH-ID TLV MUST be included in 415 a LSP object in the PCEP message from PCC. The P flag in LSP object 416 is set to 0. On receiving this report, the PCE updates the 417 information in its database. The active PCE (where the LSP is 418 delegated) further informs the egress about the path ID allocated by 419 the PCC using the PCInitiate message as described in 420 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 422 Ingress Egress 423 +-+-+ +-+-+ +-+-+ 424 |PCC| |PCE| |PCC| 425 +-+-+ +-+-+ +-+-+ 426 1) LSP State | ---- PCRpt ----> | | 427 Delegate and | Delegate=1 | | 428 Inform the | PATH-ID TLV |2) PCE update | 429 Path ID alloc | | the LSP-DB | 430 by PCC | | | 431 |3) PCE informs the | --- PCInitiate ---> | 432 | Path ID to Egress| FEC=Path | 433 | | | 434 | | <-------- PCRpt --- | 435 | | | 437 Figure 3: Ingress PCC Allocated Path ID 439 5.2. PCE Allocated Path ID 441 5.2.1. PCE Controlled ID Spaces Advertisement 443 For allocating the path IDs to SR paths by the PCEs, the PCE 444 controlled ID Spaces MUST be known at PCEs via configurations or any 445 other mechanism. The PCE controlled ID spaces MAY be advertised as 446 described in [I-D.li-pce-controlled-id-space]. 448 5.2.2. Ingress PCC request Path ID to PCE 450 The ingress PCC could request the path ID to be allocated by the PCE 451 via PCRpt message as per [RFC8231]. The delegate flag (D-flag) MUST 452 also be set for this LSP. The PATH-ID TLV MAY be included with Path 453 ID set to 0x0000. The active PCE would allocated the path ID as per 454 the PATH-ID flags and in case PATH-ID is not included, the PCE MUST 455 act based on the local policy. The PCE would further respond to 456 Ingress PCC with PCUpd message as per [RFC8231] and MUST include the 457 PATH-ID TLV in a LSP object. The PCE would further inform the egress 458 PCC about the path ID allocated by the PCE using the PCInitiate 459 message as described in 460 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 462 Ingress Egress 463 +-+-+ +-+-+ +-+-+ 464 |PCC| |PCE| |PCC| 465 +-+-+ +-+-+ +-+-+ 466 1) LSP State | ---- PCRpt ----> | | 467 Delegate | Delegate=1 | | 468 | P=1 |2) PCE update | 469 | | the LSP-DB and | 470 | | allocate Path ID | 471 |<---- PCUpd ---- |3)Paths update with | 472 | PATH-ID TLV | Path ID | 473 | | | 474 4) LSP State Report | ----- PCRpt ---> | | 475 | | | 476 |5) PCE informs the | --- PCInitiate ---> | 477 | Path ID to Egress| FEC=Path | 478 | | | 479 | | <-------- PCRpt --- | 480 | | | 482 Figure 4: Ingress PCC request Path ID to PCE 484 5.2.3. PCE allocated Path ID on its own 486 The PCE could allocate the path ID on its own accord for a PCE- 487 Initiated (or delegated LSP). The allocated path ID needs to be 488 informed to the Ingress and Egress PCC. The PCE would use the 489 PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the 490 Ingress PCC and MUST include the PATH-ID TLV in the LSP object. The 491 PCE would further inform the egress PCC about the path ID allocated 492 by the PCE using the PCInitiate message as described in 493 [I-D.zhao-pce-pcep-extension-pce-controller-sr]. 495 Ingress Egress 496 +-+-+ +-+-+ +-+-+ 497 |PCC| |PCE| |PCC| 498 +-+-+ +-+-+ +-+-+ 499 | | | 500 | <--PCInitiate--- |1)Initiate LSP with | 501 | PATH-ID TLV | Path ID | 502 | | | 503 2)LSP delegation |---PCRpt, D=1---> | (Confirm) | 504 | | | 505 |3) PCE informs the | --- PCInitiate ---> | 506 | Path ID to Egress| FEC=Path | 507 | | | 508 | | <-------- PCRpt --- | 509 | | | 511 Figure 5: PCE allocated Path ID on its own 513 5.3. Two Label Solution 515 [I-D.cheng-spring-mpls-path-segment] describe a Path Segment to 516 uniquely identify an SR path in a specific context. (e.g., in the 517 context of the egress node or ingress node of an SR path, or within 518 an SR domain). It further describes two solution based on 'one 519 label' or 'two labels' solution. For the latter, two segments 520 (Source segment and Path segment) are used to identify an SR path 521 where the source segment is a global node segment which can uniquely 522 identify a node within the SR domain (it is NOT used for forwarding 523 and indicates that a Path segment immediately follows). The 524 combination of Source segment and Path segment uniquely identify an 525 SR Path with an SR domain. 527 The procedure described in this document allocates and encode the 528 Path Segment only. It is expected that the Egress PCC is aware of 529 the Source segment by some other procedures. These procedures could 530 be IGP, PCECC-SR, or some other mechanisms. 532 6. IANA Considerations 534 TBA 536 7. Security Considerations 538 TBA 540 8. Acknowledgments 542 9. References 544 9.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 552 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 553 DOI 10.17487/RFC5440, March 2009, 554 . 556 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 557 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 558 May 2017, . 560 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 561 Computation Element Communication Protocol (PCEP) 562 Extensions for Stateful PCE", RFC 8231, 563 DOI 10.17487/RFC8231, September 2017, 564 . 566 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 567 and D. Dhody, "Optimizations of Label Switched Path State 568 Synchronization Procedures for a Stateful PCE", RFC 8232, 569 DOI 10.17487/RFC8232, September 2017, 570 . 572 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 573 Computation Element Communication Protocol (PCEP) 574 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 575 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 576 . 578 [I-D.ietf-pce-segment-routing] 579 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 580 and J. Hardwick, "PCEP Extensions for Segment Routing", 581 draft-ietf-pce-segment-routing-11 (work in progress), 582 November 2017. 584 [I-D.negi-pce-segment-routing-ipv6] 585 Negi, M., Kaladharan, P., Dhody, D., and S. Sivabalan, 586 "PCEP Extensions for Segment Routing leveraging the IPv6 587 data plane", draft-negi-pce-segment-routing-ipv6-01 (work 588 in progress), March 2018. 590 [I-D.li-pce-controlled-id-space] 591 Li, C., Chen, M., Dong, J., Li, Z., and D. Dhody, "PCE 592 Controlled ID Space", draft-li-pce-controlled-id-space-00 593 (work in progress), June 2018. 595 [I-D.zhao-pce-pcep-extension-pce-controller-sr] 596 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 597 and C. Zhou, "PCEP Procedures and Protocol Extensions for 598 Using PCE as a Central Controller (PCECC) of SR-LSPs", 599 draft-zhao-pce-pcep-extension-pce-controller-sr-03 (work 600 in progress), June 2018. 602 [I-D.zhao-pce-pcep-extension-for-pce-controller] 603 Zhao, Q., Li, Z., Dhody, D., Karunanithi, S., Farrel, A., 604 and C. Zhou, "PCEP Procedures and Protocol Extensions for 605 Using PCE as a Central Controller (PCECC) of LSPs", draft- 606 zhao-pce-pcep-extension-for-pce-controller-08 (work in 607 progress), June 2018. 609 9.2. Informative References 611 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 612 Element (PCE)-Based Architecture", RFC 4655, 613 DOI 10.17487/RFC4655, August 2006, 614 . 616 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 617 Element (PCE) Communication Protocol Generic 618 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 619 2006, . 621 [I-D.ietf-spring-segment-routing] 622 Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., 623 Litkowski, S., and R. Shakir, "Segment Routing 624 Architecture", draft-ietf-spring-segment-routing-15 (work 625 in progress), January 2018. 627 [I-D.ietf-spring-segment-routing-policy] 628 Filsfils, C., Sivabalan, S., daniel.voyer@bell.ca, d., 629 bogdanov@google.com, b., and P. Mattes, "Segment Routing 630 Policy Architecture", draft-ietf-spring-segment-routing- 631 policy-01 (work in progress), June 2018. 633 [I-D.cheng-spring-mpls-path-segment] 634 Cheng, W., Wang, L., Li, H., Chen, M., Zigler, R., and S. 635 Zhan, "Path Segment in MPLS Based Sement Routing Network", 636 draft-cheng-spring-mpls-path-segment-01 (work in 637 progress), March 2018. 639 [I-D.li-spring-passive-pm-for-srv6-np] 640 Li, C. and M. Chen, "Passive Performance Measurement for 641 SRv6 Network Programming", draft-li-spring-passive-pm-for- 642 srv6-np-00 (work in progress), March 2018. 644 [I-D.li-idr-sr-policy-path-segment-distribution] 645 Li, C., Chen, M., Dong, J., and Z. Li, "Segment Routing 646 Policies for Path Segment and Bi-directional Path", draft- 647 li-idr-sr-policy-path-segment-distribution-00 (work in 648 progress), April 2018. 650 Authors' Addresses 652 Cheng Li 653 Huawei Technologies 654 Huawei Campus, No. 156 Beiqing Rd. 655 Beijing 100095 656 China 658 Email: chengli13@huawei.com 660 Mach(Guoyi) Chen 661 Huawei Technologies 662 Huawei Campus, No. 156 Beiqing Rd. 663 Beijing 100095 664 China 666 Email: Mach.chen@huawei.com 668 Jie Dong 669 Huawei Technologies 670 Huawei Campus, No. 156 Beiqing Rd. 671 Beijing 100095 672 China 674 Email: jie.dong@huawei.com 675 Zhenbin Li 676 Huawei Technologies 677 Huawei Campus, No. 156 Beiqing Rd. 678 Beijing 100095 679 China 681 Email: lizhenbin@huawei.com 683 Dhruv Dhody 684 Huawei Technologies 685 Divyashree Techno Park, Whitefield 686 Bangalore, Karnataka 560066 687 India 689 Email: dhruv.ietf@gmail.com