RFC 10005

BGP Link Bandwidth Extended Community

📅 published June 2026, from ietf

okay bestie, here's the tea on this one 💅 It's an IETF (Internet Engineering Task Force) doc in the Standards Track category, published in June 2026 with ISSN 2070-1721. The authors are P. Mohapatra (Google LLC), R. Das, Ed. (HPE), S. Mohanty, Ed. (Zscaler), S. Krier (Cisco Systems), R.J. Szarecki (Google LLC), and A. Gattani (Arista Networks). The title block doesn't list any documents it obsoletes or updates 🌸

Abstract ✨

ok so this doc defines a BGP extended community called the Link Bandwidth Extended Community 🎀 It carries bandwidth info so you can do weighted load-balancing when multipath is in play, and it lays out the format and the processing rules for this community type.

Status of This Memo 📜

This is an Internet Standards Track document.

This doc is a product of the Internet Engineering Task Force (IETF) 🌈 It represents the consensus of the IETF community, it got public review, and the Internet Engineering Steering Group (IESG) approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 7841.

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc10005 🍓

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) as they stand on the date this document was published. Please actually read those, because they spell out your rights and restrictions for this document 🙈 Code Components pulled out of this document have to include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as described in the Revised BSD License.

Table of Contents 🗂️

1.  Introduction
  1.1.  Requirements Language
2.  Link Bandwidth Extended Community
3.  Protocol Procedures
  3.1.  Sender (Originating Link Bandwidth Extended Community)
  3.2.  Receiver (Receiving Link Bandwidth Extended Community)
  3.3.  Re-Advertisement Procedures
    3.3.1.  Re-Advertisement with Next Hop Change
    3.3.2.  Re-Advertisement with Next Hop Unchanged
  3.4.  Link Bandwidth Extended Community Arithmetic and BGP
        Multipath
4.  Error Handling
5.  IANA Considerations
6.  Security Considerations
7.  Operational Considerations
  7.1.  Inconsistent Deployment
  7.2.  Bandwidth Value
8.  References
  8.1.  Normative References
  8.2.  Informative References
Appendix A.  Document History
Acknowledgments
Contributors
Authors' Addresses

1. Introduction ✨

load-balancing is a big deal in network design 🦋 It's how you use the bandwidth you've got efficiently and make the whole network perform better. The catch is that plain equal load-balancing doesn't care that different paths can have totally different capacities, which is lowkey a problem.

So this doc proposes carrying the bandwidth info in the network using one of two new extended communities [RFC4360]: a transitive one and a non-transitive one, both called the Link Bandwidth Extended Community 💖 The community carries the bandwidth info for either a directly connected link or a multi-hop/multipath next hop, as advertised by a router. This is what helps you max out your network resources 🔥

1.1. Requirements Language

Here's how the key words work 🎀 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 read as described in BCP 14 [RFC2119] [RFC8174], but only when they show up in all capitals, just like they do here.

the Link Bandwidth Extended Community is a BGP extended community that carries the bandwidth info of a router (identified by its BGP next hop) connecting to a remote network 💅 Routers can use it to tell each other how much bandwidth is available over a given route.

It can be transitive or non-transitive 🦋 So the high-order octet of the extended Type field is 0x00 for transitive or 0x40 for non-transitive. 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 can't fit in 2 octets, AS_TRANS [RFC6793] SHOULD be used in the Global Administrator sub-field. The encoding of full 4-octet ASNs isn't supported by the Link Bandwidth Extended Community. If the operational need ever shows up, a new BGP extension may be provided for it 🔮 The value in the Global Administrator sub-field doesn't change the use or semantics of the Link Bandwidth Extended Community. This keeps things consistent with 2-octet community registries and stays operationally familiar 🫶

The bandwidth value is a 4-octet floating point number in the format from [IEEE.754-2019], measured in bytes (not bits!) per second 😭 It lives in the Local Administrator sub-field of the Value field.

    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                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1: Link Bandwidth Extended Community

Here's what each field does 🍓

  • 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 [IEEE.754-2019].

3. Protocol Procedures 🌸

The procedures cover both the transitive and non-transitive variants of the Link Bandwidth Extended Community 🧚 That way implementations can handle either one and interoperate correctly across every deployment. For more details, check out Section 5 and Appendix A.

A BGP speaker that attaches a Link Bandwidth Extended Community SHOULD be able to advertise either a transitive or a non-transitive one ✨ Implementations SHOULD provide configuration to set the transitivity type, along with the Global Administrator and the bandwidth values in the Local Administrator sub-field, using local policy 💖 Different implementations MAY use different default values for the transitivity type. The configuration SHOULD let operators override the default transitivity value whenever they need to 🫶 And implementations SHOULD expose their default value too.

An implementation MAY advertise a bandwidth value of zero 🙈 For example, an operator may set the Link Bandwidth Extended Community to zero to signal that the path shouldn't attract traffic during maintenance. However, per Section 3.2, the receiver's local policy decides how a link-bandwidth value of zero gets handled 💅

Usually you attach one Link Bandwidth Extended Community, of whichever transitivity type your deployment wants, to a route 🦋 But during transition (see Section 7 for the details), a BGP speaker MAY attach one Link Bandwidth Extended Community per transitivity type (transitive and non-transitive). In that case, the bandwidth value in both communities SHOULD be the same 👑

A Link Bandwidth Extended Community MAY be attached to or updated on a BGP route when it's received during Adj-RIB-In processing 🌈 It also MAY be attached or updated on a BGP route's Adj-RIB-Out entry while it's being advertised to a neighboring BGP speaker. (Adj-RIB-In and Adj-RIB-Out are as defined in [RFC4271].)

Implementations MAY provide a config option to send non-transitive Link Bandwidth Extended Communities on external BGP sessions 🍓

A BGP receiver that supports the Link Bandwidth Extended Community MUST support processing both the transitive and non-transitive types 💖 The receiver MUST NOT flap or treat the route as malformed just because of the transitivity of the Link Bandwidth Extended Community, the BGP session type (internal versus external), or both 🙅‍♀️

Implementations MAY provide configuration to accept non-transitive Link Bandwidth Extended Communities from external BGP sessions 🌸

A BGP update with a Link Bandwidth Extended Community whose bandwidth value is zero is valid ✨ When all the contributing paths have a non-zero value in the Link Bandwidth Extended Community, you can use those bandwidth values (or their ratio) as weights for weighted load-balancing 🎀 The details of weighted load-balancing are outside the scope of this document, but [LINK-BW-USE-CASES] covers some of the weighted load-balancing aspects, so go check it out 🧠 If the paths have a mix of zero and non-zero values, or all zeros, the behavior is decided by local policy. For example, implementations may exclude the zero-value paths from forming the weighted load-balancing set as long as at least one non-zero path 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 Link Bandwidth Extended Communities that have the same bandwidth value, the transitivity doesn't matter for computing weighted load-balancing or programming the Forwarding Information Base (FIB) 🦋

3.3. Re-Advertisement Procedures 🔁

This section covers what to do when a BGP speaker receives a route with an attached Link Bandwidth Extended Community and then re-advertises that route 💖

3.3.1. Re-Advertisement with Next Hop Change

okay so bestie, this one is about what happens when a BGP speaker passes along a route that has a Link Bandwidth Extended Community and changes the next hop to itself (or some other address) 💅 the speaker MAY do any one of these by default: remove the Link Bandwidth Extended Community, re-advertise it unchanged, or regenerate it with an updated value ✨ it's giving "pick your fighter," and totally valid 🦋

the default is up to the implementation, but implementations SHOULD give you a local configuration method to switch that default to one of the other options, with per-session granularity 🎀 so you can be picky session by session 💖 implementations SHOULD also expose what their default value actually is 🙈 no hiding the tea!!

when you regenerate the community, the same procedures from Section 3.1 apply 🌸 and if you're in a BGP multipath situation, go peek at Section 3.4 🧚

3.3.2. Re-Advertisement with Next Hop Unchanged

this is the chill one 🌈 if a BGP speaker gets a route with a Link Bandwidth Extended Community and just re-advertises or reflects it without changing the next hop, it SHOULD NOT change the Link Bandwidth Extended Community in any way 🫶 leave it alone, bestie 💅

in a BGP multipath environment, the bandwidth value that gets sent or re-advertised MAY be calculated from the Link Bandwidth Extended Community on each constituent path that's contributing to multipath in the Local Routing Information Base (Local-RIB) ✨ this is a whole topic on its own, and it's beyond the scope of this document 🙈 if you want the spicy use cases, check out [LINK-BW-USE-CASES], which describes how this could be done in specific scenarios 🔥

4. Error Handling 💀

okay so if a BGP speaker gets a route with more than one Link Bandwidth Extended Community and it uses that route to compute weighted load-balancing, it SHOULD use the extended community with the lowest bandwidth value (zero counts too!) and ignore the transitivity 👑 implementations MAY provide configuration to change that preference, though 🎀

a negative value in a Link Bandwidth Extended Community SHOULD NOT be attached or originated by any BGP speaker 😭 and if a BGP receiver runs into a Link Bandwidth Extended Community with a negative link-bandwidth value, that community SHALL be ignored 🚫 no exceptions, periodt 💅

Zero is NOT malformed!! Link Bandwidth Extended Communities with a zero value MUST NOT be considered malformed 🌈✨ bestie, zero is valid, we love a zero 🧚

last one: if any of the paths lack a valid Link Bandwidth Extended Community, equal load-balancing SHOULD be used unless local configuration overrides it 🍓 simple, clean, iconic 💜

5. IANA Considerations 🎀

the IANA folks did some updates in two registries, and this is the tea ☕

in the "Transitive Two-Octet AS-Specific Extended Community Sub-Types" registry [IANA-TransExComm] (Type 0x00), IANA updated Sub-Type 0x04 to:

Name:  Link Bandwidth

in the "Non-Transitive Two-Octet AS-Specific Extended Community Sub-Types" registry [IANA-Non-TransExComm] (Type 0x40), IANA also updated Sub-Type 0x04 to:

Name:  Link Bandwidth

both updates reference this document 🦋 so now you know where to look 🌸

6. Security Considerations 💀

okay this part is SERIOUS, bestie, so pay attention 😭

this extension to BGP has similar security implications as BGP extended communities [RFC4360] 🔐

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 🙈 so when you're propagating routes with a Link Bandwidth Extended Community towards an untrusted network or outside of an administrative domain, it is recommended that operators use policy to filter out this community 🛡️ protect your tea, sis 🫶

7. Operational Considerations 🧚

7.1. Inconsistent Deployment

so older deployments of this feature have had implementations that only understood one of the two extended community transitivity types 🕰️ those implementations would just ignore the transitivity type they don't understand 🙃 the procedures in this document are the ones that govern how multiple transitivity types for bandwidth should operate ✨

inconsistent behavior can happen when networks have a mix of implementations: some that support this document's procedures for both transitivity types, and some older ones that only understand one 🌀 a prime example is when a BGP speaker gets a route containing both a transitive and a non-transitive Link Bandwidth Extended Community, and then it updates only one of them 💔 the other one may now have an inconsistent value, and downstream BGP speakers that receive those routes may do inappropriate weighted load-balancing 😬

to mitigate this, when operators know older implementations are around, they MAY take steps to deal with the inconsistencies 💅 one option is to filter the unsupported transitivity type of the Link Bandwidth Extended Community at advertisement time on the older BGP speaker, if that implementation can do that filtering 🎀 another option: a receiving BGP speaker that knows the sender can't do these operations could strip the Link Bandwidth Extended Community type the sender doesn't support 🧹

ideally this is a short-lived situation, lasting only until all the routers in the network have been upgraded to implementations that consistently support the procedures in this document 🚀 we love a glow-up 💖

7.2. Bandwidth Value

how the bandwidth value gets computed or determined is out of scope for this document 🙅‍♀️ check [LINK-BW-USE-CASES] for 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 😵‍💫 bestie, keep things steady 🫶

8. References 📚

8.1. Normative References

[IEEE.754-2019]
           IEEE, "IEEE Standard for Floating-Point Arithmetic", IEEE
           Std 754-2019, DOI 10.1109/IEEESTD.2019.8766229, 22 July
           2019, <https://ieeexplore.ieee.org/document/8766229>.

[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/info/rfc2119>.

[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/info/rfc4271>.

[RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
           Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
           February 2006, <https://www.rfc-editor.org/info/rfc4360>.

[RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
           Autonomous System (AS) Number Space", RFC 6793,
           DOI 10.17487/RFC6793, December 2012,
           <https://www.rfc-editor.org/info/rfc6793>.

[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/info/rfc8174>.

8.2. Informative References

[IANA-Non-TransExComm]
           IANA, "Non-Transitive Two-Octet AS-Specific Extended
           Community Sub-Types", <https://www.iana.org/assignments/
           bgp-extended-communities>.

[IANA-TransExComm]
           IANA, "Transitive Two-Octet AS-Specific Extended Community
           Sub-Types", <https://www.iana.org/assignments/bgp-
           extended-communities>.

[LINK-BW-USE-CASES]
           Litkowski, S., Ed., Mohanty, S R., Ed., Vayner, A.,
           Gattani, A., Kini, A., Tantsura, J., and R. Das, "BGP link
           bandwidth extended community use cases", Work in Progress,
           Internet-Draft, draft-ietf-bess-ebgp-dmz-10, 8 April 2026,
           <https://datatracker.ietf.org/doc/html/draft-ietf-bess-
           ebgp-dmz-10>.

Appendix A. Document History 🕰️

okay so the BGP Link Bandwidth Extended Community has glowed up over a bunch of versions of the IETF draft 💫 in the earlier versions up to draft-ietf-idr-link-bandwidth-08, only the non-transitive version was supported 🙃 but starting from draft-ietf-idr-link-bandwidth-09, both the transitive and non-transitive versions are supported 🎉

a BGP speaker (sender or receiver) needs to be upgraded to support the procedures in this document if you want full interoperability for both transitive and non-transitive versions 🛠️ and to keep things simple, interoperability by upgrading only the Route Reflector (RR) is NOT a goal 🙅‍♀️ no shortcuts, sis 💅

Acknowledgments 🫶

the authors want to thank Yakov Rekhter, Srihari Sangli, and Dan Tappan for proposing unequal-cost load-balancing as one possible application of the extended community attribute 🌟 they also want to thank Jeff Haas for all the discussions and for providing text for operational considerations 💜

the authors would also like to thank Bruno Decraene, Robert Raszuk, Joel Halpern, Aleksi Suhonen, Randy Bush, Stephane Litkowski, Mankamana Mishra, Moshiko Nayman, Keon Vafai, Ketan Talaulikar, Yingzhen Qu, Anoop Ghanwani, Dongjie (Jimmy), and John Scudder for their comments and contributions 🎀 so many legends 👑

Contributors 🦋

Kaliraj Vairavakkalai HPE 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: kaliraj.vairavakkalai@hpe.com

Natrajan Venkataraman HPE 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: natrajan.venkataraman@hpe.com

Rex Fernando Cisco Systems 170 W. Tasman Drive San Jose, CA 95134 United States of America Email: rex@cisco.com

Authors' Addresses 🌸

Pradosh Mohapatra Google LLC Email: pradosh@gmail.com

Reshma Das (editor) HPE 1133 Innovation Way Sunnyvale, CA 94089 United States of America Email: reshma.das@hpe.com

Satya Mohanty (editor) Zscaler 120 Holger Way San Jose, CA 95134 United States of America Email: smohanty@zscaler.com

Serge Krier Cisco Systems Pegasus Parc, De Kleetlaan 6a Belgium Email: sekrier@cisco.com

Rafal Jan Szarecki Google LLC 1160 N Mathilda Ave Sunnyvale, CA 94089 United States of America Email: rszarecki@gmail.com

Akshay Gattani Arista Networks 5453 Great America Parkway Santa Clara, CA 95054 United States of America Email: akshay@arista.com

📦 where this page comes from