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

[Satya Mohanty <[e-mail]>]

Hi all,

We will be publishing a new version of the draft
https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-07.txt.
We will add the new material presented in the IDR meeting on Monday in the
draft.

Thanks,
--Satya


On Wed, Jul 24, 2024 at 7:52 PM linchangwang <[e-mail]>
wrote:

> Hi ketan,
>
>
>
> Yes, I agree. Currently, the bandwidth definitions are spread across three different communities,
>
> resulting in inconsistent behavior and various restrictions across different address families.
>
> Additionally, EVPN's link bandwidth is also restricted to the specific routes' ES link bandwidth.
>
> In fact, the application scenarios are similar to those in L3 VPN, L2 VPN, and public network egress scenarios.
>
>
>
> I hope that from the perspective of the global BGP protocol, these definitions can be made applicable across all address families, with controllable bandwidth units and transmission attributes.
>
>
>
> Here are the current three definitions:
>
>
>
> 1.  using a new extended community [RFC4360]  -the link bandwidth
> extended community.
>
> https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-07.txt
>
> The extended community is optional non-transitive.
>
>
>
>
>
> 2. using a  new type of IPv6 Address Specific Extended Community[RFC5701]- Link Bandwidth Extended Community
>
> https://www.ietf.org/archive/id/draft-li-idr-link-bandwidth-ext-02.txt
>
> The subtypes defined here can be used for both optional transitive
>
>    and non-transitive extended community attributes.
>
>
>
> 3.using a new type of EVPN Extended Community Sub-Types- EVPN Link Bandwidth Extended Community
>
> https://www.ietf.org/archive/id/draft-ietf-bess-evpn-unequal-lb-21.txt
>
> EVPN Link Bandwidth extended community is defined as transitive.
>
> A new EVPN Link Bandwidth extended community is defined to signal
>
> local ES link bandwidth to ingress PEs.
>
>
>
>
>
>
>
> Thanks,
>
> Changwang
>
>
>
> *发件人:* Ketan Talaulikar <[e-mail]>
> *发送时间:* 2024年7月25日 10:02
> *收件人:* Reshma Das <[e-mail]>
> *抄送:* idr@ietf. org <[e-mail]>;
> [e-mail]; BESS <[e-mail]>;
> [e-mail]; Jeff Haas <[e-mail]>; Susan Hares <
> [e-mail]>
> *主题:* [Idr] Re: Do we need yet another link bandwidth community?
>
>
>
> 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
>
>
>
>
> -------------------------------------------------------------------------------------------------------------------------------------
> 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
> 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
> 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
> 邮件！
> This e-mail and its attachments contain confidential information from New
> H3C, which is
> intended only for the person or entity whose address is listed above. Any
> use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender
> by phone or email immediately and delete it!
>