Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Gyan Mishra
Across the DC space in general most providers use NVO3 and vxlan source port entropy L2/L3/L4 hash which provides per packet uniform 50/50 load balancing at the L2 VNI overlay layer, which translates into underlay load balancing of flows and thus no polarization. Across the DC space speaking from

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Robert Raszuk
Hi Arie, Draft draft-ietf-idr-link-bandwidth talks about advertising towards IBGP. It does not talk about advertising over EBGP. While I do support your use case I think it would be much cleaner to just ask for new ext. community type. Reason being that as you illustrate you may want to

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Arie Vayner
Jeff, Actually, the way this draft is written, and how the implementations I'm aware of are implemented, this is not really a transitive community. It is a new community that is being generated on the AS boundary. The community value is not carried over, but is calculated based on an cumulative

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Jeff Tantsura
Hi, I support adoption of the draft as Informational, please note, that request to change transitivity characteristics of the community is requested in another draft. Gyan  - please note, while pretty much every vendor has implemented the community and relevant data-plane constructs, initial

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Gyan Mishra
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 wrote: > Gyan, > > It is always

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Gyan Mishra
Arie Thanks for responding on the polarization question and I agree it can enhance ECMP capability and maybe even counter or reduce effects of polarization. Thanks Gyan On Tue, May 25, 2021 at 1:26 PM Arie Vayner wrote: > The flow polarization or elephant flow issues are well known industry

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Gyan Mishra
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

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Robert Raszuk
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.

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Jakob Heitz (jheitz)
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 On Behalf Of Gyan Mishra Sent: Tuesday, May 25, 2021

Re: [bess] Request discussion on Cumulative Link Bandwidth Draft

2021-05-25 Thread Gyan Mishra
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