]> Cisco Systems, Inc.

Eurovea Central 3. Bratislava 811 09 Slovakia ssidor@cisco.com

Airtel India

Praveen.Maheshwari@airtel.com

Nokia

andrew.stone@nokia.com

Verizon

luay.jalil@verizon.com

Huawei Technologies

pengshuping@huawei.com

PCE Working Group This document proposes a set of extensions for Path Computation Element Communication Protocol (PCEP) for Circuit Style Policies - Segment-Routing Policy designed to satisfy requirements for connection-oriented transport services. New TLV is introduced to control path recomputation and new flag to add ability to request path with strict hops only. 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.

Introduction Usage of Segment-routing and PCEP in connection-oriented transport services require path persistancy and hop-by-hop behavior for PCE computed paths. Circuit-Style Policy introduced in requires PCEP extensions, which are covered in this document. This document:

• Introduces possibility to request strict path from the PCE by extending LSP-EXTENDED-FLAG TLV
• Adding new TLV to encode information about disabling path recomputation for specific path to the PCE, to be carried inside the LSPA object, which is defined in .
• Clarifies usage of existing O-flag from RP object in Segment-routing

PCEP extensions described in this document can be used with any Path Setup Type.

Terminology The following terminologies are used in this document:

ERO:

Explicit Route Object

IGP:

Interior Gateway Protocol

LSP:

Label Switched Path.

LSPA:

Label Switched Path Attributes.

OTN:

Optical Transport Network.

PCC:

Path Computation Client

PCE:

Path Computation Element

PCEP:

Path Computation Element Protocol.

SDH:

Synchronous Digital Hierarchy

SID:

Segment Identifier

SONET:

Synchronous Optical Network

SR:

Segment Routing.

SR-TE:

Segment Routing Traffic Engineering.

Overview of Extensions to PCEP

New flag in the LSP-EXTENDED-FLAG TLV O-flag is proposed in the LSP-EXTENDED-FLAG TLV, which was introduced in 3.1 of . TLV format will be added after assigning O-flag bit position by IANA. O (Strict-Path): If set to 1, this indicates to the PCE that a path exclusively made of strict hops is required. Strict hop definition is described in Section 4.1

PATH-RECOMPUTATION TLV This document defines new TLV for the LSPA Object for encoding information whether path recomputation is allowed for delegated LSP. The TLV is optional. If the TLV is included in LSPA object, the PCE MUST NOT recompute path in cases specified by flags in the TLV. Type (16 bits): the value is TBD2 by IANA. Length (16 bits): 4 octets

Reserved:

MUST be set to zero by the sender and MUST be ignored by the receiver.

Flags:

This document defines the following flag bits. The other bits MUST be set to zero by the sender and MUST be ignored by the receiver.

• P (Permanent): If set to 1, the PCE MUST NOT recompute path even if current path is not satisfying path computation constraints. If this flag is cleared, then the PCE SHOULD recompute path if original path is invalidated.
• F (Force): If set to 1, the PCE MUST NOT update path. If flag is cleared, the PCE MAY update path based on explicit request from operator.

Operation

Strict path enforcement PCC MAY set the O flag in LSP-EXTENDED-FLAG TLV in PCRpt message to the PCE to indicate that a path exclusively made of strict hops is required. O flag cleared or LSP-EXTENDED-FLAG TLV not included indicates that a loose path is acceptable. In PCUpdate or PCInitiate messages, PCE MAY set O bit if strict path is provided. The flag is applicable only for stateful messages. Existing O flag in RP object MAY be used to indicate similar behavior in PCReq and PCRep messages as described in as described in Section 7.4.1 of . If O flag is set to 1 for both stateful and stateless messages for SR paths introduced in , PCE MUST use only SIDs, which will use explicitly specified adjacencies for packet forwarding. For example Adjacency SIDs MAY be used, but Prefix SIDs MUST NOT be used (even if there is only one adjacency).

Path recomputation PCC MAY set flags in PATH-RECOMPUTATION TLV to control path computation behavior on PCE side. If TLV is not included, then the PCE MAY use local policy to trigger path-computation or LSP path update. The presence of the TLV is blocking path recomputation based on various triggers like topology update, any periodic update or changed state of other LSPs in the network. LSP path MAY be modified if forwarded packets will still use same path - for example if same path can be encoded using Adjacency and Prefix SIDs, then PCE MAY switch between various representations of same path. If P flag is cleared, the PCE MAY recompute if current path is not considered valid, for example after topology update resulting in path not satisfying LSP's path constraints, but it MUST NOT recompute path if current path is not optimal. If P flag is set, the PCE MUST NOT recompute path during LSP lifetime even if path is invalidated. Only exception is explicit request from operator to recompute path If F flag is cleared, path update triggered manually by operator or any northbound interface of PCE MAY be done. If flag is set the PCE CAN update path only to tear down LSP by sending PCUpdate message with empty ERO. TLV MAY be included in PCInitiate and PCUpdate messages to indicate, which triggers will be disabled on the PCE. PCC should reflect flag values in PCRpt messages to forward requirement to other PCEs in the network.

All manageability requirements and considerations listed in , and apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section apply.

A PCE or PCC implementation MAY allow the capability of supporting PCEP extensions introduced in this document to be enabled/disabled as part of the global configuration.

An implementation SHOULD allow the operator to view the capability defined in this document. Section 4.1 and 4.1.1 of should be extended to include that capability for PCEP peer. Section 4.2 of module should be extended to add notification for blocked recomputation satisfying specified constraints if recomputation is blocked using PATH-RECOMPUTATION TLV.

Circuit-Style Policy draft is already describing connectivity verification and path validity considerations for Circuit Style Policies.

A PCE implementation SHOULD notify operator in case blocked recomputation for path, which is no longer satisfying specified constraints and it SHOULD allow the operator to view LSPs on PCE, which are not satisfying specified constraints.

The PCEP extensions defined in this document do not imply any new requirements on other protocols. Overall concept of Circuit Style policies requires interaction with other protocols, but those requirements are already described in .

The mechanisms defined in , , and also apply to the PCEP extensions defined in this document.

[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".

• Organization: Cisco Systems
• Implementation: IOS-XR PCC and PCE.
• Description: PCEP extensions supported using VENDOR-INFORMATION Object.
• Maturity Level: Production.
• Coverage: Partial.
• Contact: ssidor@cisco.com

The security considerations described in , , , and in itself. Note that this specification introduces possibility to block path recomputation after various topology events. This creates an additional vulnerability if the security mechanisms of , , and are not used. If there is no integrity protection on the session, then an attacker could block path updates from PCE potentially resulting in traffic drop.

IANA Considerations

LSP-EXTENDED-FLAG TLV defines the LSP-EXTENDED-FLAG TLV. IANA is requested to make the following assignment from the "LSP-EXTENDED-FLAG TLV Flag Field" registry:

Bit	Description	Reference
TBD1	Strict-Path Flag (O)	This document

PATH-RECOMPUTATION TLV IANA is requested to make the assignment of a new value for the existing "PCEP TLV Type Indicators" registry as follows:

TLV Type	TLV Name	Reference
TBD2	PATH-RECOMPUTATION TLV	This document

References Normative References 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. 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] 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. 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. ZTE Corporation RFC 8231 describes a set of extensions to Path Computation Element Communication Protocol (PCEP) to enable stateful control of MPLS-TE and GMPLS Label Switched Paths(LSPs) via PCEP. One of the extensions is the LSP object which includes a Flag field of the length of 12 bits. However, all bits of the Flag field have already been assigned in RFC 8231, RFC 8281 and RFC 8623. This document proposes to define a new LSP-EXTENDED-FLAG TLV for the LSP object for an extended flag field. 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. Informative References Cisco Systems, Inc. Cisco Systems, Inc. Airtel India Ciena Nokia This document describes how Segment Routing (SR) policies can be used to satisfy the requirements for strict bandwidth guarantees, end-to- end recovery and persistent paths within a segment routing network. SR policies satisfying these requirements are called "circuit-style" SR policies (CS-SR policies). The Path Computation Element Communication Protocol (PCEP) defines the mechanisms for the communication between a Path Computation Client (PCC) and a Path Computation Element (PCE), or among PCEs. This document describes PCEPS -- the usage of Transport Layer Security (TLS) to provide a secure transport for PCEP. The additional security mechanisms are provided by the transport protocol supporting PCEP; therefore, they do not affect the flexibility and extensibility of PCEP. This document updates RFC 5440 in regards to the PCEP initialization phase procedures. American National Standards Institute International Telecommunication Union Huawei Technologies Metaswitch Juniper Networks This document defines a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs. The data model includes configuration and state data. 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.

Contributors Bell Canada

daniel.voyer@bell.ca

Ciena

rrokui@ciena.com

Cisco Systems, Inc.

tsaad.net@gmail.com

Cisco Systems, Inc.

zali@cisco.com