RFC 10067
Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs
RFC 10067 — Path Computation Element Communication Protocol (PCEP) Extensions for Associated Bidirectional Segment Routing (SR) LSPs 🦋
okay bestie, before we get into the protocol tea, here's the title block, and no I did not skip a single line of it 💅
- Request for Comments: 10067
- Category: Standards Track
- ISSN: 2070-1721
- Date: October 2026
- Authors:
- C. Li, Ed. — Huawei Technologies
- M. Chen — Huawei Technologies
- W. Cheng — China Mobile
- R. Gandhi, Ed. — Cisco Systems, Inc.
- Q. Xiong — ZTE Corporation
Abstract
So, Segment Routing (SR) steers packets through a network using the IPv6 or MPLS data planes via source routing — that's the whole vibe. 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
- Introduction
- Terminology 2.1. Requirements Language
- Overview 3.1. PCE-Initiated Associated Bidirectional SR LSPs 3.2. PCC-Initiated Associated Bidirectional SR LSPs
- 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
- Additional PCEP Considerations 5.1. PLSP-ID Usage 5.2. Error Handling
- Security Considerations
- 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
- IANA Considerations 8.1. Association Type
- 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. two data planes, one protocol, we love a versatile icon 👑
[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. both ends knowing both directions?? that's called communication, bestie 🫶
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]. (yes that's a lot of homework, but it's prerequisite homework, so 😭)
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.
okay this one is the real one, bestie: those capitals are load-bearing. They mean exactly what BCP 14 says they mean, and they only count when they're written in all caps like that. No vibes-based reading of requirements, ever 💅
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. (happy path first, chaos later ✨)
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 = Destinationlook at that glow-up — the tunnels come back with real IDs and everything 🦋
3.2. PCC-Initiated Associated Bidirectional SR LSPs
Okay so now the PCC is the one driving the whole thing 🎀 and here's the high-level roadmap for when a PCC creates associated bidirectional SR LSPs — it's literally right there in Figures 3 and 4.
- Step 1 - PCC Behavior:
The PCC creates and updates an SR LSP for the "Bidirectional SR LSP Association" with the Association ID 2, and it reports the change in the association group of an SR LSP to the 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:
The 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 = Destination4. PCEP Extensions 🌈
So the whole glow-up here: 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 by employing the procedures defined in [RFC9059] and [RFC10066]. It's giving "two icons, one era."
4.1. Bidirectional SR LSP Association Group
For associating two unidirectional SR LSPs, this document defines a brand-new Association Type called "Bidirectional SR LSP Association" for the Association Group object (Class-Value 40), and it goes like this:
- 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 is set exactly as defined in [RFC8697]. No notes, no deviations, periodt.
[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. 🚨 Not me being dramatic, but this one's serious — log it and alarm it, fr fr.
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. 💀 Like, yes, ignored — but also logged and alarmed. Both. Always both.
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]. 🦋 Setting that flag correctly is the entire vibe — it's how the PCC knows which way is which.
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. 👀 Catch the inconsistency, write it down, sound the alarm. That's the whole assignment.
5. Additional PCEP Considerations
Extra notes for associating bidirectional SR LSPs? All summarized in the subsections below bestie, don't worry 🌸
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. Two IDs, two sides, zero confusion 💅
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]. 🚨 Non-SR PST? Not on this association's watch. Bounce it back with the right error code.
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. Read them, all of them, for real.
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. So yes — a hostile speaker can try to mess with associations, and that is exactly why this matters. Hence, securing the PCEP session using Transport Layer Security (TLS) [RFC8253], [RFC9916], as per the recommendations and best current practices in [RFC9325] is RECOMMENDED. 🛡️ Please actually do this. Protect the session. It's not a vibe to skip it.
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. On top of that, the operational requirements and considerations listed in this section also apply. 💜
7.1. Control of Function and Policy
The mechanisms defined in this document do not imply any new control or policy requirements. 🎀 Genuinely — nothing new to configure on that front.
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
✨ Like, that's the wishlist — a little YANG glow-up waiting to happen.
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. 👀 Two sides checking themselves is cute, but somebody up top has to correlate them so you actually know the service works.
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. 🫶 Operator's job, but a very doable one.
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 1Number 8, name locked in, reference immortalized. Iconic. 👑
9. References
9.1. Normative References ✨
okay bestie, these are the normative ones — the receipts you literally cannot ship without 💅 every single one is quoted here exactly, character for character, so no shortcuts, no "you get the vibe" 🌸
[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>.not the list being this long and this iconic at the same time 🫶 every entry is load-bearing, okay? don't go trimming it for aesthetics 💜
9.2. Informative References 🦋
and these? these are the informative girlies — background reading, extra lore, the "you don't have to but you'll be better for it" shelf 📚 still copied out perfectly because we're not messy in this house ✨
[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>.see how they're still fully spelled out with authors, titles, DOIs, dates and URLs? that's the standard, bestie, we simply do not abbreviate references in this household 💅
Acknowledgments 🌸
okay the shoutout section, and honestly it's giving appreciation post energy because SO many people read this thing and made it better 😭💖 huge 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 🎀 and Carlos Pignataro for the OpsDir review, and Dhruv Dhody for the Shepherd review, and Ketan Talaulikar for the WG AD review, and 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 🫶
the way that a single thoughtful review comment can save an entire spec from chaos... we stan reviewers, no cap 👑
Contributors 💜
these are the people who substantially contributed to this document — put some respect on the names, and here's their info exactly as written 📇
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.comAuthors' Addresses 🎀
and finally, the main characters themselves 💅 the editors and authors of this whole document, contact details untouched and exact 🦋
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.cnand that's the whole document, bestie — every section, every reference, every name, every address, all of it intact ✨ the vibe got a glow-up, the facts did not move an inch, and that's exactly how we like it 💖🎀🦋
📦 where this page comes from
- ietf: rfc10067 2026-10
- 💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms