Hi Reshma, Pls find inline replies
Brgds, From: Das, Reshma <[email protected]> Sent: Tuesday, March 3, 2026 12:21 AM To: Jeffrey Haas <[email protected]>; [email protected]; Stephane Litkowski (slitkows) <[email protected]>; [email protected]; [email protected] Cc: BESS <[email protected]>; idr-chairs <[email protected]> Subject: [bess] Re: draft-ietf-bess-ebgp-dmz - preparation for working group last call Hi Jeff, Regarding the IPR call, I'm not aware of any IPR related to this draft. Reviewing the document I have couple of comments: 1. In Section 4.2: “for consistency reason, all BGP paths of a prefix MUST use a contributing bandwidth based on the same source (e.g.: all paths are using contributing bandwidth from the same function)." Should this be a MUST? In the context of EIBGP peering, the source of the LBW value may differ depending on the type of session. For single‑hop EBGP peers, the contributing bandwidth may correspond to the directly connected interface, whereas for multi‑hop IBGP peers, the contributing bandwidth would be derived from the LBW received from the upstream node. In both cases, the attached LBW values can be used for WECMP calculations. However, enforcing that all BGP paths of a prefix MUST derive contributing bandwidth from the same source appears unnecessarily restrictive. [SLI] I agree, that we should not be so restrictive, we can probably relax that. Would a SHOULD be ok ? I could put a note for the EIBGP case. 2. In section 4.3: a. Example: “ P/m Path1: NH=R1, Link-BW extended-community: 1000Mbps, local-link-bandwidth: 2000Mbps, contributing-bandwidth: 2000 best, multipath Path2: NH=R2, Link-BW extended-community: 2000Mbps, local-link-bandwidth: 2000Mbps, contributing-bandwidth: 4000 multipath Path3: NH=R3, Link-BW extended-community: 3000Mbps, multipath" This example is a bit confusing. Could you elaborate on how the contributing bandwidth is calculated? Although Path3 has received a Link Bandwidth (LBW) extended community, its contributing bandwidth is shown as 0. It appears that the contributing bandwidth for all three paths is calculated differently, which contradicts the second MUST statement in Section 4.2. [SLI] Yes, I think contributing BW have been set randomly here I think which doesn’t help and doesn’t match with 4.2 reqs. Good catch. I’ll fix this to make it more readable. b. Further, according to Section 4.2, since Path3 does not have any contributing bandwidth, WECMP cannot be done on this prefix. Although the DUT does not perform WECMP, it is still aggregates and advertises the LBW value to the peer, which can be misleading In my opinion the cumulative or aggregated LBW should be the sum of the LBW value that is used locally for WECMP. This provides the peer with an accurate representation of the bandwidth available downstream. [SLI] In fact it’s may not always be the case. Cumulating BW across layers is causing problems of churn. If a remote link (far away) flaps, it would be reflected everywhere in the fabric. But it’s not always suitable. Some people prefer when cumulating hiding what’s happening upstream and cumulate only based on local link BW available even if they use something different for WECMP. Thanks & Regards, Reshma Das Get Outlook for Mac <https://aka.ms/GetOutlookForMac> From: Jeffrey Haas <[email protected] <mailto:[email protected]> > Date: Monday, February 23, 2026 at 11:19 AM To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> >, Das, Reshma <[email protected] <mailto:[email protected]> >, Stephane Litkowski (slitkows) <[email protected] <mailto:[email protected]> >, [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> >, [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]> > Cc: BESS <[email protected] <mailto:[email protected]> >, idr-chairs <[email protected] <mailto:[email protected]> > Subject: Re: draft-ietf-bess-ebgp-dmz - preparation for working group last call Note that IPR attestations are still pending for Reshma, Stephane, and Arie. Ajay, Akshay has made one note related to Arista, but please confirm your own understanding. Authors, the following still needs to be addressed: "[NOTE: IS THAT TRUE IN OUR CASE ?]" :-) -- Jeff On Feb 13, 2026, at 18:38, Jeffrey Haas <[email protected] <mailto:[email protected]> > wrote: https://datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/shepherdwriteup/ <https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-bess-ebgp-dmz/shepherdwriteup/__;!!NEt6yMaO-gk!F0JKYQ9w22XTRB5wHBiBLajKvCfqbO7QAryzC1Vqk8dy5tdx4HMJ4vFyZAfWj4b83A0KEg0idUoE$> In November 2025, the IDR chairs corresponded with the BESS chairs about the disposition of the DMZ draft. As you know from the long history of this draft, the link-bandwidth one, and the work that came to be part of RFC 4360-bis, we've discussed leaving the DMZ draft in BESS and running concurrent WGLC's on this draft along with RFC 4360-bis. As part of this concurrent WGLC, I've completed an initial shepherd report for the DMZ draft. Please review its contents for correctness. A few items have been identified that will be needing to be addressed prior to starting the last call. They are: - Author count > 5. I've not recommended changes since I've not been a participant in those discussions. The chairs have been urged to discuss what to do about it. - Proposed status. Ketan, as part of the link-bandwidth draft AD review, suggested that the DMZ draft should likely be informational. - IPR declarations were partially gathered during document adoption. While I have not been deeply thorough in my review of the IETF mailarchive for search terms covering this draft, my cursory review suggests we're missing IPR declarations for some of the authors. If you're one of the authors identified in the shepherd writeup, please either make an appropriate declaration or perhaps provide a pointer in the archive for a prior one. - The authors have left a NOTE in the draft suggesting a bit of doubt about the disposition of one of the points regarding zero link-bandwidth. Discussion about this was part of our last minute link-bandwidth document changes in IDR - so this isn't surprising. The authors are requested to please address this lingering point in the draft. - While there are no normative procedures specified in the draft, the procedures do raise questions about supporting implementations. I won't speak for the chairs in terms of expectations of formal implementation reports for their working group. If such an implementation report exists for one of your implementations, please disclose it so it can be added to the report. - The document may benefit from a routing-directorate review. I was unable to identify a prior review for this document from the mail archives. In general, the document is in good shape. I'll be working on a similar shepherd report for RFC 4360-bis in IDR. IDR does have a requirement for at least two implementations in order to progress the document. Since part of the motivation for RFC 4360-bis was addressing the transitivity considerations needed for this document, I find it highly likely that there are implementations from authors participating in the DMZ draft for the RFC 4360-bis work. Please contribute to IDR's implementation report so that we can send both documents to the IESG at the same time when they've completed their reviews. -- Jeff (as document shepherd)
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
