Hi all, The following are my late comments: First, it is anomalous for a document purely focused on use cases to be advanced as a Standards Track RFC.
Second, it is inappropriate to progress this VPN-unrelated draft within the BESS Working Group, rather than the IDR Working Group. Third, the original DMZ use case is inherently straightforward and well-defined, which renders a standalone dedicated draft entirely unnecessary. The relevant scenarios can be sufficiently addressed by incorporating a modest amount of descriptive text into the existing link-bandwidth draft. 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). 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. ________________________________ 1. Issues and solutions introduced in version -07 The -07 draft states: “With the existing rules for the DMZ link bandwidth, this is not possible. First the LB extended community is not sent over EBGP. Secondly the DMZ does not have a notion of conveying the cumulative link bandwidth (of the directed tree rooted at a node) to an upstream router. To enable the use case described above, the cumulative link bandwidth of R1 and R2 has to be advertised by R3 to R4, and, similarly, the cumulative bandwidth of R6 and R7 has to be advertised by R5 to R4. This will enable R4 to load-balance based on the proportion of the cumulative link bandwidth that it receives from its downstream routers R3 and R5.” In essence, this changes the extended community from non‑transitive to transitive and introduces the concept of bandwidth aggregation – both of which were already present in draft-xu-idr-fare version -00. 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. ________________________________ Notably, even with the aforementioned revisions, draft-ietf-bess-ebgp-dmz remains inapplicable to 5‑stage CLOS networks—the prevailing mainstream architecture deployed in 100K-XPU and even million-XPU scale AI clusters. I hope the community will revisit these aspects before progressing the draft further. Best regards, Tiger
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
