Hi Jeff,
Many thanks for the detailed review and comments. Have uploaded rev27 to address these comments. Please see inline below. §4.1 "Value-Weight" isn't really defined, although the implication is that it's unsigned. There needs to be at least a single sentence suggesting that it's a unsigned integer, 5 octets in length, encoded in network byte order in the range of 0..2^40-1. [NM]: ack, this was missing. Added. "All other values (for the extended community) are to be considered as invalid." Given the IANA procedures suggest that future assignments will be permitted, perhaps consider text that simply defers their behavior to out of scope for this document. More comment on this set of behaviors below. [NM]: Updated the text in this section to be in line with IANA considerations that allow possibility of later updates. §4.1.1 "Non-Zero 'Value': Only non-zero 'Value' received in this extended community is considered as a valid value." The extended community consists of a value-units, which might be 0, and a value-weight. I suspect this paragraph is intended to address only value-weight. [NM]: good catch. Corrected. "Malformed Extended Community: If a PE detects a malformed EVPN Link Bandwidth Extended Community, for example because the "Value-Units" has a value other than 0x00 or 0x01, it MUST discard the extended community as specified in [RFC7606]. The extended community is considered invalid and ignored for all paths associated with the route." There are a few issues in here: If the extended community is 8 octets in length, it's not malformed. RFC 7606 procedures, including the attribute discard this tries to nod to, only applies toward that type of malformation. [NM]: Thanks for pointing this out. Corrected. However, it's fine for this document to decide that the extended community in this document has additional rules for its type/sub-type contents. In this case, the "value-units". However, given the procedure here is "there are exactly two valid cases", this effectively eliminates most simple upgrade scenarios. Given the IANA considerations nodding toward a possibility of later update, this is perhaps overly aggressive. A general consequence for any of the procedures of "I don't like this community" is "the deployment falls back to stock ECMP". I'm unbothered by this from a protocol correctness standpoint. However, it perhaps becomes an operational consideration, especially for incremental deployment of new value types for this community. [NM]: makes sense. I have updated the text in this section to be in line with IANA considerations that allow possibility of later updates. §5.2 The mechanism for the weight calculation is straight forward. However, there's nothing nodding towards the considerations for what paths are permitted to be evaluated against during these procedures. Intuitively, they are paths that are accepted by the BGP procedures and are eligible to be used for forwarding; i.e. resolvable. If that's the case, consider a sentence stating that or at least reinforcing existing procedure that may be in other documents for such evaluation. [NM] ack. Added. §7.6 and Appendix A Thanks for discussing the interactions (mostly, non-interactions) with the BGP link-bandwidth community. Although appendix A notes that the BGP link-bw community was considered, this split application for EVPN as underlay technology provides a good motivation to not cause confusion as to how these communities translate between EVPN use and other scenarios. That said, a consequence of such interactions would seem to be present and potentially in operational conflict for EVPN RT-5. Within the EVPN domain, traffic is load balanced via the EVPN link-bw community. Once it leaves that domain, load balancing for the same routes may be governed by the BGP link-bw community. If the ratios of these communities are not harmonized, it seems like traffic may perversely load balance in undesired fashion vs. the two features. Has there been any discussion about how to document operational considerations for this interaction, if this is a valid observation? [NM]: There was discussion on this and as a result, sections 7.5, 7.6, and 7.7 were added to limit the scope of EVPN link-bandwidth to an EVPN network as well as limit the scope of this document to its usage within an EVPN network. In line with [EVPN-IPVPN], this document calls for not preserving EVPN link-bandwidth into a non-EVPN network, as well as calls for EVPN link-bandwidth to take preference in an EVPN network. That said, it is entirely possible for [BGP-LINK-BW] to govern load balancing of the flow outside the EVPN network until it reaches the EVPN border PE, where the flow would be load balanced a per EVPN link bandwidth (if present). Any additional translation / cumulation use cases between the two (if possible) to achieve more optimal load balancing end to end are considered to be out of scope of this document. As such, thought is that if such a use case is encountered and is considered worth investing in, [EVPN-IPVPN] or a new document may be more appropriate. Please let me know if this makes sense. Appendix A is historic and I did update the text a bit to make it clearer. Thanks, Neeraj On Sep 10, 2025, at 4:31 AM, [email protected]<mailto:[email protected]> wrote: Hi, Authors from draft-ietf-bess-evpn-unequal-lb published updates to the document that requires review from the WG. The document passed WGLC a long time back (2021). A new WGLC is then required. This email starts a WGLC poll (including IDR WG for review). It will end on 9/24. Similarly, as the last IPR poll was done a long time back. We are also polling for knowledge of any undisclosed IPR that applies to this document (see RFCs 3979, 4879, 3669 and 5378 for more details). Authors, please ensure you reply again to the new IPR poll. Thank you Brgds, Stephane, Matthew, Jeffrey (BESS chairs) _______________________________________________ Idr mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
