Gorry

On 29 Oct 2025, at 16:51, R= eshma Das <dreshma@juniper.net> wrote:

=EF=BB=BF

Hi Gorry,

Please find my replies inline as RD1>

Thanks & Regards,

Reshma Das

Juniper Business Use Only

From: Gorry Fairhurst <= gorry@erg.abdn.ac.uk>
Date: Wednesday, October 22, 2025 at 12:48=E2=80=AF<= /span>AM
To: Reshma Das <dreshma@juniper.net>, The IESG <iesg@ietf.or= g>
Cc: draft-ietf-idr-link-bandwidth@ietf.org <draft-ietf-idr-link-ba= ndwidth@ietf.org>, idr-chairs@ietf.org <idr-chairs@ietf.org>, idr@i= etf.org <idr@ietf.org>, jhaas@pfrc.org <jhaas@pfrc.org>
Subject: Re: Gorry Fairhurst's No Objection on draft-ietf-idr-link-ba= ndwidth-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 i= nline:

RD>

Thanks & Regards,

Reshma Das

Get Outlook for Mac

Juni= per Business Use Only

From: Gorry Fairhurst via D= atatracker <noreply@ietf.org>
Date: Monday, October 20, 2025 at 7:16=E2=80=AFAM
To: The IESG <iesg@ietf.org>
Cc: draft-i= etf-idr-link-bandwidth@ietf.org <draft-ietf-idr= -link-bandwidth@ietf.org>, idr-chairs@ietf.org <idr-chairs@ietf.org>, idr@ietf.or= g <idr@ietf.org>, jhaas@pfrc.org <jhaas@pfrc.org>, jhaas@pfrc.org= <jhaas@pfrc.org>
Subject: Gorry Fairhurst's No Objection on draft-ietf-idr-link-bandwi= dth-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/statement= s/handling-ballot-positions/__;!!NEt6yMaO-gk!HGHe5hi4-R0hZY4SCN1-5fsL3z7zjqW= LvreOGtEtF80J0qgAe3ayXhljKP2sdKk1sei3m_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_p1= D1bxoIc$

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

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

I have two substantial comments with the text, that were also echoed by one o= f
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, bu= t
the maximum value that could be encoded is 8x2^32 =3D ~34Gbps?"

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

RD> The bandwidth value format is an IEEE 754 32-bi= t floating point number= . Its maximum range is roughly 3.4 x 10^38.

GF: Ah, understood. <= o:p>

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 i= t
really about router forwarding capability?

RD> The Link Bandwidth Ext= ended Community provides a mechanism for routers to advertise the bandwidth o= f 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&nb= sp;a directly con= nected link or multi-hop/multipath nexthop advertised by a router"

RD1> ACK. Updated t= his (GitHub-Link)

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 Extend= ed
Community then ECMP can (MAY) be used?

RD> If all paths don=E2=80= =99t have a valid LBWC that it is not possible to do accurate WECMP. Hence t= his 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 :

=E2=80=9CIf any of the paths lack a valid Link Bandwidth Extended Com= munity, ECMP (Equal-Cost Multi-Path) MAY be used.=E2=80=9D=

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 t= he
purpose/

GF: Please could you also address this issue?

RD1> ACK, updated this. (GitHub-Link)<= o:p>

RD> Please review the sugg= ested text :

=E2=80=9CThis document define= s a BGP Extended Community, the Link Bandwidth Extended Community, which car= ries link bandwidth information to enable weighted load-balancing in multipath scenarios. It specifies the format and processing rules for th= is community type=E2=80=9D

GF: Look good to me.

I look forward to proposals to address the last couple of comments.<= /o:p>

RD1> ACK, I have updated the abstract. (GitHub-Link)

Best wishes,

Gorry

= --Apple-Mail-2871825C-3244-4216-B62B-5D66E6887917--