Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)
Extracted elements (34)
EVI-RT Extended Communities are introduced because IGMP Membership Report Synch and Leave Synch routes must be distributed only to PEs on the same ES (via ES-Import RT), not all PEs of the EVI, so the standard EVI RT cannot be used. A separate EC that identifies the EVI without influencing distribution is necessary.
IGMP/MLD group state must be synchronized among all PEs serving the VPN (via SMET, Membership Report Synch, and Leave Synch routes) because EVPN's All-Active multihoming means different IGMP messages and their corresponding Leaves for the same flow can arrive at different PEs, making per-PE state inconsistent without explicit coordination.
In the event of a PE or PE-to-CE link failure causing a mass withdrawal of Multicast Membership Report Synch routes, remote PEs SHOULD NOT immediately remove state; instead, a General Query SHOULD be generated to refresh states. This avoids unnecessary multicast traffic disruption when the failure may be transient or new hosts will rejoin.
When a PE receives an EVPN SMET route with more than one version flag set (e.g., both v2 and v3), there must be no source IP address in the route. If there is a source IP address in such a route, an error SHOULD be logged. The PE MUST generate an IGMP Membership Report for each version indicated.
When the first-hop PE receives IGMPv3 Membership Reports for (S,G), it MUST advertise the corresponding EVPN SMET route regardless of whether source S is locally attached, in order to facilitate source move in the future. The only valid version flag for (S,G) routes is v3; v2 flags MUST be set to 0.
A PE that supports IGMP and/or MLD Proxy on a given BD MUST attach the Multicast Flags Extended Community to its IMET route advertisement for that BD and MUST set the corresponding IGMP and/or MLD Proxy Support flags to 1. Absence of this community indicates no IGMP/MLD Proxy support.
All-Active multihoming PEs for a given ES MUST support IGMP synchronization procedures (Membership Report Synch and Leave Synch routes) if they need to perform IGMP Proxy for hosts connected to that ES, because IGMP messages and their corresponding Leaves can arrive at different PEs in the redundancy group.
An IGMPv2 Membership Report MUST NOT be sent on an AC that does not lead to a CE multicast router, because IGMPv2 hosts suppress their own Membership Reports upon receiving one for the same group, which would prevent the PE from forwarding multicast data to those hosts.
Each IGMP Membership Report Synch and Leave Synch route MUST carry exactly one EVI-RT EC and exactly one ES-Import RT. If a received Synch route has no EVI-RT EC or more than one EVI-RT EC, the PE MUST apply the 'treat-as-withdraw' procedure per RFC 7606.
Each PE MUST have proxy querier functionality to enable the EVPN network to act as a distributed anycast multicast router and to suppress IGMP Membership Reports and Membership Queries over the MPLS/IP core.
If a PE does not support the Membership Report Synch or Leave Synch route types, it MUST NOT indicate IGMP Proxy support in the Multicast Flags Extended Community for EVIs corresponding to its multihomed ESs.
If a received BGP update contains Flags not in accordance with the IGMP/MLD version-X expectation, the PE MUST apply the 'treat-as-withdraw' procedure per RFC 7606. If route keys cannot be extracted due to malformation, the BGP update MUST be considered invalid and 'session reset' applied.
If all version flags in a received EVPN SMET route are reset (no version flag set), this is an error because the PE should have received a BGP route withdraw; the PE MUST treat it as a BGP error and apply the 'treat-as-withdraw' procedure per RFC 7606.
If an ASBR is configured to perform RT-rewriting of EVI RTs in EVPN routes, it MUST also be configured to perform RT-rewriting of the corresponding EVI-RT extended communities in IGMP Join Synch and IGMP Leave Synch routes.
IGMPv1 routes are considered invalid; the PE MUST apply the 'treat-as-withdraw' procedure per RFC 7606. Implementations are expected to only use IGMPv2 and above for IPv4 and MLDv1 and above for IPv6.
The SMET Originator Router IP address MUST match that of the IMET (or S-PMSI AD) route originated for the same EVI by the same downstream PE, ensuring consistent identification of the advertising PE.
When a first-hop PE receives IGMP Membership Reports of different versions for the same (*,G), it MUST NOT withdraw the existing EVPN SMET route before sending the updated route, because the Flags field is not part of BGP route key processing and a withdraw-then-readvertise would cause state loss at remote PEs.
When a PE connected to a PIM ASM network behind a multicast router needs to receive all multicast traffic in the EVPN domain, it MUST originate a (*,*) SMET route using the wildcard procedure from RFC 6625.
When a PE in All-Active mode receives an IGMP Membership Report for (x,G) on a multihomed ES and does not already have that state, it MUST instantiate the local IGMP Membership Request state and MUST advertise a BGP IGMP Membership Report Synch route carrying the ES-Import RT for that ES.
When a PE receives a BGP update where both M and I flags of the Multicast Flags Extended Community are 0, the router MUST treat this update as malformed and MUST ignore the extended community.
When a PE receives an EVPN SMET route withdraw, it removes the remote PE from the OIF list for that multicast group, and if no OIF entries remain (local or remote), the PE MUST stop responding to Membership Queries from any locally attached router and stop sending multicast traffic for that source.
For ingress replication tunnels, selective multicast is achieved by sending (x,G) traffic only to (a) PEs not supporting IGMP/MLD Proxy (those advertising IMET without Multicast Flags EC or with both proxy flags unset), and (b) IGMP/MLD Proxy-supporting PEs that have advertised a SMET route for that (x,G) group.
Four EVI-RT Extended Community sub-types (0x0A–0x0D, Types 0–3) are defined to associate Membership Report Synch and Leave Synch routes with a specific EVI without influencing BGP route distribution. They mirror the four standard RT EC types (Two-Octet AS, IPv4-Address, Four-Octet AS, IPv6-Address specific).
RFC 9251 defines three new BGP EVPN route types: Route Type 6 (Selective Multicast Ethernet Tag Route, SMET), Route Type 7 (Multicast Membership Report Synch Route), and Route Type 8 (Multicast Leave Synch Route), used to carry IGMP/MLD membership state across the EVPN network.
IANA allocated five new codepoints in the 'EVPN Extended Community Sub-Types' subregistry: 0x09 (Multicast Flags Extended Community), 0x0A (EVI-RT Type 0), 0x0B (EVI-RT Type 1), 0x0C (EVI-RT Type 2), and 0x0D (EVI-RT Type 3), all referencing RFC 9251.
IANA allocated three new EVPN Route Types in the 'EVPN Route Types' subregistry: 6 (Selective Multicast Ethernet Tag Route), 7 (Multicast Membership Report Synch Route), and 8 (Multicast Leave Synch Route).
IANA created a new 'Multicast Flags Extended Community' subregistry under the BGP Extended Communities registry with First Come First Served registration policy. Initial assignments: bit 15 = IGMP Proxy Support, bit 14 = MLD Proxy Support, bits 0–13 = Unassigned.
Security considerations for RFC 9251 inherit from the underlying EVPN and BGP substrates (RFC 7432), multicast in MPLS/BGP IP VPNs (RFC 6513, RFC 6514), and the IGMP/MLD protocols themselves (RFC 2236, RFC 3376, RFC 2710, RFC 3810). The EVPN IGMP Proxy provides a single broadcast domain, so the same IGMP/MLD security considerations apply.
Leave group synchronization state machine: triggered by IGMP Leave reception, the PE (1) computes Maximum Response Time (Last Member Query Count × Last Member Query Interval + BGP propagation delta), (2) starts the timer, (3) sends Group-Specific Queries, (4) advertises Leave Synch route with Maximum Response Time. On timer expiry, the Leave Synch route is withdrawn and IGMP Membership Request state is removed if no new Membership Reports or Synch routes arrived.
The Multicast Flags Extended Community is an 8-octet EVPN Extended Community (Type 0x06, Sub-Type 0x09) with a 2-octet Flags field where bit 15 (I) = IGMP Proxy Support and bit 14 (M) = MLD Proxy Support; bits 0-13 are reserved. The remaining 4 octets are Reserved and set to 0.
The Multicast Leave Synch Route NLRI has the same structure as the Membership Report Synch Route but appends a Reserved field (4 octets) and Maximum Response Time (1 octet) before the Flags octet. The Reserved, Maximum Response Time, and Flags fields are excluded from BGP route key processing.
The Multicast Membership Report Synch Route NLRI extends the SMET format by prepending an Ethernet Segment Identifier (ESI, 10 octets) after the RD field, used to coordinate IGMP/MLD membership state between PEs on a multihomed Ethernet segment. All fields except the 1-octet Flags are part of the BGP route key.
The Selective Multicast Ethernet Tag (SMET) Route NLRI contains: RD (8 octets), Ethernet Tag ID (4 octets), Multicast Source Length (1 octet), Multicast Source Address (variable), Multicast Group Length (1 octet), Multicast Group Address (variable), Originator Router Length (1 octet), Originator Router Address (variable), and Flags (1 octet). All fields except the Flags octet are part of the BGP route key.
The SMET Flags field is 1 octet with bits: v1 (bit 7, IGMPv1/MLDv1), v2 (bit 6, IGMPv2/MLDv2), v3 (bit 5, IGMPv3 only), IE (bit 4, Include=0/Exclude=1), and reserved (bits 0-3). For IPv6 (MLD) routes, bit 5 (v3) MUST be 0 and bit 4 MUST be ignored if bit 6 is not set.