Path Computation Element Communication Protocol (PCEP) Extensions for SID verification for SR-MPLS

Internet-Draft	SID Verification for SR-MPLS	December 2025
Chen, et al.	Expires 15 June 2026	[Page]

Abstract

This document defines extensions to the Path Computation Element Communication Protocol (PCEP) to support SID verification in Segment Routing MPLS (SR-MPLS) networks. Specifically, it introduces a flag in the SR-ERO subobject to indicate that the Path Computation Client (PCC) is explicitly requested to verify SID(s) by the Path Computation Element (PCE), and defines capability exchange mechanisms.¶

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 15 June 2026.¶

Copyright Notice

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

1. Introduction

[RFC9256] describes the "SID verification" bit usage and semantics for Segment Routing Policies. SID verification is performed when the headend is explicitly requested to verify SID(s) by the controller via the signaling protocol used. Implementations MAY provide a local configuration option to enable verification on a global, per-policy, or per candidate path basis.¶

[RFC8664] specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate Traffic-Engineering (TE) paths, as well as a Path Computation Client (PCC) to request a path subject to certain constraints and optimization criteria in SR networks. [RFC9603] defines similar SID verification extensions for SRv6-ERO subobjects.¶

This document specifies PCEP extensions to support the SID verification feature in SR-MPLS networks. It defines a Verification (V) flag in the SR-ERO subobject to enable the PCE to explicitly request SID verification from the PCC. Additionally, it introduces capability exchange mechanisms and detailed processing procedures for SID verification in both PCE-initiated and PCC-initiated LSP scenarios.¶

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

1.2. Terminology

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

PCC: Path Computation Client¶
PCE: Path Computation Element¶
PCEP: Path Computation Element Communication Protocol¶

This document uses the following terms defined in [RFC8664]:¶

ERO: Explicit Route Object¶
RRO: Record Route Object¶
SR-ERO: Segment Routing Explicit Route Object subobject¶
SR-RRO: Segment Routing Record Route Object subobject¶
SID: Segment Identifier¶
NAI: Network Access Identifier¶

This document uses the following terms defined in [RFC9256]:¶

Segment Routing Policy: An ordered list of segments (SIDs) that define a source-routed path through a network¶
SID Verification: The procedure of verifying that a Segment Identifier can be correctly resolved and programmed at the headend¶

2. SID verification flag(V-Flag)

2.1. V-Flag in SR-ERO Subobject

Section 4.3.1 in [RFC8664] describes the SR-ERO subobject format to carry a Segment Identifier (SID) and/or Network Access Identifier (NAI) information. This document defines a new flag in the SR-ERO subobject Flags field to request SID verification.¶

V (Verification) Flag (1 bit): When set to 1, the V-flag indicates that the PCE is explicitly requesting the PCC to verify the SID(s) associated with this SR-ERO subobject. The PCC MUST verify SID(s) according to the procedures defined in Section 5.1 of [RFC9256]. When set to 0, the V-flag indicates that SID verification is not explicitly requested by the PCE (though local policy on the PCC MAY still trigger verification).¶

The V-flag is applicable to both PCE-initiated LSPs (via PCUpd or PCInitiate messages) and PCC-initiated LSPs (via PCReq or PCRpt messages). The interpretation of the V-flag differs depending on direction:¶

When set by the PCE in PCUpd or PCInitiate messages: The V-flag is a request to the PCC to verify the specified SID(s).¶
When present in PCRpt messages sent by the PCC: The V-flag indicates that SID verification was requested (either via explicit PCE request or due to local policy). If the LSP is in the operational up state and the V-flag is set, this indicates that verification was completed successfully. If the LSP is not in the operational up state or if an LSP-ERROR-CODE is present indicating verification failure, the V-flag reflects that verification was requested but failed. The PCC SHOULD set the V-flag in PCRpt if it received a PCUpd/PCInitiate with V-flag set, or if it is performing verification based on local policy.¶

2.2. V-Flag in SR-RRO Subobject

The SR-RRO subobject format is the same as the SR-ERO subobject, except it lacks the L-Flag, per [RFC8664].¶

The V-flag has no meaning in the SR-RRO and is ignored on receipt at the PCE, consistent with the treatment of the V-flag in SRv6-RRO as specified in [RFC9603].¶

2.3. SID verification Processing

On receiving an SR-ERO subobject with the V-flag set to 1, a PCC MUST verify the SID(s) as described in Section 5.1 of [RFC9256]. The verification procedure is performed during path setup and before the LSP is activated.¶

If a PCC successfully verifies the SID(s) with the V-flag set in an SR-ERO subobject, it proceeds with LSP setup. The successful transition to operational up state indicates that verification was completed successfully.¶

If a PCC determines that "Verification fails" for a SID with the V-flag set in an SR-ERO subobject, the PCC MUST report this error by including an LSP-ERROR-CODE TLV with error-value "SID Verification fails" (as defined in [RFC9256]) in the LSP object within a PCRpt message sent to the PCE. The LSP MUST NOT be activated when SID verification fails.¶

For PCC-initiated LSPs, if a PCC is performing verification without explicit PCE request (due to local policy), and verification fails, the PCC SHOULD report the failure via LSP-ERROR-CODE to inform the PCE of the verification failure.¶

3. Capability Exchange

In order to ensure compatibility between PCE and PCC regarding SID verification support, PCEP speakers MUST advertise their support for the V-flag via capability exchange during session establishment.¶

3.1. SR-PCE-CAPABILITY Sub-TLV

The SR-PCE-CAPABILITY Sub-TLV is defined in [RFC8664] Section 4.1.2 and is included in the PATH-SETUP-TYPE-CAPABILITY TLV.¶

This document defines a new flag in the SR-PCE-CAPABILITY Sub-TLV Flags field:¶

V (SID Verification Capability) - bit TBD: If set to 1, a PCEP speaker indicates support for the V-flag in the SR-ERO subobject defined in [RFC8664] for LSPs setup using Path Setup Type 1 (Segment Routing). This flag indicates that the PCEP speaker is capable of handling SID verification requests and responses. If this flag is set to 0, the other PCEP speaker MUST NOT set the V-flag in SR-ERO subobjects.¶

A PCE MUST NOT set the V-flag in PCUpd or PCInitiate messages unless it has received a PCOpen message from the PCC with the V flag set in the SR-PCE-CAPABILITY Sub-TLV. Similarly, a PCC MUST NOT include the V-flag in RRO subobjects of PCRpt messages unless it has advertised support via the V flag in its SR-PCE-CAPABILITY Sub-TLV.¶

If a PCEP speaker receives a PCEP message with the V-flag set in an SR-ERO subobject, but the sender has not advertised support for the V-flag in its SR-PCE-CAPABILITY Sub-TLV, the receiver MUST send a PCErr message with Error-Type 19 (Invalid Operation) and Error-Value TBD (SID Verification capability not supported). The LSP MUST NOT be created or modified.¶

5. IANA Considerations

5.1. SR-ERO Subobject Flags

This document defines a new bit value in the sub-registry "SR-ERO Flag Field" in the "Path Computation Element Protocol (PCEP) Numbers" registry.¶


    Bit     Name                         Reference
    ---     -----------------------      -------------
    TBD     SID Verification (V)         This document

5.2. SR-PCE-CAPABILITY Sub-TLV Flags

This document defines a new bit value in the sub-registry "SR-PCE-CAPABILITY Sub-TLV Flags Field" in the "Path Computation Element Protocol (PCEP) Numbers" registry.¶


    Bit     Name                         Reference
    ---     -----------------------      -------------
    TBD     SID Verification (V)         This document

5.3. PCEP-Error Object

This document defines a new Error-Value for Error-Type 19 (Invalid Operation) in the "PCEP-Error Object" registry.¶


    Error-Type  Error-Value  Meaning                    Reference
    -----------  -----------  ----------------------    ----------
    19           TBD          SID Verification          This document
                              capability not supported

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