PCE Working Group S. Peng Internet-Draft Huawei Technologies Updates: 8733 (if approved) D. Dhody Intended status: Standards Track Huawei Expires: 12 April 2027 R. Gandhi Cisco Systems, Inc. 9 October 2026 Update to the Automatic Bandwidth Adjustment Procedure for MPLS-TE and SR-TE LSPs with a Stateful PCE draft-ietf-pce-stateful-pce-autobw-update-05 Abstract Extensions for the stateful PCE model enable control of Traffic Engineering (TE) LSPs using the Path Computation Element Communication Protocol (PCEP) for RSVP-TE and Segment Routing (SR), for both PCE-initiated and PCC-initiated LSPs. RFC 8733 defines PCEP extensions for automatically adjusting bandwidth on MPLS-TE Label Switched Paths (LSPs) using a stateful PCE. It also defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub-TLVs for the attributes. A sub-TLV is included when its value differs from the value last sent in a PCEP message. However, RFC 8733 lacks a mechanism to explicitly remove an attribute identified by a sub-TLV. This document updates RFC 8733 by defining such a mechanism. In addition, this document applies the PCEP extensions for automatic bandwidth adjustment to SR-TE LSPs in both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. It also extends automatic bandwidth adjustment to multiple Segment Lists in an SR LSP using the extensions defined in draft-ietf-pce-multipath. 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/. Peng, et al. Expires 12 April 2027 [Page 1] Internet-Draft Auto-BW-Update October 2026 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 12 April 2027. Copyright Notice Copyright (c) 2026 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 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. AUTO-BANDWIDTH-ATTRIBUTES TLV . . . . . . . . . . . . . . . . 4 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Updated PCEP Procedures . . . . . . . . . . . . . . . . . 7 3.3. PCEP Extension for Auto-Bandwidth . . . . . . . . . . . . 7 3.4. Examples . . . . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. Example 1 . . . . . . . . . . . . . . . . . . . . . . 8 3.4.2. Example 2 . . . . . . . . . . . . . . . . . . . . . . 8 3.4.3. Example 3 . . . . . . . . . . . . . . . . . . . . . . 8 4. Auto-Bandwidth for Segment Routing LSPs . . . . . . . . . . . 9 4.1. Procedure for Multipath Auto-Bandwidth . . . . . . . . . 9 4.2. PCEP Extension for Multipath Auto-Bandwidth . . . . . . . 10 5. Backward Compatibility . . . . . . . . . . . . . . . . . . . 10 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 6.1. Huawei's Commercial Delivery . . . . . . . . . . . . . . 11 7. Operational and Manageability Considerations . . . . . . . . 11 7.1. Control of Function and Policy . . . . . . . . . . . . . 12 7.2. Information and Data Models . . . . . . . . . . . . . . . 12 7.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 7.4. Verifying Correct Operation . . . . . . . . . . . . . . . 12 7.5. Requirements for Other Protocols . . . . . . . . . . . . 12 7.6. Impact on Network Operations . . . . . . . . . . . . . . 12 Peng, et al. Expires 12 April 2027 [Page 2] Internet-Draft Auto-BW-Update October 2026 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction [RFC5440] describes the Path Computation Element Communication Protocol (PCEP). PCEP enables a Path Computation Client (PCC) to communicate with a Path Computation Element (PCE), or with other PCEs, to compute paths for Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs). [RFC8231] specifies extensions to PCEP that enable stateful control of MPLS-TE LSPs. It describes two operating modes: passive stateful PCE and active stateful PCE. [RFC8281] describes the setup, maintenance, and teardown of PCE-initiated LSPs in the stateful PCE model. [RFC8733] defines PCEP extensions for automatically adjusting bandwidth on MPLS-TE Label Switched Paths (LSPs) using a stateful PCE. It defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and a set of sub- TLVs for the attributes. A sub-TLV is included when its value differs from the value last sent in a PCEP message. However, RFC 8733 lacks a mechanism to explicitly remove an attribute identified by a sub-TLV. This document updates [RFC8733] by defining such a mechanism. [RFC8664] specifies PCEP extensions for Segment Routing (SR). These extensions allow a stateful PCE to compute and initiate TE paths and allow a PCC to request paths subject to constraints and optimization criteria. [RFC9603] extends PCEP for SR in the IPv6 data plane (SRv6). As specified in [RFC8664], an LSP can be an MPLS-TE LSP or an SR-TE LSP, depending on the path setup type. An SR Policy, as defined in [RFC9256], contains one or more Candidate Paths (CPs), which a PCE may compute. Each Candidate Path can contain one or more Segment Lists (SLs). In PCEP messages, an SL is encoded as an Explicit Route Object (ERO) as described in Section 4.3 of [RFC8664]. Peng, et al. Expires 12 April 2027 [Page 3] Internet-Draft Auto-BW-Update October 2026 [I-D.ietf-pce-multipath] defines PCEP extensions that allow the signaling of multipath information via PCEP. Using multipath extensions for SR Policy Candidate Paths requires support for [RFC9862]. This document applies PCEP extensions for automatic bandwidth adjustment to SR-TE LSPs in both the MPLS (SR-MPLS) and IPv6 (SRv6) data planes. It also extends automatic bandwidth adjustment to multiple SLs of an SR-TE LSP using the extensions defined in [I-D.ietf-pce-multipath]. 2. Conventions 2.1. Terminology The reader is assumed to be familiar with the terminology defined in [RFC8231], [RFC8281], [RFC8733], and [I-D.ietf-pce-multipath]. This document uses the following terms defined in [RFC5440]: Explicit Route Object (ERO), Path Computation Client (PCC), Path Computation Element (PCE), Path Computation Element Communication Protocol (PCEP), PCEP peer, and PCEP speaker. This document extends the definition of Label Switched Path (LSP) in [RFC3031] as: While the base PCEP specification [RFC4655] originally defined the PCE architecture for MPLS and GMPLS networks with LSPs instantiated using the RSVP-TE signaling protocol. As specified in the Terminology Section of [RFC9603], the term "LSP" used in the PCEP specifications would be equivalent to an SRv6 path (represented as a list of SRv6 segments) in the context of supporting SRv6 in PCEP using the SRv6 Path Setup Type. 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. AUTO-BANDWIDTH-ATTRIBUTES TLV Peng, et al. Expires 12 April 2027 [Page 4] Internet-Draft Auto-BW-Update October 2026 3.1. Overview [RFC8733] describes the auto-bandwidth feature, which automatically adjusts TE LSP bandwidth reservations based on the traffic volume flowing through each LSP. It specifies PCEP extensions for auto- bandwidth adjustment using an active stateful PCE for both PCE- initiated [RFC8281] and PCC-initiated LSPs. RFC 8733 also defines the AUTO-BANDWIDTH-ATTRIBUTES TLV, which provides configurable parameters for the feature and may be included as an optional TLV in the LSPA object. The TLV is included in all PCEP messages for an LSP while auto-bandwidth adjustment is enabled; its absence indicates that the PCEP speaker wishes to disable the feature. The TLV contains multiple AUTO-BANDWIDTH-ATTRIBUTES sub- TLVs defined in [RFC8733]. A sub-TLV is included when its value differs from the value last sent in a PCEP message. When a sub-TLV is absent, local policy determines whether its default value or another operator-configured value is used. Because the absence of a sub-TLV in a subsequent PCEP message indicates that its value has not changed, a PCEP speaker cannot use omission to remove a previously specified attribute. This document updates [RFC8733] to define such a procedure. A PCEP speaker can reset an attribute with an associated default value by encoding that value in the sub-TLV. This approach is unavailable for attributes without a default value. This document defines a special all-zero value to mean "restore to default." Depending on the attribute, this restores its default value or removes the attribute. The following table lists the sub-TLVs and their default values as defined in [RFC8733]. Peng, et al. Expires 12 April 2027 [Page 5] Internet-Draft Auto-BW-Update October 2026 +======+=====+==========================+======================+ | Type | Len | Name | Default | +======+=====+==========================+======================+ | 1 | 4 | Sample-Interval | 300 seconds | +------+-----+--------------------------+----------------------+ | 2 | 4 | Adjustment-Interval | 86400 seconds | +------+-----+--------------------------+----------------------+ | 3 | 4 | Down-Adjustment-Interval | Adjustment-Interval | +------+-----+--------------------------+----------------------+ | 4 | 4 | Adjustment-Threshold | none | +------+-----+--------------------------+----------------------+ | 5 | 8 | Adjustment-Threshold- | 5%, 0 | | | | Percentage | | +------+-----+--------------------------+----------------------+ | 6 | 4 | Down-Adjustment- | Adjustment-Threshold | | | | Threshold | | +------+-----+--------------------------+----------------------+ | 7 | 8 | Down-Adjustment- | Adjustment- | | | | Threshold-Percentage | Threshold-Percentage | +------+-----+--------------------------+----------------------+ | 8 | 4 | Minimum-Bandwidth | 0 | +------+-----+--------------------------+----------------------+ | 9 | 4 | Maximum-Bandwidth | none | +------+-----+--------------------------+----------------------+ | 10 | 8 | Overflow-Threshold | none | +------+-----+--------------------------+----------------------+ | 11 | 8 | Overflow-Threshold- | none | | | | Percentage | | +------+-----+--------------------------+----------------------+ | 12 | 8 | Underflow-Threshold | none | +------+-----+--------------------------+----------------------+ | 13 | 8 | Underflow-Threshold- | none | | | | Percentage | | +------+-----+--------------------------+----------------------+ Table 1: AUTO-BANDWIDTH-ATTRIBUTES Sub-TLVs and Default Values Thus, an all-zero value in the value field of a sub-TLV indicates "restore to default," which may mean one of the following: * if an explicit default value is set for the sub-TLV: - Restore the default value * if the default value is set to another sub-TLV value: - Remove the associated attribute Peng, et al. Expires 12 April 2027 [Page 6] Internet-Draft Auto-BW-Update October 2026 * if there is no default value for the sub-TLV: - Remove the associated attribute The value portion of the sub-TLV contains encoded data of the specified length and type and is set to zero. If it contains multiple fields, each field is set to zero. 3.2. Updated PCEP Procedures Section 5.2 of [RFC8733] defines the AUTO-BANDWIDTH-ATTRIBUTES TLV and its associated sub-TLVs. This document updates [RFC8733] by adding this text at the end of paragraph 3 of Section 5.2 of [RFC8733]: A special value of all zeros in the value portion of the sub-TLV indicates that the attribute identified by the sub-TLV is restored to the default value. The value of all zeros is not considered an invalid value and MUST be checked before individual fields. For the attributes that have an associated default value, on receiving such a sub-TLV, the PCEP speaker MUST treat it as an instruction to restore the default values. Note that the PCEP speaker could also set the default value in the sub-TLV itself. For the attributes that do not have an associated default value, on receiving such a sub-TLV, the PCEP speaker MUST treat it as an instruction to remove the specific auto-bandwidth attribute. 3.3. PCEP Extension for Auto-Bandwidth Section 5.1.1 of [RFC8733] defines the AUTO-BANDWIDTH-CAPABILITY TLV as an optional TLV for use in the OPEN Object for auto-bandwidth adjustment. This document adds the following flag: * Z (bit 31): Indicates that a PCEP speaker supports using the special all-zero value in the value field as specified in this document. The presence of the Z flag indicates to the PCEP peer that this speaker supports the updated procedures defined in this document. A PCEP speaker MUST NOT use the all-zero value semantics defined in this document unless the peer has advertised the Z flag in the AUTO- BANDWIDTH-CAPABILITY TLV. Peng, et al. Expires 12 April 2027 [Page 7] Internet-Draft Auto-BW-Update October 2026 3.4. Examples The examples in this section assume that both PCEP speakers have advertised support for the Z flag. 3.4.1. Example 1 Consider an LSP with the following information in the AUTO-BANDWIDTH- ATTRIBUTES TLV in the PCInitiate message: * Sample-Interval: 600 (in seconds) * Adjustment-Interval: 172800 (2 days in sec) * Adjustment-Threshold: 0x49989680 (10 Mbps in bps) If the PCE wants to disable the Adjustment-Threshold feature for the LSP and set the Adjustment-Interval to one day, it can send the AUTO- BANDWIDTH-ATTRIBUTES TLV in the PCUpd message with the following sub- TLVs: * Adjustment-Interval: 86400 (1 day in seconds, the default value) * Adjustment-Threshold: 0x0 When the PCEP speaker receives an all-zero value in the Adjustment- Threshold sub-TLV, it interprets the value as an instruction to remove the Adjustment-Threshold feature. The PCE could also set the Adjustment-Interval to 0x0 to reset it to its default value. The Sample-Interval remains unchanged. 3.4.2. Example 2 Consider an LSP with the following information in the AUTO-BANDWIDTH- ATTRIBUTES TLV in the PCInitiate message: * Sample-Interval = 1000 If the PCC receives an update that sets Sample-Interval to all zeros, the PCC resets Sample-Interval to its default value of 300 seconds. 3.4.3. Example 3 Consider an LSP with the following information in the AUTO-BANDWIDTH- ATTRIBUTES TLV in the PCInitiate message: * Adjustment-Threshold: 0x49989680 (10 Mbps in bps) Peng, et al. Expires 12 April 2027 [Page 8] Internet-Draft Auto-BW-Update October 2026 * Down-Adjustment-Threshold: 0x93312D00 (20 Mbps in bps) When the PCC receives an update that sets Down-Adjustment-Threshold to all zeros, it removes that attribute, leaving only Adjustment- Threshold. If the PCC receives an update that sets Adjustment-Threshold to all zeros, it removes that attribute as well. 4. Auto-Bandwidth for Segment Routing LSPs The PCEP extensions for automatic bandwidth adjustment defined in [RFC8733] for path setup type "0: Path is set up using the RSVP-TE signaling protocol" also apply to SR-TE LSPs that use path setup types as follows: * Path setup type "1: Traffic-engineering path is set up using Segment Routing" [RFC8664] for the SR-MPLS data plane. * Path setup type "3: Traffic engineering path is set up using SRv6" [RFC9603] for the IPv6 data plane. 4.1. Procedure for Multipath Auto-Bandwidth This document extends the automatic bandwidth adjustment procedure defined in [RFC8733] to multiple path (e.g., SLs of an LSP) using the multipath PCEP extensions defined in [I-D.ietf-pce-multipath] as follows: * The auto-bandwidth attributes defined in Section 5.2 of [RFC8733] apply independently to each path of an LSP. Each path uses its own traffic samples, current bandwidth reservation, and calculated Adjusted Bandwidth. * A PCC (LSP head-end) collects traffic-rate samples and calculates the Adjusted Bandwidth independently for each path. As defined in Section 5.3 of [RFC8733], the PCC reports the calculated bandwidth to be adjusted to the stateful PCE using the existing Requested Bandwidth (Object-Type 1) fo BANDWIDTH (Class 5) for each path. The Requested Bandwidth in BANDWIDTH object is associated with each path identified by its Path ID as specified in Section 4.2 of [I-D.ietf-pce-multipath] in PCRpt message specified in Section 5 of [I-D.ietf-pce-multipath]. * A PCE updates the PCC with the bandwidth value used to compute each path in a PCUpd message, using the existing Requested Bandwidth in BANDWIDTH for each path. Peng, et al. Expires 12 April 2027 [Page 9] Internet-Draft Auto-BW-Update October 2026 The Requested Bandwidth in BANDWIDTH object is associated with each path identified by its Path ID as specified in Section 4.2 of [I-D.ietf-pce-multipath] in a PCUpd message as specified in Section 5 of [I-D.ietf-pce-multipath]. For a PCE-initiated LSP, the same per-path association for Requested Bandwidth in BANDWIDTH object is used in the PCInitiate message as specified in Section 5 of [I-D.ietf-pce-multipath]. 4.2. PCEP Extension for Multipath Auto-Bandwidth Section 5.1.1 of [RFC8733] defines the AUTO-BANDWIDTH-CAPABILITY TLV as an optional TLV for use in the OPEN Object for auto-bandwidth adjustment. This document adds the following flag: * B (bit 30): Indicates that a PCEP speaker supports automatic bandwidth adjustment for multipath LSPs. A PCEP speaker MUST NOT use the multipath auto-bandwidth procedure unless both peers advertise the AUTO-BANDWIDTH-CAPABILITY TLV defined in Section 5.1 of [RFC8733] with the B flag set, and successfully negotiate the MULTIPATH-CAP TLV as specified in Section 4.1 of [I-D.ietf-pce-multipath]. The MULTIPATH-CAP TLV MUST be present in the OPEN objects of both peers. Any per-LSP MULTIPATH-CAP TLV and its effective multipath limit are subject to the procedures in Section 4.1 of [I-D.ietf-pce-multipath]. 5. Backward Compatibility To achieve the same objective, an implementation conforming to [RFC8733] could first send a PCEP message without the AUTO-BANDWIDTH- ATTRIBUTES TLV and then include the TLV with the updated sub-TLV. This is equivalent to turning the feature off and on again, but causes unnecessary path-computation churn compared with targeted removal of the attribute. An existing implementation of [RFC8733] that does not support this update (where the Z flag is not set) will not recognize or use the special value of all zeros in the sub-TLV. If such a sub-TLV is received, as per [RFC8733], implementations may treat the sub-TLV as malformed and ignore it. 6. Implementation Status [Note to the RFC Editor: remove this section before publication and remove the reference to [RFC7942].] Peng, et al. Expires 12 April 2027 [Page 10] Internet-Draft Auto-BW-Update October 2026 This section records the status of known implementations of the protocol defined by this specification as of the posting of this Internet-Draft. It follows the proposal described in [RFC7942]. This information is intended to assist the IETF in deciding whether to progress drafts to RFCs; listing an implementation does not imply IETF endorsement. The information was supplied by IETF contributors and has not been independently verified. This section is not a catalog of available implementations or their features; 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". 6.1. Huawei's Commercial Delivery * Organization: Huawei * Implementation: Based on NE40E-M2 V800R024C00SPC500. * Description: Enabling Automatic Bandwidth Adjustment for a PCC- Initiated SR-MPLS TE Policy * Maturity Level: Product (shipping) * Contact: tanren@huawei.com * Reference: https://support.huawei.com/enterprise/en/doc/ EDOC1100419268/10a4db61/enabling-automatic-bandwidth-adjustment- for-a-pcc-initiated-sr-mpls-te-policy 7. Operational and Manageability Considerations All manageability requirements and considerations listed in [RFC5440], [RFC8231], [RFC8664], and [RFC9256] apply to the PCEP protocol extensions defined in this document. The operational considerations in [I-D.ietf-pce-multipath] also apply to the multipath auto-bandwidth procedure defined in this document. The manageability considerations in Section 6 of [RFC8733] also apply to this document. In addition, the requirements and considerations listed in this section apply. Peng, et al. Expires 12 April 2027 [Page 11] Internet-Draft Auto-BW-Update October 2026 7.1. Control of Function and Policy Per-LSP controls at the PCC (LSP head-end) or PCE allow operators to enable or disable the auto-bandwidth feature. Configuration parameters include sampling and adjustment intervals, minimum and maximum bandwidths, and adjustment thresholds. Appropriate bandwidth limits help avoid adverse effects on the administrative domain, while consistent overflow and underflow thresholds support predictable bandwidth adjustments. 7.2. Information and Data Models Management data models can expose auto-bandwidth configuration and operational information, including the relevant parameters and counters for PCEP messages carrying auto-bandwidth TLVs. 7.3. Liveness Detection and Monitoring This document introduces no new liveness detection or monitoring requirements beyond those specified in [RFC5440]. 7.4. Verifying Correct Operation This document introduces no new procedures for verifying correct operation beyond those specified in [RFC5440]. Logging an invalid sub-TLV value when it is ignored and the previous value is retained can aid troubleshooting. 7.5. Requirements for Other Protocols The mechanisms defined in this document impose no new requirements on other protocols. 7.6. Impact on Network Operations auto-bandwidth processing increases the load on PCCs and PCEs and can increase PCEP message traffic and signaling churn. Per-LSP limits, message-rate controls, and notifications for overload or threshold crossings provide ways to manage this impact. Short sampling intervals leave less time for transport protocols to react to frequent bandwidth changes. 8. Security Considerations The security considerations described in [RFC5440], [RFC8231], [RFC8281], [RFC8664], and [RFC9256] apply to this specification. Peng, et al. Expires 12 April 2027 [Page 12] Internet-Draft Auto-BW-Update October 2026 The security considerations in [I-D.ietf-pce-multipath] apply to the multipath auto-bandwidth procedure defined in this document. The security considerations described in [RFC8733] also apply to this specification. Incorrect or unauthorized use of the all-zero value semantics could remove or reset auto-bandwidth attributes and affect LSP bandwidth adjustment behavior. Therefore, deployments MUST apply the security mechanisms and access controls described in [RFC8733] and the underlying PCEP security mechanisms. 9. IANA Considerations 9.1. AUTO-BANDWIDTH-CAPABILITY TLV Flag Field [RFC8733] defines the AUTO-BANDWIDTH-CAPABILITY TLV Flag Field registry within the "Path Computation Element Protocol (PCEP) Numbers" registry group. IANA is requested to allocate the bits 30 and 31 in that registry. Bit numbers are counted from bit 0 as the most significant bit. +=====+===========================================+===============+ | Bit | Description | Reference | +=====+===========================================+===============+ | 31 | Z flag (special value of all zeros) | This document | +-----+-------------------------------------------+---------------+ | 30 | B flag (multipath auto-bandwidth support) | This document | +-----+-------------------------------------------+---------------+ Table 2: AUTO-BANDWIDTH-CAPABILITY TLV Flag Field 10. References 10.1. Normative References [I-D.ietf-pce-multipath] Koldychev, M. and S. Sidor, "Path Computation Element Communication Protocol (PCEP) Extensions for Signaling Multipath Information", Work in Progress, Internet-Draft, draft-ietf-pce-multipath-29, 23 June 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Peng, et al. Expires 12 April 2027 [Page 13] Internet-Draft Auto-BW-Update October 2026 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, DOI 10.17487/RFC3031, January 2001, . [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, DOI 10.17487/RFC5440, March 2009, . [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, . [RFC8733] Dhody, D., Ed., Gandhi, R., Ed., Palle, U., Singh, R., and L. Fang, "Path Computation Element Communication Protocol (PCEP) Extensions for MPLS-TE Label Switched Path (LSP) Auto-Bandwidth Adjustment with Stateful PCE", RFC 8733, DOI 10.17487/RFC8733, February 2020, . [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, . Peng, et al. Expires 12 April 2027 [Page 14] Internet-Draft Auto-BW-Update October 2026 [RFC9862] Koldychev, M., Sivabalan, S., Sidor, S., Barth, C., Peng, S., and H. Bidgoli, "Path Computation Element Communication Protocol (PCEP) Extensions for Segment Routing (SR) Policy Candidate Paths", RFC 9862, DOI 10.17487/RFC9862, October 2025, . 10.2. Informative References [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, . [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, . [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, . Appendix A. Acknowledgments Thanks to Aijun Wang, Andrew Stone, and Luis Miguel Contreras Murillo for their review comments. Authors' Addresses Shuping Peng Huawei Technologies Huawei Bld., No.156 Beiqing Rd. Beijing 100095 China Email: pengshuping@huawei.com Dhruv Dhody Huawei India Email: dhruv.ietf@gmail.com Peng, et al. Expires 12 April 2027 [Page 15] Internet-Draft Auto-BW-Update October 2026 Rakesh Gandhi Cisco Systems, Inc. Canada Email: rgandhi@cisco.com Peng, et al. Expires 12 April 2027 [Page 16]