Hi Jeff, I apologize for missing your email. Please see my response inline with [Tiger].
发件人: Jeffrey Haas <[email protected]> 日期: 星期三, 2026年5月27日 20:56 收件人: Tiger Xu <[email protected]>, Gunter Van de Velde <[email protected]>, [email protected] <[email protected]> 抄送: BESS <[email protected]>, idr@ietf. org <[email protected]> 主题: Re: [Idr] Working Group Last Call on draft-ietf-bess-ebgp-dmz Tiger, Some of these questions are impacting progression of the DMZ draft. Would you please respond: On Wed, May 06, 2026 at 10:02:01AM -0400, Jeffrey Haas wrote: > [Speaking as an IDR chair and the shepherd for the DMZ document in this > response] > > > Fourth, the new use cases and associated technical approaches introduced in > > draft-ietf-bess-ebgp-dmz -07 (published 20 July 2025) were already fully > > and explicitly documented in draft-xu-idr-fare -00 (released 1 July 2024). > > There are certainly overlaps in the problem space between the DMZ and FARE > documents. draft-xu-idr-fare-00 was issued on January 2025. The DMZ draft > had been getting work done on it over several years with refining use cases. > Is there a specific use case you are referring to here? If so, please > clarify what section in the document you're discussing. [TIger] *draft-xu-idr-fare-00* (https://datatracker.ietf.org/doc/html/draft-xu-idr-fare-00), published in July 2024, introduces the concept of path bandwidth usage. In contrast, *draft-ietf-bess-ebgp-dmz-08*, published in October 2025, introduces path bandwidth usage for the first time as well, specifically in Section 1 and Section 4.2. See the following quoted text from DMZ-08: “...The example above shows that the BGP link bandwidth extended community may not be limited to carry only a "link" bandwidth value. In our example, the value 30Gbps advertised by R3 represents an aggregated path bandwidth.” —quoted from section 1 of DMZ-08 “...BGP may have to consider a combination of the local link and remote bandwidth when computing the weights for weighted load-balancing. Any function of the two may be used like for instance a "minimum" function that was highlighted in Section 1<https://datatracker.ietf.org/doc/html/draft-ietf-bess-ebgp-dmz-08#intro>. “ —quoted from section 4.2 of DMZ-08 For more details, see https://author-tools.ietf.org/iddiff?url1=draft-ietf-bess-ebgp-dmz-07&url2=draft-ietf-bess-ebgp-dmz-08&difftype=--hwdiff) > Also, is there a concern that there is work covered in that overlapping > portion of the documents that have undisclosed IPR considerations? Or, is > this more a matter that the DMZ document appropriated a use case without > attribution to its contributors? The above impacts both attribution and IPR. [Tiger] Both. I will ask my legal colleague to submit the IPR disclose. > > Further detailed analysis is presented below. IMHO, the IETF, as a leading > > global standards-setting body, ought not to endorse or tolerate such > > non-compliant community practices. Allowing such precedent would undermine > > the IETF’s reputation for impartiality and erode its ecosystem of original > > technical innovation. > > I'll address the technical points below, but what "non-compliant community > practices" are you referring to? Please be explicit. Would you clarify what non-compliant practices you're discussing? [Tiger] Non-compliant community practices involve copying ideas from other drafts and then competing with those drafts. If the IETF tolerates such practices, it would force more authors to resort to IPR to defend their intellectual efforts. That would be a dilemma for the IETF community. > > 2. Issues and solutions introduced in version -08 > > Version -08 adds: > > “In addition, as illustrated in the previous sections, BGP may have to > > consider a combination of the local link and remote bandwidth when > > computing the weights for weighted load‑balancing. Any function of the two > > may be used like for instance a ‘minimum’ function … The weight of each > > path may then be based on either: only the remote bandwidth, only the local > > link bandwidth, or a function of both.” > > This introduces the minimum function (choosing the smaller value between > > the link bandwidth and the path bandwidth of the received route). The draft > > also acknowledges for the first time the necessity of path bandwidth: > > “In our example, the value 30Gbps advertised by R3 represents an aggregated > > path bandwidth.” > > Again, both the minimum function and the concept of path bandwidth were > > already described in draft-xu-idr-fare version -00. > > For this point, I'll ask that the DMZ authors respond to the provenance of > the use case. I'd also suggest to the BESS chairs and AD to halt progression > of the document until that point is settled. Minimally, if there's an issue > of attribution, that should be addressed. [Tiger] Fully agree. Best regards, Tiger > Further, I ask again on this point where there is undisclosed IPR that you > consider an issue for this use case? Would you clarify if there's undisclosed IPR considerations? -- Jeff
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
