Hi Gyan, I do not think link bandwidth is helpful for weighted UCMP load balancing because in the field network the link with big bandwidth may be congested and meanwhile the link with small bandwidth may be in low utilization.
Best Regards, Zhenqiang Li China Mobile li_zhenqi...@hotmail.com From: Gyan Mishra Date: 2024-07-26 12:09 To: Ketan Talaulikar CC: Reshma Das; idr@ietf. org; draft-li-idr-link-bandwidth-ext; BESS; satya.mohanty; Jeff Haas; Susan Hares Subject: [bess] Re: [Idr] Re: Do we need yet another link bandwidth community? All I think has been a great effort by all authors involved over many years in trying to encode link bandwidth to be carried in BGP for weighted UCMP load balancing. Many thanks to all the authors on your work! Here is some history on all of these drafts below and my take on possible path forward and which drafts could be combined. All of these drafts I agree should be consolidated into a a single draft single source or truth. However some may or may not be possible due to need for backwards compatibility for what has already been deployed as well as some drafts are similar but different enough that could remain as a separate draft. Applies to all AFI/SAFI 2009 standards track https://datatracker.ietf.org/doc/html/draft-ietf-idr-link-bandwidth-07 Original draft was adopted by most all vendors Cisco, Juniper, Nokia etc Extended community HO/LO byte type / sub type 0x4/0x4, global administrative (AS_TRANS) local administrative - bandwidth Bandwidth is expressed in bytes floating point format in bytes/second Gap - non transitive only advertised intra-as 2022 informational introduces knob for transitive https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/ Supports transitive and non transitive extended to eBGP peering aggregate link bandwidth cumulative bandwidth across the internal iBGP paths to build the aggregate weight and regenerated when advertised over eBGP peering. Since the original draft has been implemented by many vendors both non transitive so now both would be supported sub TLV 0x0004 and transitive 0x4004 via vendor specific knob 2021 standards track https://datatracker.ietf.org/doc/draft-li-idr-link-bandwidth-ext/02/ Bandwidh expressed as unsigned integer Supports transitive and non transitive Extended community sub type is same as original draft and global administrative is ASN and local administrative is bandwidth More discrete unit bandwidth values for bps,kbs etc using unsigned integer 2024 standards track https://datatracker.ietf.org/doc/html/draft-xu-idr-fare-01 Path bandwidth extended community for adaptive routing for AI workloads and signals minimum bandwidth path towards a destination. New IPv4 specific address community that can be transitive or non transitive. Extended community HO/LO TLV/Sub TLV is 0x01 or 0x/41 , sub TLV / LO is TBD Global Administrative is router id of advertising router similar to type-1 extended community and local administrative contains the path bandwidth in floating point format units GB/s EVPN AFI/SAFI specific W-UCMP https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-unequal-lb EVPN load balancing and routed and BUM traffic distributed DF election distribution for a given ES for multi homed PE in proportion to PE-CE link bandwidth and uses the two DF election algorithms HRW or highest preference. -Introduces new link bandwidth extended community bandwidth encoded as unsigned integer MB/s unit value encoded as weight for ucmp load balancing. Summary: There is some backwards compatibility to take into account on the original dmz and cumulative which are in alignment and can be easily combined. The other remaining drafts except path bandwidth could be combined into a net new draft with agreement on units to use unsigned integer. I think the path bandwidth procedure and objective is different enough that I would keep as separate draft. Kind Regards Gyan On Wed, Jul 24, 2024 at 10:02 PM Ketan Talaulikar <ketant.i...@gmail.com> wrote: Hi Reshma, Glad to see that we are in agreement to avoid another LBW extcomm. One of the points that I was trying to make is that we don't have a "single source of truth" if we look at this more holistically from BGP protocol perspective. We have two that have been implemented and deployed (even if for different address families). Let's work this out keeping the full and broader picture in mind. Thanks, Ketan On Wed, 24 Jul, 2024, 6:00 pm Reshma Das, <dres...@juniper.net> wrote: Hi Ketan, I agree we don’t need yet another new draft to carry LBW community. As we know the base draft(draft-ietf-idr-link-bandwidth) is being revived to support both transitive and non-transitive use cases. This was presented in Mondays IDR session: (https://www.youtube.com/watch?v=ePPCAPOSQfM). It is worth updating the base draft as a single source of truth to accommodate all use cases. That provides the most interop. Since this is an effort initiated by IDR chairs, you are more than welcome to contribute to this effort as part the IDR WG. Thanks & Regards, Reshma Das Juniper Business Use Only From: Ketan Talaulikar <ketant.i...@gmail.com> Date: Wednesday, July 24, 2024 at 2:57 PM To: idr@ietf. org <i...@ietf.org>, draft-li-idr-link-bandwidth-...@ietf.org <draft-li-idr-link-bandwidth-...@ietf.org> Cc: BESS <bess@ietf.org> Subject: [Idr] Do we need yet another link bandwidth community? [External Email. Be cautious of content] Hello All, Checking on the need for draft-li-idr-link-bandwidth-ex when we already have the EVPN Link Bandwidth Extended Community (draft-ietf-bess-evpn-unequal-lb). Is it because of the name containing "EVPN" or am I missing something? If it is just the name, I hope we still have the time to change it in draft-ietf-bess-evpn-unequal-lb? We already have 2 types (ignoring the transitive/non-transitive variants) and I hope we can avoid the need for a third one ... Thanks, Ketan _______________________________________________ Idr mailing list -- i...@ietf.org To unsubscribe send an email to idr-le...@ietf.org
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
