Gyan, It is always helpful to an assessment into right scale.
Yes if you take few flows perhaps even a few big ones may suffer from polarization. But the feature here is about hashing millions of micro flows. With that in mind polarization effects are insignificant at decent operational scale. I support this draft. Cheers, Robert PS. Also keep in mind that for handling elephant flows there are bunch of TE like solutions in place which can be used which in turn give you very fine control. On Tue, May 25, 2021 at 9:23 AM Gyan Mishra <hayabusa...@gmail.com> wrote: > > 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= > 40cisco....@dmarc.ietf.org> 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 >> BESS@ietf.org >> https://www.ietf.org/mailman/listinfo/bess >> > -- > > <http://www.verizon.com/> > > *Gyan Mishra* > > *Network Solutions A**rchitect * > > *Email gyan.s.mis...@verizon.com <gyan.s.mis...@verizon.com>* > > > > *M 301 502-1347* > > _______________________________________________ > BESS mailing list > BESS@ietf.org > https://www.ietf.org/mailman/listinfo/bess >
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
