Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPsHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinamach.chen@outlook.comChina MobileChinachengweiqiang@chinamobile.comCisco Systems, Inc.Canadargandhi@cisco.comZTE CorporationChinaxiong.quan@zte.com.cn
RTG
pceBidirectional Co-routed SR LSPsReverse SR LSP
Segment Routing (SR) steers packets through a network using the IPv6 or MPLS data planes via source routing. Stateful Path Computation Element Communication Protocol (PCEP) extensions are defined for SR Traffic Engineering (TE) LSPs.
PCEP supports grouping two RSVP-TE signaled, unidirectional MPLS-TE Label-Switched Paths (LSPs) where a path in each direction in a network is grouped into an associated bidirectional LSP.
This document extends PCEP support to group two unidirectional SR LSPs into an associated bidirectional SR LSP. The mechanisms defined in this document apply to both stateless and stateful PCEs for PCE-initiated and PCC-initiated LSPs.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2026 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
() 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 Revised BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Revised BSD License.
Table of Contents
. Introduction
. Terminology
. Requirements Language
. Overview
. PCE-Initiated Associated Bidirectional SR LSPs
. PCC-Initiated Associated Bidirectional SR LSPs
. PCEP Extensions
. Bidirectional SR LSP Association Group
. Bidirectional LSP Association Group TLV
. PATH-ATTRIB Object
. MULTIPATH-OPPDIR-PATH TLV
. Additional PCEP Considerations
. PLSP-ID Usage
. Error Handling
. Security Considerations
. Operational Considerations
. Control of Function and Policy
. Information and Data Models
. Liveness Detection and Monitoring
. Verify Correct Operations
. Requirements on Other Protocols
. Impact on Network Operations
. IANA Considerations
. Association Type
. References
. Normative References
. Informative References
Acknowledgments
Contributors
Authors' Addresses
IntroductionSegment Routing (SR) can
be used to steer packets through a network employing source routing.
SR can be applied to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes.
describes the Path Computation Element (PCE)
Communication Protocol (PCEP).
specifies a set of extensions to PCEP to
enable stateful control of Traffic Engineering (TE) Label Switched Paths
(LSPs) within and across PCEP sessions.
As described in , a PCE can be either stateful or stateless.
specifies extensions to the PCEP for SR networks that
allow a stateful PCE to compute and initiate SR TE paths, as well as a
Path Computation Client (PCC) to request, report, or delegate them.
There are features such as directed Bidirectional Forwarding Detection (BFD)
and Performance Measurement
that require the ingress
node (PCC) to be aware of the reverse direction SR path.
For such features, the reverse SR paths need to be communicated to the ingress
nodes (PCCs) using PCEP mechanisms. This allows both endpoint
nodes to be aware of the forward and reverse SR paths.
An SR Policy contains one or more Candidate Paths (CPs), which may be computed by a PCE.
A Candidate Path of an SR Policy can contain one or more Segment Lists (SLs).
In PCEP messages, an SL is encoded as an Explicit Route Object (ERO)
as described in .
defines PCEP extensions for carrying
multiple SLs in the PCEP messages along with their opposite direction SLs,
as described in .
As per , TE LSPs can be associated by adding
them to a common association group by a PCEP peer.
uses the association group object to group two unidirectional
RSVP-TE LSPs into an associated bidirectional LSP for both stateful and stateless PCE.
This document extends this procedure and allows grouping two unidirectional SR LSPs
into an associated bidirectional SR LSP for co-routed and non-co-routed paths.
This extension also utilizes the procedure
defined in to carry the multiple EROs
and the associated reverse path EROs for an SR LSP.
Note that the association group and the procedure introduced in this document
are specific to SR-TE and SRv6 Path Setup Types.
TerminologyThe reader is assumed to be familiar with the
terminology defined in , , , ,
, and .This document uses the following terms defined in :
Explicit Route Object (ERO), Path Computation Client (PCC), Path Computation Element (PCE),
Path Computation Element Communication Protocol (PCEP), PCEP peer, and PCEP speaker.This document extends the following term defined in :
Label Switched Path (LSP) - the base PCEP specification originally defined the
PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the
RSVP-TE signaling protocol.
As specified in , the term "LSP"
used in the PCEP specifications would be equivalent to an SRv6 path
(represented as a list of SRv6 segments) in the context of supporting
SRv6 in PCEP using the SRv6 Path Setup Type.
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.
OverviewAssociated bidirectional SR LSPs can be created and updated by a Stateful PCE or by a PCC
as described in the subsections below for the case when there are no errors encountered and all operations are successful.
PCE-Initiated Associated Bidirectional SR LSPsHigh-level steps for creating associated bidirectional SR LSPs by a Stateful PCE are shown in Figures and .
Step 1 - Stateful PCE Behavior:Stateful PCE creates and updates the SR LSP and the associated reverse SR LSP EROs,
for the "Bidirectional SR LSP Association" with the Association ID 1
on a PCC via PCInitiate and PCUpd messages, respectively.Step 1: PCE-Initiated Associated Bidirectional SR LSP with Forward-Direction LSPs and Reverse-Direction EROs
+-----+
| PCE |
+-----+
PCInitiate: / \ PCInitiate:
Tunnel 1 (0) / \ Tunnel 2 (0)
LSP1 (F1, R2) / \ LSP2 (F2, R1)
Association ID 1 / \ Association ID 1
(Single LSP) / \ (Single LSP)
v v
+-----+ LSP1 +-----+
| S |------------>| D |
| |<------------| |
+-----+ LSP2 +-----+
<no signaling>
F1 and F2 =
Forward LSP EROs
R1 and R2 =
Reverse LSP EROs
0 =
PLSP-ID
S =
Source
D =
Destination
Step 2 - PCC Behavior:The PCC, upon receiving the PCInitiate for the SR LSP and the associated reverse SR LSP EROs, locally assigns a
PCEP-specific Identifier for the LSP (PLSP-ID) and reports it to the PCE via a PCRpt message.
Step 2: PCC-Reported Bidirectional SR LSP with Forward-Direction LSPs and Reverse-Direction EROs
+-----+
| PCE |
+-----+
PCRpt: ^ ^ PCRpt:
Tunnel 1 (100) / \ Tunnel 2 (200)
LSP1 (F1, R2==F2) / \ LSP2 (F2, R1==F1)
Association ID 1 / \ Association ID 1
(Single LSP) / \ (Single LSP)
/ \
+-----+ LSP1 +-----+
| S |------------>| D |
| |<------------| |
+-----+ LSP2 +-----+
<no signaling>
F1 and F2 =
Forward LSP EROs
R1 and R2 =
Reverse LSP EROs
100 and 200 =
PLSP-IDs
S =
Source
D =
Destination
PCC-Initiated Associated Bidirectional SR LSPsHigh-level steps for creating associated bidirectional SR LSPs by a PCC are shown in Figures and .
Step 1 - PCC Behavior:PCC creates and updates an SR LSP for the "Bidirectional SR LSP Association" with the Association ID 2 and
reports the change in the association group of an SR
LSP to PCE(s) via a PCRpt message.Step 1: PCC-Initiated Associated Bidirectional SR LSP with Forward-Direction LSP
+-----+
| PCE |
+-----+
Report/Delegate: ^ ^ Report/Delegate:
Tunnel 1 (100) / \ Tunnel 2 (200)
LSP1 (F1) / \ LSP2 (F2)
Association ID 2 / \ Association ID 2
/ \
/ \
+-----+ LSP1 +-----+
| S |------------>| D |
| |<------------| |
+-----+ LSP2 +-----+
<no signaling>
F1 and F2 =
Forward LSP EROs
100 and 200 =
PLSP-IDs
S =
Source
D =
Destination
Step 2 - Stateful PCE Behavior:Stateful PCE updates the SR LSP and the associated reverse SR LSP EROs, for the "Bidirectional SR LSP Association" on a PCC via a PCUpd message. Step 2: PCE-Updated Associated Bidirectional SR LSP with Forward-Direction LSPs and Reverse-Direction EROs
+-----+
| PCE |
+-----+
PCUpd: / \ PCUpd:
Tunnel 1 (100) / \ Tunnel 2 (200)
LSP1 (F1, R2==F2) / \ LSP2 (F2, R1==F1)
Association ID 2 / \ Association ID 2
(Single LSP) / \ (Single LSP)
v v
+-----+ LSP1 +-----+
| S |------------>| D |
| |<------------| |
+-----+ LSP2 +-----+
<no signaling>
F1 and F2 =
Forward LSP EROs
R1 and R2 =
Reverse LSP EROs
100 and 200 =
PLSP-IDs
S =
Source
D =
Destination
PCEP ExtensionsTwo unidirectional SR LSPs (one in each
direction between two nodes in a network) can be associated together by using the
association group defined in this document for the PCEP messages and employing the
procedures defined in and .Bidirectional SR LSP Association GroupFor associating two unidirectional SR LSPs, this document defines
a new Association Type called "Bidirectional SR LSP
Association" for the Association Group object (Class-Value 40) as follows:
Association Type (value 8) = Bidirectional SR LSP Association
The handling of the Association ID, Association Source, optional
Global Association Source and optional Extended Association ID in this
association are set as defined in . specifies the mechanism for the capability
advertisement of the Association Types supported by a PCEP speaker by
defining an ASSOC-Type-List TLV (value 35) to be carried within an
OPEN object. The PCEP speaker MUST include the "Bidirectional SR LSP
Association" type in the ASSOC-Type-List TLV and MUST receive the same
from the PCEP peer before using it in the PCEP messages.An SR LSP MUST NOT be part of more than
one "Bidirectional SR LSP Association" on a PCE.
A PCE, upon detecting this condition, MUST NOT send the associated reverse
EROs to the ingress node PCC.
This error condition MUST be logged and an alarm MUST be generated.
Bidirectional LSP Association Group TLV
A PCEP message for an associated bidirectional SR LSP
MAY include the "Bidirectional LSP Association Group TLV" to indicate
the co-routed path using the C flag defined in .
As there is no reverse SR LSP instantiated,
the Reverse LSP (R flag) MUST NOT be set for an associated bidirectional SR LSP
and MUST be ignored. This error condition MUST be logged and an alarm MUST be generated.
PATH-ATTRIB Object
When a PCE informs an ingress node PCC about the associated reverse SR LSP EROs computed for an SR LSP with
the "Bidirectional SR LSP Association", it MUST include
the "PATH-ATTRIB" object with the Reverse (R flag) set to 1 to indicate
that the ERO is for the reverse direction .
MULTIPATH-OPPDIR-PATH TLV
The PCE MAY include
the "MULTIPATH-OPPDIR-PATH TLV" to indicate the co-routed path properties (in the N-flag and L-flag)
for the reverse ERO for an SR LSP.
The PCC MUST detect the mismatch between the co-routed path properties in the "MULTIPATH-OPPDIR-PATH TLV" for the reverse ERO and
the co-routed path (C) flag in the "Bidirectional LSP Association Group TLV" for the (forward) SR LSP
and log it as an error condition and generate an alarm.
Additional PCEP ConsiderationsAdditional considerations for associating bidirectional SR LSPs are summarized in the subsections below.
PLSP-ID UsageAs per , an ingress node PCC reports a unique PLSP-ID for each LSP of an SR Policy.
For an associated bidirectional SR LSP,
the PCE will maintain two PLSP-IDs, one from the ingress node PCC and one from the egress node PCC.
In the examples shown in Figures and , the ingress node PCC (node S) reports Tunnel 1, LSP1 to the PCE
with PLSP-ID 100 whereas the egress node PCC (node D) reports Tunnel 2, LSP2 to the PCE with PLSP-ID 200.
Error HandlingThe error handling as described in
continues to apply for the "Bidirectional SR LSP Association".
The PCEP Path Setup Type (PST) for SR LSP uses either value "1: Traffic-engineering path is set up using Segment Routing"
or "3: Traffic engineering path is set up using SRv6" .
If a PCEP speaker receives a non-SR LSP PST value for the "Bidirectional
SR LSP Association", the PCEP speaker MUST return a PCErr message with
Error-Type = 26 (Association Error) and Error-value = "16: Path Setup Type not supported" .
Security ConsiderationsThe security considerations described in ,
, , , ,
and apply to the extensions defined in this document as well.A new Association Type for the Association object,
"Bidirectional SR LSP Association", is introduced in this
document. Additional security considerations related to LSP associations
due to a malicious PCEP speaker are described in and apply to this Association Type. Hence, securing
the PCEP session using Transport Layer Security (TLS) , ,
as per the recommendations and best current practices in is RECOMMENDED.
Operational ConsiderationsThe manageability requirements and considerations listed in , , , ,
and apply to the PCEP protocol extensions defined in this
document. In addition, the operational requirements and considerations listed in this
section apply.Control of Function and PolicyThe mechanisms defined in this document do not imply any new control or
policy requirements.
Information and Data Models describes the PCEP MIB; there are no new
MIB Objects defined for LSP associations.
The PCEP YANG module defines a data model for LSP associations.
However, it does not include information for associated bidirectional SR LSPs.
It can be extended to include data related to the associated bidirectional SR LSPs, such as:
Indication of whether the associated bidirectional SR LSPs are supported
Enablement and disablement of the bidirectional SR LSP association
Counters for the successfully associated bidirectional SR LSPs
Counters for the SR LSPs that failed to form a bidirectional association
Liveness Detection and MonitoringMechanisms defined in this document do not imply any new liveness
detection and monitoring requirements as they are performed independently on both sides of a bidirectional SR LSP,
using the forward and reverse LSP paths of the bidirectional SR LSP.
However, the monitoring on both sides of a bidirectional SR LSP needs to be correlated at the management level to ensure that
the bidirectional service carried by the bidirectional SR LSP is operational.
Verify Correct OperationsMechanisms defined in this document do not imply any new operation
verification requirements.
Requirements on Other ProtocolsMechanisms defined in this document do not imply any new
requirements on other protocols.Impact on Network OperationsAssociating two SR LSPs to form an associated bidirectional SR LSP requires an operator to ensure that
the correct LSP associations are employed on both sides of the bidirectional SR LSP.
Tools such as directed BFD and Performance Measurement
can be used to verify the correct operation of a bidirectional SR LSP.
IANA ConsiderationsAssociation TypeIANA has registered the following Association Type
for the Association Group object (Class-Value 40) in the "ASSOCIATION Type Field" registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group (see ):
Type
Name
Reference
8
Bidirectional SR LSP Association
RFC 10067
ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn 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.Multiprotocol Label Switching ArchitectureThis document specifies the architecture for Multiprotocol Label Switching (MPLS). [STANDARDS-TRACK]Path Computation Element (PCE) Communication Protocol (PCEP)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]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 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.Path Computation Element Communication Protocol (PCEP) Extensions for Stateful PCEThe 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.PCEPS: Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)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.Path Computation Element Communication Protocol (PCEP) Extensions for PCE-Initiated LSP Setup in a Stateful PCE ModelThe 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.Segment Routing ArchitectureSegment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.Conveying Path Setup Type in PCE Communication Protocol (PCEP) MessagesA 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.Path Computation Element Communication Protocol (PCEP) Extensions for Segment RoutingSegment 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.Path Computation Element Communication Protocol (PCEP) Extensions for Establishing Relationships between Sets of Label Switched Paths (LSPs)This document introduces a generic mechanism to create a grouping of Label Switched Paths (LSPs) in the context of a Path Computation Element (PCE). This grouping can then be used to define associations between sets of LSPs or between a set of LSPs and a set of attributes (such as configuration parameters or behaviors), and it is equally applicable to the stateful PCE (active and passive modes) and the stateless PCE.Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Label Switched Paths (LSPs)This document defines Path Computation Element Communication Protocol (PCEP) extensions for grouping two unidirectional MPLS-TE Label Switched Paths (LSPs), one in each direction in the network, into an associated bidirectional LSP. These PCEP extensions can be applied either using a stateful PCE for both PCE-initiated and PCC-initiated LSPs or using a stateless PCE. The PCEP procedures defined are applicable to the LSPs using RSVP-TE for signaling.Segment Routing Policy ArchitectureSegment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are used to protect data exchanged over a wide range of application protocols and can also form the basis for secure transport protocols. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases.RFC 7525, an earlier version of the TLS recommendations, was published when the industry was transitioning to TLS 1.2. Years later, this transition is largely complete, and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, this document updates RFCs 5288 and 6066 in view of recent attacks.Path Computation Element Communication Protocol (PCEP) Extensions for IPv6 Segment RoutingSegment 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.Updates to the Usage of TLS to Provide a Secure Transport for the Path Computation Element Communication Protocol (PCEP)Section 3.4 of RFC 8253 specifies TLS connection establishment restrictions for PCEPS; PCEPS refers to usage of TLS to provide a secure transport for the Path Computation Element Communication Protocol (PCEP). This document adds restrictions to specify what PCEPS implementations do if they support more than one version of the TLS protocol and to restrict the use of TLS 1.3's early data.Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath InformationCiena CorporationCisco Systems.Informative ReferencesA Path Computation Element (PCE)-Based ArchitectureConstraint-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.Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) ModuleThis memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for modeling of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.Simple Two-Way Active Measurement Protocol (STAMP) Extensions for Segment Routing NetworksSegment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) forwarding planes. This document specifies Simple Two-Way Active Measurement Protocol (STAMP) extensions (as described in RFC 8762) for SR networks, for both the SR-MPLS and SRv6 forwarding planes, by augmenting the optional extensions defined in RFC 8972.Bidirectional Forwarding Detection (BFD) Reverse Path for MPLS Label Switched Paths (LSPs)Bidirectional Forwarding Detection (BFD) is expected to be able to monitor a wide variety of encapsulations of paths between systems. When a BFD session monitors an explicitly routed unidirectional path, there may be a need to direct the egress BFD peer to use a specific path for the reverse direction of the BFD session. This document describes an extension to the MPLS Label Switched Path (LSP) echo request that allows a BFD system to request that the remote BFD peer transmit BFD control packets over the specified LSP.A YANG Data Model for the Path Computation Element Communication Protocol (PCEP)This document defines a YANG data model for the management of the Path Computation Element Communication Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs.Acknowledgments
Many thanks to , , , , , and for the detailed review of this document and
for providing many useful comments.
Also, thank you, , for the RtgDir Early review, for the OpsDir review,
for the Shepherd review, for the WG AD review, for Genart review, and ,
, , , , and for the IESG review, which helped
improve this document.ContributorsThe following people have substantially contributed to this document:Huawei TechnologiesDivyashree Techno Park, WhitefieldBangaloreKarnataka560066Indiadhruv.ietf@gmail.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinalizhenbin@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinajie.dong@huawei.comAuthors' AddressesHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinac.l@huawei.comHuawei TechnologiesHuawei Campus, No. 156 Beiqing Rd.Beijing100095Chinamach.chen@outlook.comChina MobileChinachengweiqiang@chinamobile.comCisco Systems, Inc.Canadargandhi@cisco.comZTE CorporationChinaxiong.quan@zte.com.cn