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

[Gyan Mishra <[e-mail]>]

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]
>