Skip to main content

Cumulative DMZ Link Bandwidth and load-balancing

Document Type Replaced Internet-Draft (individual)
Expired & archived
Authors Satya Mohanty , Arie Vayner , Akshay Gattani , Ajay Kini
Last updated 2021-09-16 (Latest revision 2021-03-15)
Replaced by draft-ietf-bess-ebgp-dmz
RFC stream (None)
Intended RFC status (None)
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Replaced by draft-ietf-bess-ebgp-dmz
Telechat date (None)
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:


The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination (which is in a different AS than the source) which is reachable via more than one path. Typically, the link bandwidth (either configured on the link of the EBGP egress interface or set via a policy) is encoded in an extended community and then sent to the IBGP peer which employs multi-path. The link-bandwidth value is then extracted from the path extended community and is used as a weight in the FIB, which does the load-balancing. This draft extends the usage of the DMZ link bandwidth to another setting where the ingress BGP speaker requires knowledge of the cumulative bandwidth while doing the load-balancing. The draft also proposes neighbor- level knobs to enable the link bandwidth extended community to be regenerated and then advertised to EBGP peers to override the default behavior of not advertising optional non-transitive attributes to EBGP peers.


Satya Mohanty
Arie Vayner
Akshay Gattani
Ajay Kini

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)