



PCE Working Group                                               S. Sidor
Internet-Draft                                                    Z. Ali
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: 23 April 2026                                             C. Li
                                                     Huawei Technologies
                                                            M. Koldychev
                                                       Ciena Corporation
                                                                A. Stone
                                                                   Nokia
                                                         20 October 2025


LSP State Reporting Extensions in Path Computation Element Communication
                            Protocol (PCEP)
           draft-sidor-pce-lsp-state-reporting-extensions-05

Abstract

   The Path Computation Element Communication Protocol (PCEP) is defined
   in multiple RFCs for enabling communication between Path Computation
   Elements (PCEs) and Path Computation Clients (PCCs).

   Although PCEP defines various Label Switched Path (LSP) identifiers,
   attributes, and constraints, there are operational attributes
   available on the PCC that can enhance path computation and improve
   the debugging experience, which are not currently supported in PCEP.

   This document proposes extensions to PCEP to include:

   *  Support for explicit or dynamic path types
   *  Mechanisms to mark LSPs as eligible for use as transit LSPs

   These extensions aim to address the existing gaps, enhancing the
   overall functionality and operational efficiency of PCEP.

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







Sidor, et al.             Expires 23 April 2026                 [Page 1]

Internet-Draft         STATE-REPORTING-EXTENSIONS           October 2025


   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 23 April 2026.

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  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Object Formats  . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  STATEFUL-PCE-CAPABILITY TLV . . . . . . . . . . . . . . .   3
     3.2.  LSP-EXTENDED-FLAG TLV . . . . . . . . . . . . . . . . . .   4
   4.  Operation . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     4.1.  Explicit or Dynamic Path  . . . . . . . . . . . . . . . .   4
     4.2.  LSP Transit Eligibility . . . . . . . . . . . . . . . . .   5
   5.  Manageability Considerations  . . . . . . . . . . . . . . . .   5
     5.1.  Control of Function and Policy  . . . . . . . . . . . . .   6
     5.2.  Information and Data Models . . . . . . . . . . . . . . .   6
     5.3.  Verify Correct Operations . . . . . . . . . . . . . . . .   6
     5.4.  Impact On Network Operations  . . . . . . . . . . . . . .   6
   6.  Implementation Status . . . . . . . . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
     8.1.  STATEFUL-PCE-CAPABILITY TLV Flag  . . . . . . . . . . . .   7
     8.2.  LSP-EXTENDED-FLAG TLV Flags . . . . . . . . . . . . . . .   7
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   7
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .   7
     9.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   9




Sidor, et al.             Expires 23 April 2026                 [Page 2]

Internet-Draft         STATE-REPORTING-EXTENSIONS           October 2025


1.  Introduction

   A Stateful Path Computation Element (PCE) maintains comprehensive
   information on the current network state, including computed Label
   Switched Paths (LSPs), reserved network resources, and the pending
   path computation requests.  This information is critical for
   computing paths for traffic-engineering LSPs and any associated or
   dependent LSPs.

   This document introduces the ability to encode information regarding
   whether a path included in an Explicit Route Object (ERO) was
   specified explicitly or it is the result of dynamic path computation
   executed by a PCE or PCC.  Such information can help in debuggability
   and can be used by other PCEs in the network to avoid triggering
   unnecessary path computations for LSPs where it is not intended
   (e.g., PCE-initiated LSPs with explicit path).

   Additionally, this document specifies a set of extensions to PCEP to
   enhance the accuracy of path computations by considering LSP transit
   eligibility, for example as described in case of LSP stitching in
   [I-D.ietf-pce-stateful-interdomain].

   The mechanisms described in this document are applicable to all path
   setup types.

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

   The following terminologies are used in this document:

   *  ERO: Explicit Route Object.
   *  PCE: Path Computation Element.
   *  PCEP: Path Computation Element Protocol.
   *  LSP: Label Switched Path.

3.  Object Formats

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



Sidor, et al.             Expires 23 April 2026                 [Page 3]

Internet-Draft         STATE-REPORTING-EXTENSIONS           October 2025


   *  T (TRANSIT-ELIGIBLE-CAPABILITY): If set, indicates that the PCEP
      peer supports the advertisement of the Transit Eligible flag in
      the LSP-EXTENDED-FLAG as described in Section 4.2.
   *  X (EXPLICIT-PATH-CAPABILITY): If set, indicates that the PCEP peer
      supports the advertisement of the Explicit flag in the LSP-
      EXTENDED-FLAG.

3.2.  LSP-EXTENDED-FLAG TLV

   New flags are introduced in the LSP-EXTENDED-FLAG TLV, which was
   initially defined in Section 3.1 of [RFC9357].

   *  X (Explicit): If set, indicates that the path encoded in the ERO
      is explicitly specified and not dynamically computed by the PCEP
      peer.
   *  T (Transit Eligible): If set, indicates that the binding value of
      the LSP can be used in paths computed for other LSPs.

4.  Operation

4.1.  Explicit or Dynamic Path

   The X flag in the LSP-EXTENDED-FLAG TLV MUST NOT be set unless the
   EXPLICIT-PATH-CAPABILITY is supported by both PCEP peers.

   If the EXPLICIT-PATH-CAPABILITY is not advertised, the PCE
   implementation MAY use a local policy to determine the type of path.

   For instance, if an operator requests the creation of a PCE-Initiated
   Candidate Path with an Explicit Path, then such path will be encoded
   in the ERO object of the PCInitiate message sent to the PCC.  If the
   delegation of such LSP is transferred to another PCE, the new PCE
   will not know whether the path of the LSP was computed dynamically or
   explicitly specified by the operator.

   Even if a similar problem does not exist for LSPs originated on the
   PCC, information about the type of path may be valuable for other
   purposes, such as debuggability.

   For LSPs initiated by PCC, the X flag value is initially set by the
   PCC in the PCRpt message and the PCE MUST set the flag value in PCUpd
   messages for such LSP based on the last reported state.

   For PCE-initiated LSPs, the X flag value is initially set by the PCE
   in PCInitiate message but MAY be modified in the PCUpd messages.  The
   PCC MUST set the flag value in PCRpt messages for such LSP based on
   the value received from the last PCInitiate or PCUpd message.




Sidor, et al.             Expires 23 April 2026                 [Page 4]

Internet-Draft         STATE-REPORTING-EXTENSIONS           October 2025


   Both explicitly specified and dynamically computed paths, can contain
   a mix of strict and loose subobjects:

   *  For an Explicitly Specified Path (X flag set): An operator might
      define a path that explicitly specifies certain hops (strict) but
      allows the forwarding to select the exact route for other nodes
      (loose).  For example, "go strictly through Router A, then loosely
      to Network B, then strictly through Router C."
   *  For a Dynamically Computed Path (X flag not set): A PCE, when
      computing a path, might generate an ERO that includes strict hops
      (e.g., to satisfy specific constraints like avoiding certain
      links) and loose hops (e.g., where flexibility is allowed to
      optimize for metrics like shortest path).

   For LSPs with multiple Segment Lists (SLs) per Candidate Path (CP),
   the path type (explicit or dynamic) is advertised only once per
   Candidate Path.  Therefore, it is not possible to mix dynamic and
   explicit Segment Lists within a single Candidate Path.

4.2.  LSP Transit Eligibility

   The T flag in the LSP-EXTENDED-FLAG TLV MUST NOT be set unless the
   TRANSIT-ELIGIBLE-CAPABILITY is supported by both PCEP peers.

   If the TRANSIT-ELIGIBLE-CAPABILITY is not advertised, the PCE
   implementation MAY use a local policy to determine the value of the
   Transit Eligible flag.

   For PCC-initiated LSPs, the T flag value is initially set by the PCC
   in the PCRpt message.  The PCE MUST set the flag value in PCUpd
   messages for these LSPs based on the last reported state.

   For PCE-initiated LSPs, the T flag value is initially set by the PCE
   in the PCInitiate message but MAY be modified in subsequent PCUpd
   messages.  The PCC MUST set the flag value in PCRpt messages for
   these LSPs based on the value received from the latest PCInitiate or
   PCUpd message.

5.  Manageability Considerations

   All manageability requirements and considerations listed in [RFC5440]
   and [RFC8231] apply to PCEP protocol extensions defined in this
   document.  In addition, requirements and considerations listed in
   this section apply.







Sidor, et al.             Expires 23 April 2026                 [Page 5]

Internet-Draft         STATE-REPORTING-EXTENSIONS           October 2025


5.1.  Control of Function and Policy

   A PCE or PCC implementation MAY allow the capability of supporting
   PCEP extensions introduced in this document to be enabled or disabled
   as part of the global configuration.

5.2.  Information and Data Models

   An implementation SHOULD allow the operator to view the capability
   defined in this document.  Sections 4.1 and 4.1.1 of
   [I-D.ietf-pce-pcep-yang] should be extended to include the capability
   introduced in Section 3.1 for the PCEP peer.

5.3.  Verify Correct Operations

   Operation verification requirements already listed in [RFC5440] and
   [RFC8231] are applicable to mechanisms defined in this document.

5.4.  Impact On Network Operations

   The mechanisms defined in [RFC5440] and [RFC8231] also apply to the
   PCEP extensions defined in this document.

6.  Implementation Status

   [Note to the RFC Editor - remove this section before publication, as
   well as remove the reference to RFC 7942.]

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




Sidor, et al.             Expires 23 April 2026                 [Page 6]

Internet-Draft         STATE-REPORTING-EXTENSIONS           October 2025


7.  Security Considerations

   The security considerations described in [RFC8231] and [RFC5440] are
   applicable to this document.  No additional security measures are
   required.

8.  IANA Considerations

8.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 to manage the Flags field of the STATEFUL-PCE-
   CAPABILITY TLV.  IANA is requested to make the following assignments:

        +======+=================================+===============+
        | Bit  | Description                     | Reference     |
        +======+=================================+===============+
        | TBA1 | T (TRANSIT-ELIGIBLE-CAPABILITY) | This document |
        +------+---------------------------------+---------------+
        | TBA4 | X (EXPLICIT-PATH-CAPABILITY)    | This document |
        +------+---------------------------------+---------------+

                                 Table 1

8.2.  LSP-EXTENDED-FLAG TLV Flags

   IANA maintains a registry, named "LSP-EXTENDED-FLAG TLV Flag Field",
   within the "Path Computation Element Protocol (PCEP) Numbers"
   registry group to manage the Flags field of the LSP-EXTENDED-FLAG
   TLV.  IANA is requested to make the following assignments:

              +======+======================+===============+
              | Bit  | Description          | Reference     |
              +======+======================+===============+
              | TBA2 | X (Explicit)         | This document |
              +------+----------------------+---------------+
              | TBA3 | T (Transit Eligible) | This document |
              +------+----------------------+---------------+

                                  Table 2

9.  References

9.1.  Normative References






Sidor, et al.             Expires 23 April 2026                 [Page 7]

Internet-Draft         STATE-REPORTING-EXTENSIONS           October 2025


   [I-D.ietf-pce-pcep-yang]
              Dhody, D., Beeram, V. P., Hardwick, J., and J. Tantsura,
              "A YANG Data Model for Path Computation Element
              Communications Protocol (PCEP)", Work in Progress,
              Internet-Draft, draft-ietf-pce-pcep-yang-30, 26 January
              2025, <https://datatracker.ietf.org/doc/html/draft-ietf-
              pce-pcep-yang-30>.

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

   [RFC9357]  Xiong, Q., "Label Switched Path (LSP) Object Flag
              Extension for Stateful PCE", RFC 9357,
              DOI 10.17487/RFC9357, February 2023,
              <https://www.rfc-editor.org/info/rfc9357>.

9.2.  Informative References

   [I-D.ietf-pce-stateful-interdomain]
              Dugeon, O., Meuric, J., Lee, Y., and D. Ceccarelli, "PCEP
              Extension for Stateful Inter-Domain Tunnels", Work in
              Progress, Internet-Draft, draft-ietf-pce-stateful-
              interdomain-07, 3 March 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-pce-
              stateful-interdomain-07>.

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




Sidor, et al.             Expires 23 April 2026                 [Page 8]

Internet-Draft         STATE-REPORTING-EXTENSIONS           October 2025


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


   Andrew Stone
   Nokia
   Email: andrew.stone@nokia.com










Sidor, et al.             Expires 23 April 2026                 [Page 9]
