Cumulative DMZ Link Bandwidth and load-balancing
draft-ietf-bess-ebgp-dmz-05
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
Expired & archived
|
|
---|---|---|---|
Authors | SATYA R MOHANTY , Arie Vayner , Akshay Gattani , Ajay Kini , Jeff Tantsura , Reshma Das | ||
Last updated | 2024-12-18 (Latest revision 2024-06-16) | ||
Replaces | draft-mohanty-bess-ebgp-dmz | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | Matthew Bocci | ||
IESG | IESG state | Expired | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | matthew.bocci@nokia.com |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
The DMZ Link Bandwidth draft provides a way to load-balance traffic to a destination which is reachable via more than one path according to the weight attahced. 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 that employs multi-path. The link-bandwidth value is then extracted from the extended community and is used as a weight in the RIB/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.
Authors
SATYA R MOHANTY
Arie Vayner
Akshay Gattani
Ajay Kini
Jeff Tantsura
Reshma Das
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)