PCE Q. Xiong Internet-Draft S. Peng Intended status: Standards Track ZTE Corporation Expires: 11 April 2027 F. Qin China Mobile J. Zhao CAICT 8 October 2026 Path Computation Element Communication Protocol (PCEP) Extension for SR- MPLS Entropy Label Positions draft-ietf-pce-entropy-label-position-08 Abstract The Entropy label (EL) can be used in the SR-MPLS data plane to improve load-balancing and multiple Entropy Label Indicator (ELI)/EL pairs may be inserted in the SR-MPLS label stack as specified in RFC8662. This document defines a set of extensions for Path Computation Element Communication Protocol (PCEP) to indicate where in the label stack the ELI/EL pairs should be inserted in SR-MPLS network - the Entropy Label Positions (ELP). 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 11 April 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Xiong, et al. Expires 11 April 2027 [Page 1] Internet-Draft PCEP for Entropy Label Positions October 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions used in this document . . . . . . . . . . . . . . 4 2.1. Abbreviations and Terminology . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Entropy Labels in SR-MPLS Scenario with PCE . . . . . . . . . 4 4. PCEP Extensions . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. The OPEN Object . . . . . . . . . . . . . . . . . . . . . 6 4.2. The LSP-EXTENDED-FLAG TLV . . . . . . . . . . . . . . . . 6 4.3. The SR-ERO Object . . . . . . . . . . . . . . . . . . . . 6 5. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 7 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9.1. New SR PCE Capability Flag Registry . . . . . . . . . . . 10 9.2. New LSP-EXTENDED-FLAG Flag Registry . . . . . . . . . . . 10 9.3. New SR-ERO Flag Registry . . . . . . . . . . . . . . . . 10 9.4. PCEP-ERROR Object Error Type . . . . . . . . . . . . . . 11 10. Manageability Considerations . . . . . . . . . . . . . . . . 11 10.1. Control of Function and Policy . . . . . . . . . . . . . 11 10.2. Information and Data Models . . . . . . . . . . . . . . 11 10.3. Liveness Detection and Monitoring . . . . . . . . . . . 12 10.4. Verify Correct Operations . . . . . . . . . . . . . . . 12 10.5. Requirements On Other Protocols . . . . . . . . . . . . 12 10.6. Impact On Network Operations . . . . . . . . . . . . . . 12 11. Operational Considerations . . . . . . . . . . . . . . . . . 12 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 13.2. Informative References . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Xiong, et al. Expires 11 April 2027 [Page 2] Internet-Draft PCEP for Entropy Label Positions October 2026 1. Introduction [RFC5440] describes the Path Computation Element Computation Protocol (PCEP) which is used between a Path Computation Element (PCE) and a Path Computation Client (PCC) (or other PCE) to enable computation of Multi-protocol Label Switching (MPLS) for Traffic Engineering Label Switched Path (TE LSP). PCEP Extensions for the Stateful PCE Model [RFC8231] describes a set of extensions to PCEP to enable active control of MPLS-TE and Generalized MPLS (GMPLS) tunnels. [RFC8281] describes the setup and teardown of PCE-initiated LSPs under the active stateful PCE model, without the need for local configuration on the PCC, thus allowing for dynamic centralized control of a network. Segment Routing (SR) leverages the source routing paradigm. Segment Routing can be instantiated on MPLS data plane which is referred to as SR-MPLS [RFC8660]. SR-MPLS leverages the MPLS label stack to construct the SR path. PCEP Extensions for Segment Routing [RFC8664] specifies extensions to the PCEP that allow a stateful PCE to compute and initiate TE paths, as well as a PCC to request a path subject to certain constraint(s) and optimization criteria in SR networks. Entropy label (EL) [RFC6790] is a technique used in the MPLS data plane to improve load-balancing. Entropy Label Indicator (ELI) can be immediately preceding an EL in the MPLS label stack. The idea behind the EL is that the ingress router computes a hash based on several fields from a given packet and places the result in an additional label, named "entropy label". Then, this entropy label can be used as part of the hash keys used by an Label Switch Router (LSR). Using the entropy label as part of the hash keys reduces the need for deep packet inspection in the LSR while keeping a good level of entropy for the load-balancing. When the entropy label is used, the keys used in the hashing functions are still a local configuration matter and an LSR may use solely the entropy label or a combination of multiple fields from the incoming packet. As per [RFC8662], the entropy labels are used in SR-MPLS networks and one or more pairs may be inserted in the SR-MPLS label stack. The ingress node determines the number and positions of the ELI/ELs pairs based on load-balancing requirements. An Entropy Label Position (ELP) identifies each position at which an pair is to be inserted into the label stack. In some cases, a controller(e.g., PCE) could be used to perform the TE path computation as well as entropy label positions which is useful for inter-domain scenarios. This document defines a set of extensions for PCEP to configure the ELP information for SR-MPLS networks. Xiong, et al. Expires 11 April 2027 [Page 3] Internet-Draft PCEP for Entropy Label Positions October 2026 2. Conventions used in this document 2.1. Abbreviations and Terminology The terminology is defined as [RFC5440], [RFC6790], [RFC8664] and [RFC8662]. This document uses the following abbreviations: BMI-MSD: Base MPLS Imposition MSD EL: Entropy Label ELI: Entropy Label Indicator ELC: Entropy Label Capability ELP: Entropy Label Position ERLD: Entropy Readable Label Depth MPLS: Multiprotocol Label Switching MSD: Maximum SID Depth SR: Segment Routing SID: Segment Identifier 2.2. 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. 3. Entropy Labels in SR-MPLS Scenario with PCE [RFC8662] section 4 defines how to use entropy labels for SR-MPLS networks. The Entropy Readable Label Depth (ERLD) is defined as the number of labels which a router can read in an MPLS packet and use in its load-balancing function. As described in [RFC8662] section 7.2.1, the ELRD value is an important factor that needs to be considered when inserting ELI/EL and the minimum ELRD must be evaluated for each node along a computed path. As per [RFC8662], ELI/EL placement requires the minimum ERLD Xiong, et al. Expires 11 April 2027 [Page 4] Internet-Draft PCEP for Entropy Label Positions October 2026 to be evaluated for each node along the path. This adds complexity to ingress insertion and may not be feasible when the ingress cannot obtain per-node ERLD information, such as in inter-domain scenarios where some segments are resolved via other domains. Consequently, the ingress may be unable to evaluate the minimum ERLD for each node and to determine the valid ELI/EL positions. As shown in Figure 1, in SR-MPLS inter-domain scenario, the ingress node of the first domain could not get the ERLD information of other nodes of other domains. The PCE may be used to compute the SR-MPLS path and configure the ELP information using the MSD information advertised from IS-IS [RFC8491] and OSPF [RFC8476], and the ERLD value collected via IS-IS [RFC9088] and OSPF [RFC9089]. The ELP information including the number and the places of the ELI/ELs may be indicated from PCE to PCC to help with the ELI/EL insertion at the ingress node. This document defines the extensions for PCE to perform the computation of the end-to-end path as well as the positions of entropy labels in SR-MPLS networks. The ingress nodes can directly insert the ELI/ELs based on the ELP information. +-----+ +-----+ +-----+ |PCE-1| |PCE-2| |PCE-3| +--+--+ +--+--+ +--+--+ | | | .........+.......... .........+.......... .........+........... . . . . . . .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . .| A |-------| B |------ | C |------| X |-------| Y |------| Z | . .+---+ +---+ . . +---+ +---+ . .+---+ +----+ . . SR-AS 1 . . SR-AS 2 . . SR-AS 3 . .................... .................... ..................... Figure 1: Entropy Labels in SR-MPLS Inter-Domain Scenario 4. PCEP Extensions Xiong, et al. Expires 11 April 2027 [Page 5] Internet-Draft PCEP for Entropy Label Positions October 2026 4.1. The OPEN Object [RFC8408] defines the PATH-SETUP-TYPE-CAPABILITY TLV for use in the OPEN object. As defined in Section 4.1.2 of [RFC8664], PCEP speakers use SR-PCE-CAPABILITY sub-TLV to exchange information about their SR capability. This document defines a new flag (E-flag) for SR PCE Capability sub-TLV. E (ELP Configuration is supported) : A PCE sets this flag bit to 1 carried in Open message to indicate that it supports the computation of SR path with ELP information. A PCC sets this flag to 1 to indicate support for inserting one or more ELI/EL pairs at PCE- indicated positions and for applying PCE-computed SR paths that carry ELP. 4.2. The LSP-EXTENDED-FLAG TLV The LSP Object is defined in Section 7.3 of [RFC8231]. This document defines a new flag (E-flag) for the LSP-EXTENDED-FLAG TLV carried in LSP Object as defined in [RFC9357]. E (Request for ELP Configuration) : In a request from a PCC (e.g., PCReq) as per [RFC5440], the bit is set to 1 indicates that the PCC requests the PCE to compute the SR-MPLS path with ELP information. In a response from a PCE (e.g., PCRep) as per [RFC5440], or in a stateful update (e.g., PCUpd) as per [RFC8231] or initiation (e.g., PCInitiate) as per [RFC8281], the PCE sets this bit to 1 to indicate that ELP information is included in the SR-ERO as specified in Section 4.3. 4.3. The SR-ERO Object SR-ERO subobject is used for SR-TE path which consists of one or more SIDs as defined in [RFC8664]. This document defines a new flag (E-flag) for the SR-ERO subobject. E (ELP Configuration) : If this flag is set in an SR-ERO subobject, the PCC SHOULD insert an pair into the position immediately after this label derived from that subobject when imposing the SR- MPLS label stack. Otherwise it SHOULD NOT insert pair after that subobject. Xiong, et al. Expires 11 April 2027 [Page 6] Internet-Draft PCEP for Entropy Label Positions October 2026 5. Operation A PCC can request the computation of SR path and a PCE may respond with PCRep message. And the SR path can also be initiated by PCE with PCInitiate or PCUpd message in stateful PCE mode. When the E bit of LSP-EXTENDED-FLAG TLV in the LSP object is set to 1 within the message, it indicates to request the ELP configuration with the SR path. The SR path being received by PCC encoded in SR-ERO, for example, , especially S3 and S6 with E-flag set. It indicates that two pairs SHOULD be inserted into the label stack of the SR forwarding entry, respectively after the label for S3 and label for S6. With EL information, the label stack for SR-MPLS would be . 6. Error Handling The document defines the E flag in three related signals and the error handling procedures are like: A PCE setting the E flag of SR PCE Capability sub-TLV in OPEN object MUST be capable of computing SR-MPLS ELP positions using MSD and ERLD information and a PCC setting this flag MUST be capable of inserting one or more pairs at PCE-indicated SR-ERO positions. If the PCE advertises ELP computation support but the PCC does not advertise support for inserting multiple ELI and EL pairs, the PCE MUST NOT return ELP positions that the PCC cannot apply. If the PCE sends an SR-ERO subobject containing E bit, the PCC SHOULD return a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = TBD4 ("Unsupported ELP capability"). If the PCC advertises ELP computation support but the PCE does not advertise support for computing the ELP positions, the PCC MUST NOT set the E flag in the LSP request. If the PCC sends a request containing E bit in LSP object, the PCE SHOULD return a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error- value = TBD4 ("Unsupported ELP capability"). When a PCC requests a PCE to compute the SR path with ELP, the following error handling procedures apply: If the PCC does not set the E flag in LSP-EXTENDED-FLAG TLV but the PCE includes E flags in the SR-ERO response, the PCC MUST NOT apply them and return a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = TBD5 ("Unexpected ELP information"). Xiong, et al. Expires 11 April 2027 [Page 7] Internet-Draft PCEP for Entropy Label Positions October 2026 The PCE MUST NOT return an invalid or partial set of ELP positions. If the PCC received a ELP in SR-ERO subobject which is not valid or partially valid, the PCC SHOULD return a PCErr message with Error- Type = 10 ("Reception of an invalid object") and Error-value = TBD6 ("Invalid ELP information"). If the PCC and PCE advertises the ELP support and the PCC sets the E flag in LSP request but the PCE cannot compute valid ELP positions because ERLD or MSD information is missing, inconsistent, or insufficient, the PCE SHOULD return no usable SR-ERO subobjects and a PCErr message with Error-Type = 10("Reception of an invalid object") and Error-value = TBD7 ("ELP information can not be computed"). In stateful mode, the following error handling procedures apply: For PCE-initiated LSPs: when the PCC receives a PCInitiate message, if the SR-ERO subobjects contains invalid or partially valid ELP information, the PCC SHOULD return a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = TBD6 ("Invalid ELP information"). For PCC-initiated LSPs: when the PCC receives a PCUpd message, the ELP information in the SR-ERO subobjects is the complete replacement for the previous positions for that LSP. A valid SR-ERO subobject with E flag atomically replaces the previous ELP. A valid SR-ERO with subobject no E flag removes all previous ELI and EL pairs. If the SR-ERO subobjects contains invalid or partially valid ELP information, the PCC MUST NOT modify the existing path or ELP state and SHOULD return a PCErr message with Error-Type = 10 ("Reception of an invalid object") and Error-value = TBD6 ("Invalid ELP information"), correlated with the SRP ID of the PCUpd. 7. Implementation Status [NOTE TO RFC EDITOR : This whole section and the reference to RFC 7942 is to be removed before publication as an RFC] Xiong, et al. Expires 11 April 2027 [Page 8] Internet-Draft PCEP for Entropy Label Positions October 2026 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". At the time of posting this version of this document, there are no known implementations of this mechanism. It is believed that some vendor are considering prototype implementations, but these plans are too vague to make any further assertions. 8. Security Considerations The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC8408], [RFC8662] and [RFC8664] apply to this document. This document introduces PCEP extensions to request, compute, and configure the ELP using the E flag in the SR-PCE-CAPABILITY sub-TLV, the LSP-EXTENDED-FLAG TLV, and the SR-ERO subobject. It does not define new authentication, confidentiality, or integrity considerations. But incorrect or unauthorized ELP information creates additional operational and security risks. A PCC MUST validate before applying any ELP. An pair inserted at a position that is deeper than the ERLD of a transit node will be viewed as invalid ELP in error handling section 6. It can not be used by that node for entropy-based load-balancing. This may result in uneven traffic distribution, congestion on specific links, or reduced utilization of ECMP/LAG paths. An pair inserted at a position that exceeds the PCC's Maximum SID Depth (MSD) or Base MPLS Imposition MSD (BMI-MSD), or that causes the total label stack to exceed a midpoint node's imposition limit, may cause label-stack overflow, packet drops, or unsuccessful path installation. Xiong, et al. Expires 11 April 2027 [Page 9] Internet-Draft PCEP for Entropy Label Positions October 2026 9. IANA Considerations 9.1. New SR PCE Capability Flag Registry SR PCE Capability TLV is defined in [RFC8664], and the registry to manage the Flag field of the SR PCE Capability TLV is requested in [RFC8664]. IANA is requested to make allocations from the registry, as follows: +=======+====================================+=================+ | Value | Name | Reference | +=======+====================================+=================+ | TBD1 | ELP Configuration is supported (E) | [this document] | +-------+------------------------------------+-----------------+ Table 1 9.2. New LSP-EXTENDED-FLAG Flag Registry [RFC9357] defines the LSP-EXTENDED-FLAG TLV. IANA is requested to make allocations from the Flag field registry, as follows: +=======+===================================+=================+ | Value | Name | Reference | +=======+===================================+=================+ | TBD2 | Request for ELP Configuration (E) | [this document] | +-------+-----------------------------------+-----------------+ Table 2 9.3. New SR-ERO Flag Registry SR-ERO subobject is defined in [RFC8664], and the registry to manage the Flag field of SR-ERO is requested in [RFC8664]. IANA is requested to make allocations from the registry, as follows: +=======+=======================+=================+ | Value | Name | Reference | +=======+=======================+=================+ | TBD3 | ELP Configuration (E) | [this document] | +-------+-----------------------+-----------------+ Table 3 Xiong, et al. Expires 11 April 2027 [Page 10] Internet-Draft PCEP for Entropy Label Positions October 2026 9.4. PCEP-ERROR Object Error Type IANA is requested to add following Error-Types and Error-values within the "PCEP-ERROR Object Error Types and Values" registry of the "Path Computation Element Protocol (PCEP) Numbers" registry group. +=======+=====================================+=================+ | Value | Meaning | Reference | +=======+=====================================+=================+ | TBD4 | Unsupported ELP capability | [this document] | +-------+-------------------------------------+-----------------+ | TBD5 | Unexpected ELP information | [this document] | +-------+-------------------------------------+-----------------+ | TBD6 | Invalid ELP information | [this document] | +-------+-------------------------------------+-----------------+ | TBD7 | ELP information can not be computed | [this document] | +-------+-------------------------------------+-----------------+ Table 4 10. Manageability Considerations All manageability requirements and considerations listed in [RFC5440], [RFC8231], and [RFC8664] apply to PCEP protocol extensions defined in this document. In addition, requirements and considerations listed in this section also should be applied. 10.1. Control of Function and Policy A PCEP implementation supporting this document SHOULD allow configuration of the capability to support the entropy label position in the stateful PCEP message exchange. A PCC implementation SHOULD allow the operator to configure the policy the PCC needs to apply when configuring the entropy label position. 10.2. Information and Data Models A PCEP implementation supporting this document SHOULD allow the operator to view the entropy label position capability defined in this document. The PCEP YANG module is defined in [RFC9826]. In future, sections 4.1 and 4.1.1 of this YANG module should be extended or augmented to include the capability introduced in section 4.1 for the entropy label position. Xiong, et al. Expires 11 April 2027 [Page 11] Internet-Draft PCEP for Entropy Label Positions October 2026 10.3. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in [RFC5440]. 10.4. Verify Correct Operations Mechanisms defined in this document do not imply any new operation verification requirements in addition to those already listed in [RFC5440], [RFC8231], and [RFC8664] . 10.5. Requirements On Other Protocols Mechanisms defined in this document do not imply any new requirements on other protocols. 10.6. Impact On Network Operations Mechanisms defined in this document do not have any impact on network operations in addition to those already listed in [RFC5440], [RFC8231], and [RFC8664]. 11. Operational Considerations When computing SR-MPLS paths with ELP information, a PCE does not set the E flag on every SR-ERO subobject. Setting an E flag causes the PCC to insert one pair immediately after the label derived from that subobject; therefore, unnecessary E flags increase the label stack depth and consume MSD without improving load-balancing. The PCE SHOULD select SR-ERO subobjects for the E flag using the criteria as sepcified in [RFC8662]. Operators SHOULD ensure consistent ERLD, MSD and ELC advertisement, synchronize the PCE TED, and monitor actual stack depth against MSD. If advertised ERLD is wrong or missing, the PCE MUST NOT assume a deeper readable depth than learned. It may fall back to default values or invalid ELP, and use the error handling rules in Section 6. When computing the ELI/EL positions, the PCE MUST take into consideration Maximum SID Depth (MSD) imposition. The PCEs SHOULD get the information of all nodes such as MSD (e.g. Base MPLS Imposition MSD (BMI-MSD) or ERLD-MSD) through Interior Gateway Protocol (IGP) and compute the minimum ERLD along the end-to-end path based on these topology information. Xiong, et al. Expires 11 April 2027 [Page 12] Internet-Draft PCEP for Entropy Label Positions October 2026 The PCEP extensions defined in this document do not impose any new requirements on other protocols but rely on the MSD information advertised from IS-IS [RFC8491] and OSPF [RFC8476] and the ERLD value collected via IS-IS [RFC9088], and OSPF [RFC9089]. 12. Acknowledgements The authors would like to thank Stephane Litkowski, Dhruv Dhody, Tarek Saad, Zhenbin Li, Jeff Tantsura, Andrew Stone, Xuesong Geng, Ran Chen, Gyan Mishra, Weiqiang Cheng, Samuel Sidor, Saumya Dikshit and Adrian Farrel for their review, suggestions and comments to this document. 13. References 13.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, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [RFC6790] Kompella, K., Drake, J., Amante, S., Henderickx, W., and L. Yong, "The Use of Entropy Labels in MPLS Forwarding", RFC 6790, DOI 10.17487/RFC6790, November 2012, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [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, . [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, . Xiong, et al. Expires 11 April 2027 [Page 13] Internet-Draft PCEP for Entropy Label Positions October 2026 [RFC8408] Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. Hardwick, "Conveying Path Setup Type in PCE Communication Protocol (PCEP) Messages", RFC 8408, DOI 10.17487/RFC8408, July 2018, . [RFC8476] Tantsura, J., Chunduri, U., Aldrin, S., and P. Psenak, "Signaling Maximum SID Depth (MSD) Using OSPF", RFC 8476, DOI 10.17487/RFC8476, December 2018, . [RFC8491] Tantsura, J., Chunduri, U., Aldrin, S., and L. Ginsberg, "Signaling Maximum SID Depth (MSD) Using IS-IS", RFC 8491, DOI 10.17487/RFC8491, November 2018, . [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC8662] Kini, S., Kompella, K., Sivabalan, S., Litkowski, S., Shakir, R., and J. Tantsura, "Entropy Label for Source Packet Routing in Networking (SPRING) Tunnels", RFC 8662, DOI 10.17487/RFC8662, December 2019, . [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, . [RFC9088] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., and M. Bocci, "Signaling Entropy Label Capability and Entropy Readable Label Depth Using IS-IS", RFC 9088, DOI 10.17487/RFC9088, August 2021, . [RFC9089] Xu, X., Kini, S., Psenak, P., Filsfils, C., Litkowski, S., and M. Bocci, "Signaling Entropy Label Capability and Entropy Readable Label Depth Using OSPF", RFC 9089, DOI 10.17487/RFC9089, August 2021, . Xiong, et al. Expires 11 April 2027 [Page 14] Internet-Draft PCEP for Entropy Label Positions October 2026 [RFC9357] Xiong, Q., "Label Switched Path (LSP) Object Flag Extension for Stateful PCE", RFC 9357, DOI 10.17487/RFC9357, February 2023, . 13.2. Informative References [RFC9826] Dhody, D., Ed., Beeram, V., Hardwick, J., and J. Tantsura, "A YANG Data Model for the Path Computation Element Communication Protocol (PCEP)", RFC 9826, DOI 10.17487/RFC9826, September 2025, . Authors' Addresses Quan Xiong ZTE Corporation No.6 Huashi Park Rd Wuhan Hubei, 430223 China Email: xiong.quan@zte.com.cn Shaofu Peng ZTE Corporation No.50 Software Avenue Nanjing Jiangsu, 210012 China Email: peng.shaofu@zte.com.cn Fengwei Qin China Mobile Beijing China Email: qinfengwei@chinamobile.com Junfeng Zhao CAICT Beijing China Email: zhaojunfeng@caict.ac.cn Xiong, et al. Expires 11 April 2027 [Page 15]