Hi Stephane, Thank you for the detailed comments. Please see my response inline.
Thanks, Aditya From: [email protected] <[email protected]> Date: Monday, September 21, 2026 at 1:53 AM To: 'Aditya Ramadurgam' <[email protected]>; [email protected] <[email protected]> Cc: [email protected] <[email protected]>; [email protected] <[email protected]> Subject: [bess] Re: Comments on draft-ietf-bess-ebgp-dmz-11 (Section 4.2 / 4.3) Hi Aditya, Thanks for your comments, please find my replies inline. Brgds, From: Aditya Ramadurgam <[email protected]> Sent: Thursday, September 10, 2026 8:11 PM To: [email protected] Cc: [email protected]; [email protected] Subject: [bess] Comments on draft-ietf-bess-ebgp-dmz-11 (Section 4.2 / 4.3) Hi all, I've been working through draft-ietf-bess-ebgp-dmz-11, specifically the worked example in Sections 4.2/4.3 (Path1/Path2/Path3 advertised toward R4), and wanted to flag two proposed text changes. 1. Section 4.2 — contributing bandwidth collapses to zero when only one input is missing In the worked example, Path3 has a perfectly valid remote bandwidth (3000Mbps via the Link-BW extended community) but no local-link-bandwidth. Because the configured contributing-bandwidth function is min(local, remote), and the current text states that "if the function cannot return a result, the contributing bandwidth is considered as zero", Path3's contributing bandwidth collapses to zero — discarding real, valid remote-signaled data purely because the other input happens to be unavailable. This disqualifies Path3 from weighted load-balancing under the MUST clause later in the same section, and excludes it from cumulation under any configured basis. Proposed text: "If contributing bandwidth is set to a function of local link and remote bandwidth, and one of the two inputs is unavailable for a given path, the contributing bandwidth for that path SHOULD fall back to whichever input is available, rather than being considered zero. Contributing bandwidth is only considered zero when none of the configured inputs are available for that path or when one of them is zero" This only changes behavior for paths currently being silently zeroed out; it doesn't affect paths where both inputs are present or when one input is purposefully set to zero. [SLI] I see the intent of what you propose. My worry is in case for instance user wants the contributing BW to be the remote BW (or some function of the remote BW), but there is no remote BW available, I don’t think implementation should fallback to the local link BW as user explicitly stated that he didn’t care about the local link BW. Doing a fallback will then go against what user wanted. IMHO, if user wants to use (for instance) a function of remote BW, then it is expected that the remote BW information will be there (as per the network design). [Adi] To be precise, the changes I proposed only apply to the case when contributing bandwidth is set as a function of local and remote bandwidth. If the user sets the contributing bandwidth to remote (or a function of remote) or to local (or a function of local), the scope is limited to remote or local respectively, and does not fall back to any other available bandwidth. The changes I proposed generally help eiBGP deployment scenarios, where the user can set the contributing bandwidth to a function of local and remote bandwidth without having to worry whether the contributing path is iBGP or some tunnel, which in most cases don't have local bandwidth. This, along with cumulation based on contributing bandwidth, gives the upstream router a realistic sense of downstream capacity, instead of silently cutting off paths that are perfectly capable of forwarding traffic. 1. Section 4.3 — local-basis cumulation can overstate advertised bandwidth Using the same worked example: if Path1 and Path2's local-link-bandwidth were both raised to 5000Mbps (remote unchanged at 1000/4000), cumulation configured on local-link-bandwidth-basis would advertise 10000Mbps to R4 (5000+5000+0), while the actual downstream-serviceable capacity per the remote-signaled values is only 5000Mbps (1000+4000). Local-link-bandwidth reflects the physical capacity of the link to the immediate next hop, not what's actually reachable behind it, so local-basis cumulation can systematically overstate capacity whenever local link capacity exceeds the real downstream constraint. [SLI] As per default behavior (using contributing BW for cumulation), the issue you describe will not appear as advertised BW will be still 3000Mbps. I agree that if user decides to modify this to use local link BW, then advertised BW will be larger than what is available. Similar issue could happen if people starts to override the link BW value and reset it to any value. If user decides to override the default, it should do it with care (knowing possible consequences). I don’t think implementations should always enforcing some cap. I have seen some deployment cases where people do this cumulation based on local-link-bw on purpose. I understand your point, if needed we can add a small text to talk about potential consequences of overriding. We could also add a sentence similar to what you propose with a “MAY”, but I would personally not go for a MUST which is too restrictive. [Adi] I understand that MUST can be restrictive, so I'm fine with changing it to MAY. Adding a word of caution is a good idea as well. Proposed text: "Regardless of the configured cumulation basis, the value used for cumulation for a given path MUST NOT exceed that path's contributing bandwidth (Section 4.2)." This makes all three configurable cumulation bases converge on the same, accurate figure whenever they'd otherwise diverge, without removing the option to choose a basis for other reasons not stated in this document. Together, proposed changes 1 and 2 ensure the cumulated figure advertised upstream always equals the true, locally-reconciled aggregate capacity — something that this document, as currently written, can compute incorrectly in either direction (discarding valid data, or overstating capacity). Happy to help iterate on the text for any of these. Thanks, Aditya Ramadurgam [EXTERNAL]
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
