Early Review of draft-ietf-idr-link-bandwidth-16
review-ietf-idr-link-bandwidth-16-opsdir-early-chown-2025-09-08-00

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