Hi Anoop,

Thank you for reviewing the document and providing feedback.
I have updated the draft with all your review comments. Please go through the 
latest version.

 https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-14.html

Thanks & Regards,
Reshma Das



Juniper Business Use Only
From: Anoop Ghanwani <[email protected]>
Date: Monday, July 28, 2025 at 1:20 PM
To: [email protected] <[email protected]>
Cc: Jeffrey Haas <[email protected]>, idr <[email protected]>, 
[email protected] 
<[email protected]>, [email protected] 
<[email protected]>, [email protected] <[email protected]>, 
[email protected] <[email protected]>
Subject: Re: [bess] Re: [Idr] Re: WGLC for draft-ietf-idr-link-bandwidth 
(Ending 1 August, 2025)
[External Email. Be cautious of content]

I support the progression of this doc for publication as RFC.

I have a couple of terminology questions and an editorial nit.

Questions:

The doc starts out by saying this allows one to perform unequal cost load 
balancing.  Would it be more precise to say WECMP (which is the term used in 
the rest of the doc)?  Unequal cost load balancing could mean UCMP where paths 
are of unequal length.  It doesn't seem this draft does anything to enable that.

In section 4, we have:
"the transitivity doesn't matter for purpose of computing WECMP or programming 
to forwarding."
Would it be better to say "programming the FIB" rather than "programming to 
forwarding"?

Editorial nit:

All of the following are used:

link bandwidth community
Link Bandwidth Community
link bandwidth extended community
Link Bandwidth extended community
Link Bandwidth Extended Community

Might be good if they are made consistent.

Thanks,
Anoop



From: Jeffrey Haas <[email protected]<mailto:[email protected]>>
Sent: Thursday, July 17, 2025 7:46 PM
To: idr <[email protected]<mailto:[email protected]>>
Cc: 
[email protected]<mailto:[email protected]>
Subject: [Idr] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 
2025)

This is a reminder that WGLC is in progress for link bandwidth.  Please respond 
to the list whether you think the document is ready to be advanced for 
publication.

-- Jeff (shepherding chair)

On Jul 11, 2025, at 11:01 AM, Jeffrey Haas 
<[email protected]<mailto:[email protected]>> wrote:

https://datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-idr-link-bandwidth/__;!!NEt6yMaO-gk!GriwevGwXc24juGBy1XB18RvO1ji28Pz7qNSj1F9lY62O7qdoW76BevXIcIIX9dJpD-Xx1M8gVRcFwvWqZKQ$>

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)
_______________________________________________
Idr mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>

_______________________________________________
BESS mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
BESS mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to