Hi Robert Very good point on millions of mice flows that can take advantage of unequal cost lb, versus a small number of elephant flows.
Good point on further granularity with TE bandwidth management . Gyan On Tue, May 25, 2021 at 2:06 PM Robert Raszuk <rob...@raszuk.net> wrote: > 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 >> > -- <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
