Stephane and authors, A few BGP-specific notes from reviewing this draft:
§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. "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. §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. "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. 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. §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. §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? -- Jeff > On Sep 10, 2025, at 4:31 AM, [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]
