[Idr] draft-ietf-idr-link-bandwidth-16 early Opsdir review

Tim Chown via Datatracker <noreply@ietf.org> Mon, 08 September 2025 13:43 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: idr@ietf.org
Delivered-To: idr@mail2.ietf.org
Received: from [10.244.8.59] (unknown [4.156.85.76]) by mail2.ietf.org (Postfix) with ESMTP id 67F2F5F46FF1; Mon, 8 Sep 2025 06:43:34 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Tim Chown via Datatracker <noreply@ietf.org>
To: ops-dir@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.49.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <175733901404.1136899.13171464228492876995@dt-datatracker-f7c8fdcb7-pjx77>
Date: Mon, 08 Sep 2025 06:43:34 -0700
Message-ID-Hash: ZVTRH6N7XYPGU7FONH52SSEDDIQYZ3IY
X-Message-ID-Hash: ZVTRH6N7XYPGU7FONH52SSEDDIQYZ3IY
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.all@ietf.org, idr@ietf.org
X-Mailman-Version: 3.3.9rc6
Reply-To: Tim Chown <tim.chown@jisc.ac.uk>
Subject: [Idr] draft-ietf-idr-link-bandwidth-16 early Opsdir review
List-Id: Inter-Domain Routing <idr.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/bUPO7-9TDvAFYp22SCWdWtbJO0o>
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>

Document: draft-ietf-idr-link-bandwidth
Title: BGP Link Bandwidth Extended Community
Reviewer: Tim Chown
Review result: Has Nits

Hi,

I've reviewed this document on behalf of the IETF Ops Dir.

The draft defines a mechanism by which BGP extended communities can be used to
convey external link bandwidth such that weighted ECMP can be applied in cases
where a set of non-zero value tagged paths are received.

The idea seems useful, and worth progressing to publication. Overall, the
document is well-written and easy to follow.

I have no major issues with the document, just a handful of minor comments for
consideration which I'd consider Nit level.

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?  Might it be worth
using Kbps as the unit rather than bytes?

2. The document doesn't say anything about whether the value is a static
capacity (as "bandwidth"), a capacity that might change through network
configuration operations, or perhaps even the current average available
(unused) capacity given the utilisation. This may be something useful to
clarify in the Operational Considerations section. (Section 1 says "does not
account for the varying capacities of differing paths" - that could be taken as
static (two paths have varying capacities) or dynamic (two paths each have
varying available capacities).

3. In reading up a bit around the draft I found RFC 7938 that talks about a use
case for this draft in DC scenarios in section 6.3, and it cites an old version
of the draft (-06). This also led me to realise the draft has been around since
2009, and been dormant a couple of times for a few years including a 6-year gap
between -07 and -08. I don't think that should count against it, and it has had
9 updates in the last year or so.

Best wishes,
Tim