Hi Yingzhen Qu, Thank you for reviewing the document and providing feedback. Please find my replies inline:
RD>> Thanks & Regards, Reshma Das Juniper Business Use Only From: Yingzhen Qu <[email protected]> Date: Thursday, July 31, 2025 at 9:11 PM To: Jeffrey Haas <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]> Subject: [Idr] Re: WGLC for draft-ietf-idr-link-bandwidth (Ending 1 August, 2025) [External Email. Be cautious of content] Hi, Sorry for the late comments. I read the draft and have a few questions. What's the plan for section 5? Will it be removed before publication of this draft? This draft has a long history, started in 2009, and it has support for transitive link bandwidth extended community only since last year. So if there had been implementations before last year, it should have been implemented as non-transitive, is this correct? RD>> No, Actually this draft has a long history. Currently, both the transitive and non-transitive versions of the Link Bandwidth Extended Community (LBWC) are implemented and deployed in the field. Juniper has implemented and deployed the transitive version for years and now supports both transitive and non-transitive versions. Additionally, within the working group, multiple drafts have been introduced, as the non-transitive version does not address all customer use cases. Hence, the revival and updating of this draft were requested by the working group chairs to address the issue of interoperability with minimal changes to procedures and to ensure backward compatibility. Beginning of section 8.1 says: " Prior deployments of the feature specified in this document have involved implementations that only understood one of the two extended community transitivity types. " This conflicts with my understanding. The answer to the above question will help me to understand the procedure defined in section 3.1 about backward compatibility. " No more than one Link Bandwidth Extended Community SHOULD be attached to a route. For purpose of backward compatibility during transition, a BGP speaker MAY attach one Link Bandwidth Extended Community per transitivity (transitive/non-transitive) both having the same 'Link Bandwidth Value' field. " Also in section 5: " A BGP speaker (Sender or Receiver) need to be upgraded to support the procedures defined in this document to provide full interoperability for both transitive and non-transitive versions of Link Bandwidth Extended Community. In order simplify implementations, it is not a goal to provide interoperability by upgrading only the RR. " My question is if an old implementation only supports non-transitive, what's the interoperability issue? it can't process the transitive community as specified in section 3.2. What's the RR role here? nits: need / needs In order / In order to RD>> Took care of nits in the latest version. Please check: https://www.ietf.org/archive/id/draft-ietf-idr-link-bandwidth-14.html The "Deployment Consideration" in version 8 has useful information, I'm wondering why it was removed instead of becoming section 8.2? RD>> The idea was is to make this a base draft with normative procedures and if required have other informational drafts describe various use cases. The BESS draft-ietf-bess-ebgp-dmz is one of those that has use cases, we can see if we can add this use case too. Editorial nits: The "Type" in Figure 1 should be 8 bits, not 11 bits as illustrated in the figure. "WECMP" should be expanded the first time it's used, not later. Regarding draft-ietf-bess-ebgp-dmz, I don't have a strong opinion about whether it should be a separate document or merge into draft-ietf-idr-link-bandwidth. However, I noticed in the introduction, it says: " The link bandwidth extended community cannot be advertised over EBGP peers as it is defined to be optional non-transitive. " so it should be updated to be aligned with the IDR document. Thanks, Yingzhen On Thu, Jul 31, 2025 at 2:28 PM Jeffrey Haas <[email protected]<mailto:[email protected]>> wrote: IDR and BESS Working Groups, Please note that the last call for the link-bandwidth draft is scheduled to finish at end of day tomorrow. If you've not offered comment as to whether this draft should progress or not, please do so. Similarly, note the thread suggesting the merge of the DMZ use cases which would stall progress of the main draft. -- Jeff (for the IDR Chairs) On 7/11/25 11:01, Jeffrey Haas 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!CBstLmDd2TWGtjHa2uapyJb6FdTwjkVmZyhlnN3TAlbed_hnJZ-8edp3zlOCBblGZIbqcuJCpGzvmxc8EwPAkRA$> > > 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]> _______________________________________________ Idr 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]
