Binding Label/Segment Identifier (SID) Extensions in Path Computation Element Communication Protocol (PCEP)
draft-sidor-pce-binding-label-sid-extensions-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Authors | Samuel Sidor , Zafar Ali , Cheng Li , Mike Koldychev | ||
| Last updated | 2025-07-04 | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sidor-pce-binding-label-sid-extensions-00
PCE Working Group S. Sidor
Internet-Draft Z. Ali
Intended status: Standards Track Cisco Systems, Inc.
Expires: 5 January 2026 C. Li
Huawei Technologies
M. Koldychev
Ciena Corporation
4 July 2025
Binding Label/Segment Identifier (SID) Extensions in Path Computation
Element Communication Protocol (PCEP)
draft-sidor-pce-binding-label-sid-extensions-00
Abstract
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to instantiate and
manage Label Switched Paths (LSPs) on a Path Computation Client
(PCC). This includes the ability for a PCE to specify a Binding
Segment Identifier (SID) for an LSP as described in RFC9604.
A binding value specified by a PCE may not be available for use on
the PCC. This can lead to LSP instantiation failures or entire PCEP
message being rejected.
This document proposes extensions to PCEP to allow a PCC to fall back
to allocating a Binding SID from its own dynamic range if the value
specified by the PCE is unavailable. It also defines a mechanism for
the PCC to report both the requested and the allocated binding values
back to the PCE.
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 5 January 2026.
Sidor, et al. Expires 5 January 2026 [Page 1]
Internet-Draft PCEP Binding SID Extensions July 2025
Copyright Notice
Copyright (c) 2025 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
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . . 3
3.2. TE-PATH-BINDING TLV . . . . . . . . . . . . . . . . . . . 3
4. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Manageability Considerations . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7.1. STATEFUL-PCE-CAPABILITY TLV Flag . . . . . . . . . . . . 5
7.2. TE-PATH-BINDING TLV Flags . . . . . . . . . . . . . . . . 5
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
A Stateful PCE [RFC8231] can instantiate LSPs on a PCC. When
instantiating an Segment Routing Traffic Engineering (SR-TE) LSP
[RFC8664], the PCE may request a specific Binding SID (BSID) to be
associated with the LSP using the TE-PATH-BINDING TLV [RFC9604]. A
problem arises if the BSID requested by the PCE is already in use or
is outside the valid range on the PCC. In the current PCEP
specification, this would result in an LSP instantiation failure.
Sidor, et al. Expires 5 January 2026 [Page 2]
Internet-Draft PCEP Binding SID Extensions July 2025
This document specifies PCEP extensions to handle this situation
gracefully. It introduces a capability that allows a PCC to signal
its ability to fall back to local allocation. It also extends the
TE-PATH-BINDING TLV to allow a PCE to control the fallback behavior
and for a PCC to report the actual allocated BSID back to the PCE.
1.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.
2. Terminology
This document uses the following terms defined in [RFC5440]: PCC,
PCE, PCEP Peer, and PCEP speaker.
The base PCEP specification [RFC4655] originally defined the use of
the PCE architecture for MPLS and GMPLS networks with LSPs
instantiated using the RSVP-TE signaling protocol. Over time,
support for additional path setup types, such as SRv6, has been
introduced [RFC9603]. The term "LSP" is used extensively in PCEP
specifications and, in the context of this document, refers to a
Candidate Path within an SR Policy, which may be an SRv6 path (still
represented using the LSP Object as specified in [RFC8231].
3. PCEP Extensions
3.1. STATEFUL-PCE-CAPABILITY TLV
A new flag is proposed for the STATEFUL-PCE-CAPABILITY TLV,
originally defined in Section 5.4 of [RFC8231].
* F (BSID-FALLBACK-CAPABILITY): If set, indicates that the PCEP peer
supports LSP creation and fall back to dynamic binding value
allocation if the specific binding value is unavailable, as
detailed in Section 4.
3.2. TE-PATH-BINDING TLV
New flags are proposed in the TE-PATH-BINDING TLV, which was
originally defined in Section 4 of [RFC9604].
* A (Allocated): If set, indicates that the binding value encoded in
the TLV represents an allocated binding value.
Sidor, et al. Expires 5 January 2026 [Page 3]
Internet-Draft PCEP Binding SID Extensions July 2025
* D (Down on BSID Unavailability): If set, indicates that LSP can be
created even if specified binding value is unavailable, but LSP
will be in down state.
* F (Fallback): If set, indicates that binding value allocation from
the dynamic range will be performed if the specified binding value
is unavailable.
4. Operation
The PCEP protocol extensions defined in this document MUST NOT be
used if one or both PCEP speakers have not indicated support for the
extensions by setting the F flag (BSID-FALLBACK-CAPABILITY) in the
STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages.
When a PCE wants to instantiate or update an LSP and suggest a
binding value, it includes the TE-PATH-BINDING TLV in the PCInitiate
or PCUpd message. The PCE can set the F flag or the D flag in this
TLV to control the PCC's behavior in case the requested binding value
is unavailable. The F and D flags are mutually exclusive.
If the PCC receives a TE-PATH-BINDING TLV with the F flag set and the
requested binding value is unavailable, the PCC MUST attempt to
allocate a new binding value from its dynamic pool. If successful,
the LSP is brought up with the new binding value.
If the PCC receives a TE-PATH-BINDING TLV with the D flag set and the
requested binding value is unavailable, the PCC MUST instantiate the
LSP but keep it in a down state.
In its PCRpt message, the PCC reports the status of the binding value
allocation. If the originally requested binding value and the
allocated binding value differ, two instances of the TE-PATH-BINDING
TLV MUST be included in the PCRpt message:
* A TLV instance with the originally requested binding value with
the A flag cleared.
* A TLV instance with the actually allocated binding value with the
A flag set.
If the requested binding value was successfully allocated, only a
single instance of the TE-PATH-BINDING TLV with the A flag set SHOULD
be included in the PCEP message.
The A, D and F flags in the TE-PATH-BINDING TLV MUST NOT be used if
one or both PCEP speakers have not set the BSID-FALLBACK-CAPABILITY
in the STATEFUL-PCE-CAPABILITY TLV in their respective OPEN messages.
Sidor, et al. Expires 5 January 2026 [Page 4]
Internet-Draft PCEP Binding SID Extensions July 2025
5. Manageability Considerations
All manageability requirements and considerations listed in
[RFC5440], [RFC8231], and [RFC9604] apply to the PCEP extensions
defined in this document.
A PCE or PCC implementation MAY allow the capability of supporting
PCEP extensions introduced in this document to be enabled/disabled as
part of the global configuration. An implementation SHOULD allow the
operator to view the advertised and received capabilities.
6. Security Considerations
The security considerations described in [RFC5440], [RFC8231], and
[RFC9604] are applicable to this document. No additional security
measures are required.
7. IANA Considerations
7.1. STATEFUL-PCE-CAPABILITY TLV Flag
IANA maintains a registry, named "STATEFUL-PCE-CAPABILITY TLV Flag
Field", within the "Path Computation Element Protocol (PCEP) Numbers"
registry group. IANA is requested to make the following assignment:
+======+==============================+===============+
| Bit | Description | Reference |
+======+==============================+===============+
| TBA1 | F (BSID-FALLBACK-CAPABILITY) | This document |
+------+------------------------------+---------------+
Table 1
7.2. TE-PATH-BINDING TLV Flags
IANA maintains a registry, named "TE-PATH-BINDING TLV Flag Field",
within the "Path Computation Element Protocol (PCEP) Numbers"
registry group. IANA is requested to make the following assignments:
Sidor, et al. Expires 5 January 2026 [Page 5]
Internet-Draft PCEP Binding SID Extensions July 2025
+======+=================================+===============+
| Bit | Description | Reference |
+======+=================================+===============+
| TBA2 | A (Allocated) | This document |
+------+---------------------------------+---------------+
| TBA3 | D (Down on BSID Unavailability) | This document |
+------+---------------------------------+---------------+
| TBA4 | F (Fallback) | This document |
+------+---------------------------------+---------------+
Table 2
8. References
8.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>.
[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>.
[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>.
[RFC9604] Sivabalan, S., Filsfils, C., Tantsura, J., Previdi, S.,
and C. Li, Ed., "Carrying Binding Label/SID in PCE-Based
Networks", RFC 9604, DOI 10.17487/RFC9604, August 2024,
<https://www.rfc-editor.org/info/rfc9604>.
8.2. Informative References
Sidor, et al. Expires 5 January 2026 [Page 6]
Internet-Draft PCEP Binding SID Extensions July 2025
[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>.
[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>.
Appendix A. Acknowledgements
The authors would like to thank Rajesh Melarcode Venkateswaran for
their contributions to this document.
Authors' Addresses
Samuel Sidor
Cisco Systems, Inc.
Eurovea Central 3
Pribinova 10
811 09 Bratislava
Slovakia
Email: ssidor@cisco.com
Zafar Ali
Cisco Systems, Inc.
Email: zali@cisco.com
Cheng Li
Huawei Technologies
Huawei Campus, No. 156 Beiqing Rd.
Beijing
100095
China
Email: c.l@huawei.com
Mike Koldychev
Ciena Corporation
385 Terry Fox Dr.
Kanata Ontario K2K 0L1
Canada
Email: mkoldych@proton.me
Sidor, et al. Expires 5 January 2026 [Page 7]