BGP-based Inter-domain Elastic Bandwidth-aware Routing Framework
draft-rzz-rtgwg-inter-domain-ebr-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ke Ruan , Li Zhang , Keyi Zhu , Yusheng Zhang | ||
| Last updated | 2026-09-21 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-rzz-rtgwg-inter-domain-ebr-00
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,
<https://datatracker.ietf.org/doc/html/draft-czz-rtgwg-
elastic-bandwidth-routing-00>.
[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,
<https://www.rfc-editor.org/rfc/rfc4271>.
[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/rfc/rfc2119>.
[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/rfc/rfc8174>.
[RFC4451] McPherson, D. and V. Gill, "BGP MULTI_EXIT_DISC (MED)
Considerations", RFC 4451, DOI 10.17487/RFC4451, March
2006, <https://www.rfc-editor.org/rfc/rfc4451>.
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,
<https://www.rfc-editor.org/rfc/rfc9552>.
[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, <https://www.rfc-editor.org/rfc/rfc9086>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-idr-rpd-
20>.
[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, <https://www.rfc-editor.org/rfc/rfc9087>.
[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,
<https://www.rfc-editor.org/rfc/rfc8986>.
[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,
<https://www.rfc-editor.org/rfc/rfc8660>.
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]