Hi Deb, Thanks for the review.
Attaching the work in progress draft with the diffs that include your suggestion. Regards, Rakesh On Tue, Mar 3, 2026 at 8:36 AM Deb Cooley via Datatracker <[email protected]> wrote: > Deb Cooley has entered the following ballot position for > draft-ietf-pce-sr-bidir-path-24: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-pce-sr-bidir-path/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Section 7, para 2: Consider adding I-D.ietf-pce-pceps-tls13 (it is in > AUTH48) > in addition to RFC 8253 as this contains the most up to date TLS > information. > > > > _______________________________________________ > Pce mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
PCE Working Group C. Li
Internet-Draft M. Chen
Intended status: Standards Track Huawei Technologies
Expires: 4 September 2026 W. Cheng
China Mobile
R. Gandhi
Cisco Systems, Inc.
Q. Xiong
ZTE Corporation
3 March 2026
Path Computation Element Communication Protocol (PCEP) Extensions for
Associated Bidirectional Segment Routing (SR) LSPs
draft-ietf-pce-sr-bidir-path-25
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) with one in each direction in a network
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 Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 4 September 2026.
Li, et al. Expires 4 September 2026 [Page 1]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. PCE-Initiated Associated Bidirectional SR LSPs . . . . . 4
3.2. PCC-Initiated Associated Bidirectional SR LSPs . . . . . 6
4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Bidirectional SR LSP Association Group . . . . . . . . . 8
4.2. Bidirectional LSP Association Group TLV . . . . . . . . . 9
4.3. PATH-ATTRIB Object . . . . . . . . . . . . . . . . . . . 9
4.4. MULTIPATH-OPPDIR-PATH TLV . . . . . . . . . . . . . . . . 9
5. Additional PCEP Considerations . . . . . . . . . . . . . . . 9
5.1. PLSP-ID Usage . . . . . . . . . . . . . . . . . . . . . . 10
5.2. Error Handling . . . . . . . . . . . . . . . . . . . . . 10
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10
6.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 11
6.2. ZTE's Commercial Delivery . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Operational Considerations . . . . . . . . . . . . . . . . . 12
8.1. Control of Function and Policy . . . . . . . . . . . . . 12
8.2. Information and Data Models . . . . . . . . . . . . . . . 12
8.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12
8.4. Verify Correct Operations . . . . . . . . . . . . . . . . 12
8.5. Requirements On Other Protocols . . . . . . . . . . . . . 13
8.6. Impact On Network Operations . . . . . . . . . . . . . . 13
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
9.1. Association Type . . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Li, et al. Expires 4 September 2026 [Page 2]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
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 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]. [I-D.ietf-pce-multipath] defines PCEP extensions for
carrying multiple SLs in the PCEP messages along with their opposite
direction SLs, as described in Section 7.4 (Opposite Direction
Tunnels) in [I-D.ietf-pce-multipath].
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 [I-D.ietf-pce-multipath] 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.
Li, et al. Expires 4 September 2026 [Page 3]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
2. Terminology
The reader is assumed to be familiar with the terminology defined in
[RFC8231], [RFC8281], [RFC8697], [RFC8408], [RFC9059], and
[I-D.ietf-pce-multipath].
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), while 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 the Terminology Section 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 sub-sections 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 1a and 1b.
Step 1 - Stateful PCE Behaviour:
* Stateful PCE creates and updates the SR LSP and the associated
reverse SR LSP EROs, for the 'Bidirectional SR LSP Association'
with the association identifier 1 on a PCC via PCInitiate and
PCUpd messages, respectively.
Li, et al. Expires 4 September 2026 [Page 4]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
+-----+
| 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>
Legends: F1 and F2 = Forward LSP EROs, R1 and R2 = Reverse LSP EROs
Legends: 0 = PLSP-ID
Legends: S = Source, D = Destination
Figure 1a: Step 1: PCE-Initiated Associated Bidirectional SR LSP
with Forward Direction LSPs and Reverse Direction EROs
Step 2 - PCC Behaviour:
* 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.
Li, et al. Expires 4 September 2026 [Page 5]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
+-----+
| 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>
Legends: F1 and F2 = Forward LSP EROs, R1 and R2 = Reverse LSP EROs
Legends: 100 and 200 = PLSP-IDs
Legends: S = Source, D = Destination
Figure 1b: Step 2: PCC-Reported Bidirectional SR LSP
with Forward Direction LSPs and Reverse Direction EROs
3.2. PCC-Initiated Associated Bidirectional SR LSPs
High-level steps for creating associated bidirectional SR LSPs by a
PCC are shown in Figures 2a and 2b.
Step 1 - PCC Behaviour:
* PCC creates and updates an SR LSP for the 'Bidirectional SR LSP
Association' with the association identifier 2 and reports the
change in the association group of an SR LSP to PCE(s) via a PCRpt
message.
Li, et al. Expires 4 September 2026 [Page 6]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
+-----+
| 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>
Legends: F1 and F2 = Forward LSP EROs
Legends: 100 and 200 = PLSP-IDs
Legends: S = Source, D = Destination
Figure 2a: Step 1: PCC-Initiated Associated Bidirectional SR LSP
with Forward Direction LSPs
Step 2 - Stateful PCE Behaviour:
* 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.
Li, et al. Expires 4 September 2026 [Page 7]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
+-----+
| 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>
Legends: F1 and F2 = Forward LSP EROs, R1 and R2 = Reverse LSP EROs
Legends: 100 and 200 = PLSP-IDs
Legends: S = Source, D = Destination
Figure 2b: Step 2: PCE-Updated Associated Bidirectional SR LSP
with Forward Direction LSPs and Reverse Direction EROs
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 [I-D.ietf-pce-multipath].
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.
Li, et al. Expires 4 September 2026 [Page 8]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
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 [I-D.ietf-pce-multipath].
4.4. MULTIPATH-OPPDIR-PATH TLV
The PCE MAY include the 'MULTIPATH-OPPDIR-PATH TLV' to indicate the
co-routed path properties (in N and L flags) for the reverse ERO
[I-D.ietf-pce-multipath] 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 sub-sections below.
Li, et al. Expires 4 September 2026 [Page 9]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
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 Figure 1b and
Figure 2a, the ingress node PCC (node S) reports the Tunnel 1, LSP1
to the PCE with PLSP-ID 100 whereas the egress node PCC (node D)
reports the 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. Implementation Status
[Note to the RFC Editor - remove this section before publication, as
well as remove the reference to [RFC7942].
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalog of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
Li, et al. Expires 4 September 2026 [Page 10]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
6.1. Huawei's Commercial Delivery
The feature is developing based on Huawei VRP8.
* Organization: Huawei
* Implementation: Huawei's Commercial Delivery implementation based
on VRP8.
* Description: The implementation is under development.
* Maturity Level: Product
* Contact: [email protected]
6.2. ZTE's Commercial Delivery
* Organization: ZTE
* Implementation: ZTE's Commercial Delivery implementation based on
Rosng v8.
* Description: The implementation is under development.
* Maturity Level: Product
* Contact: [email protected]
7. Security Considerations
The security considerations described in [RFC5440], [RFC8231],
[RFC8281], [RFC8408], [RFC9059], and [I-D.ietf-pce-multipath] 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], [I-D.ietf-pce-pceps-tls13], as per the
recommendations and best current practices in [RFC9325].
Li, et al. Expires 4 September 2026 [Page 11]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
8. Operational Considerations
The manageability requirements and considerations listed in
[RFC5440], [RFC8231], [RFC8281], [RFC8697], and
[I-D.ietf-pce-multipath] apply to the PCEP protocol extensions
defined in this document. In addition, the operational requirements
and considerations listed in this section apply.
8.1. Control of Function and Policy
The mechanisms defined in this document do not imply any new control
or policy requirements.
8.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
8.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.
8.4. Verify Correct Operations
Mechanisms defined in this document do not imply any new operation
verification requirements.
Li, et al. Expires 4 September 2026 [Page 12]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
8.5. Requirements On Other Protocols
Mechanisms defined in this document do not imply any new requirements
on other protocols.
8.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.
9. IANA Considerations
9.1. Association Type
This document defines a new Association Type, originally described in
[RFC8697]. IANA is requested to update the value it has assigned
through the early allocation process in the "ASSOCIATION Type Field"
registry [RFC8697] within the "Path Computation Element Protocol
(PCEP) Numbers" registry group, making it permanent:
Type Name Reference
------------------------------------------------------------------
8 Bidirectional SR LSP Association [This document]
10. References
10.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>.
Li, et al. Expires 4 September 2026 [Page 13]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
[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>.
Li, et al. Expires 4 September 2026 [Page 14]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
[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>.
[I-D.ietf-pce-multipath]
Koldychev, M., Sivabalan, S., Saad, T., Beeram, V. P.,
Bidgoli, H., Peng, S., and S. Sidor, "Path Computation
Element Communication Protocol (PCEP) Extensions for
Signaling Multipath Information", Work in Progress,
Internet-Draft, draft-ietf-pce-multipath-20, 2 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-pce-
multipath-20>.
[I-D.ietf-pce-pceps-tls13]
Dhody, D., Turner, S., and R. Housley, "Updates for PCEPS:
TLS Connection Establishment Restrictions", Work in
Progress, Internet-Draft, draft-ietf-pce-pceps-tls13-04, 9
January 2024, <https://datatracker.ietf.org/doc/html/
draft-ietf-pce-pceps-tls13-04>.
10.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>.
Li, et al. Expires 4 September 2026 [Page 15]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
[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>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[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, Mohamed Boucadair, Eric Vyncke, Deb
Cooley, and Gunter Van de Velde for the IESG review, which helped
improve this document.
Contributors
The following people have substantially contributed to this document:
Li, et al. Expires 4 September 2026 [Page 16]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
Dhruv Dhody
Huawei Technologies
Divyashree Techno Park, Whitefield
Bangalore, Karnataka 560066
India
Email: [email protected]
Zhenbin Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: [email protected]
Jie Dong
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing 100095
China
Email: [email protected]
Authors' Addresses
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: [email protected]
Mach(Guoyi) Chen
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: [email protected]
Li, et al. Expires 4 September 2026 [Page 17]
Internet-Draft PCEP for Associated Bidirectional SR LSP March 2026
Weiqiang Cheng
China Mobile
China
Email: [email protected]
Rakesh Gandhi
Cisco Systems, Inc.
Canada
Email: [email protected]
Quan Xiong
ZTE Corporation
China
Email: [email protected]
Li, et al. Expires 4 September 2026 [Page 18]
<<< text/html; charset="US-ASCII"; name="draft-ietf-pce-sr-bidir-path-25.diff.html": Unrecognized >>>
_______________________________________________ Pce mailing list -- [email protected] To unsubscribe send an email to [email protected]
