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

[Gorry Fairhurst <[e-mail]>]

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://aka.ms/GetOutlookForMac>
>
>
> Juniper Business Use Only
>
> *From: *Gorry Fairhurst via Datatracker <[e-mail]>
> *Date: *Monday, October 20, 2025 at 7:16 AM
> *To: *The IESG <[e-mail]>
> *Cc: *[e-mail] 
> <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] 
> <[e-mail]>, [e-mail] <[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-bitfloatingpointnumber. 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"

>
> 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".

>
> 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?


> 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.

Best wishes,

Gorry