Document: draft-ietf-bess-evpn-per-mcast-flow-df-election Title: Per multicast flow Designated Forwarder Election for EVPN Reviewer: Gyan Mishra Review result: Almost Ready
Summary: This document defines an enhancement to the Designated Forwarder (DF) election process in Ethernet Virtual Private Network (EVPN) environments. While traditional DF election operates at a per Virtual Local Area Network (VLAN) or per group of VLANs (in case of VLAN bundle or VLAN-aware bundle service) level, such granularity may not be sufficient for applications requiring optimized or isolated multicast forwarding. This specification introduces a refined DF election mechanism that extends existing hash-based methods to operate at a more granular level specifically at the tuple of Ethernet Segment Identifier (ESI), VLAN, and multicast flow. This approach enables improved traffic distribution, enhanced load balancing, and greater deployment flexibility for multicast delivery in EVPN based networks. The proposed method is designed to remain compatible with existing DF election procedures while offering targeted improvements for multicast scenarios. The document is very well written and I thank the authors and collaborators on this critical enhancement to DF election process to take into account BUM flow based load balancing. Major issues: None Minor issues: Section 4 describes the DF election extended community and does talk about backwards compatibility. I would recommend having a separate section on backwards compatibility. The section gives an example of vlan missing on a PE and then the PE is excluded from the new multicast flow process. However does not give an example of a PE not supporting and how the non supporting PE os excluded from redundancy group for the per multicast flow DF election. Load balancing is between the local PEs within the ESI redundancy group and not the per EVI remote PEs. That should be noted. RFC 7432bis DF section included local DF and BDF and per EVI remote PEs are not eligible as forwarders. I think we should include interoperability of new DF for use case with mix of SH and MH PEs. Nits: Section 6, 3. Old 1. PE-1: non-Designated Forwarder (nDF) for flow (s1, g1), and DF for all other Broadcast, Unknown unicast, and Multicast (BUM) traffic 2. PE-2 forwarding state would be DF for flow (s1,g1) and nDF for rest other BUM traffic. 3. PE-3 forwarding state would be nDF for flow (s1,g1) and rest other BUM traffic. New Should backup DF (bDF) be mentioned here PE-2 DF, PE-1 bDF and PE-3 nDF. https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-13#name-signaling-primary-and-backu 1. PE-1: non-Designated Forwarder (nDF) for flow (s1, g1), and DF for all other Broadcast, Unknown unicast, and Multicast (BUM) traffic 2. PE-2 Designated Forwarder (DF) for flow (s1,g1) and nDF for rest other BUM traffic. 3. PE-3 non-Designated forwarder (nDF) for flow (s1,g1) and DF for all othet Broadcasr, Unknown Uunicaat, and Multicast (BUM) traffic _______________________________________________ BESS mailing list -- [email protected] To unsubscribe send an email to [email protected]
