OISM Selective multicast Ingress replication with IGMP proxy

Multicast is an unavoidable 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. We sent an IGMPv3 (S, G) join message from the receiver and confirmed that all multihomed DUTs sent RT-6 and RT-7. Next, we sent multicast from the source and verified that only one multicast copy was received in the multihomed domain. Subsequently, we sent IGMP leave messages 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.
Spirent TestCenter was used as the traffic generator for this test.