PCE Working Group C. Li Internet-Draft M. Chen Intended status: Standards Track Huawei Technologies Expires: September 9, 2019 W. Cheng China Mobile J. Dong Z. Li Huawei Technologies R. Gandhi Cisco Systems, Inc. March 08, 2019 Path Computation Element Communication Protocol (PCEP) Extension for Path Segment in Segment Routing (SR) draft-li-pce-sr-path-segment-04 Abstract The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Path identification is needed for several use cases such as performance measurement in Segment Routing (SR) network. This document specifies extensions to the Path Computation Element Protocol (PCEP) to support requesting, replying, reporting and updating the Path Segment ID (Path SID) between PCEP speakers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Li, et al. Expires September 9, 2019 [Page 1] Internet-Draft PCEP for SR Path Segment March 2019 time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 9, 2019. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Overview of Path Segment Extensions in PCEP . . . . . . . . . 4 4. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 5 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 5 4.1.1. The SR PCE Capability sub-TLV . . . . . . . . . . . . 5 4.1.2. The SRv6 PCE Capability sub-TLV . . . . . . . . . . . 6 4.1.3. PCECC-CAPABILITY sub-TLV . . . . . . . . . . . . . . 6 4.2. LSP Object . . . . . . . . . . . . . . . . . . . . . . . 7 4.2.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 7 4.3. FEC Object . . . . . . . . . . . . . . . . . . . . . . . 9 4.4. CCI Object . . . . . . . . . . . . . . . . . . . . . . . 10 5. Operations . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. PCC Allocated Path Segment . . . . . . . . . . . . . . . 11 5.1.1. Egress PCC Allocated Path Segment . . . . . . . . . . 11 5.2. PCE Allocated Path Segment . . . . . . . . . . . . . . . 15 5.2.1. PCE Controlled Label Spaces Advertisement . . . . . . 15 5.2.2. Ingress PCC request Path Segment to PCE . . . . . . . 15 5.2.3. PCE allocated Path Segment on its own . . . . . . . . 17 6. Dataplane Considerations . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7.1. SR PCE Capability Flags . . . . . . . . . . . . . . . . . 18 7.2. SRv6 PCE Capability Flags . . . . . . . . . . . . . . . . 18 7.3. New LSP Flag Registry . . . . . . . . . . . . . . . . . . 18 7.4. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . 19 Li, et al. Expires September 9, 2019 [Page 2] Internet-Draft PCEP for SR Path Segment March 2019 7.4.1. Path Segment TLV . . . . . . . . . . . . . . . . . . 19 7.5. New CCI Flag Registry . . . . . . . . . . . . . . . . . . 19 7.6. New FEC Type Registry . . . . . . . . . . . . . . . . . . 20 7.7. PCEP Error Type and Value . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 20 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 11.1. Normative References . . . . . . . . . . . . . . . . . . 21 11.2. Informative References . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction [RFC5440] describes the Path Computation Element (PCE) Communication Protocol (PCEP). PCEP enables the communication between a Path Computation Client (PCC) and a PCE, or between PCE and PCE, for the purpose of computation of Multiprotocol Label Switching (MPLS) as well as Generalzied MPLS (GMPLS) Traffic Engineering Label Switched Path (TE LSP) characteristics. [RFC8231] specifies a set of extensions to PCEP to enable stateful control of TE LSPs within and across PCEP sessions in compliance with [RFC4657]. It includes mechanisms to effect LSP State Synchronization between PCCs and PCEs, delegation of control over LSPs to PCEs, and PCE control of timing and sequence of path computations within and across PCEP sessions. The model of operation where LSPs are initiated from the PCE is described in [RFC8281]. [I-D.ietf-pce-pcep-extension-for-pce-controller] specify the procedures and PCEP protocol extensions for using the PCE as the central controller for static LSPs, where LSPs can be provisioned as explicit label instructions at each hop on the end-to-end path. Segment routing (SR) [RFC8402] leverages the source routing and tunneling paradigms and supports steering packets into an explicit forwarding path at the ingress node. An SR path needs to be identified in some use cases such as performance measurement. For identifying an SR path, [I-D.cheng-spring-mpls-path-segment] introduces a new segment that is referred to as Path Segment. [I-D.ietf-pce-segment-routing] specifies extensions to the Path Computation Element Protocol (PCEP) [RFC5440] for SR networks, that allow a stateful PCE to compute and initiate SR-TE paths, as well as a PCC to request, report or delegate SR paths. Li, et al. Expires September 9, 2019 [Page 3] Internet-Draft PCEP for SR Path Segment March 2019 [I-D.negi-pce-segment-routing-ipv6] extend PCEP to support SR paths for IPv6 data plane. [I-D.zhao-pce-pcep-extension-pce-controller-sr] specifies the procedures and PCEP protocol extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers (SR SID distribution in this case), in addition to computing the paths for packet flows in a segment routing network and telling the edge routers what instructions to attach to packets as they enter the network. This document specifies a mechanism to carry the SR path identification information in PCEP messages [RFC5440] [RFC8231] [RFC8281]. The SR path identifier can be a Path Segment in SR-MPLS [I-D.cheng-spring-mpls-path-segment], or a Path Segment in SRv6 [I-D.li-spring-srv6-path-segment] or other IDs that can identify an SR path. This document also extends the PCECC-SR mechanism to inform the Path Segment to the egress PCC. 2. Terminology This memo makes use of the terms defined in [RFC4655], [I-D.ietf-pce-segment-routing], and [RFC8402]. 2.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Overview of Path Segment Extensions in PCEP This document specifies a mechanism of encoding (and allocating) Path Segment in PCEP extensions. For supporting Path Segment in PCEP, several TLVs and flags are defined. The formats of the objects and TLVs are described in Section 4. The procedures of Path Segment allocation are described in Section 5. There are various modes of operations, such as - o The Path Segment can be allocated by Egress PCC. The PCE should request the Path Segment from Egress PCC. o The PCE can allocate a Path Segment on its own accord and inform the ingress/egress PCC, useful for PCE-initiated LSPs. Li, et al. Expires September 9, 2019 [Page 4] Internet-Draft PCEP for SR Path Segment March 2019 o Ingress PCC can also request PCE to allocate the Path Segment, in this case, the PCE would either allocate and inform the assigned Path Segment to the ingress/egress PCC using PCEP messages, or first request egress PCC for Path Segment and then inform it to the ingress PCC. The path information to the ingress PCC and PCE is exchanged via an extension to [I-D.ietf-pce-segment-routing] and [I-D.negi-pce-segment-routing-ipv6]. The Path Segment information to the egress PCC can be informed via an extension to the PCECC-SR procedures [I-D.zhao-pce-pcep-extension-pce-controller-sr]. For the PCE to allocate a Path Segment, the PCE SHOULD be aware of the MPLS label space from the PCCs. This is done via mechanism as described in [I-D.li-pce-controlled-id-space]. Otherwise, the PCE should request the egress PCC for Path Segment allocation. 4. Objects and TLVs 4.1. The OPEN Object 4.1.1. The SR PCE Capability sub-TLV [I-D.ietf-pce-segment-routing] defined a new Path Setup Type (PST) and SR-PCE-CAPABILITY sub-TLV for SR. PCEP speakers use this sub-TLV to exchange information about their SR capability. The TLV defines a Flags field that includes one bit (L-flag) to indicate Local Significance [I-D.ietf-pce-segment-routing]. This document adds an additional flag for Path Segment allocation, as follows - P (Path Segment Identification bit): A PCEP speaker sets this flag to 1 to indicate that it has the capability to encode SR path identification (Path Segment, as per [I-D.cheng-spring-mpls-path-segment]). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD11 | Length=4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |P|N|X| MSD | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: P-flag in SR-PCE-CAPABILITY TLV Li, et al. Expires September 9, 2019 [Page 5] Internet-Draft PCEP for SR Path Segment March 2019 The figure is included for the ease of the reader and can be removed at the time of publication. 4.1.2. The SRv6 PCE Capability sub-TLV [I-D.negi-pce-segment-routing-ipv6] defined a new Path Setup Type (PST) and SRv6-PCE-CAPABILITY sub-TLV for SRv6. PCEP speakers use this sub-TLV to exchange information about their SRv6 capability. The TLV includes a Flags field and one bit (L-flag) was allocated in [I-D.negi-pce-segment-routing-ipv6]. This document adds an additional flag for Path Segment allocation, as follows - P (Path Segment Identification bit): A PCEP speaker sets this flag to 1 to indicate that it has the capability to encode SRv6 path identification.(Path Segment, as per [I-D.li-spring-srv6-path-segment]). 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type=TBD1 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |P|L| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | MSD-Type | MSD-Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // ... // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MSD-Type | MSD-Value | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: P-flag in SRv6-PCE-CAPABILITY TLV The figure is included for the ease of the reader and can be removed at the time of publication. 4.1.3. PCECC-CAPABILITY sub-TLV Along with the SR sub-TLVs, the PCECC Capability as per [I-D.zhao-pce-pcep-extension-pce-controller-sr] should be advertised if the PCE allocates the Path Segment and acts as a Central Controller that manages the Label space. The PCECC Capability should also be advertised on the egress PCEP session, along with the SR sub-TLVs. This is needed to ensure that Li, et al. Expires September 9, 2019 [Page 6] Internet-Draft PCEP for SR Path Segment March 2019 the PCE can use the PCECC objects/mechanism to request/inform the egress PCC of the Path Segment as described in this document. 4.2. LSP Object The LSP Object is defined in Section 7.3 of [RFC8231]. This document adds the following flags to the LSP Object: P (PCE Allocation bit): If the bit is set to 1, it indicates that the PCC requests PCE to allocate resource for this LSP. With the resource TLV, a PCE can undertsand what kind of resource should be allocated, such as Path Segment and Binding Segment. A PCC would set this bit to 1 and include a PATH-SEGMENT TLV in the LSP object to request for allocation of Path Segment by the PCE in the PCReq or PCRpt message. A PCE would also set this bit to 1 and include a PATH-SEGMENT TLV to indicate that the Path Segment is allocated by PCE and encoded in the PCRep, PCUpd or PCInitiate message. Further, a PCE would set this bit to 0 and include a PATH-SEGMENT TLV in the LSP object to indicate that the Path Segment should be allocated by the PCC as described in Section 5.1.1. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PLSP-ID | Flag|P|C| O |A|R|S|D| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: P-flag in LSP Object The figure is included for the ease of the reader and can be removed at the time of publication. 4.2.1. Path Segment TLV The PATH-SEGMENT TLV is an optional TLV for use in the LSP Object for Path Segment allocation. The type of this TLV is to be allocated by IANA (TBA4). The format is shown below. Li, et al. Expires September 9, 2019 [Page 7] Internet-Draft PCEP for SR Path Segment March 2019 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ST | Flag |L| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ (Variable length) Path Segment ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: The PATH-SEGMENT TLV Format The type (16-bit) of the TLV is TBA4 (to be allocated by IANA). The length (16-bit) has a fixed value of 8 octets. The value contains the following fields: ST (The Segment type - 8 bits): The ST field specifies the type of the Path Segment field, which carries a Path Segment corresponding to the SR path. * 0: MPLS Path Segment, which is an MPLS label as defined in [I-D.cheng-spring-mpls-path-segment]. The PST type MUST be set to SR (MPLS). * 1: SRv6 Path Segment, which is a 128 bit IPv6 address as defined in [I-D.li-spring-srv6-path-segment]. The PST type MUST be set to SRv6. Flags (8 bits): Two flags are currently defined: * L-Bit (Local/Global - 1 bit): If set, then the Path Segment carried by the PATH-SEGMENT TLV has local significance. If not set, then the Path Segment carried by this TLV has global significance (i.e. Path Segment is global within an SR domain). * The unassigned bits MUST be set to 0 and MUST be ignored at receipt. Reserved (16 bits): MUST be set to 0 and MUST be ignored at receipt. Path Segment: The Path Segment of an SR path. The Path Segment type is indicated by the ST field. When the ST is 0, it is a MPLS Path Segment [I-D.cheng-spring-mpls-path-segment] in the MPLS label format. When the ST field is 1, it is a 128-bit SRv6 Path Segment as defined in [I-D.li-spring-srv6-path-segment]. Li, et al. Expires September 9, 2019 [Page 8] Internet-Draft PCEP for SR Path Segment March 2019 In general, only one instance of PATH-SEGMENT TLV will be included in LSP object. If more than one PATH-SEGMENT TLV is included, the first one is processed and others MUST be ignored. Multiple Path Segment allocation for use cases like alternate-making will be considered in future version of this draft. When the Path Segment allocation is enable, a PATH-SEGMENT TLV MUST be included in the LSP object. If the label space is maintained by PCC itself, and the Path Segment is allocated by Egress PCC, then the PCE should request the Path Segment from Egress PCC as described in Section 5.1.1. In this case, the PCE should send a PCUpdate or PCInitiate message to the egress PCC to request the Path Segment. The P-flag in LSP should be unset in this case. If a PCEP node does not recognize the PATH-SEGMENT TLV, it would behave in accordance with [RFC5440] and ignore the TLV. If a PCEP node recognizes the TLV but does not support the TLV, it MUST send PCErr with Error-Type = 2 (Capability not supported). 4.3. FEC Object The FEC Object [I-D.zhao-pce-pcep-extension-pce-controller-sr] is used to specify the FEC information and MAY be carried within PCInitiate or PCRpt message for the PCECC-SR operations. The PCE MUST inform the Path Identification information to the Egress PCC. To do this, this document extends the procedures of [I-D.zhao-pce-pcep-extension-pce-controller-sr] by defining a new FEC object type for Path. FEC Object-Type is TBA6 'Path'. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // TLV(s) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: The path FEC object Format One or more following TLV(s) are allowed in the 'path' FEC object - o SYMBOLIC-PATH-NAME TLV: As defined in [RFC8231], it is a human- readable string that identifies an LSP in the network. Li, et al. Expires September 9, 2019 [Page 9] Internet-Draft PCEP for SR Path Segment March 2019 o LSP-IDENTIFIERS TLVs: As defined in [RFC8231], it is optional for SR, but could be used to encode the source, destination and other identification information for the path. o SPEAKER-ENTITY-ID TLV: As defined in [RFC8232], a unique identifier for the PCEP speaker, it is used to identify the Ingress PCC. Either SYMBOLIC-PATH-NAME TLV or LSP-IDENTIFIERS TLV MUST be included. SPEAKER-ENTITY-ID TLV is optional. Only one instance of each TLV is processed, if more than one TLV of each type is included, the first one is processed and others MUST be ignored. 4.4. CCI Object The Central Control Instructions (CCI) Object is used by the PCE to specify the forwarding instructions is defined in [I-D.ietf-pce-pcep-extension-for-pce-controller]. Further [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object type for SR. The Path Segment information is encoded directly in the CCI SR object. The Path Segment TLV as described in the Section 4.2.1, MUST also be included in the CCI SR object as the TLV (as it includes additional information regarding the Path Segment identifier). This document adds the following flags to the CCI Object: o C (PCC Allocation bit): If the bit is set to 1, it indicates that the allocation needs to be done by the PCC for this central controller instruction. A PCE set this bit to request the PCC to make an allocation from its SR label space. A PCC would set this bit to indicate that it has allocated the CC-ID and report it to the PCE. Li, et al. Expires September 9, 2019 [Page 10] Internet-Draft PCEP for SR Path Segment March 2019 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CC-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MT-ID | Algorithm | Flags |C|N|E|V|L|O| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SID/Label/Index (variable) // +---------------------------------------------------------------+ | | // Optional TLV // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: The CCI object for SR (Editor's Note - An update is planned for [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision detailing this procedure, and the above text might move there.) 5. Operations The Path Segment allocation and encoding is as per the stateful PCE operations for segment routing. The procedures are as per the corresponding extensions defined in [I-D.ietf-pce-segment-routing] and [I-D.negi-pce-segment-routing-ipv6] (which are further based on [RFC8231] and [RFC8281]). The additional operations for Path Segment are defined in this section. To notify (or request) the Path Segment to the Egress PCC, the procedures are as per the PCECC-SR [I-D.zhao-pce-pcep-extension-pce-controller-sr] (which is based on [I-D.ietf-pce-pcep-extension-for-pce-controller]). The additional operations are defined in this section. 5.1. PCC Allocated Path Segment 5.1.1. Egress PCC Allocated Path Segment As defined in [I-D.cheng-spring-mpls-path-segment], a Path Segment can be allocated by the egress PCC. In this case, the label space may be maintained on the PCC itself. On receiving a stateful path computation request with Path Segment allocation request from an ingress PCC, or by initiating or updating an LSP with Path Segment actively, a PCE can request the egress PCC to allocate a Path Segment. This is needed if the PCE does not Li, et al. Expires September 9, 2019 [Page 11] Internet-Draft PCEP for SR Path Segment March 2019 control the Path Segment allocation for the egress PCC or the label space is maintained by the egress PCC itself. The mechanism of Path Segment request and reply may be achieved by using PCInitiate and PCUpd message as described in this section. 5.1.1.1. Using CCI and FEC objects (PCECC) The PCE can request the egress to allocate the Path Segment using the PCInitiate message as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr]. The C flag in the CCI object is set to 1 and the CC-ID is set to a special value of 0x0000 to indicate that the allocation needs to be done by the PCC. The PATH-SEGMENT TLV is also be included in CCI object along with the FEC object identifying the SR-Path. The egress PCC would allocate the Path Segment and would report to the PCE using the PCRpt message as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr] with the allocated Path Segment in the CC-ID field as well as in the PATH- SEGMENT TLV. (Editor's Note - An update is planned for [I-D.zhao-pce-pcep-extension-pce-controller-sr] in the next revision detailing this procedure) If the value of CC-ID/Path Segment is 0 and the C flag is set, it indicates that the PCE is requesting a Path Segment for this LSP. If the CC-ID/Path Segment is set to a value 'n' and the C flag is set in the CCI object, it indicates that the PCE requests a specific value 'n' of Path Segment. If the Path Segment is allocated successfully, the egress PCC should report the Path Segment via PCRpt message with the CCI object along with the PATH-SEGMENT TLV. Else, it MUST send a PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the value of Path Segment in CCI object is valid, but the PCC is unable to allocate the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID failure") and Error Value = 2 ("Unable to allocate the specified label/SID"). Once the PCE receives the PCRpt message with the CCI object, it can obtain the Path Segment information from the egress PCC and then update the path with Path Segment or reply to the ingress PCC, the path information with Path Segment. If the SR-Path is setup the ingress PCC will acknowledge with a PCRpt message to the PCE. In case of error, as described in [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to the PCE. The PCE MUST request the withdraw of the Path Segment allocation by sending a PCInitiate message to remove the central Li, et al. Expires September 9, 2019 [Page 12] Internet-Draft PCEP for SR Path Segment March 2019 controller instruction as per [I-D.zhao-pce-pcep-extension-pce-controller-sr]. When the LSP is deleted or the Path Segment is removed, the PCE should synchronize with the egress PCC. If the egress PCC wishes to withdraw or modify a previously reported Path Segment value, it MUST send a PCRpt message without any PATH- SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path Segment respectively in the CCI object. The PCE would further trigger the removal of the central controller instruction as per [I-D.zhao-pce-pcep-extension-pce-controller-sr]. If a PCE wishes to modify a previously requested Path Segment value, it MUST send a new PCInitiate message with an allocation request CC- ID/PATH-SEGMENT TLV containing the new Path Segment value and C flag is set. The PCE should trigger the removal of the older Path Segment next as per [I-D.zhao-pce-pcep-extension-pce-controller-sr]. Ingress Egress +-+-+ +-+-+ +-+-+ |PCC| |PCE| |PCC| +-+-+ +-+-+ +-+-+ 1) LSP State | ---- PCRpt ----> | | Delegate | Delegate=1 | | | P=1 |2) PCE update | | | the LSP-DB and | | | request Path SID | | | | | | --- PCInitiate ---> | Egress | | CC-ID=0 | allocates | | FEC=Path | a Path-SID | | | from its | | <----- PCRpt ------ | space | | CC-ID= | | | Path SID | | | | |<---- PCUpd ---- |3)Paths update with | | PATH-SEGMENT TLV | Path SID | | | | 4) LSP State | ----- PCRpt ---> | | Report | | | | | | Figure 7: Egress PCC Allocated Path Segment Li, et al. Expires September 9, 2019 [Page 13] Internet-Draft PCEP for SR Path Segment March 2019 5.1.1.2. Using LSP objects (PCEP-SR) The PATH-SEGMENT TLV MUST be included in an LSP object in the PCInitiate message sent from the PCE to the egress to request path identification allocation by the egress PCC. The P flag in LSP object MUST be set to 0. This PCInitiate message to egress PCC would be the similar to the one sent to ingress PCC as per [I-D.ietf-pce-segment-routing], but the egress PCC would only allocate the Path Segment and would not trigger the initiation/update operation. If the value of Path Segment is 0x0 it indicates that the PCE is requesting a Path Segment for this LSP. If the Path Segment is set to a value 'n' and the P flag is unset in the LSP object, it indicates that the PCE requests a specific value 'n' of Path Segment. If the Path Segment is allocated successfully, the egress PCC should report the Path Segment via PCRpt message with PATH-SEGMENT TLV in LSP object. Else, it MUST send a PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the value of Path Segment is valid, but the PCC is unable to allocate the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID failure") and Error Value = 2 ("Unable to allocate the specified label/SID"). Once the PCE receives the PCRpt message, it can obtain the Path Segment information from the egress PCC and then update the path with Path Segment or reply to the ingress PCC, the path information with Path Segment. If the SR-Path is setup, the ingress PCC will acknowledge with a PCRpt message to the PCE. In case of error, as described in [I-D.ietf-pce-segment-routing], an PCErr message will be sent back to the PCE. The PCE MUST request the withdraw of the Path Segment allocation by sending a PCUpd message to remove the LSP and associated Path Segment by setting the R flag in the SRP object. When the LSP is deleted or the Path Segment is removed, the PCE should send a PCUpd message to synchronize with the egress PCC. If the egress PCC wishes to withdraw or modify a previously reported Path Segment value, it MUST send a PCRpt message without any PATH- SEGMENT TLV or with the PATH-SEGMENT TLV containing the new Path Segment respectively. If a PCE wishes to modify a previously requested Path Segment value, it MUST send a PCUpd message with PATH-SEGMENT TLV containing the new Path Segment value and P flag is LSP object would be unset. Absence of the PATH-SEGMENT TLV in PCUpd message means that the PCE wishes to withdraw the Path Segment. Li, et al. Expires September 9, 2019 [Page 14] Internet-Draft PCEP for SR Path Segment March 2019 If a PCC receives a valid Path Segment value from a PCE which is different than the current Path Segment, it MUST try to allocate the new value. If the new Path Segment is successfully allocated, the PCC MUST report the new value to the PCE. Otherwise, it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID failure") and Error Value = 2 ("Unable to allocate the specified label/SID"). Ingress Egress +-+-+ +-+-+ +-+-+ |PCC| |PCE| |PCC| +-+-+ +-+-+ +-+-+ 1) LSP State | ---- PCRpt ----> | | Delegate | Delegate=1 | | | P=1 |2) PCE update | | | the LSP-DB and | | | request Path SID | | | | | | --- PCInitiate ---> | Egress | | PATH-SEGMENT | allocates | | TLV in LSP | a Path-SID | | | from its | | <----- PCRpt ------ | space | | Path SID | | | | |<---- PCUpd ---- |3)Paths update with | | PATH-SEGMENT TLV | Path SID | | | | 4) LSP State | ----- PCRpt ---> | | Report | | | | | | Figure 8: Egress PCC Allocated Path Segment 5.2. PCE Allocated Path Segment 5.2.1. PCE Controlled Label Spaces Advertisement For allocating the Path Segments to SR paths by the PCEs, the PCE controlled label space MUST be known at PCEs via configurations or any other mechanism. The PCE controlled label spaces MAY be advertised as described in [I-D.li-pce-controlled-id-space]. 5.2.2. Ingress PCC request Path Segment to PCE The ingress PCC could request the Path Segment to be allocated by the PCE via PCRpt message as per [RFC8231]. The delegate flag (D-flag) Li, et al. Expires September 9, 2019 [Page 15] Internet-Draft PCEP for SR Path Segment March 2019 MUST also be set for this LSP. Also, the P-flag in the LSP object MUST be set. A PATH-SEGMENT TLV MUST be included in the LSP object. If the value of Path Segment is 0x0, it indicates that the Ingress PCC is requesting a Path Segment for this LSP. If the Path Segment is set to a value 'n', it indicates that the ingress PCC requests a specific value 'n' of Path Segment. If the Path Segment is allocated successfully, the PCE would further respond to Ingress PCC with PCUpd message as per [RFC8231] and MUST include the PATH-SEGMENT TLV in a LSP object. Else, it MUST send a PCErr message with Error-Type = TBA7 ("Path SID failure") and Error Value = 1 ("Invalid SID"). If the value of Path Segment is valid, but the PCC is unable to allocate the Path Segment, it MUST send a PCErr message with Error-Type = TBA7 ("Path label/SID failure") and Error Value = 2 ("Unable to allocate the specified label/SID"). The active PCE would allocate the Path Segment as per the PATH- SEGMENT flags and in case PATH-SEGMENT is not included, the PCE MUST act based on the local policy. The PCE would further inform the egress PCC about the Path Segment allocated by the PCE using the PCInitiate message as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr]. Ingress Egress +-+-+ +-+-+ +-+-+ |PCC| |PCE| |PCC| +-+-+ +-+-+ +-+-+ 1) LSP State | ---- PCRpt ----> | | Delegate | Delegate=1 | | | P=1 |2) PCE update | | | the LSP-DB and | | | allocate Path SID | |<---- PCUpd ---- |3)Paths update with | | PATH-SEGMENT TLV | Path SID | | | | 4) LSP State Report | ----- PCRpt ---> | | | | | |5) PCE informs the | --- PCInitiate ---> | | Path SID to Egress| FEC=Path | | | | | | <-------- PCRpt --- | | | | Figure 9: Ingress PCC request Path Segment to PCE Li, et al. Expires September 9, 2019 [Page 16] Internet-Draft PCEP for SR Path Segment March 2019 5.2.3. PCE allocated Path Segment on its own The PCE could allocate the Path Segment on its own for a PCE- Initiated (or delegated LSP). The allocated Path Segment needs to be informed to the Ingress and Egress PCC. The PCE would use the PCInitiate message [RFC8281] or PCUpd message [RFC8231] towards the Ingress PCC and MUST include the PATH-SEGMENT TLV in the LSP object. The PCE would further inform the egress PCC about the Path Segment allocated by the PCE using the PCInitiate message as described in [I-D.zhao-pce-pcep-extension-pce-controller-sr]. Ingress Egress +-+-+ +-+-+ +-+-+ |PCC| |PCE| |PCC| +-+-+ +-+-+ +-+-+ | | | | <--PCInitiate--- |1)Initiate LSP with | | PATH-SEGMENT TLV | Path SID | | | | 2)LSP delegation |---PCRpt, D=1---> | (Confirm) | | | | |3) PCE informs the | --- PCInitiate ---> | | Path SID to Egress| FEC=Path | | | | | | <-------- PCRpt --- | | | | Figure 10: PCE allocated Path Segment on its own 6. Dataplane Considerations As described in [I-D.cheng-spring-mpls-path-segment], in an SR-MPLS network, when a packet is transmitted along an SR path, the labels in the MPLS label stack will be swapped or popped. So that no label or only the last label may be left in the MPLS label stack when the packet reaches the egress node. Thus, the egress node cannot determine from which SR path the packet comes. For this reason, it introduces the Path Segment. Apart from allocation and encoding of the Path Segment (described in this document) for the LSP, it would also be included in the SID/ Label stack of the LSP (usually for processing by the egress). To support this, the Path Segment MAY also be a part of SR-ERO as prepared by the PCE as per [I-D.ietf-pce-segment-routing]. The PCC MAY also include the Path Segment while preparing the label stack based on the local policy and use-case. Li, et al. Expires September 9, 2019 [Page 17] Internet-Draft PCEP for SR Path Segment March 2019 It is important that the PCE learns the Maximum SID Depth (MSD) that can be imposed at each node/link of a given SR path to ensure that the SID stack depth does not exceed the number of SIDs the node is capable of imposing. As a new type of segment, Path Segment will be inserted in the SID list just like other SIDs. Thus, the PCE needs to consider the affect of Path Segment when computing a LSP with Path Segment allocation. 7. IANA Considerations 7.1. SR PCE Capability Flags SR PCE Capability TLV is defined in [I-D.ietf-pce-segment-routing], and the registry to manage the Flag field of the SR PCE Capability TLV is requested in [I-D.ietf-pce-segment-routing]. IANA is requested to make the following allocation in the aforementioned registry. Bit Description Reference TBA1 Path Segment Allocation is supported(P) This document 7.2. SRv6 PCE Capability Flags SRv6 PCE Capability TLV is defined in defined in [I-D.negi-pce-segment-routing-ipv6], and the registry to manage the Flag field of the SRv6 PCE Capability Flags is requested in [I-D.negi-pce-segment-routing-ipv6]. IANA is requested to make the following allocation in the aforementioned registry. Bit Description Reference TBA2 Path Segment Allocation is supported(P) This document 7.3. New LSP Flag Registry [RFC8231] defines the LSP object; per that RFC, IANA created a registry to manage the value of the LSP object's Flag field. IANA has allocated a new bit in the "LSP Object Flag Field" subregistry, as follows: Bit Description Reference TBA3 Request for Path Segment Allocation(P) This document Li, et al. Expires September 9, 2019 [Page 18] Internet-Draft PCEP for SR Path Segment March 2019 7.4. New PCEP TLV IANA is requested to add the assignment of a new allocation in the existing "PCEP TLV Type Indicators" subregistry as follows: Value Description Reference TBA4 PATH-SEGMENT TLV This document 7.4.1. Path Segment TLV This document requests that a new subregistry named "PATH-SEGMENT TLV Segment Type (ST) Field" to be created to manage the value of the ST field in the PATH-SEGMENT TLV. Value Description Reference 0 MPLS Path Segment(MPLS label) This document 1 SRv6 Path Segment(IPv6 address) This document Further, this document also requests that a new subregistry named "PATH-SEGMENT TLV Flag Field" to be created to manage the Flag field in the PATH-SEGMENT TLV. New values are assigned by Standards Action [RFC8126]. Each bit should be tracked with the following qualities: o Bit number (counting from bit 0 as the most significant bit) o Capability description o Defining RFC Bit Description Reference 7 Local Signification(L) This document 7.5. New CCI Flag Registry CCI object is defined in defined in [I-D.ietf-pce-pcep-extension-for-pce-controller], further [I-D.zhao-pce-pcep-extension-pce-controller-sr] defined a CCI object type for SR. and the subregistry to manage the Flag field of the CCI object for SR is requested in [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested to make the following allocation in the aforementioned subregistry. Li, et al. Expires September 9, 2019 [Page 19] Internet-Draft PCEP for SR Path Segment March 2019 Bit Description Reference TBA5 PCC is requested to This document allocate resource(C) 7.6. New FEC Type Registry A new PCEP object called FEC is defined in [I-D.zhao-pce-pcep-extension-pce-controller-sr]. IANA is requested to allocate a new Object-Type for FEC object in the "PCEP Objects" subregistry. Value Description Reference TBA6 SR path This document 7.7. PCEP Error Type and Value IANA is requested to allocate code-points in the "PCEP-ERROR Object Error Types and Values" subregistry for the following new error-types and error-values: Error-Type Meaning Reference TBA7 Path SID failure: This document Error-value = 1 Invalid SID Error-value = 2 Unable to allocate Path SID 8. Security Considerations TBA 9. Acknowledgments 10. Contributors The following people have substantially contributed to this document: Li, et al. Expires September 9, 2019 [Page 20] Internet-Draft PCEP for SR Path Segment March 2019 Dhruv Dhody Huawei Technologies Divyashree Techno Park, Whitefield Bangalore, Karnataka 560066 India Email: dhruv.ietf@gmail.com Quan Xiong ZTE Corporation No.6 Huashi Park Rd Wuhan, Hubei 430223 China Email: xiong.quan@zte.com.cn Zafar Ali Cisco Systems, Inc. Email: zali@cisco.com 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Li, et al. Expires September 9, 2019 [Page 21] Internet-Draft PCEP for SR Path Segment March 2019 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCE", RFC 8231, DOI 10.17487/RFC8231, September 2017, . [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., and D. Dhody, "Optimizations of Label Switched Path State Synchronization Procedures for a Stateful PCE", RFC 8232, DOI 10.17487/RFC8232, September 2017, . [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, . [I-D.ietf-pce-segment-routing] Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., and J. Hardwick, "PCEP Extensions for Segment Routing", draft-ietf-pce-segment-routing-16 (work in progress), March 2019. [I-D.negi-pce-segment-routing-ipv6] Negi, M., Li, C., Sivabalan, S., and P. Kaladharan, "PCEP Extensions for Segment Routing leveraging the IPv6 data plane", draft-negi-pce-segment-routing-ipv6-04 (work in progress), February 2019. [I-D.zhao-pce-pcep-extension-pce-controller-sr] Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of SR-LSPs", draft-zhao-pce-pcep- extension-pce-controller-sr-04 (work in progress), February 2019. [I-D.ietf-pce-pcep-extension-for-pce-controller] Zhao, Q., Li, Z., Negi, M., and C. Zhou, "PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) of LSPs", draft-ietf-pce-pcep- extension-for-pce-controller-01 (work in progress), February 2019. Li, et al. Expires September 9, 2019 [Page 22] Internet-Draft PCEP for SR Path Segment March 2019 [I-D.li-spring-srv6-path-segment] Li, C., Chen, M., Dhody, D., Li, Z., Dong, J., and R. Gandhi, "Path Segment for SRv6 (Segment Routing in IPv6)", draft-li-spring-srv6-path-segment-00 (work in progress), October 2018. 11.2. Informative References [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, DOI 10.17487/RFC4657, September 2006, . [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [I-D.li-pce-controlled-id-space] Li, C., Chen, M., Dong, J., Li, Z., Wang, A., and C. Zhou, "PCE Controlled ID Space", draft-li-pce-controlled-id- space-02 (work in progress), March 2019. [I-D.cheng-spring-mpls-path-segment] Cheng, W., Wang, L., Li, H., Chen, M., Gandhi, R., Zigler, R., and S. Zhan, "Path Segment in MPLS Based Segment Routing Network", draft-cheng-spring-mpls-path-segment-03 (work in progress), October 2018. Authors' Addresses Cheng Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: chengli13@huawei.com Li, et al. Expires September 9, 2019 [Page 23] Internet-Draft PCEP for SR Path Segment March 2019 Mach(Guoyi) Chen Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: Mach.chen@huawei.com Weiqiang Cheng China Mobile China Email: chengweiqiang@chinamobile.com Jie Dong Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: jie.dong@huawei.com Zhenbin Li Huawei Technologies Huawei Campus, No. 156 Beiqing Rd. Beijing 100095 China Email: lizhenbin@huawei.com Rakesh Gandhi Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Li, et al. Expires September 9, 2019 [Page 24]