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

[Anoop Ghanwani <[e-mail]>]

Thanks Reshma.  The changes look good to me.

On Fri, Aug 1, 2025 at 4:54 PM Reshma Das <[e-mail]> wrote:

> 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 <[e-mail]>
> *Date: *Monday, July 28, 2025 at 1:20 PM
> *To: *[e-mail] <[e-mail]>
> *Cc: *Jeffrey Haas <[e-mail]>, idr <[e-mail]>,
> [e-mail] <
> [e-mail]>, [e-mail] <
> [e-mail]>, [e-mail] <[e-mail]>,
> [e-mail] <[e-mail]>
> *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 <[e-mail]>
> *Sent:* Thursday, July 17, 2025 7:46 PM
> *To:* idr <[e-mail]>
> *Cc:* [e-mail]
> *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 <[e-mail]> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>
>
> _______________________________________________
> BESS mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
>