Hi Jeff, Many thanks for further text improvements with the suggested text. Have incorporated the two suggestions below in rev28.
Thanks, Neeraj From: Jeffrey Haas <[email protected]> Date: Monday, October 6, 2025 at 1:27 PM To: Neeraj Malhotra (nmalhotr) <[email protected]> Cc: [email protected] <[email protected]>, [email protected] <[email protected]>, BESS <[email protected]>, idr <[email protected]>, [email protected] <[email protected]>, idr-chairs <[email protected]> Subject: Re: [bess] [Idr] WGLC and IPR poll on draft-ietf-bess-evpn-unequal-lb Neeraj, Sorry for response latency. This message overlapped some time off along with related recovery time for my personal inbox. On Sep 22, 2025, at 9:34 PM, Neeraj Malhotra (nmalhotr) <[email protected]<mailto:[email protected]>> wrote: 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. Thanks for addressing those two points. "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. This is the text you've changed to: "Malformed Extended Community: If a PE detects a malformed EVPN Link Bandwidth Extended Community as defined in [RFC7606], 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." This isn't quite right. RFC 7606 doesn't have any sense what this community is. At best RFC 7606, §7.14 tells you that if the set of extended communities isn't divisible by 8, treat-as-withdraw for all destinations in the update is done. In the current format, this new extended community (type/subtype) has a value-units that has two values defined, and the rest is undefined. You've taken the edit that clarifies that the value-weight is an unsigned integer 0..2^40-1 means that there's not much room to be malformed. So, if the procedure is that value-units is allowed to be maintained in the future, I think you can drop this section. RFC 7606 procedures cover malformed extended communities. 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. The text you've moved to discards the community if it's unrecognized. That means every single box that doesn't understand a new type that is being incrementally deployed (e.g. through a route reflector) will throw it out. You probably don't mean this. What you wrote was: "Unsupported 'Value-Units': If a PE receives "Value-Units" that it does not support, it MUST discard the extended community. The extended community is considered invalid and ignored for all paths associated with the route." Would your use cases be fine with simply: "Unupported 'Value-Units': If a PE receives 'Value-Units' that it does not support, that EVPN Link Bandwidth Extended Community is IGNORED and is not considered for load balancing purposes." ? §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. That works. §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 for the history. I'd suggest that the collective chairs between IDR and BESS pay attention to this as review during last call. -- Jeff
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
