]> Nokia

andrew.stone@nokia.com

Ciena

mkoldych@proton.me

Ciena

ssivabal@ciena.com

Nokia

diego.achaval@nokia.com

Huawei Technologies

pengshuping@huawei.com

Juniper Networks, Inc

hkotni@juniper.net

Cisco

ssidor@cisco.com

Routing PCE Working Group This document updates RFC8231 and RFC8664 to reflect operationalized implementations and define optimizations in the PCEP protocol.

Introduction The PCEP protocol has evolved from a stateless protocol to a stateful protocol , incorporating numerous extensions. During interoperability testing it was observed that various implementations have implemented optimizations in the protocol. This document serves to optimize the original procedure in to optionally drop the PCReq and PCReply exchange, which greatly simplifies implementation and optimizes the protocol. In addition, introduced extensions for Segment Routing and the encoding of segments in the ERO and RRO objects in PCEP. This document serves as an update to to permit the exclusion of the RRO object for Segment Routed paths Note: the content in this document originated from version 07, which has been branched to become a standards updating document while is to become an informational document.

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 when, and only when, they appear in all capitals, as shown here.

Stateful Bringup Section 5.8.2, allows delegation of an LSP in operationally down state, but at the same time mandates the use of PCReq, before sending PCRpt. In this document, we would like to make it clear that sending PCReq is optional. We shall refer to the process of sending PCReq before PCRpt as "stateless bringup". In reality, stateless bringup introduces overhead and is not possible to enforce from the PCE, because the stateless PCE is not required to keep any per-LSP state about previous PCReq messages. It was found that many vendors choose to ignore this requirement and send the PCRpt directly, without going through PCReq. Even though this behavior is against , it offers some advantages and simplifications, as will be explained in this section. This document therefore updates . Even though all the major vendors today are moving to the stateful PCE model, it does not deprecate the need for stateless PCEP. The key property of stateless PCEP is that PCReq messages do not modify the state of the PCE LSP-DB. Therefore, PCReq messages are useful for many OAM ping/traceroute applications where the PCC wishes to probe the network topology without having any effect on the existing LSPs.

Updates to RFC 8231 Section 5.8.2, says "The only explicit way for a PCC to request a path from the PCE is to send a PCReq message. The PCRpt message MUST NOT be used by the PCC to attempt to request a path from the PCE." In this document we update to remove the quoted text. As part of the new bringup procedure, the PCC MAY delegate an empty LSP (no ERO or empty ERO) to the PCE and then wait for the PCE to send PCUpd, without sending PCReq. We shall refer to this process as "stateful bringup". The PCE MUST support the original stateless bringup, for backward compatibility purposes. Supporting stateful bringup should not require introducing any new behavior on the PCE, because as mentioned earlier, the PCE does not modify LSP-DB state based on PCReq messages. So whether the PCE has received a PCReq or not, it would process the PCRpt all the same. An example of stateful bringup follows. In our example the PCC starts off by using LSP-ID of 0. The value 0 does not hold any special meaning, any other 16-bit value could have been used. PCC has no LSP yet, but wants to establish a path. PCC sends PCRpt(R-FLAG=0, D-flag=1, OPER-FLAG=DOWN, PLSP-ID=100, LSP-ID=0, ERO={}). Content of LSP DB after first PcRpt

TUNNEL	LSP
PLSP-ID=100	OLSP-ID=0, D-flag=1, OPER=DOWN, ERO={}

PCC received a PCUpd from the PCE and has decided to install the ERO={A} from that PCUpd. PCC sends PCRpt(R-FLAG=0, D-flag=1, OPER- FLAG=UP, PLSP-ID=100, LSP-ID=0, ERO={A}). Content of LSP DB after PcUpd

TUNNEL	LSP
PLSP-ID=100	LSP-ID=0, D-flag=1, OPER=UP, ERO={A}

Use of SR-RRO and SRv6-RRO objects defines a PCRpt message which contains <intended-path> known as the ERO object and <actual-path> known as the RRO object. defines SR-ERO and SR-RRO sub-objects for SR-TE LSPs. further defines SRv6-ERO and SRv6-RRO sub-objects for SRv6-TE paths. In practice RRO data is the result of signalling via a protocol such as RSVP-TE, which allows collection of per-hop information along the path. The ERO and RRO values may be different as the path encoded in the ERO may differ than the RRO such as during protection conditions or if the ERO contains loose hops which are expanded upon. As Segment Routing LSP does not perform any signalling, the values of an SR-ERO/SRv6-ERO and SR-RRO/SRv6-RRO (respectively) are in practice the same, therefore some implementations have omitted the RRO when reporting a SR-TE LSP while others continue to send both ERO and RRO values. This document updates by clarifying and relaxing requirement for both an ERO and RRO object to exist for SR-TE paths. If both ERO and RRO are present for the same LSP, it SHOULD be interpreted as the RRO being the actual path the LSP is taking but MAY interpret only the ERO as the actual path. In the absence of RRO a PCE MUST interpret the ERO as the actual path for the LSP. Until SR-TE introduces some form of signaling similar to RSVP-TE, the use of RRO is discouraged for SR-TE LSPs.

Security Considerations TODO

Managability Considerations TODO

IANA Considerations This document has no IANA actions.

References Normative References This document specifies the Path Computation Element (PCE) Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a PCE, or between two PCEs. Such interactions include path computation requests and path computation replies as well as notifications of specific states related to the use of a PCE in the context of Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering. PCEP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future. [STANDARDS-TRACK] The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. Although PCEP explicitly makes no assumptions regarding the information available to the PCE, it also makes no provisions for PCE control of timing and sequence of path computations within and across PCEP sessions. This document describes a set of extensions to PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP. Segment Routing (SR) enables any head-end node to select any path without relying on a hop-by-hop signaling technique (e.g., LDP or RSVP-TE). It depends only on "segments" that are advertised by link-state Interior Gateway Protocols (IGPs). An SR path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), an explicit configuration, or a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. This document updates RFC 8408. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Ciena Corporation Ciena Corporation Huawei Technologies Nokia Juniper Networks, Inc Nokia This document clarifies certain aspects of the PCEP protocol. The content of this document has been compiled based on several interop exercises. Segment Routing (SR) can be used to steer packets through a network using the IPv6 or MPLS data plane, employing the source routing paradigm. An SR Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since SR can be applied to both MPLS and IPv6 data planes, a PCE should be able to compute an SR Path for both MPLS and IPv6 data planes. The Path Computation Element Communication Protocol (PCEP) extension and mechanisms to support SR-MPLS have been defined. This document outlines the necessary extensions to support SR for the IPv6 data plane within PCEP.

Acknowledgments The authors would like to thank Adrian Farrel for useful review comments on which have been carried over and have been applied into this document.