Cumulative DMZ Link Bandwidth and load-balancing
draft-mohanty-bess-ebgp-dmz-02
| Document | Type | Expired Internet-Draft (individual) | |
|---|---|---|---|
| Authors | satyamoh@cisco.com , Aaron Millisor , Arie Vayner , Akshay Gattani , Ajay Kini | ||
| Last updated | 2021-01-14 (latest revision 2020-07-13) | ||
| Stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats |
Expired & archived
pdf
htmlized (tools)
htmlized
bibtex
|
||
| Stream | Stream state | (No stream defined) | |
| Consensus Boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | Expired | |
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
https://www.ietf.org/archive/id/draft-mohanty-bess-ebgp-dmz-02.txt
Abstract
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.
Authors
satyamoh@cisco.com
(satyamoh@cisco.com)
Aaron Millisor
(amilliso@cisco.com)
Arie Vayner
(ariev@vayner.net)
Akshay Gattani
(akshay@arista.com)
Ajay Kini
(ajkini@arista.com)
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)