Path Computation Element Communication Protocol (PCEP) Extensions for SID verification for SR-MPLS
draft-ietf-pce-sr-mpls-sid-verification-00

PCE                                                              R. Chen
Internet-Draft                                           ZTE Corporation
Intended status: Standards Track                                S. Sidor
Expires: 18 July 2026                                      Cisco Systems
                                                                  C. Zhu
                                                         ZTE Corporation
                                                                 Z. Rose
                                                           Cisco Systems
                                                            M. Koldychev
                                                       Ciena Corporation
                                                         14 January 2026

 Path Computation Element Communication Protocol (PCEP) Extensions for
                      SID verification for SR-MPLS
               draft-ietf-pce-sr-mpls-sid-verification-00

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 18 July 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Chen, et al.              Expires 18 July 2026                  [Page 1]
Internet-Draft        SID Verification for SR-MPLS          January 2026

   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
     1.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  SID verification flag(V-Flag) . . . . . . . . . . . . . . . .   4
     2.1.  V-Flag in SR-ERO Subobject  . . . . . . . . . . . . . . .   4
     2.2.  V-Flag in SR-RRO Subobject  . . . . . . . . . . . . . . .   4
     2.3.  SID verification Processing . . . . . . . . . . . . . . .   5
   3.  Capability Exchange . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  SR-PCE-CAPABILITY Sub-TLV . . . . . . . . . . . . . . . .   5
   4.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  SR-ERO Subobject Flags  . . . . . . . . . . . . . . . . .   6
     5.2.  SR-PCE-CAPABILITY Sub-TLV Flags . . . . . . . . . . . . .   6
     5.3.  PCEP-Error Object . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8

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

Chen, et al.              Expires 18 July 2026                  [Page 2]
Internet-Draft        SID Verification for SR-MPLS          January 2026

   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

Chen, et al.              Expires 18 July 2026                  [Page 3]
Internet-Draft        SID Verification for SR-MPLS          January 2026

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

Chen, et al.              Expires 18 July 2026                  [Page 4]
Internet-Draft        SID Verification for SR-MPLS          January 2026

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.

Chen, et al.              Expires 18 July 2026                  [Page 5]
Internet-Draft        SID Verification for SR-MPLS          January 2026

   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.

4.  Acknowledgements

   We would like to thank Dhruv Dhody and John Scudder for their useful
   comments and suggestions.

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.

Chen, et al.              Expires 18 July 2026                  [Page 6]
Internet-Draft        SID Verification for SR-MPLS          January 2026

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

6.  Security Considerations

   The security considerations described in [RFC5440], [RFC8231],
   [RFC8281], and [RFC8664] are applicable to this specification.  No
   additional security measures are required.

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

Chen, et al.              Expires 18 July 2026                  [Page 7]
Internet-Draft        SID Verification for SR-MPLS          January 2026

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

Authors' Addresses

   Ran Chen
   ZTE Corporation
   Nanjing
   China
   Email: chen.ran@zte.com.cn

   Samuel Sidor
   Cisco Systems
   Email: ssidor@cisco.com

   Chun Zhu
   ZTE Corporation
   Nanjing
   China
   Email: zhu.chun1@zte.com.cn

   Zoey Rose
   Cisco Systems
   Email: atokar@cisco.com

   Mike Koldychev
   Ciena Corporation
   Email: mkoldych@ciena.com

Chen, et al.              Expires 18 July 2026                  [Page 8]