PCE LSP validation Extensions in Path Computation Element Communication Protocol (PCEP)
draft-fizgeer-pce-lsp-validation-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.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Marina Fizgeer | ||
| Last updated | 2025-10-15 | ||
| RFC stream | (None) | ||
| Intended RFC status | (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-fizgeer-pce-lsp-validation-extensions-00
PCE Working Group M. Fizgeer
Internet-Draft Ribbon Communications
Intended status: Standards Track October 2025
Expires: 18 April 2026
PCE LSP validation Extensions in Path Computation Element Communication
Protocol (PCEP)
draft-fizgeer-pce-lsp-validation-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). A Stateful PCE RFC8231 can instantiate LSPs on a PCC. In
some cases, the PCC shall perform additional validations and/or
actions. If some validations or actions fail, the LSP will not be
created and established or updated. This document specifies PCEP
extensions to handle this situation gracefully in case the problem
can be resolved by some network changes (freeing up resources,
restoring or changing the network, and so on). This draft defines
common usage of the new flag and known use cases for using this flag.
Each draft relevant to LSP creation can add a corresponding bit to
the use case list.
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 April 2026.
Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved.
Fizgeer Expires 18 April 2026 [Page 1]
Internet-Draft PCE LSP validation Extensions in Path Co October 2025
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 . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Known use cases . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. Binding value is unavailable . . . . . . . . . . . . . . 3
3.2. Path (ERO list) is not passed resolution . . . . . . . . 3
3.3. S-BFD - Out Of Resources . . . . . . . . . . . . . . . . 3
4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 3
4.1. STATEFUL-PCE-CAPABILITY . . . . . . . . . . . . . . . . . 3
4.2. SRP Object: . . . . . . . . . . . . . . . . . . . . . . . 4
4.3. Processing . . . . . . . . . . . . . . . . . . . . . . . 4
4.3.1. Handling of possible failures: . . . . . . . . . . . 5
5. Manageability Considerations . . . . . . . . . . . . . . . . 5
6. Security Considerations . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7.1. STATEFUL-PCE-CAPABILITY TLV Flag . . . . . . . . . . . . 5
7.2. SRP object . . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Normative References . . . . . . . . . . . . . . . . . . 6
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
This document specifies PCEP extensions to handle the situation when
LSP validation is failed. The goal is to handle it gracefully in
case the problem can be resolved by some network changes (freeing up
resources, restoring or changing the network, and so on).
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.
Fizgeer Expires 18 April 2026 [Page 2]
Internet-Draft PCE LSP validation Extensions in Path Co October 2025
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. Known use cases
3.1. Binding value is unavailable
Initially defined in (draft-sidor-pce-binding-label-sid-extensions).
Indicates that the PCEP peer supports LSP creation and fall back to
dynamic binding value allocation if the specific binding value is
unavailable.
3.2. Path (ERO list) is not passed resolution
Indicates that the PCEP peer supports LSP creation if some ERO in the
ERO list is unreachable, unknown.
3.3. S-BFD - Out Of Resources
The PCEP peer supports LSP creation when the LSP is initiated with
S-BFD enabled. However, if S-BFD resources are currently exhausted
or have reached their maximum allocation, the LSP can still be
created but may remain in a down state until resources become
available.
4. PCEP Extensions
4.1. STATEFUL-PCE-CAPABILITY
A new flag is proposed for the STATEFUL-PCE-CAPABILITY TLV,
originally defined in Section 5.4 of [RFC8231]. Also referenced in
the "PCEP Binding SID Extensions".
Fizgeer Expires 18 April 2026 [Page 3]
Internet-Draft PCE LSP validation Extensions in Path Co October 2025
D (DOWN-CAPABILITY): If set, this flag indicates that the PCEP peer
supports LSP creation even when certain validations or actions fail.
In such cases, the LSP is instantiated but remains in a down state,
allowing for potential recovery through network changes or further
actions.
4.2. SRP Object:
New optional TLV can be added to the SRP object, initially defined in
[RFC8231].
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Type | Length |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
| Bit String |D| |
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Figure 1: SRP object new TLV
* D flag: If set, indicates that LSP can be created even if
specified validation or action cannot be passed, but LSP will be
in down state.
* Bit String (If flag D is 1):
bit 0 - if specified binding value is unavailable (draft-sidor-
pce-binding-label-sid-extensions)
bit 1 - if specified path in ERO list is not passed resolution
bit 2 - S-BFD leak of resources.
4.3. Processing
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 D flag in the STATEFUL-PCE-CAPABILITY TLV
in their respective OPEN messages.
When a PCE wants to instantiate or update an LSP, in the PCInitiate
or PCUpd message, the PCE can set the D flag in this TLV to control
the PCC's behavior in case the requested LSP has some problem.
If the PCC receives this new TLV with the D flag set and the bit is
set in the string with relevant use case, the PCC MUST instantiate
the LSP but keep it in a down state in case of relevant failure.
Fizgeer Expires 18 April 2026 [Page 4]
Internet-Draft PCE LSP validation Extensions in Path Co October 2025
4.3.1. Handling of possible failures:
Some failures can be resolved by the PCC. For example, ERO
resolution may succeed after certain network changes (e.g., freeing
up resources or restoring connectivity). In such cases, the PCC MUST
update the state of the LSP and send a PCRpt message to the PCE.
Other failures, such as S-BFD resource exhaustion, may require
rechecking initiated by the PCE. Each use case and its corresponding
behavior shall be defined in the relevant draft that utilizes the new
D flag.
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 |
+======+================================+===============+
| TBD1 | D (DOWN-CAPABILITY) | This document |
+------+--------------------------------+---------------+
Figure 2: New IANA request
Fizgeer Expires 18 April 2026 [Page 5]
Internet-Draft PCE LSP validation Extensions in Path Co October 2025
7.2. SRP object
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:
+======+=========================+===============+
| N | Description | Reference |
+======+=========================+===============+
| TBD2 | New optional TLV in SRP | This document |
+------+-------------------------+---------------+
Figure 3: New TLV IANA request
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>.
Fizgeer Expires 18 April 2026 [Page 6]
Internet-Draft PCE LSP validation Extensions in Path Co October 2025
8.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>.
[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 author thanks for...
Author's Address
Marina Fizgeer
Ribbon Communication
Yagia Kapaim 24
Petah Tikva
Israel
Email: marina.fizgeer@rbbn.com
Fizgeer Expires 18 April 2026 [Page 7]