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. 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. 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
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
