[bess] Re: [Idr] Re: Do we need yet another link bandwidth community?

["[e-mail]" <[e-mail]>]

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
[e-mail]
 
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 <[e-mail]> 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, <[e-mail]> 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 <[e-mail]>
Date: Wednesday, July 24, 2024 at 2:57 PM
To: idr@ietf. org <[e-mail]>, [e-mail] <[e-mail]>
Cc: BESS <[e-mail]>
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 -- [e-mail]
To unsubscribe send an email to [e-mail]