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

[Reshma Das <[e-mail]>]

Hi Gorry,

Please find my replies inline as RD1>

Thanks & Regards,
Reshma Das

Get Outlook for Mac <https://aka.ms/GetOutlookForMac>



Juniper Business Use Only
From: Gorry Fairhurst <[e-mail]>
Date: Wednesday, October 22, 2025 at 12:48 AM
To: Reshma Das <[e-mail]>, The IESG <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: Re: Gorry Fairhurst's No Objection on draft-ietf-idr-link-bandwidth-19: (with COMMENT)
[External Email. Be cautious of content]

On 22/10/2025 07:00, Reshma Das wrote:
Hi Gory,

Thank you for reviewing the document. Please find my reply inline:

RD>

Thanks & Regards,
Reshma Das

Get Outlook for Mac <https://urldefense.com/v3/__https:/aka.ms/GetOutlookForMac__;!!NEt6yMaO-gk!DD7GcYODxdhkrMnlyi8DSWH-5GZtil1M3gMcLavEcjTgKUl3SAWpzTk2lgOq3QP6KfgkNlEsa6rANGy54Oo$>



Juniper Business Use Only
From: Gorry Fairhurst via Datatracker <[e-mail]><mailto:[e-mail]>
Date: Monday, October 20, 2025 at 7:16 AM
To: The IESG <[e-mail]><mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>, [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>
Subject: Gorry Fairhurst's No Objection on draft-ietf-idr-link-bandwidth-19: (with COMMENT)
[External Email. Be cautious of content]


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://urldefense.com/v3/__https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!HGHe5hi4-R0hZY4SCN1-5fsL3z7zjqWLvreOGtEtF80J0qgAe3ayXhljKP2sdKk1sei3m_p1QFWX4FI$<https://urldefense.com/v3/__https:/www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/__;!!NEt6yMaO-gk!HGHe5hi4-R0hZY4SCN1-5fsL3z7zjqWLvreOGtEtF80J0qgAe3ayXhljKP2sdKk1sei3m_p1QFWX4FI$>
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!HGHe5hi4-R0hZY4SCN1-5fsL3z7zjqWLvreOGtEtF80J0qgAe3ayXhljKP2sdKk1sei3m_p1D1bxoIc$<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!HGHe5hi4-R0hZY4SCN1-5fsL3z7zjqWLvreOGtEtF80J0qgAe3ayXhljKP2sdKk1sei3m_p1D1bxoIc$>



----------------------------------------------------------------------
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?
RD> The bandwidth value format is an IEEE 754 32-bit floating point number.  Its maximum range is roughly 3.4 x 10^38.

GF: Ah, understood.

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?
RD> The Link Bandwidth Extended Community provides a mechanism for routers to advertise the bandwidth of their downstream path that may either be a directly connected link or multi-hop/multipath nexthop.


GF: I suggest one way to resolve this would be to state:

"carries the bandwidth information of a directly connected link or multi-hop/multipath nexthop advertised by a  router"

RD1> ACK. Updated this (GitHub-Link<https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/91cf7dae03e74226fc4badafded9a8fef14b06c9>)

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?
RD> If all paths don’t have a valid LBWC that it is not possible to do accurate WECMP. Hence this is a MUST.

GF: I do not agree.

I read the requires action as "MUST NOT use WECMP and MAY use ECMP".



RD1>  Please review suggested text :

“If any of the paths lack a valid Link Bandwidth Extended Community, ECMP (Equal-Cost Multi-Path) 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.
GF: Please see below.

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

GF: Please could you also address this issue?

RD1> ACK, updated this. (GitHub-Link<https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/91cf7dae03e74226fc4badafded9a8fef14b06c9>)


RD> Please review the suggested text :
“This document defines a BGP Extended Community, the Link Bandwidth Extended Community, which carries link bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for this community type”

GF: Look good to me.

I look forward to proposals to address the last couple of comments.



RD1>  ACK, I have updated the abstract. (GitHub-Link<https://github.com/ietf-wg-idr/draft-ietf-idr-link-bandwidth/commit/91cf7dae03e74226fc4badafded9a8fef14b06c9>)

Best wishes,

Gorry