OISM Selective multicast Ingress replication with IGMP proxy

Multicast is another key topic in today's network. It can reduce bandwidth consumption in variable use cases like multimedia, IPTV, etc. The PIM protocol is a common solution for multicast routing. However, it may not fit the data center network. Therefore, the Ingress Replication (IR) (no need for PIM) is developed and described in RFC 9574 to handle the complex multicast requirement in DC networks.
Before we move to multicast, we test the IGMP proxy function that follows RFC 9251. The IGMP Proxy mechanism is used to reduce the flooding of IGMP messages over an EVPN network, similar to the ARP proxy used in reducing the flooding of ARP messages over EVPN. It also provides a triggering mechanism for the PEs to set up their underlay multicast tunnels. RFC 9251 introduces 3 new EVPN route types: type 6 for Selective Multicast Ethernet Tag Route, type 7 for Multicast Membership Report Synch Route, and type 8 for Multicast Leave Synch Route.
In our test, we evaluated the IGMP proxy function and IR. EANTC sent an IGMPv3 (S, G) join message from the receiver with Spirent TestCenter and confirmed that all multihomed DUTs sent RT-6 and RT-7. Next, EANTC generated multicast from the source with Spirent TestCenter and verified that only one multicast copy was received in the multihomed domain. Subsequently, EANTC sent IGMP leave messages with Spirent TestCenter while the multicast transmission was ongoing. As a result, no multicast traffic was received in the multihomed domain, indicating that RT-8 functioned as expected. Since only one host was configured, we only validated the Ingress Replication by checking the DUT's CLI output.
After verifying the protocol, we need to examine traffic forwarding. RFC 9625 defines EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding. In our tests, we conducted three runs involving two different traffic forwarding scenarios: intra-VLAN forwarding and inter-VLAN forwarding. RFC 9625 introduces the concept of the Supplementary Broadcast Domain (SBD) for the inter-VLAN forwarding scenario.
In our first topology, we tested intra-VLAN forwarding, which occurs when the multicast source and receiver are in the same VLAN (BD). Following that, we tested inter-VLAN forwarding in the next two runs. In these scenarios, the multicast source and receiver were in different VLANs (BDs). Consequently, the SBD was tested under these conditions. EANTC generated IGMPv3 (S, G) join/leave messages and multicast traffic with Spirent TestCenter. And we didn't observe packet loss or duplication in either of these tests.