[Idr] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 2025)

"lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com> Sat, 02 August 2025 05:14 UTC

Return-Path: <lizhenqiang@chinamobile.com>
X-Original-To: idr@mail2.ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id ED8534EA4DF2; Fri, 1 Aug 2025 22:14:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgBW-_6bn0S9; Fri, 1 Aug 2025 22:14:34 -0700 (PDT)
Received: from cmccmta2.chinamobile.com (cmccmta8.chinamobile.com [111.22.67.151]) by mail2.ietf.org (Postfix) with ESMTP id 660984EA4DEA; Fri, 1 Aug 2025 22:14:22 -0700 (PDT)
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from spf.mail.chinamobile.com (unknown[10.188.0.87]) by rmmx-syy-dmz-app06-12006 (RichMail) with SMTP id 2ee6688d9ea76af-4202b; Sat, 02 Aug 2025 13:14:21 +0800 (CST)
X-RM-TRANSID: 2ee6688d9ea76af-4202b
X-RM-TagInfo: emlType=0
X-RM-SPAM-FLAG: 00000000
Received: from cmcc-PC (unknown[223.72.68.43]) by rmsmtp-syy-appsvr01-12001 (RichMail) with SMTP id 2ee1688d9ea9c88-c0e12; Sat, 02 Aug 2025 13:14:21 +0800 (CST)
X-RM-TRANSID: 2ee1688d9ea9c88-c0e12
Date: Sat, 02 Aug 2025 13:14:44 +0800
From: "lizhenqiang@chinamobile.com" <lizhenqiang@chinamobile.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "idr@ietf.org" <idr@ietf.org>
References: <EA45DEC9-49DA-4CA1-877F-D7AC46AAAD6A@pfrc.org>, <20250725085149.GA32546@pfrc.org>
X-Priority: 3
X-GUID: D78D4446-DD73-47F7-8515-E772561A39DA
X-Has-Attach: no
X-Mailer: Foxmail 7.2.25.432[cn]
Mime-Version: 1.0
Message-ID: <2025080213144371940517@chinamobile.com>
Content-Type: multipart/alternative; boundary="----=_001_NextPart077170001870_=----"
Message-ID-Hash: UCZQJUXDXY3HMT3NPBFBYUU2GRRRXBYL
X-Message-ID-Hash: UCZQJUXDXY3HMT3NPBFBYUU2GRRRXBYL
X-MailFrom: lizhenqiang@chinamobile.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-idr.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: draft-ietf-idr-link-bandwidth <draft-ietf-idr-link-bandwidth@ietf.org>
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Idr] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 2025)
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/j3jYrUPFvBwZJAFXJw4-Qz7rMVM>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Owner: <mailto:idr-owner@ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Subscribe: <mailto:idr-join@ietf.org>
List-Unsubscribe: <mailto:idr-leave@ietf.org>

Hello Jeff, Authors, and all,

I believe the following issue should be addressed before moving the document to the next stage.

In the introduction section, it is stated that the Link Bandwidth Extended Community is used to facilitate the maximum utilization of network resources. However, there is no content in the document explaining how this goal can be achieved. Do BGP speakers require any specific behaviors to handle the Link Bandwidth Extended Community?

Best Regards,
Zhenqiang Li
China Mobile


lizhenqiang@chinamobile.com
 
From: Jeffrey Haas
Date: 2025-07-25 16:51
To: idr
CC: draft-ietf-idr-link-bandwidth
Subject: [Idr] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 2025)
On Fri, Jul 11, 2025 at 11:01:03AM -0400, Jeffrey Haas wrote:
> https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/ <https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/>
> 
> This begins the working group last call for the link bandwidth extended community draft.  Thanks to the authors for working their way through the substantive items that have been obstacles to interoperability over the years.
> 
> This last call ends a week after IETF 123 to give the working group time to review and also take advantage of the focus time that IETF meeting weeks bring to our work.
 
Note that there's one more week for last call support/not-support comments.
 
At the moment, the related discussion about merging the BESS documents has
mixed feedback.  Please also consider commenting on that point.
 
-- Jeff
 
_______________________________________________
Idr mailing list -- idr@ietf.org
To unsubscribe send an email to idr-leave@ietf.org