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

["Dongjie (Jimmy)" <[e-mail]>]

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.


1.      In the abstract, suggest to replace "unequal cost load balancing" with "weighted equal-cost multi-path (WECMP)".


2.      In section 2, "the available bandwidth on through a given route", may consider to remove either "on" or "through"?


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



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



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


6.      Security considerations. Since the link bandwidth ext. community can impact the load sharing ratio on the paths/links, some discussion about misusing this ext. community to reduce traffic on some paths may be helpful.

Hope this helps,.

-Jie

From: Jeffrey Haas <[e-mail]>
Sent: Friday, July 11, 2025 11:01 PM
To: idr <[e-mail]>
Cc: [e-mail]
Subject: [Idr] WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 2025)

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/

This begins the working group last call for the link bandwidth extended community draft.  Thanks to the authors for working their way through the substantive items that have been obstacles to interoperability over the years.

This last call ends a week after IETF 123 to give the working group time to review and also take advantage of the focus time that IETF meeting weeks bring to our work.

An item in particular we'd like to request particular attention to from the working group's review are the procedures covering default behaviors and interactions with deployments with mixed transitivities.  The current draft text works to try to accommodate maximal backward compatibility with various deployment scenarios, but such text is tricky.

For purposes of the shepherd's report and according to IETF BCP 78/79, the authors are requested to declare whether they are aware of any undisclosed IPR covering this draft. Members of the working group are similarly obligated to report any they are aware of as well.

-- Jeff (for the IDR Chairs)