Routing Area Working Group K. Ruan Internet-Draft China Telecom Intended status: Informational L. Zhang Expires: 25 March 2027 K. Zhu Y. Zhang Huawei 21 September 2026 BGP-based Inter-domain Elastic Bandwidth-aware Routing Framework draft-rzz-rtgwg-inter-domain-ebr-00 Abstract Although operators typically consider redundant capacity during network design, link congestion may still occur under specific scenarios, such as link degradation or traffic bursts. Several congestion mitigation mechanisms have been proposed for intra-domain links, but congestion is not limited to intra-domain links, it can also occur on inter-domain links. Since changes of available bandwidth do not trigger updates to BGP route selection, BGP cannot alleviate inter-domain link congestion automatically, causing packet loss or increased delay. This document defines a BGP-based inter-domain elastic bandwidth- aware routing (BEBR) mechanism, to alleviate inter-domain link congestion. To avoid the dependency on cross-domain deployment, this document proposes both inbound BEBR and outbound BEBR, designed to address inbound and outbound traffic congestion, respectively. Thus, the congestion on both directions of inter-domain links can be mitigated by deploying BEBR on only one side of the inter-domain link. 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." Ruan, et al. Expires 25 March 2027 [Page 1] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 This Internet-Draft will expire on 25 March 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 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Use Cases of Inter-domain Link Congestion . . . . . . . . . . 4 3. Inbound BEBR . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Overview of Inbound BEBR . . . . . . . . . . . . . . . . 5 3.2. Monitoring and Advertising Link Bandwidth Information . . 6 3.3. Traffic Adjustment Upon Congestion . . . . . . . . . . . 6 3.4. Traffic Fallback of Inbound BEBR . . . . . . . . . . . . 7 4. Outbound BEBR . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Overview of Outbound BEBR . . . . . . . . . . . . . . . . 8 4.2. Monitoring and Advertising of Link Bandwidth Information . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Load-balancing Alternate Path Calculation . . . . . . . . 10 4.4. Traffic Distribution Upon Congestion . . . . . . . . . . 10 4.5. Traffic Fallback of Outbound BEBR . . . . . . . . . . . . 11 5. Operational Considerations . . . . . . . . . . . . . . . . . 11 5.1. Oscillation Suppression . . . . . . . . . . . . . . . . . 11 5.2. Secondary Congestion Handling . . . . . . . . . . . . . . 11 5.3. Triggers for Bandwidth Information Advertisement . . . . 12 5.4. Applicability . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Compatibility . . . . . . . . . . . . . . . . . . . . . . 13 6. Implementation Requirements . . . . . . . . . . . . . . . . . 13 6.1. Protocol List . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Protocols Used in Inbound BEBR . . . . . . . . . . . 13 6.1.2. Protocols Used in Outbound BEBR . . . . . . . . . . . 13 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Normative References . . . . . . . . . . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Ruan, et al. Expires 25 March 2027 [Page 2] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Although operators typically reserve redundant capacity during network design, link congestion may still occur under specific scenarios, such as link degradation or traffic bursts. [I-D.czz-rtgwg-elastic-bandwidth-routing] specifies a congestion avoidance mechanism for intra-domain links. It alleviates congestion by dynamically distributing traffic across both the primary shortest path and load-balancing alternate paths, thereby effectively mitigating intra-domain congestion. However, congestion is not limited to intra-domain links; it can also occur on inter-domain links. When inter-domain link degradation or traffic bursts occur on inter- domain links, BGP[RFC4271] routes remain unchanged because the BGP peer relationship between the two nodes is not disconnected. The relevant ASBR (AS Border Router) cannot detect the degradation and thus cannot automatically optimize the forwarding path. As a result, traffic congestion occurs on the inter-domain links, causing packet loss or increased delay. To address this issue, this document defines a BGP-based inter-domain elastic bandwidth-aware routing mechanism to alleviate inter-domain link congestion. To avoid the dependency on cross-domain deployment, this document proposes both inbound BEBR and outbound BEBR, designed to address inbound and outbound traffic congestion, respectively. Thus, the congestion on both directions of inter-domain links can be mitigated by deploying BEBR on only one side of the inter-domain link. 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 Load-Balancing Alternate Path: An alternate routing path utilized for load balancing traffic when the primary path experiences congestion. Congestion Threshold: A configured bandwidth utilization limit. Ruan, et al. Expires 25 March 2027 [Page 3] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 Traffic distribution among the primary path and load-balancing alternate paths is triggered when the bandwidth utilization of a local link exceeds this threshold. Post-restore Threshold: A configured bandwidth utilization limit. The congested node initiates a fallback to the primary path when the local link's bandwidth utilization drops below this threshold, indicating that congestion has subsided. Local-domain Peer AS Border Router(LP-ASBR): An ASBR is considered an LP-ASBR of another ASBR if both belong to the same domain and connect to the same adjacent domain. 2. Use Cases of Inter-domain Link Congestion On the network shown in Figure 1, node A and node B on the MAN (metropolitan area network) respectively establish EBGP peer relationships with node C and node D on the backbone network through loopback interfaces. Multiple physical links exist between the EBGP peers, and routes of the MAN and backbone network are advertised to each other through EBGP. Traffic is load balanced between domains. If some physical links between node A and node C fail or traffic bursts occur on some links between the two nodes, BGP routes remain unchanged because the EBGP peer relationship between the two nodes is not disconnected. In this case, the backbone network and MAN cannot detect the faults and thus cannot automatically optimize the forwarding path. As a result, traffic congestion occurs on node A and node C, causing packet loss or increased delay. -------------------+ +------------------- +-----+ | | +-----+ --------| A |========================| C |-------- +-----+ | EBGP | +-----+ || | | || | | || | | MAN ||IBGP | | Backbone network || | | || | | || | | +-----+ | EBGP | +-----+ --------| B |========================| D |-------- +-----+ | | +-----+ -------------------+ +------------------- Figure 1: Example topology for inter-domain link congestion Ruan, et al. Expires 25 March 2027 [Page 4] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 3. Inbound BEBR 3.1. Overview of Inbound BEBR Inbound BEBR migrates traffic by adjusting the attributes of advertised BGP routes. It is applicable in scenarios where an ASBR’s inbound link is congested, Figure 2 shows a typical example topology. The process of Inbound BEBR is as follows: 1. Nodes enabling inbound BEBR (e.g., node A and B in Figure 2) need to collect the available bandwidth, bandwidth utilization of their inter-domain links, and the volume of each flow (e.g., based on prefix) on inter-domain links. The available bandwidth and bandwidth utilization information of inter-domain links are advertised to their LP-ASBRs (e.g., through BGP-LS). 2. When a node enabling inbound BEBR detects congestion on a local inter-domain link (e.g., link C-A in Figure 2) and perceives that sufficient bandwidth is available on alternative inter-domain links(e.g, link D-B in Figure 2), it adjusts the BGP attributes of specific routes (e.g., via BGP MED[RFC4451] or AS_PATH[RFC4271]). This adjustment causes nodes in the adjacent domain to select BGP routes with alternative inter-domain links, effectively diverting traffic from the local congested link. 3. When the congestion on the local inter-domain link (e.g., link C-A in Figure 2) disappears, the BGP attributes of specific routes are restored. The updated BGP routes with restored attributes are advertised to ASBRs in the adjacent domain. This update causes nodes in the adjacent domain to select the original routes, thereby reverting traffic back to the local inter-domain link. -------------------+ Traffic +------------------- +-----+ | <---------- | +-----+ --------| A |========================| C |-------- +-----+ | Congestion | +-----+ || | | || | | || | | MAN ||IBGP | EBGP | Backbone network || | | || | | || | Traffic | +-----+ | <---------- | +-----+ --------| B |========================| D |-------- +-----+ | | +-----+ -------------------+ +------------------- Ruan, et al. Expires 25 March 2027 [Page 5] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 Figure 2: Example topology for inbound BEBR 3.2. Monitoring and Advertising Link Bandwidth Information Nodes deploying inbound BEBR need to continuously monitor the bandwidth utilization and available bandwidth of their inbound links. Bandwidth utilization is a key factor in determining whether an link is congested. This determination relies on a configurable Congestion Threshold. If the bandwidth utilization of a link exceeds the Congestion threshold, then the link is congested. Additionally, the volume of each flow (e.g., based on prefix) is required to be collected. This information is used to identify which flows should be diverted from the congested link when congestion occurs. The mechanism for obtaining per-flow volume is out of scope for this document. Upon detecting local link congestion, adjusting traffic arbitrarily may cause new congestion on other inter-domain links. Therefore, it is crucial to obtain information regarding the available bandwidth and bandwidth utilization of alternate inter-domain links in the network. The bandwidth information of an ASBR's inter-domain link is required to be advertised to its LP-ASBRs. This can be realized by enabling BGP-LS[RFC9552] between an ASBR and its LP-ASBRs, and by enabling BGP EPE (Egress Peer Engineering)[RFC9086] between an ASBR and its neighber ASBRs in adjacent domains. The triggers for bandwidth information advertisement are introduced in Section 5.3. 3.3. Traffic Adjustment Upon Congestion Once a node deploying inbound BEBR detects that one of its links is expericing congestion, the traffic adjustment mechanism is triggered to divert specific flows from the congested link. The traffic adjustment process is as follows: Ruan, et al. Expires 25 March 2027 [Page 6] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 1. The congested node (a node that has an inbound inter-domain link experiencing congestion, e.g., node A in Figure 2) generates optimization policies and corresponding RPD[I-D.ietf-idr-rpd] routing policies (optional). The optimization policies determine which flows need to be diverted from the congested link based on the volume of each flow and the available bandwidth of other alternate inter-domain links. 2. The congested node applies the generated optimization policies to adjust the BGP attributes of specific routes (e.g., by increasing the MED values or AS_PATH lengths of specific routes). 3. Optionally, the congested node sends the RPD routing policies to its LP-ASBRs (e.g., node B in Figure 2). The content of the RPD routing policies is to instruct the adjusting of BGP attributes of specific routes advertised by its LP-ASBRs. 4. Optionally, upon receiving the RPD routing policies, the LP-ASBRs (e.g., node B in Figure 2) adjust the BGP attributes of specific routes in accordance with the RPD routes. 5. Upon receiving the BGP routes with updated attributes, nodes in the adjacent domain(e.g., node C and D in Figure 2) select the routes advertised by the LP-ASBRs(e.g., node B in Figure 2) and forward traffic to them, thereby implementing traffic migration. RPD routing policies are advertised only when the BGP attributes of specific routes advertised by LP-ASBRs need to be adjusted. This mechanism helps to either avoid or preferentially select routes from specific LP-ASBRs during traffic adjustment. To prevent the confliction of simultaneous traffic adjustment from multiple ASBRs, the ASBR with the smallest router ID will execute traffic adjustment when multiple ASBRs are doing traffic adjustment at the same time. Policies may be configured to determine which flows (e.g., based on traffic class or IP prefixes) should be diverted to the alternate inter-domain links. 3.4. Traffic Fallback of Inbound BEBR Traffic Fallback refers to the process where an ASBR reverts traffic from the alternate inter-domain link to the original inter-domain link, thereby restoring the network to its original state. The conditions for triggering traffic fallback are as follows: Ruan, et al. Expires 25 March 2027 [Page 7] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 * Condition 1: After all traffic has reverted to the original inter- domain link, its bandwidth utilization does not exceed the Post- restore Threshold. * Condition 2: Condition 1 is met and has sustained for a configurable Restore Period (to prevent frequent traffic oscillation). The traffic fallback process is as follows: 1. The congestion recovery node (the node that previously experienced congestion, e.g., node A in Figure 2) cancels the optimization policies, restoring the BGP attributes of affected routes to their original values. The updated BGP routes with restored attributes are advertised to ASBRs in the adjacent domain. 2. Optionally, the congestion recovery node withdraws the RPD routing policies previously sent to its LP-ASBRs (e.g., node B in Figure 2). 3. Optionally, upon receiving the RPD routing policy withdrawal, the LP-ASBRs restores the BGP attributes of specific routes and advetises the updated BGP routes with restored attributes to ASBRs in the adjacent domain. 4. Upon receiving the updated routes, nodes in the adjacent domain (e.g., node C and D in Figure 2) select routes from the original ASBR, thereby completing the traffic fallback. 4. Outbound BEBR 4.1. Overview of Outbound BEBR Outbound BEBR implements traffic load balancing by steering specific flows to pre-computed load-balancing alternate paths via SR strict path. It is applicable in scenarios where an ASBR’s outbound link is congested, as shown in Figure 3). The process of outbound BEBR is as follows: 1. Nodes enabling outbound BEBR (e.g., node A in Figure 3) monitor the available bandwidth, bandwidth utilization of their outbound links, and per-flow volume (e.g., based on prefix) forwarded through inter-domain links. The available bandwidth and bandwidth utilization information of the links are advertised to their LP-ASBRs (e.g., via BGP-LS). Ruan, et al. Expires 25 March 2027 [Page 8] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 2. Nodes enabling outbound BEBR pre-calculate load-balancing alternate paths that bypass the congested inter-domain link. 3. When a node enabling outbound BEBR detects congestion on a local inter-domain link (e.g., link C-A in Figure 2) , it migrates specific flows to the pre-computed load-balancing alternate paths via SR strict path, thereby reducing the traffic load on the congested link. 4. When the congestion on the local inter-domain link disappears, the traffic is reverted back to the original local inter-domain link (e.g., link A-C in Figure 3). -------------------+ Traffic +------------------- +-----+ | ----------> | +-----+ --------| A |========================| C |-------- +-----+ | Congestion | +-----+ || | | || | | || | | MAN ||IBGP | EBGP | Backbone network || | | || | | || | Traffic | +-----+ | ----------> | +-----+ --------| B |========================| D |-------- +-----+ | | +-----+ -------------------+ +------------------- Figure 3: Example topology for outbound BEBR 4.2. Monitoring and Advertising of Link Bandwidth Information The procedures for monitoring and advertising link bandwidth information are the same as Section 3.2. The difference between outbound BEBR and inbound BEBR is that the nodes enabling outbound BEBR need to monitor and advertise the bandwidth information for their outbound links. In addition, the ASBR and its LP-ASBRs need to be directly connected, so that the ASBRs can collect the bandwidth information of links between the ASBRs and their LP-ASBRs (e.g. link A-B in Figure 3). Ruan, et al. Expires 25 March 2027 [Page 9] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 4.3. Load-balancing Alternate Path Calculation The load-balancing alternate paths in BEBR are used for load balancing when the inter-domain link of the primary path is congested. Each BEBR-enabled node SHOULD calculate load-balancing alternate paths to the adjacent domain in advance. The destination of a load-balancing alternate path does not need to align with the primary path, it only needs to be one of the reachable ASBRs of the same adjacent domain. SIDs are required to be configured on inter-domain links (e.g., link A-C and B-D in Figure 3) for composing the load-balancing alternate path. IGP is required to be deployed on ASBRs to advertise the SID information to their LP- ASBRs. The algorithm used for load-balancing alternate path calculation is implementation-specific. 4.4. Traffic Distribution Upon Congestion Once a node enabling outbound BEBR detects that one of its links is expericing congestion, the traffic distribution mechanism is triggered to distribute traffic between the primary and load- balancing alternate paths. UCMP (Unequal Cost Multi-Path) is recommended for flow distribution. The weight of each path is determined by its available bandwidth and bandwidth utilization. Specifically: * Path Available Bandwidth: Defined as the minimum available bandwidth among all links on the path (i.e., the bottleneck). * Path Utilization: Defined as the maximum utilization ratio among all links on the path. Path weights remain static once determined, unless new congestion is detected on the links of the load-balancing alternate paths. Flows steered to load-balancing alternate paths are forwarded by SR strict paths, ensuring loop-free forwarding. The SIDs of the inter- domain links May be used as the destination for outer encapsulation. The encapsulation method depends on the data plane type: * SR-MPLS: Packets are encapsulated with an ordered list of MPLS labels representing the load-balancing alternate path. Ruan, et al. Expires 25 March 2027 [Page 10] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 * SRv6: Packets are encapsulated with an outer IPv6 header and a Segment Routing Header (SRH) containing the SID list for the load- balancing alternate path. Policies may be configured to determine which flows (e.g., based on traffic class or IP prefixes) should be migrated from the primary path to the load-balancing alternate paths. 4.5. Traffic Fallback of Outbound BEBR The conditions for traffic fallback of outbound BEBR are the same as those defined in Section 3.4. The fallback process for outbound traffic is straightforward. The congestion recovery node disables UCMP load balancing on the primary and load-balancing alternate paths, reverting traffic to the primary path. 5. Operational Considerations 5.1. Oscillation Suppression Micro-burst traffic or flapping bundle member links may cause frequent changes in link utilization and congestion state, potentially resulting in traffic distribution oscillation. To mitigate this, the following suppression measures should be implemented: * Congestion detection and fallback decisions should account for the statistical characteristics of bandwidth utilization over a sustained period, rather than relying solely on instantaneous utilization. * The Congestion Threshold should be sufficiently separated from the Post-restore Threshold to prevent congestion state flapping caused by minor traffic fluctuations. 5.2. Secondary Congestion Handling Although available bandwidth and bandwidth utilization of load- balancing alternate path are considered during traffic distribution, congestion may still occur on the alternate inter-domain links due to unexpected factors. There are two mechanisms for inbound and outbound BEBR to alleviate the potential secondary congestions. Ruan, et al. Expires 25 March 2027 [Page 11] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 * Inbound BEBR: When a node which initiated traffic adjustment detects that the bandwidth utilization of one of the in-use inter- domain link exceeds the Congestion Threshold, it may adjust the BGP attributes of specific routes to shift traffic away from the congested inter-domain link and alleviate congestion. * Outbound BEBR: Similarly, when a node which initiated the traffic distribution detects that the bandwidth utilization of one of the in-use load-balancing alternate path exceeds the Congestion Threshold, it may decrease the load-balancing weight of that path to reduce traffic flow on the congested path and alleviate congestion. In addition to secondary congestion occurring on inter-domain links, such congestion may also arise on intra-domain links. Shifting traffic from one ASBR to another can increase the bandwidth utilization of specific intra-domain links. Therefore, it is recommended that the EBR [I-D.czz-rtgwg-elastic-bandwidth-routing] be deployed within each domain to alleviate congestion on intra-domain links. 5.3. Triggers for Bandwidth Information Advertisement BEBR relies on available bandwidth and bandwidth utilization information of inter-domain links advertised by BGP-LS. The frequency of advertisement should be constrained to prevent the control plane overhead. The following recommendations define the triggers for bandwidth information advertisement: * Minimum Advertisement Interval: The interval between consecutive advertisements must not be less than the configured Minimum Advertisement Interval. The Minimum Advertisement Interval is configurable, a value of 30 seconds is recommended. * Absolute Change Threshold: If the Minimum Advertisement Interval has elapsed and the available bandwidth has changed by at least x% since the last advertisement, a new advertisement SHOULD be sent. The threshold x is configurable; a value of 5% is recommended. 5.4. Applicability The mechanism proposed in this document is applicable to the network scenarios where the following conditions are met: * Two adjacent domains are directly connected via links. * Multiple inter-domain links exist between these two adjacent domains. Ruan, et al. Expires 25 March 2027 [Page 12] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 5.5. Compatibility BEBR supports incremental deployment in a network. It does not require coordination with the peer nodes in adjacent domains and can alleviate inter-domain congestion by being deployed on one side only. 6. Implementation Requirements 6.1. Protocol List 6.1.1. Protocols Used in Inbound BEBR The following protocols are used in outbound BEBR: * BGP [RFC4271] * BGP-LS [RFC9552] * BGP-EPE [RFC9087] * BGP-RPD [I-D.ietf-idr-rpd] (Optional) 6.1.2. Protocols Used in Outbound BEBR The following protocols are used in outbound BEBR: * BGP [RFC4271] * SRv6 [RFC8986]/SR-MPLS[RFC8660] * BGP-LS [RFC9552] * BGP-EPE [RFC9087] 7. IANA Considerations This document has no IANA actions. 8. Security Considerations All security considerations for base BGP-LS [RFC9552] and BGP extensions for RPD [I-D.ietf-idr-rpd] apply to this document. Ruan, et al. Expires 25 March 2027 [Page 13] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 BEBR relies on bandwidth information advertised via BGP-LS. Incorrect bandwidth information may lead to congestion on specific links. In typical deployments, BEBR is implemented by ASBR within a single domain that is entirely under the control of a single operator. However, if link bandwidth information is transported over unauthenticated channels, a man-in-the-middle attacker could modify the bandwidth values, thereby inducing congestion on specific links. Furthermore, advertising links that are approaching congestion may provide an attacker with valuable information to destabilize the network. For example, an attacker could inject an edge-to-edge flow (i.e., without needing to modify anything inside the network) to trigger congestion on the identified link. Cryptographic authentication mechanisms for link state advertisements can mitigate these risks. 9. Normative References [I-D.czz-rtgwg-elastic-bandwidth-routing] Cheng, W., KaZhang, Zhang, L., Contreras, L. M., and J. Dong, "Elastic Bandwidth-aware Routing Framework", Work in Progress, Internet-Draft, draft-czz-rtgwg-elastic- bandwidth-routing-00, 6 July 2026, . [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC4451] McPherson, D. and V. Gill, "BGP MULTI_EXIT_DISC (MED) Considerations", RFC 4451, DOI 10.17487/RFC4451, March 2006, . Ruan, et al. Expires 25 March 2027 [Page 14] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 [RFC9552] Talaulikar, K., Ed., "Distribution of Link-State and Traffic Engineering Information Using BGP", RFC 9552, DOI 10.17487/RFC9552, December 2023, . [RFC9086] Previdi, S., Talaulikar, K., Ed., Filsfils, C., Patel, K., Ray, S., and J. Dong, "Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing BGP Egress Peer Engineering", RFC 9086, DOI 10.17487/RFC9086, August 2021, . [I-D.ietf-idr-rpd] Li, Z., Ou, L., Luo, Y., Mishra, G. S., Chen, H., and H. Wang, "BGP Extensions for Routing Policy Distribution (RPD)", Work in Progress, Internet-Draft, draft-ietf-idr- rpd-20, 1 March 2026, . [RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E., and D. Afanasiev, "Segment Routing Centralized BGP Egress Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August 2021, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [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, . Acknowledgements TBD Contributors Ka Zhang Huawei China Email: zhangka@huawei.com Ruan, et al. Expires 25 March 2027 [Page 15] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 Jie Dong Huawei China Email: jie.dong@huawei.com Haibo Wang Huawei China Email: rainsword.wang@huawei.com Ming Shen Huawei China Email: shenming2@huawei.com Jun Ge Huawei China Email: jack.gejun@huawei.com Yifan Wang Huawei China Email: wangyifan82@huawei.com Xiangfeng Ding Huawei China Email: dingxiangfeng@huawei.com Authors' Addresses Ke Ruan China Telecom China Email: ruanke@chinatelecom.cn Li Zhang Huawei China Email: zhangli344@huawei.com Ruan, et al. Expires 25 March 2027 [Page 16] Internet-Draft BGP-based Inter-domain Elastic Bandwidth September 2026 Keyi Zhu Huawei China Email: zhukeyi@huawei.com Yusheng Zhang Huawei China Email: ryan.cheung@huawei.com Ruan, et al. Expires 25 March 2027 [Page 17]