Thanks Reshma. The changes look good to me. On Fri, Aug 1, 2025 at 4:54 PM Reshma Das <[email protected]> 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 <[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]> > *Sent:* Thursday, July 17, 2025 7:46 PM > *To:* idr <[email protected]> > *Cc:* [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]> 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] > To unsubscribe send an email to [email protected] > > > > _______________________________________________ > BESS mailing list -- [email protected] > To unsubscribe send an email to [email protected] > >
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
