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 <linchangwang.04...@h3c.com> 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 <ketant.i...@gmail.com> > *发送时间:* 2024年7月25日 10:02 > *收件人:* Reshma Das <dres...@juniper.net> > *抄送:* idr@ietf. org <i...@ietf.org>; > draft-li-idr-link-bandwidth-...@ietf.org; BESS <bess@ietf.org>; > satya.moha...@gmail.com; Jeff Haas <jh...@juniper.net>; Susan Hares < > sha...@ndzh.com> > *主题:* [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, <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 > > > > > ------------------------------------------------------------------------------------------------------------------------------------- > 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出 > 的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、 > 或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本 > 邮件！ > 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! >
_______________________________________________ BESS mailing list -- bess@ietf.org To unsubscribe send an email to bess-le...@ietf.org
