Hello Krishna, et all It will be great to hear back on my below email
Thanks, Saumya. ________________________________ From: Dikshit, Saumya <[email protected]> Sent: Monday, July 27, 2026 4:22:37 pm To: Dikshit, Saumya <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; BESS <[email protected]> Cc: Joshi, Vinayak <[email protected]> Subject: Re: DF Alg registry coordination -- draft-saumvinayak-bess-all-df-bum vs. draft-kriswamy-bess-evpn-perflow-df Cc’ed to @BESS<mailto:[email protected]> , moved the [grow] distribution email to bcc Thanks, Saumya. From: Dikshit, Saumya <[email protected]> Date: Sunday, 26 July 2026 at 5:27 PM To: [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Cc: Joshi, Vinayak <[email protected]>; [email protected] <[email protected]> Subject: [GROW] DF Alg registry coordination -- draft-saumvinayak-bess-all-df-bum vs. draft-kriswamy-bess-evpn-perflow-df Hi Krishnaswamy, Ali, Lukas, I'm one of the co-authors of draft-saumvinayak-bess-all-df-bum , which defines a new EVPN DF Election Algorithm called "ALL-PEs-DF” and its been around for a while: * It lets every PE on an Ethernet Segment act as DF simultaneously, for the specific case of redundant active/active firewall or gateway deployments spread across sites, where each site's PE should locally forward BUM traffic to its own on-site firewall rather than electing a single DF for the whole ES. While updating our IANA Considerations section (it previously just said "yet to be concluded"), I noticed draft-kriswamy-bess-evpn-perflow-df-02 is concurrently requesting a new value (6, "Per-flow") from the same “DF Alg" registry created by RFC 8584. Our draft is provisionally requesting value 7 as a placeholder for ALL-PEs-DF, chosen specifically to avoid colliding with your value 6. Hence wanted to reach out, rather than have two individual drafts leveraging adjacent code/data points from a registry without any coordination. It will be great to hear your response on following: 1. Would you be open to each draft citing the other as a sibling RFC 8584 DF-Alg extension (we've already added this cross-reference on our side, along with draft-ietf-bess-evpn-per-mcast-flow-df-election, which is also touching this registry)? 1. Do you have a preference between (a) each draft keeping its own provisional <TBD> value and letting the WG/IANA resolve final numbering at adoption/allocation time, or (b) trying to informally agree on non-overlapping values now, before either draft is adopted? 1. Is there any appetite for a short joint note to the BESS list flagging that RFC 8584's DF Alg registry now has three concurrent extension proposals in flight (per-flow, per-multicast-flow, and all-PEs-DF), so the WG is aware before any of them progress further? Happy to align terminology or merge text if there's overlap I'm not seeing on our use case (redundant firewall gateways) and seems distinct from per-flow load-splitting. But you'd know better than I would if there’s any interaction worth calling out explicitly in either document. Thanks, Saumya Dikshit (co-author, draft-saumvinayak-bess-all-df-bum) Aruba Networks, HPE [email protected]
_______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
