[Idr] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 2025)

[Reshma Das <[e-mail]>]

Hi Jimmy,

Thank you for reviewing the document and providing your feedback.
Please find my replies inline.

RD>>

Thanks & Regards,
Reshma Das



Juniper Business Use Only
From: Dongjie (Jimmy) <jie.dong=[e-mail]>
Date: Friday, August 1, 2025 at 9:49 AM
To: Jeffrey Haas <[e-mail]>, idr <[e-mail]>
Cc: [e-mail] <[e-mail]>
Subject: RE: [Idr] WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 2025)
[External Email. Be cautious of content]

Hi Jeff,

Hope this is just in time. I support the changes made in recent versions on making the bandwidth extended community both transitive and non-transitive, hence support the publication of this document.

While I still have a few comments and suggestions for the authors to consider.


In the abstract, suggest to replace “unequal cost load balancing” with “weighted equal-cost multi-path (WECMP)”.
RD>> I have addressed this comment, please review the latest version:
https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-14.html#abstract


In section 2, “the available bandwidth on through a given route”, may consider to remove either “on” or “through”?
RD>> I have addressed this comment, please review the latest version:
https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-14.html#name-link-bandwidth-extended-com


In section 2, the current encoding only allows 2-octet AS number, and it says AS_TRANS should be used when the ASN can not be represented in two octets. Maybe it could say something like ”the encoding of 4-octet ASN is out of the scope and may be defined in a separate document”?
RD>> Since bytes in extended community cannot carry 4-Byte ASN along with 4 Byte LBW value, I have taken the comment and added the following line. “The encoding of 4-octet ASN is out of scope of this document”.
https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-14.html#name-link-bandwidth-extended-com


Section 3,1 it says implementations should provide configurations to set the transitivity type, the global administrator and the bandwidth values using local policy. I can understand the transitivity type should be set based on local policy, while the ASN and bandwidth value can be derived from the information of the peer and its associated interface.  It is suggested to clarify and also cover this approach.


RD>> We are trying to keep the procedures and changes to the procedures in this draft to bare minimum needed for interop. Autosense is a useful feature that various implementations do support, but it is a local policy matter. This need not be specified in the draft.


Section 3.3.1 describes the procedure of re-advertisement with Next-hop-self. Currently it says”

“In the absence of any import or export policies that alter the Link Bandwidth Extended Community, any received Link Bandwidth Extended Community on the route will be re-advertised unchanged, in accordance with standard BGP procedures.”

Since the bandwidth value refers to the bandwidth associated with the next-hop, if the next-hop is changed, it is uncertain whether keeping the value unchanged could be the proper default behavior or not, especially when the received link-bandwidth community is non-transitive. Currently I don’t have suggested text for this, just want to raise it for discussion

RD>>> This text was added by one of the authors and the intent is to record unambiguously what various implementations do today in accordance with regular BGP procedures . May be there is scope in newer mechanisms like MNH that scope bandwidth and NH together to provide such behavior. Though we understand the sentiment, this is not in the current scope.