[Idr] Gorry Fairhurst's No Objection on draft-ietf-idr-link-bandwidth-19: (with COMMENT)

Gorry Fairhurst via Datatracker <noreply@ietf.org> Mon, 20 October 2025 14:15 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from [10.244.8.144] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id BAA33780409F; Mon, 20 Oct 2025 07:15:42 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Gorry Fairhurst via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 12.50.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <176096974270.2050577.7833749670394770528@dt-datatracker-84f8f646b-tg6mn>
Date: Mon, 20 Oct 2025 07:15:42 -0700
Message-ID-Hash: P3DTVJ6DBYG4T76PV6IR67MRUCDGGBHJ
X-Message-ID-Hash: P3DTVJ6DBYG4T76PV6IR67MRUCDGGBHJ
X-MailFrom: noreply@ietf.org
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@ietf.org, idr-chairs@ietf.org, idr@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Subject: [Idr] Gorry Fairhurst's No Objection on draft-ietf-idr-link-bandwidth-19: (with COMMENT)
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/uvY3rw45Jb_bwUnJuQZTri35z8A>
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>

Gorry Fairhurst has entered the following ballot position for
draft-ietf-idr-link-bandwidth-19: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the effort put into completing this specification. I have adopted
the position of "No Objection", because I think my transport-related comments
are likely easily addressed.

I have two substantial comments with the text, that were also echoed by one of
the review team:

1. "The bandwidth value is encoded as a 4-octet value representing bytes per
second. What if there were cases where a 100Gbps (or higher) path exists, but
the maximum value that could be encoded is 8x2^32 = ~34Gbps?"

- Is there still a possibility that it be worth using Kbps as the unit rather
than bytes?

2. I don't understand this text: "carries the bandwidth information of a
router", to me it announces bandwidth information of a "link "(aka hop). Is it
really about router forwarding capability?

3. I was unsure what actually this means, is it really a requirement?:
" If any of the paths lack a valid Link Bandwidth Extended Community,
   ECMP (Equal-Cost Multi-Path) MUST be used instead."
- Maybe this could mean something like, if there is no Link Bandwidth Extended
Community then ECMP can (MAY) be used?

Some other comments are:

The current abstract is too terse to be useful:
- It does not mention 'link bandwidth', please explain this.
- It does not say that this describes both the format of the type and the
processing rules for the type.

This text appears mangled: /doesn't matter for purpose/does not matter for the
purpose/