BGP Link Bandwidth Extended CommunityGoogle LLCpradosh@gmail.comHPE1133 Innovation WaySunnyvaleCA94089United States of Americareshma.das@hpe.comZscaler120 Holger WaySan JoseCA95134United States of Americasmohanty@zscaler.comCisco SystemsPegasus Parc, De Kleetlaan 6aBelgiumsekrier@cisco.comGoogle LLC1160 N Mathilda AveSunnyvaleCA94089United States of Americarszarecki@gmail.comArista Networks5453 Great America ParkwaySanta ClaraCA95054United States of Americaakshay@arista.com
RTG
idrexampleThis document defines a BGP extended community, the Link Bandwidth
Extended Community, which carries bandwidth information to enable
weighted load-balancing in multipath scenarios. It specifies the format
and processing rules for this extended community type.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
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
() 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
. Introduction
. Requirements Language
. Link Bandwidth Extended Community
. Protocol Procedures
. Sender (Originating Link Bandwidth Extended Community)
. Receiver (Receiving Link Bandwidth Extended Community)
. Re-Advertisement Procedures
. Re-Advertisement with Next Hop Change
. Re-Advertisement with Next Hop Unchanged
. Link Bandwidth Extended Community Arithmetic and BGP Multipath
. Error Handling
. IANA Considerations
. Security Considerations
. Operational Considerations
. Inconsistent Deployment
. Bandwidth Value
. References
. Normative References
. Informative References
. Document History
Acknowledgments
Contributors
Authors' Addresses
IntroductionLoad-balancing is a critical aspect of network design, enabling
efficient utilization of available bandwidth and improving overall
network performance. Traditional equal load-balancing does not
account for the varying capacities of different paths. This document
suggests that the bandwidth be carried in the network using one of two
new extended communities : the transitive and
non-transitive Link Bandwidth Extended Community. The Link Bandwidth
Extended Community carries the bandwidth information of a directly
connected link or multi-hop/multipath next hop as advertised by a router.
This mechanism facilitates maximizing utilization of network
resources.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 when, and only when, they appear in all capitals, as
shown here.
Link Bandwidth Extended CommunityThe Link Bandwidth Extended Community is defined as a BGP extended
community that carries the bandwidth information of a router
(represented by BGP next hop) that is connecting to a remote network. This
community can be used to inform other routers about the available
bandwidth through a given route.The Link Bandwidth Extended Community can be either transitive or
non-transitive. Therefore, the value of the high-order octet of the
extended Type field can be 0x00 or 0x40, respectively. The value of the
low-order octet of the extended Type field for this community is
0x04.The Global Administrator sub-field in the Value field SHOULD be set
to the Autonomous System Number (ASN) of the router attaching the Link
Bandwidth Extended Community, but it MAY contain any 2-octet value. If
the ASN cannot be represented in 2 octets,
AS_TRANS SHOULD be used in the Global
Administrator sub-field. The encoding of the full 4-octet ASNs is not
supported by the Link Bandwidth Extended Community. Such a capability,
should the operational need for it arise, may be provided by a new BGP
extension. The value in the Global Administrator sub-field does not
affect the use or semantics of the Link Bandwidth Extended Community.
This approach maintains consistency with 2-octet community registries
and remains operationally familiar.The bandwidth value is expressed as 4 octets in the floating point format of , with units being bytes (not
bits!) per second. It is carried in the Local Administrator sub-field of
the Value field.Link Bandwidth Extended Community
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type=0x00/0x40 | SubType=0x04 | Global Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Administrator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type:
A 1-octet field that MUST be set to
0x00 or 0x40 to indicate transitive/non-transitive.
SubType:
A 1-octet field that MUST be set
to 0x04 to indicate "link-bandwidth".
Global Administrator sub-field:
A 2-octet field that represents
an operator-assigned 2-octet value. For example, this can be a
16-bit ASN.
Local Administrator sub-field:
Bandwidth value (bytes per second)
encoded as 4 octets in the 32-bit floating point format of .
Protocol ProceduresThe procedures cover both the transitive and non-transitive variants
of the Link Bandwidth Extended Community so that implementations can
handle both variants, ensuring that implementations can interoperate
correctly across all deployments. Please refer to
and for more details.Sender (Originating Link Bandwidth Extended Community)A BGP speaker that attaches a Link Bandwidth Extended Community
SHOULD be able to advertise either a transitive or a non-transitive
Link Bandwidth Extended Community. Implementations SHOULD provide the
configuration to set the transitivity type of the Link Bandwidth
Extended Community, as well as the Global Administrator and bandwidth
values in the Local Administrator sub-field, by using local policy.
Different implementations MAY use different default values for the
transitivity type of the Link Bandwidth Extended Community. The
provided configuration SHOULD allow operators to override the default
transitivity value as needed. Likewise, implementations SHOULD expose
their default value.An implementation MAY advertise bandwidth value as zero. An
operator may, for example, set the Link Bandwidth Extended Community
to zero to indicate that the path should not attract traffic during
maintenance. However, as per , it is up to
the local policy of the receiver to decide how a link-bandwidth value
of zero is handled.Generally, a single Link Bandwidth Extended Community of the
transitivity type desired in a deployment is attached to a route.
However, during transition (refer for details), a BGP speaker MAY
attach one Link Bandwidth Extended Community per transitivity
(transitive/non-transitive); the bandwidth value included in both
communities SHOULD be the same.A Link Bandwidth Extended Community MAY be attached or updated for
a BGP route upon receipt during Adj-RIB-In processing. The Link
Bandwidth Extended Community MAY be attached or updated for a BGP
route's Adj-RIB-Out entry while being advertised to a neighboring BGP
speaker. (Adj-RIB-In and Adj-RIB-Out are as defined in .)Implementations MAY provide a configuration option to send
non-transitive Link Bandwidth Extended Communities on external BGP
sessions.Receiver (Receiving Link Bandwidth Extended Community)A BGP receiver that supports the Link Bandwidth Extended Community
MUST support processing of both the transitive and non-transitive
types. The receiver MUST NOT flap or treat the route as malformed
based on the transitivity of the Link Bandwidth Extended Community
and/or BGP session type (internal versus external). Implementations MAY provide configuration to accept non-transitive
Link Bandwidth Extended Communities from external BGP sessions.A BGP update with an attached Link Bandwidth Extended Community
with a bandwidth value of zero is valid. When all contributing paths
have a non-zero value in the Link Bandwidth Extended Community, the
bandwidth values of those paths (or their ratio) can be utilized as
weights to enable weighted load-balancing. Details of weighted
load-balancing are outside the scope of this document. Refer to , which describes some of the
weighted load-balancing aspects. However, in the case where the paths
have a mix of zero and non-zero values, or all zero values, the
behavior is determined by local policy. For example, implementations
may exclude the paths with a zero value from weighted load-balancing
formation as long as at least one path with a non-zero value exists, or
they may fall back to equal load-balancing. The bandwidth value,
however, SHOULD NOT be used as an input to the BGP best path selection
process.Between transitive and non-transitive types of Link Bandwidth
Extended Communities that have the same bandwidth value, the
transitivity does not matter for the purpose of computing weighted load-balancing or programming to the Forwarding Information Base (FIB).Re-Advertisement ProceduresThis section describes the procedures to be followed when a BGP
speaker receives a route with an attached Link Bandwidth Extended
Community and subsequently re-advertises that route.Re-Advertisement with Next Hop ChangeWhen a BGP speaker re-advertises a route received with a Link
Bandwidth Extended Community and sets the next hop to itself or to
another address, it MAY do any one of the following as its default
behavior: remove the Link Bandwidth Extended Community, re-advertise
it unchanged, or regenerate it with an updated value.
Implementations SHOULD provide a local configuration method to alter
their default behavior to the other options with per-session
granularity. Likewise, implementations SHOULD expose their default
value.When regenerating the Link Bandwidth Extended Community, the same
procedures as outlined in apply. Please
also refer to for use in a
BGP multipath environment.Re-Advertisement with Next Hop UnchangedA BGP speaker that receives a route with a Link Bandwidth
Extended Community and re-advertises or reflects the same without
changing its next hop SHOULD NOT change the Link Bandwidth Extended
Community in any way.Link Bandwidth Extended Community Arithmetic and BGP MultipathIn a BGP multipath environment, the bandwidth value that is sent or
re-advertised MAY be calculated based on the Link
Bandwidth Extended Community associated with each constituent path
contributing to multipath in the Local Routing Information Base
(Local-RIB). This topic is beyond the scope of this document. Refer to
, which describes how this
could be done in specific scenarios.Error HandlingIf a BGP speaker receives a route with more than one Link Bandwidth
Extended Community and uses the route to compute weighted load-balancing, it SHOULD use the extended community with the lowest
bandwidth value (including zero), ignoring the transitivity.
Implementations MAY provide configuration to change the above
preference.A negative value in a Link Bandwidth Extended Community SHOULD NOT be
attached or originated by any BGP speaker. If a BGP receiver encounters
a Link Bandwidth Extended Community that contains a negative
link-bandwidth value, the Link Bandwidth Extended Community SHALL be
ignored.Link Bandwidth Extended Communities with a zero value MUST NOT be
considered malformed.If any of the paths lack a valid Link Bandwidth Extended Community,
equal load-balancing SHOULD be used unless overridden by local
configuration.IANA ConsiderationsIn the "Transitive Two-Octet AS-Specific
Extended Community Sub-Types" registry
(Type 0x00), IANA has updated Sub-Type 0x04 to:
Name:
Link Bandwidth
In the "Non-Transitive Two-Octet AS-Specific
Extended Community Sub-Types" registry (Type 0x40), IANA has updated Sub-Type 0x04 to:
Name:
Link Bandwidth
Both updates reference this document.Security ConsiderationsThis extension to BGP has similar security implications as BGP
extended communities .The Link Bandwidth Extended Community conveys bandwidth and capacity
information that may be sensitive. Exporting this community outside of
an administrative domain can expose private network resource details.
When propagating the routes with a Link Bandwidth Extended Community
towards an untrusted network or outside of an administrative domain, it
is recommended operators use policy to filter out this community.Operational ConsiderationsInconsistent DeploymentPrior deployments of the feature specified in this document have
involved implementations that only understood one of the two extended
community transitivity types. As a result, such implementations would
ignore the other transitivity type that they don't understand. The
procedures in this document govern how multiple transitivity types for
bandwidth should operate.Inconsistent behavior could occur when networks have deployed a
mixture of implementations supporting this document's procedures for
both transitivity types, or have deployed older implementations that
only understand one transitivity type. A prime example is when a
route received by a BGP speaker contains both a transitive and a
non-transitive Link Bandwidth Extended Community, and that BGP speaker
performs an operation that updates only one of the Link Bandwidth
Extended Communities, so then the other community may have an
inconsistent value. As a result, downstream BGP speakers that may
receive such routes may perform inappropriate weighted load-balancing.To mitigate such issues, when operators are aware that older
implementations are present in their networks, they may wish to take
actions to address such inconsistencies.
One option would be to filter the unsupported transitivity type of the
Link Bandwidth Extended Community at advertisement time on the older BGP
speaker, if the implementation is capable of such filtering.
Alternatively, a
receiving BGP speaker, knowing that the sending speaker is incapable
of doing such operations, could strip the Link Bandwidth Extended
Community type that is unsupported by the sender.Ideally, this operational consideration is short lived until all the
routers in the network have been upgraded to implementations that
consistently support the procedures in this document.Bandwidth ValueHow the bandwidth value is computed or determined is out of scope
of this document. Refer to ,
which describes how this could be done in specific scenarios. It is
recommended that implementations provide mechanisms to limit the churn
caused by frequently changing bandwidth values, because rapid
fluctuations could impact protocol stability and network
operations.ReferencesNormative ReferencesIEEE Standard for Floating-Point ArithmeticIEEEKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.A Border Gateway Protocol 4 (BGP-4)This document discusses the Border Gateway Protocol (BGP), which is an inter-Autonomous System routing protocol.The primary function of a BGP speaking system is to exchange network reachability information with other BGP systems. This network reachability information includes information on the list of Autonomous Systems (ASes) that reachability information traverses. This information is sufficient for constructing a graph of AS connectivity for this reachability from which routing loops may be pruned, and, at the AS level, some policy decisions may be enforced.BGP-4 provides a set of mechanisms for supporting Classless Inter-Domain Routing (CIDR). These mechanisms include support for advertising a set of destinations as an IP prefix, and eliminating the concept of network "class" within BGP. BGP-4 also introduces mechanisms that allow aggregation of routes, including aggregation of AS paths.This document obsoletes RFC 1771. [STANDARDS-TRACK]BGP Extended Communities AttributeThis document describes the "extended community" BGP-4 attribute. This attribute provides a mechanism for labeling information carried in BGP-4. These labels can be used to control the distribution of this information, or for other applications. [STANDARDS-TRACK]BGP Support for Four-Octet Autonomous System (AS) Number SpaceThe Autonomous System number is encoded as a two-octet entity in the base BGP specification. This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities. This document obsoletes RFC 4893 and updates RFC 4271. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.Informative ReferencesNon-Transitive Two-Octet AS-Specific Extended Community Sub-TypesIANATransitive Two-Octet AS-Specific Extended Community Sub-TypesIANABGP link bandwidth extended community use casesCiscoZscalerNvidiaArista NetworksArista NetworksNvidiaHPEBGP link bandwidth extended community provides a way to signal a value along with a BGP path that can be used to perform weighted load-balancing in multipath scenarios. This document details various use cases of the BGP link bandwidth extended community. It also describes local mechanisms to dynamically adjust the BGP link bandwidth value or the multipath weights based on different considerations.Work in ProgressDocument HistoryThe BGP Link Bandwidth Extended Community has evolved over several
versions of the IETF draft. In the earlier versions up to
draft-ietf-idr-link-bandwidth-08, only the non-transitive version of the
Link Bandwidth Extended Community was supported. However, starting from
draft-ietf-idr-link-bandwidth-09, both transitive and non-transitive
versions of the Link Bandwidth Extended Community are supported.A BGP speaker (sender or receiver) needs to be upgraded to support
the procedures defined in this document to provide full interoperability
for both transitive and non-transitive versions of the Link Bandwidth
Extended Community. In order to simplify implementations, it is not a
goal to provide interoperability by upgrading only the Route Reflector (RR).AcknowledgmentsThe authors would like to thank ,
, and for proposing unequal-cost load-balancing as one possible
application of the extended community attribute. The authors would like
to thank for all the discussions and
providing text for operational considerations.The authors would like to thank ,
, ,
, ,
, , , , , , , , and for
their comments and contributions.ContributorsHPE1133 Innovation WaySunnyvaleCA94089United States of Americakaliraj.vairavakkalai@hpe.comHPE1133 Innovation WaySunnyvaleCA94089United States of Americanatrajan.venkataraman@hpe.comCisco Systems170 W. Tasman DriveSan JoseCA95134United States of Americarex@cisco.comAuthors' AddressesGoogle LLCpradosh@gmail.comHPE1133 Innovation WaySunnyvaleCA94089United States of Americareshma.das@hpe.comZscaler120 Holger WaySan JoseCA95134United States of Americasmohanty@zscaler.comCisco SystemsPegasus Parc, De Kleetlaan 6aBelgiumsekrier@cisco.comGoogle LLC1160 N Mathilda AveSunnyvaleCA94089United States of Americarszarecki@gmail.comArista Networks5453 Great America ParkwaySanta ClaraCA95054United States of Americaakshay@arista.com