Need for IGMP and MLD Proxy in EVPN Environment

Section 16 of EVPN RFC7432 defines the mechanism for forwarding multicast traffic within EVPN networks. Ingress Replication and/or P2MP LSPs may be used for Multicast forwarding. The major shortcoming of Multicast forwarding approach defined in RFC7432 is the lack of per-group multicast trees, meaning that Multicast traffic is getting forwarded to all PE devices participating in a given EVPN instance, regardless of presence of interested receivers.

Imagine the scenario where EVPN domain spans across four PE devices as shown below:

EVPN Need for IGMP Proxy - Logical Topology
EVPN Need for IGMP Proxy – Logical Topology

Due to EVPN’s MAC learning mechanisms, unicast traffic is forwarded between a pair of PE devices with directly attached senders/receivers. For example, traffic sent from Host 1 to Host 4 will pass through PE1 and PE4 devices, but will not be seen on PE2 and PE3:

EVPN Need for IGMP Proxy - Unicast
EVPN Need for IGMP Proxy – Unicast

This is not the case of Broadcast, Multicast and Unknown Unicast (BUM) traffic. Without BUM suppression, BUM traffic will be flooded to all PE devices, regardless of Hosts’ interest in a given stream.

The following figure depicts the topology with Multicast Source attached to PE1 and two Receivers connected to PE2 and PE3. Despite the fact that there is no Multicast Receiver attached to PE4, PE4 will still receive all the traffic originated by Source Host 1 before dropping it locally.

EVPN Need for IGMP Proxy - Suboptimal Multicast
EVPN Need for IGMP Proxy – Suboptimal Multicast

While such behavior might be acceptable for low-volume BUM traffic, it leads to very inefficient use of Inter-PE bandwidth as the volume of traffic increases. For example, if Multicast is used for live video feed distribution.

IGMP and MLD Proxy for EVPN (https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-00#page-15) proposal intends to address this EVPN limitation, introducing mechanisms for selective multicast forwarding. Proposed solution requires new EVPN Route Types (6, 7 and 8) to be supported by EVPN-enabled PE devices.

EVPN Need for IGMP Proxy - Type 6
EVPN Need for IGMP Proxy – Type 6

The idea behind IGMP and MLD snooping is for EVPN-speaking router to intercept IGMP/MLD join / leave packets and understand hosts’ desire to receive or not receive multicast traffic for certain groups (*,G) or source-group (S,G) combinations. PE devices that snoops IGMP/MLD packets will pass hosts’ intent via BGP to the rest of PE devices.

In addition to EVPN Type 6 Route depicted above, ‘IGMP and MLD Proxy for EVPN’ draft also defines two additional Route Types (7 and 8) used in EVPN multi-homing scenario. We will discuss these Route-Types in one of our next articles.

One thought on “Need for IGMP and MLD Proxy in EVPN Environment”

  1. Nice article. One doubt I have is – in figure 3 above, where PE 1 is the source of BUM traffic and we have receivers behind PE2 and PE3. You mentioned even PE4 will receive this traffic since it is part of same EVI. What is PE3 does not advertise type 3 route? In that case, will it still receive the BUM traffic?

Leave a Reply

Your email address will not be published. Required fields are marked *