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.
2.
In section 4.3:
*
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.
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.
Thanks & Regards,
Reshma Das
Get Outlook for Mac <https://aka.ms/GetOutlookForMac>
From: Jeffrey Haas <[email protected]>
Date: Monday, February 23, 2026 at 11:19 AM
To: [email protected] <[email protected]>, Das,
Reshma <[email protected]>, Stephane Litkowski (slitkows)
<[email protected]>, [email protected] <[email protected]>,
[email protected] <[email protected]>
Cc: BESS <[email protected]>, idr-chairs <[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]> 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]
