BGP Link Bandwidth Extended Community

Load balancing is a critical aspect of network design, enabling efficient utilization of available bandwidth and improving overall network performance. Traditional equal-cost multi-path (ECMP) routing does not account for the varying capacities of different paths. This document suggests that the external link 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 provides a mechanism for routers to advertise the bandwidth of their downstream path(s), facilitating maximum utilization of network resources.

The Link Bandwidth Extended Communities are defined as a BGP extended community that carries the bandwidth information of a router, represented by BGP Protocol Next Hop, connecting to remote network. This community can be used to inform other routers about the available bandwidth on through a given route. The Link bandwidth extended communities 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 communities is 0x04. The value of the Global Administrator subfield in the Value Field SHOULD represent the Autonomous System of the router that attaches the Link Bandwidth Community, but it can be set to any 2-byte value. If the Autonomous System number cannot be represented in two octets, as enabled by , AS_TRANS should be used in the Global Administrator subfield. The bandwidth of the link is expressed as 4 octets in floating point format, units being bytes (not bits!) per second. It is carried in the Local Administrator subfield 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 | AS Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Bandwidth Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type: 1-octet field MUST be set to 0x00 or 0x40 to indicate transitive/non-transitive. SubType: 1-octet field MUST be set to 0x04 to indicate 'Link-Bandwidth'. Global Administrator sub-field: 2-octet represent the Autonomous System. Local Administrator sub-field: Bandwidth value (bytes per sec) encoded as 4 octets in IEEE floating point format.

An originator of the link bandwidth community SHOULD be able to originate either a transitive or a non-transitive link bandwidth extended community. Implementations SHOULD provide configuration to set the transitivity type of the link bandwidth community, as well as the Global Administrator and bandwidth values in (Local Administrator field), using local policy. No more than one link bandwidth extended community SHALL be attached to a route. The 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. Note: Implementations MAY provide a configuration option to send non-transitive link bandwidth extended communities on external BGP sessions.

A BGP receiver MUST be able to process link bandwidth extended community of both 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 vs. external). Note: Implementations MAY provide configuration to accept non-transitive link bandwidth extended communities from external BGP sessions.

When a BGP speaker re-advertises a route with the link bandwidth extended community and sets the next hop to itself, it SHOULD follow the same procedures as outlined in . In the absence of any import or export policies that alter the Link Bandwidth Extended Community, any received Link Bandwidth extended community on the route will be re-advertised unchanged, in accordance with standard BGP procedures.

A BGP speaker that receives a route with the link bandwidth community, re-advertises or reflects the same without changing its next hop, SHOULD NOT change the link bandwidth extended community in any way.

In a BGP multipath ECMP environment, the value of the link bandwidth community that is sent or re-advertised may be calculated based on the link bandwidth communities of the routes contributing to multipath in the Local Routing Information Base (Local-RIB). This topic is beyond the scope of this document.

If a receiver receives a route with more than one Link Bandwidth Extended Community, it SHOULD:

Prefer the lowest value of the attached link bandwidth community, irrespective of the extended community's transitivity.
Prefer the transitive link bandwidth extended community when choosing between transitive and non-transitive types that have the same value.

Implementations MAY provide configuration to change the above preferences. Link bandwidth extended communities with a negative value SHALL be ignored and MUST NOT be originated. WECMP (Weighted Equal-Cost Multi-Path) can be utilized when only all contributing paths have a non-zero value in the link bandwidth extended community. If any of the paths lack a valid link bandwidth extended community, ECMP (Equal-Cost Multi-Path) MUST be used instead.

The 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. An old sender/receiver is a BGP speaker that uses procedures up to draft (https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-08) or any undocumented behavior for link bandwidth extended community. A new sender/receiver is a BGP speaker that implements procedures specified in this document. Receiving BGP speakers need 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 simplify implementations, it is not a goal to provide interoperability between old Receivers and new Senders.

This document defines a specific application of the two-octet AS specific extended community. IANA is requested to update the Transitive Two-Octet AS-Specific Extended Community Sub-Types registry (Type 0x00) and Sub-Type 0x04 to:

Name ---- transitive Link Bandwidth Ext. Community IANA is requested to update the Non-Transitive Two-Octet AS-Specific Extended Community Sub-Types registry (Type 0x40) and Sub-Type 0x04 to:

Name ---- non-transitive Link Bandwidth Ext. Community Both updates are to Reference this document.

There are no additional security risks introduced by this design.

Juniper Networks, Inc.

1133 Innovation Way, Sunnyvale CA 94089 US kaliraj@juniper.net

Juniper Networks, Inc.

1133 Innovation Way, Sunnyvale CA 94089 US natv@juniper.net

The authors would like to thank Yakov Rekhter, Srihari Sangli and Dan Tappan for proposing unequal cost load balancing as one possible application of the extended community attribute. The authors would like to thank Bruno Decraene, Robert Raszuk, Joel Halpern, Aleksi Suhonen, Randy Bush, Jeff Haas, Stephane Litkowski, Serge Krier and John Scudder for their comments and contributions.