IETF Logo Mail Archive

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

"Dongjie (Jimmy)" <jie.dong@huawei.com> Thu, 25 July 2024 05:10 UTC

Return-Path: <jie.dong@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306E6C1D6FC8; Wed, 24 Jul 2024 22:10:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mvvhVXacmCyA; Wed, 24 Jul 2024 22:10:09 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4CCCC1840F9; Wed, 24 Jul 2024 22:10:08 -0700 (PDT)
Received: from mail.maildlp.com (unknown [172.18.186.231]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4WTzRs0qDkz6HJpY; Thu, 25 Jul 2024 13:08:25 +0800 (CST)
Received: from lhrpeml500004.china.huawei.com (unknown [7.191.163.9]) by mail.maildlp.com (Postfix) with ESMTPS id 5C908140519; Thu, 25 Jul 2024 13:10:05 +0800 (CST)
Received: from dggpemf500007.china.huawei.com (7.185.36.81) by lhrpeml500004.china.huawei.com (7.191.163.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2507.39; Thu, 25 Jul 2024 06:10:04 +0100
Received: from kwepemf100006.china.huawei.com (7.202.181.220) by dggpemf500007.china.huawei.com (7.185.36.81) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1544.11; Thu, 25 Jul 2024 13:10:02 +0800
Received: from kwepemf100006.china.huawei.com ([7.202.181.220]) by kwepemf100006.china.huawei.com ([7.202.181.220]) with mapi id 15.02.1544.011; Thu, 25 Jul 2024 13:10:02 +0800
From: "Dongjie (Jimmy)" <jie.dong@huawei.com>
To: Reshma Das <dreshma@juniper.net>, Ketan Talaulikar <ketant.ietf@gmail.com>, "idr@ietf. org" <idr@ietf.org>, "draft-li-idr-link-bandwidth-ext@ietf.org" <draft-li-idr-link-bandwidth-ext@ietf.org>
Thread-Topic: [Idr] Do we need yet another link bandwidth community?
Thread-Index: AQHa3hRH/DTYUDjvoUWdL/j/OuF/t7IGGdEAgADDJEk=
Date: Thu, 25 Jul 2024 05:10:02 +0000
Message-ID: <f499d96785294203a3d398760040e659@huawei.com>
References: <CAH6gdPxxsb+6v6ZGjAB=7ZVNK8+0KWs3Aa6RMJArEtMp+ddbrw@mail.gmail.com>,<DM4PR05MB955984C69E4999CD8E42C859B0AA2@DM4PR05MB9559.namprd05.prod.outlook.com>
In-Reply-To: <DM4PR05MB955984C69E4999CD8E42C859B0AA2@DM4PR05MB9559.namprd05.prod.outlook.com>
Accept-Language: en-US, zh-CN
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.242.81]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Message-ID-Hash: IJCHPMQJ6KTDLWVYLZES2RVFMUM4AWGX
X-Message-ID-Hash: IJCHPMQJ6KTDLWVYLZES2RVFMUM4AWGX
X-MailFrom: jie.dong@huawei.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bess.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: BESS <bess@ietf.org>, "satya.mohanty@gmail.com" <satya.mohanty@gmail.com>, Jeff Haas <jhaas@juniper.net>, Susan Hares <shares@ndzh.com>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [bess] Re: [Idr] Do we need yet another link bandwidth community?
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/cgDinqYL-sNdZOqcR5Z3F6Spb_4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Owner: <mailto:bess-owner@ietf.org>
List-Post: <mailto:bess@ietf.org>
List-Subscribe: <mailto:bess-join@ietf.org>
List-Unsubscribe: <mailto:bess-leave@ietf.org>

Hi Reshma and Ketan, 

It is good to see the link-bandwidth extended community in draft-ietf-idr-link-bandwidth is updated to support both transitive and non-transitive use cases. The limitation with non-transitive was one of the reasons of introducing the new extended community in draft-li-idr-link-bandwidth-ext. 

Another important reason is the 32-bit floating point format of bandwidth may cause confusion/complexity in configuration and management, and it could be worse if the link bandwidth value is used for some route-policy matching, as the precision of 32-bit floating point value would be a problem for exact match. 

It would be helpful if operators could share their experience with the link bandwidth extended community. 

-Jie

________________________________________
From: Reshma Das <dreshma@juniper.net>
Sent: Thursday, July 25, 2024 9:00
To: Ketan Talaulikar; idr@ietf. org; draft-li-idr-link-bandwidth-ext@ietf.org
Cc: BESS; satya.mohanty@gmail.com; Jeff Haas; Susan Hares
Subject: Re: [Idr] Do we need yet another link bandwidth community?

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.ietf@gmail.com>
Date: Wednesday, July 24, 2024 at 2:57 PM
To: idr@ietf. org <idr@ietf.org>, draft-li-idr-link-bandwidth-ext@ietf.org <draft-li-idr-link-bandwidth-ext@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

v2.26.15 | Report a Bug | By Email | System Status