Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs

Internet Engineering Task Force (IETF)                        C. Li, Ed.
Request for Comments: 10067                                      M. Chen
Category: Standards Track                            Huawei Technologies
ISSN: 2070-1721                                                 W. Cheng
                                                            China Mobile
                                                          R. Gandhi, Ed.
                                                     Cisco Systems, Inc.
                                                                Q. Xiong
                                                         ZTE Corporation
                                                            October 2026


 Path Computation Element Communication Protocol (PCEP) Extensions for
           Associated Bidirectional Segment Routing (SR) LSPs

Abstract

   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
   https://www.rfc-editor.org/info/rfc10067.

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
   (https://trustee.ietf.org/license-info) 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

   1.  Introduction
   2.  Terminology
     2.1.  Requirements Language
   3.  Overview
     3.1.  PCE-Initiated Associated Bidirectional SR LSPs
     3.2.  PCC-Initiated Associated Bidirectional SR LSPs
   4.  PCEP Extensions
     4.1.  Bidirectional SR LSP Association Group
     4.2.  Bidirectional LSP Association Group TLV
     4.3.  PATH-ATTRIB Object
     4.4.  MULTIPATH-OPPDIR-PATH TLV
   5.  Additional PCEP Considerations
     5.1.  PLSP-ID Usage
     5.2.  Error Handling
   6.  Security Considerations
   7.  Operational Considerations
     7.1.  Control of Function and Policy
     7.2.  Information and Data Models
     7.3.  Liveness Detection and Monitoring
     7.4.  Verify Correct Operations
     7.5.  Requirements on Other Protocols
     7.6.  Impact on Network Operations
   8.  IANA Considerations
     8.1.  Association Type
   9.  References
     9.1.  Normative References
     9.2.  Informative References
   Acknowledgments
   Contributors
   Authors' Addresses

1.  Introduction

   Segment Routing (SR) [RFC8402] 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.

   [RFC5440] describes the Path Computation Element (PCE) Communication
   Protocol (PCEP).  [RFC8231] 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
   [RFC4655], a PCE can be either stateful or stateless.  [RFC8664]
   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) [RFC9612] and Performance Measurement [RFC9503] 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 [RFC9256] 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 Section 4.3
   of [RFC8664].  [RFC10066] defines PCEP extensions for carrying
   multiple SLs in the PCEP messages along with their opposite direction
   SLs, as described in Section 4.4 of [RFC10066].

   As per [RFC8697], TE LSPs can be associated by adding them to a
   common association group by a PCEP peer.  [RFC9059] 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 [RFC9059] and non-co-routed paths.  This extension also
   utilizes the procedure defined in [RFC10066] 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.

2.  Terminology

   The reader is assumed to be familiar with the terminology defined in
   [RFC8231], [RFC8281], [RFC8697], [RFC8408], [RFC9059], and
   [RFC10066].

   This document uses the following terms defined in [RFC5440]:

   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 [RFC3031]: Label
   Switched Path (LSP) - the base PCEP specification [RFC4655]
   originally defined the PCE architecture for MPLS and GMPLS networks
   with LSPs instantiated using the RSVP-TE signaling protocol.  As
   specified in Section 2 of [RFC9603], 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.

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

3.  Overview

   Associated 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.

3.1.  PCE-Initiated Associated Bidirectional SR LSPs

   High-level steps for creating associated bidirectional SR LSPs by a
   Stateful PCE are shown in Figures 1 and 2.

   *  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.

                                  +-----+
                                  | 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>

         Figure 1: Step 1: PCE-Initiated Associated Bidirectional SR
          LSP with Forward-Direction LSPs and Reverse-Direction EROs

      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) [RFC8231] and reports it to the
      PCE via a PCRpt message.

                                  +-----+
                                  | 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>

           Figure 2: Step 2: PCC-Reported Bidirectional SR LSP with
              Forward-Direction LSPs and Reverse-Direction EROs

      F1 and F2 =  Forward LSP EROs
      R1 and R2 =  Reverse LSP EROs
      100 and 200 =  PLSP-IDs
      S =  Source
      D =  Destination

3.2.  PCC-Initiated Associated Bidirectional SR LSPs

   High-level steps for creating associated bidirectional SR LSPs by a
   PCC are shown in Figures 3 and 4.

   *  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.

                                 +-----+
                                 | 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>

         Figure 3: Step 1: PCC-Initiated Associated Bidirectional SR
                        LSP with Forward-Direction LSP

      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.

                                 +-----+
                                 | 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>

        Figure 4: Step 2: PCE-Updated Associated Bidirectional SR LSP
           with Forward- Direction LSPs and Reverse-Direction EROs

      F1 and F2 =  Forward LSP EROs
      R1 and R2 =  Reverse LSP EROs
      100 and 200 =  PLSP-IDs
      S =  Source
      D =  Destination

4.  PCEP Extensions

   Two 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 [RFC9059] and [RFC10066].

4.1.  Bidirectional SR LSP Association Group

   For 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 [RFC8697].

   [RFC8697] 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.

4.2.  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 Section 4.2 of [RFC9059].

   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.

4.3.  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 [RFC10066].

4.4.  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 [RFC10066] 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.

5.  Additional PCEP Considerations

   Additional considerations for associating bidirectional SR LSPs are
   summarized in the subsections below.

5.1.  PLSP-ID Usage

   As per [RFC8231], 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 2 and
   3, 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.

5.2.  Error Handling

   The error handling as described in Section 5.7 of [RFC9059] 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" [RFC8664]
   or "3: Traffic engineering path is set up using SRv6" [RFC9603].  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" [RFC9059].

6.  Security Considerations

   The security considerations described in [RFC5440], [RFC8231],
   [RFC8281], [RFC8408], [RFC9059], and [RFC10066] 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 [RFC8697] and apply to this
   Association Type.  Hence, securing the PCEP session using Transport
   Layer Security (TLS) [RFC8253], [RFC9916], as per the recommendations
   and best current practices in [RFC9325] is RECOMMENDED.

7.  Operational Considerations

   The manageability requirements and considerations listed in
   [RFC5440], [RFC8231], [RFC8281], [RFC8697], and [RFC10066] apply to
   the PCEP protocol extensions defined in this document.  In addition,
   the operational requirements and considerations listed in this
   section apply.

7.1.  Control of Function and Policy

   The mechanisms defined in this document do not imply any new control
   or policy requirements.

7.2.  Information and Data Models

   [RFC7420] describes the PCEP MIB; there are no new MIB Objects
   defined for LSP associations.

   The PCEP YANG module [RFC9826] 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

7.3.  Liveness Detection and Monitoring

   Mechanisms 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.

7.4.  Verify Correct Operations

   Mechanisms defined in this document do not imply any new operation
   verification requirements.

7.5.  Requirements on Other Protocols

   Mechanisms defined in this document do not imply any new requirements
   on other protocols.

7.6.  Impact on Network Operations

   Associating 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 [RFC9612] and Performance Measurement [RFC9503] can be
   used to verify the correct operation of a bidirectional SR LSP.

8.  IANA Considerations

8.1.  Association Type

   IANA has registered the following Association Type for the
   Association Group object (Class-Value 40) in the "ASSOCIATION Type
   Field" registry [RFC8697] within the "Path Computation Element
   Protocol (PCEP) Numbers" registry group (see
   <https://www.iana.org/assignments/pcep>):

          +======+==================================+===========+
          | Type | Name                             | Reference |
          +======+==================================+===========+
          | 8    | Bidirectional SR LSP Association | RFC 10067 |
          +------+----------------------------------+-----------+

                                  Table 1

9.  References

9.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031,
              DOI 10.17487/RFC3031, January 2001,
              <https://www.rfc-editor.org/info/rfc3031>.

   [RFC5440]  Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
              Element (PCE) Communication Protocol (PCEP)", RFC 5440,
              DOI 10.17487/RFC5440, March 2009,
              <https://www.rfc-editor.org/info/rfc5440>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8231]  Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for Stateful PCE", RFC 8231,
              DOI 10.17487/RFC8231, September 2017,
              <https://www.rfc-editor.org/info/rfc8231>.

   [RFC8253]  Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody,
              "PCEPS: Usage of TLS to Provide a Secure Transport for the
              Path Computation Element Communication Protocol (PCEP)",
              RFC 8253, DOI 10.17487/RFC8253, October 2017,
              <https://www.rfc-editor.org/info/rfc8253>.

   [RFC8281]  Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path
              Computation Element Communication Protocol (PCEP)
              Extensions for PCE-Initiated LSP Setup in a Stateful PCE
              Model", RFC 8281, DOI 10.17487/RFC8281, December 2017,
              <https://www.rfc-editor.org/info/rfc8281>.

   [RFC8402]  Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
              Decraene, B., Litkowski, S., and R. Shakir, "Segment
              Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
              July 2018, <https://www.rfc-editor.org/info/rfc8402>.

   [RFC8408]  Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J.
              Hardwick, "Conveying Path Setup Type in PCE Communication
              Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408,
              July 2018, <https://www.rfc-editor.org/info/rfc8408>.

   [RFC8664]  Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W.,
              and J. Hardwick, "Path Computation Element Communication
              Protocol (PCEP) Extensions for Segment Routing", RFC 8664,
              DOI 10.17487/RFC8664, December 2019,
              <https://www.rfc-editor.org/info/rfc8664>.

   [RFC8697]  Minei, I., Crabbe, E., Sivabalan, S., Ananthakrishnan, H.,
              Dhody, D., and Y. Tanaka, "Path Computation Element
              Communication Protocol (PCEP) Extensions for Establishing
              Relationships between Sets of Label Switched Paths
              (LSPs)", RFC 8697, DOI 10.17487/RFC8697, January 2020,
              <https://www.rfc-editor.org/info/rfc8697>.

   [RFC9059]  Gandhi, R., Ed., Barth, C., and B. Wen, "Path Computation
              Element Communication Protocol (PCEP) Extensions for
              Associated Bidirectional Label Switched Paths (LSPs)",
              RFC 9059, DOI 10.17487/RFC9059, June 2021,
              <https://www.rfc-editor.org/info/rfc9059>.

   [RFC9256]  Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
              A., and P. Mattes, "Segment Routing Policy Architecture",
              RFC 9256, DOI 10.17487/RFC9256, July 2022,
              <https://www.rfc-editor.org/info/rfc9256>.

   [RFC9325]  Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
              2022, <https://www.rfc-editor.org/info/rfc9325>.

   [RFC9603]  Li, C., Ed., Kaladharan, P., Sivabalan, S., Koldychev, M.,
              and Y. Zhu, "Path Computation Element Communication
              Protocol (PCEP) Extensions for IPv6 Segment Routing",
              RFC 9603, DOI 10.17487/RFC9603, July 2024,
              <https://www.rfc-editor.org/info/rfc9603>.

   [RFC9916]  Dhody, D., Turner, S., and R. Housley, "Updates to the
              Usage of TLS to Provide a Secure Transport for the Path
              Computation Element Communication Protocol (PCEP)",
              RFC 9916, DOI 10.17487/RFC9916, July 2026,
              <https://www.rfc-editor.org/info/rfc9916>.

   [RFC10066] Koldychev, M., Ed. and S. Sidor, Ed., "Path Computation
              Element Communication Protocol (PCEP) Extensions for
              Signaling Multipath Information", RFC 10066,
              DOI 10.17487/RFC10066, October 2026,
              <https://www.rfc-editor.org/info/rfc10066>.

9.2.  Informative References

   [RFC4655]  Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
              Computation Element (PCE)-Based Architecture", RFC 4655,
              DOI 10.17487/RFC4655, August 2006,
              <https://www.rfc-editor.org/info/rfc4655>.

   [RFC7420]  Koushik, A., Stephan, E., Zhao, Q., King, D., and J.
              Hardwick, "Path Computation Element Communication Protocol
              (PCEP) Management Information Base (MIB) Module",
              RFC 7420, DOI 10.17487/RFC7420, December 2014,
              <https://www.rfc-editor.org/info/rfc7420>.

   [RFC9503]  Gandhi, R., Ed., Filsfils, C., Chen, M., Janssens, B., and
              R. Foote, "Simple Two-Way Active Measurement Protocol
              (STAMP) Extensions for Segment Routing Networks",
              RFC 9503, DOI 10.17487/RFC9503, October 2023,
              <https://www.rfc-editor.org/info/rfc9503>.

   [RFC9612]  Mirsky, G., Tantsura, J., Varlashkin, I., and M. Chen,
              "Bidirectional Forwarding Detection (BFD) Reverse Path for
              MPLS Label Switched Paths (LSPs)", RFC 9612,
              DOI 10.17487/RFC9612, July 2024,
              <https://www.rfc-editor.org/info/rfc9612>.

   [RFC9826]  Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura,
              "A YANG Data Model for the Path Computation Element
              Communication Protocol (PCEP)", RFC 9826,
              DOI 10.17487/RFC9826, September 2025,
              <https://www.rfc-editor.org/info/rfc9826>.

Acknowledgments

   Many thanks to Marina Fizgeer, Adrian Farrel, Andrew Stone, Tarek
   Saad, Samuel Sidor, and Mike Koldychev for the detailed review of
   this document and for providing many useful comments.  Also, thank
   you, John Scudder, for the RtgDir Early review, Carlos Pignataro for
   the OpsDir review, Dhruv Dhody for the Shepherd review, Ketan
   Talaulikar for the WG AD review, Meral Shirazipour for Genart review,
   and Mohamed Boucadair, Éric Vyncke, Deb Cooley, Mahesh Jethanandani,
   Mike Bishop, and Gunter Van de Velde for the IESG review, which
   helped improve this document.

Contributors

   The following people have substantially contributed to this document:

   Dhruv Dhody
   Huawei Technologies
   Divyashree Techno Park, Whitefield
   Bangalore 560066
   Karnataka
   India
   Email: dhruv.ietf@gmail.com


   Zhenbin Li
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: lizhenbin@huawei.com


   Jie Dong
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: jie.dong@huawei.com


Authors' Addresses

   Cheng Li (editor)
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: c.l@huawei.com


   Mach(Guoyi) Chen
   Huawei Technologies
   Huawei Campus, No. 156 Beiqing Rd.
   Beijing
   100095
   China
   Email: mach.chen@outlook.com


   Weiqiang Cheng
   China Mobile
   China
   Email: chengweiqiang@chinamobile.com


   Rakesh Gandhi (editor)
   Cisco Systems, Inc.
   Canada
   Email: rgandhi@cisco.com


   Quan Xiong
   ZTE Corporation
   China
   Email: xiong.quan@zte.com.cn