That’s great news that Cisco had implemented and customers have deployed for years!
I see it’s supported in IOS and XR https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/iproute_bgp/configuration/xe-16/irg-xe-16-book/bgp-link-bandwidth.html https://www.cisco.com/c/en/us/td/docs/iosxr/ncs5000/bgp/65x/b-bgp-cg-ncs5000-65x/b-bgp-cg-ncs5000-65x_chapter_010.html Thanks!! Gyan On Tue, May 25, 2021 at 12:48 PM Jakob Heitz (jheitz) <[email protected]> wrote: > The link bandwidth community has been implemented by Cisco and deployed by > > our customers for several years. > > Polarization of flows in multipath is a well known problem, but it hasn't > deterred > > people from using it. > > > > Regards, > > Jakob. > > > > *From:* BESS <[email protected]> *On Behalf Of * Gyan Mishra > *Sent:* Tuesday, May 25, 2021 12:24 AM > *To:* Satya Mohanty (satyamoh) <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [bess] Request discussion on Cumulative Link Bandwidth > Draft > > > > > > Hi Satya > > > > I read the draft and have a few questions. > > > > IPv4 does not support per flow per packet load balancing as all packets > belonging to the same flow must hash to the same path to prevent out of > order packets and thus is subject to polarization of flows as high > bandwidth flows may hash to the same path and low bandwidth flows as well > to the same path resulting in very uneven load balancing. Do to this issue > it does not make either iBGP or eBGP can really benefit from link bandwidth > extended community weight based load sharing. > > > > IPV6 flow label RFC 6437 stateless locally significant 5-tuple header hash > generated 20 byte key input to hash function results in uniform 50/50 load > balancing over EGP or IGP ECMP paths. > > > > I think it maybe a good idea to reference the IPv4 polarization issue with > flow based load balancing and that only with IPv6 flow label can true 50/50 > uniform load balancing be achieved. > > > > I noticed that the normative draft referenced was adopted but has not > progressed. > > > > https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/ > > > > Has the draft been implemented by Cisco or any other vendors ? > > > > Kind Regards > > > > Gyan > > > > > > On Sat, May 22, 2021 at 11:38 AM Satya Mohanty (satyamoh) <satyamoh= > [email protected]> wrote: > > Hi all, > > > > On behalf of all the authors, we request a discussion of the draft > https://datatracker.ietf.org/doc/html/draft-mohanty-bess-ebgp-dmz-03 and > subsequent WG adoption. > > This draft extends the usage of the DMZ link bandwidth to scenarios where > the cumulative link bandwidth needs to be advertised to a BGP speaker. > > Additionally, there is provision to send the link bandwidth extended > community to EBGP speakers via configurable knobs. Please refer to section > 3 and 4 for the use cases. > > > > This feature has multiple-vendor implementations and has been deployed by > several customers in their networks. > > > > Best Regards, > > --Satya > > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess > > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions Architect * > > *Email [email protected] <[email protected]>* > > *M 301 502-1347* > > > -- <http://www.verizon.com/> *Gyan Mishra* *Network Solutions A**rchitect * *Email [email protected] <[email protected]>* *M 301 502-1347*
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
