%% You should probably cite draft-ietf-bess-ebgp-dmz-06 instead of this revision.
@techreport{ietf-bess-ebgp-dmz-02,
    number =    {draft-ietf-bess-ebgp-dmz-02},
    type =      {Internet-Draft},
    institution =   {Internet Engineering Task Force},
    publisher = {Internet Engineering Task Force},
    note =      {Work in Progress},
    url =       {https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/02/},
    author =    {SATYA R MOHANTY and Arie Vayner and Akshay Gattani and Ajay Kini and Jeff Tantsura},
    title =     {{Cumulative DMZ Link Bandwidth and load-balancing}},
    pagetotal = 12,
    year =      2023,
    month =     jan,
    day =       5,
    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.},
}