]> Nokia

andrew.stone@nokia.com

Huawei

c.l@huawei.com

Cisco

ssidor@cisco.com

Routing PCE Working Group This document describes extensions to the Path Computation Element (PCE) Communication Protocol (PCEP) to permit a PCEP Speaker to update information previously exchanged during PCEP session establishment via the Open message. Discussion Venues Discussion of this document takes place on the Path Computation Element Working Group mailing list (pce@ietf.org), which is archived at . Source for this draft and an issue tracker can be found at .

Introduction The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computations in response to requests from Path Computation Clients (PCCs). outlines the message exchange procedures that PCEP Speakers must follow upon initial connection to establish a PCEP Session. This procedure includes sending an Open Message containing an OPEN Object, which conveys various session characteristics such as protocol timers. The OPEN Object can be extended with TLVs to convey additional session characteristics, such as PCE capabilities (e.g., ) or specific values and ranges (e.g., and ). This information is exchanged only once per session and cannot be dynamically modified without tearing down and re-establishing the PCEP session, which can be operationally disruptive. Additionally, specify a Notification Message (PCNtf) containing a NOTIFICATION Object, which a PCEP Speaker may use to notify the other speaker of an event. This document proposes a generic mechanism allowing a PCEP Speaker (PCC or PCE) to update previously exchanged Open Message information using a PCNtf Message with a new notification called "Open Refresh". This approach mitigates the need to terminate the session to modify any exchanged information. Note that also proposes using PCNtf Message to relay Open Messages between PCEs about each PCE's connected peers. It is anticipated that will use a similar notification mechanism with a unique notification type, as the semantics of a PCEP Speaker exchanging its information differ from exchanging information related to a connected state-sync PCEs. This document describes a generic extension and mechanism to update Open Object content but future documents MAY describe further semantics on a per TLV basis.

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.

Terminology Open Refresh: The act of modifying content previously exchanged during PCEP Open Message in an ad-hoc manner without terminating the PCEP session. Open Refresh Notification message: An Open Refresh notification message is a new Notification Type to be used in the PCNtf Message () that will also contain the open information to be refreshed.

Operational Considerations This section discusses some high-level considerations that should be considered when supporting Open Refresh. While scenarios described here exist in present-day PCEP, they require explicitly tearing down the PCEP session which gives a clear indication of potential system impact. With ad-hoc manipulation of open information, the impact of a possible change may not be evident so this section attempts to describe some of these considerations.

Capability Change One use case of the Open message is to exchange device software capabilities and feature enablement to determine whether a PCEP Speaker may support a given operation defined in PCEP extensions. If a PCEP speaker supports removal of a capability using Open Refresh, then all states related to the capability MUST be reset and removed and MUST follow the guidelines set out by the capability should the other PCEP speaker no longer support the capability. This may impact device-wide state and network traffic. For example, defines the STATEFUL-PCE-CAPABILITY-TLV to indicate support for PCE-Initiated LSPs. The removal of this capability would result in PCE-Initiated LSPs being deleted from each PCEP Speaker.

Node-wide Property Change One use case of the Open message is to exchange device-level configurations or settings. In the case of statefully delegated LSPs (, the modification of these values may trigger path calculations for established LSPs with a possibility of LSP tear down.

Frequency of Open Refresh A PCEP implementation should consider the impact on the entire network before sending frequent Open Refresh Notifications. It could consider applying some form of dampening or back-off mechanism.

Procedures

Capability Advertisement A PCEP Speaker indicates support of Open Refresh during the PCEP Initialization phase (). As per , a PCEP Speaker sends an Open Message with exactly one OPEN object. This document defines a new flag, OPEN-REFRESH-CAPABILITY (R-bit), in the Open Message Flags field to indicate the support of the Open Refresh feature.

• R (OPEN-REFRESH-CAPABILITY - 1 bit - TBD1): If set to 1 by a PCEP speaker, the PCEP speaker indicates that the PCEP speaker supports updating the information in the Open message without resetting the session.

If a PCEP speaker receives an Open Message that does not set the OPEN-REFRESH-CAPABILITY flag, the PCEP Speaker MUST NOT send Open Refresh messages to the remote PCEP speaker.

Open Refresh An Open Refresh is transmitted by sending a PCNtf Message () containing a NOTIFICATION Object with Notification-type=TBD2 (Open-Refresh):

• Notification-value=1: Refresh the Open information. The NOTIFICATION Object encodes any TLV that can be encoded in an OPEN Object. The NOTIFICATION Object contains a snapshot of all unmodified and modified TLVs. Upon receiving an Open-Refresh Notification message, the PCEP Speaker compares the newly received TLVs with the previously received TLVs to determine what has changed. An omission of a TLV MUST be treated as a removal of the TLV and perform a necessary side effect(s) to the system state as if the TLV was never exchanged during session establishment via Open message.

Adding/removing values or Sub-TLVs If the PCEP Speaker determines it cannot support the Open-Refresh differential change(s), the PCEP Speaker generates a PCEP Error (PCErr) with Error-type=TBD3 (Unsupported-Open-Refresh) and error-value TBD4 and it SHOULD terminate the PCEP session.

Security Considerations TODO Security

Managability Considerations TODO

Implementation Status [Note to the RFC Editor - remove this section before publication, as well as remove the reference to RFC 7942.] This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in . The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist. According to , "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".

IANA Considerations

Open Object Flag Field IANA is requested to allocate a new bit value in the "Open Object Flag Field" registry:

Bit	Description	Reference
TBD1	OPEN-REFRESH-CAPABILITY	This document

NOTIFICATION Object IANA is requested to allocate a new Notification-type value in the "Notification Object" registry:

Notification-type	Name	Reference
TBD2	Open-Refresh	This document
	Notification-value
	1: Refresh the Open information

PCEP Error IANA is requested to allocate a new Error-type value in the "PCEP-ERROR Object Error Types and Values" registry:

Error-type	Meaning	Error-value	Reference
TBD3	Open-Refresh Error	1: Open-Refresh is not supported	This document

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] 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 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. A Path Computation Element (PCE) can compute Traffic Engineering (TE) paths through a network; these paths are subject to various constraints. Currently, TE paths are Label Switched Paths (LSPs) that are set up using the RSVP-TE signaling protocol. However, other TE path setup methods are possible within the PCE architecture. This document proposes an extension to the PCE Communication Protocol (PCEP) to allow support for different path setup methods over a given PCEP session. 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. 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. The extensions for stateful PCE provide active control of Multiprotocol Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE LSPs) via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. This document describes the creation and deletion of PCE-initiated LSPs under the stateful PCE model. This document describes a simple process that allows authors of Internet-Drafts to record the status of known implementations by including an Implementation Status section. This will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. This process is not mandatory. Authors of Internet-Drafts are encouraged to consider using the process for their documents, and working groups are invited to think about applying the process to all of their protocol specifications. This document obsoletes RFC 6982, advancing it to a Best Current Practice. Huawei Technologies Huawei Technologies China Telecom China Mobile HPE The Path Computation Element Communication Protocol (PCEP) provides a mechanism for the Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. Furthermore, PCE can be used for computing paths in the SR networks. Stateful PCE provides active control of MPLS-TE LSPs via PCEP, for a model where the PCC delegates control over one or more locally configured LSPs to the PCE. Further, stateful PCE could also create and remove PCE-initiated LSPs by itself. A PCE-based Central Controller (PCECC) simplify the processing of a distributed control plane by integrating with elements of Software-Defined Networking (SDN). In some use cases, such as PCECC or Binding Segment Identifier (SID) for Segment Routing (SR), there are requirements for a stateful PCE to make allocation of labels, SIDs, etc. These use cases require PCE aware of various identifier spaces from where to make allocations on behalf of a PCC. This document describes a generic mechanism for a PCC to inform the PCE of the identifier space set aside for the PCE control via PCEP. The identifier could be an MPLS label, a SID, or any other to-be-defined identifier that can be allocated and managed by the PCE. Cisco Ciena Corporation Huawei Technologies Huawei Technologies The Path Computation Element (PCE) Communication Protocol (PCEP) provides mechanisms for PCEs to perform path computation in response to a Path Computation Client (PCC) request. The Stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. A Path Computation Client (PCC) can synchronize an LSP state information to a Stateful Path Computation Element (PCE). A PCC can have multiple PCEP sessions towards multiple PCEs. There are some use cases, where an inter-PCE stateful communication can bring additional resiliency in the design, for instance when some PCC-PCE session fails. This document describes the procedures to allow a stateful communication between PCEs for various use-cases and also the procedures to prevent computations loops.

Acknowledgments The authors would like to acknowledge Dhruv Dhody for the discussion and ideas related to this document.