]> Ribbon Communication

Yagia Kapaim 24 Petah Tikva Israel marina.fizgeer@rbbn.com

PCE Working Group The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to instantiate and manage Label Switched Paths (LSPs) on a Path Computation Client (PCC). A Stateful PCE RFC8231 can instantiate LSPs on a PCC. In some cases, the PCC shall perform additional validations and/or actions. If some validations or actions fail, the LSP will not be created and established or updated. This document specifies PCEP extensions to handle this situation gracefully in case the problem can be resolved by some network changes (freeing up resources, restoring or changing the network, and so on). This draft defines common usage of the new flag and known use cases for using this flag. Each draft relevant to LSP creation can add a corresponding bit to the use case list.

Introduction This document specifies PCEP extensions to handle the situation when LSP validation is failed. The goal is to handle it gracefully in case the problem can be resolved by some network changes (freeing up resources, restoring or changing the network, and so on).

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 This document uses the following terms defined in : PCC, PCE, PCEP Peer, and PCEP speaker. The base PCEP specification originally defined the use of the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. Over time, support for additional path setup types, such as SRv6, has been introduced . The term "LSP" is used extensively in PCEP specifications and, in the context of this document, refers to a Candidate Path within an SR Policy, which may be an SRv6 path (still represented using the LSP Object as specified in ).

Known use cases

Binding value is unavailable Initially defined in (draft-sidor-pce-binding-label-sid-extensions). Indicates that the PCEP peer supports LSP creation and fall back to dynamic binding value allocation if the specific binding value is unavailable.

Path (ERO list) is not passed resolution Indicates that the PCEP peer supports LSP creation if some ERO in the ERO list is unreachable, unknown.

S-BFD - Out Of Resources The PCEP peer supports LSP creation when the LSP is initiated with S-BFD enabled. However, if S-BFD resources are currently exhausted or have reached their maximum allocation, the LSP can still be created but may remain in a down state until resources become available.

PCEP Extensions

STATEFUL-PCE-CAPABILITY A new flag is proposed for the STATEFUL-PCE-CAPABILITY TLV, originally defined in Section 5.4 of . Also referenced in the "PCEP Binding SID Extensions". D (DOWN-CAPABILITY): If set, this flag indicates that the PCEP peer supports LSP creation even when certain validations or actions fail. In such cases, the LSP is instantiated but remains in a down state, allowing for potential recovery through network changes or further actions.

SRP Object: New optional TLV can be added to the SRP object, initially defined in .

SRP object new TLV

• D flag: If set, indicates that LSP can be created even if specified validation or action cannot be passed, but LSP will be in down state.
• Bit String (If flag D is 1): bit 0 - if specified binding value is unavailable (draft-sidor-pce-binding-label-sid-extensions) bit 1 - if specified path in ERO list is not passed resolution bit 2 - S-BFD leak of resources.

Processing The PCEP protocol extensions defined in this document MUST NOT be used if one or both PCEP speakers have not indicated support for the extensions by setting the D flag in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages. When a PCE wants to instantiate or update an LSP, in the PCInitiate or PCUpd message, the PCE can set the D flag in this TLV to control the PCC's behavior in case the requested LSP has some problem. If the PCC receives this new TLV with the D flag set and the bit is set in the string with relevant use case, the PCC MUST instantiate the LSP but keep it in a down state in case of relevant failure.

Handling of possible failures: Some failures can be resolved by the PCC. For example, ERO resolution may succeed after certain network changes (e.g., freeing up resources or restoring connectivity). In such cases, the PCC MUST update the state of the LSP and send a PCRpt message to the PCE. Other failures, such as S-BFD resource exhaustion, may require rechecking initiated by the PCE. Each use case and its corresponding behavior shall be defined in the relevant draft that utilizes the new D flag.

Manageability Considerations All manageability requirements and considerations listed in , , and apply to the PCEP extensions defined in this document. 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 advertised and received capabilities.

Security Considerations The security considerations described in , , and are applicable to this document. No additional security measures are required.

IANA Considerations

STATEFUL-PCE-CAPABILITY TLV Flag IANA maintains a registry, named "STATEFUL-PCE-CAPABILITY TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to make the following assignment:

New IANA request

SRP object IANA maintains a registry named "STATEFUL-PCE-CAPABILITY TLV Flag Field", within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to make the following assignment:

New TLV IANA request

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. In order to provide greater scalability, network confidentiality, and service independence, Segment Routing (SR) utilizes a Binding Segment Identifier (BSID), as described in RFC 8402. It is possible to associate a BSID to an RSVP-TE-signaled Traffic Engineering (TE) Label Switched Path (LSP) or an SR TE path. The BSID can be used by an upstream node for steering traffic into the appropriate TE path to enforce SR policies. This document specifies the concept of binding value, which can be either an MPLS label or a Segment Identifier (SID). It further specifies an extension to Path Computation Element Communication Protocol (PCEP) for reporting the binding value by a Path Computation Client (PCC) to the Path Computation Element (PCE) to support PCE-based TE policies. Informative References Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. 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.

Acknowledgements The author thanks for...