RFC 9251

Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)

📅 published June 2022, from ietf

Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN) 🎀

Okay bestie, RFC 9251 is a Standards Track doc from the IETF, published June 2022 🦋. Five Cisco, Arrcus and Juniper people wrote it, and it's all about making IGMP/MLD (the protocols hosts use to say "hey, I want this multicast group" 🧚) work super efficiently across EVPN networks. Nothing here obsoletes or updates another RFC, so it's a fresh standard, no drama 💅.

Here's the title block, all in one place:

  • RFC number: 9251
  • Category: Standards Track
  • Status: Internet Standards Track document, approved by the IESG 🔥
  • ISSN: 2070-1721
  • Date: June 2022
  • Authors: A. Sajassi, S. Thoria, M. Mishra (Cisco Systems), K. Patel (Arrcus), J. Drake and W. Lin (Juniper Networks) 👑
  • Obsoletes: none
  • Updates: none

Abstract ✨

Okay so the abstract is giving elevator pitch: this doc explains how to support endpoints running IGMP or MLD efficiently for multicast services over an EVPN network, by adding IGMP/MLD Proxy procedures on EVPN Provider Edges (PEs) 🌸. Iconic, honestly.

Status of This Memo 📜

This is an Internet Standards Track document 💖.

It's a product of the IETF, it represents the IETF community's consensus, it got public review, and the IESG approved it for publication. If you want more on Internet Standards, check out Section 2 of RFC 7841. Errata and feedback live at https://www.rfc-editor.org/info/rfc9251 🫶.

Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved 💜.

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they were on the publication date. Read them carefully, they spell out your rights and restrictions. Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Revised BSD License says 🔥.

Table of Contents 🧚

1.  Introduction
2.  Specification of Requirements
3.  Terminology
4.  IGMP/MLD Proxy
  4.1.  Proxy Reporting
    4.1.1.  IGMP/MLD Membership Report Advertisement in BGP
    4.1.2.  IGMP/MLD Leave Group Advertisement in BGP
  4.2.  Proxy Querier
5.  Operation
  5.1.  PE with Only Attached Hosts for a Given Subnet
  5.2.  PE with a Mix of Attached Hosts and a Multicast Source
  5.3.  PE with a Mix of Attached Hosts, a Multicast Source, and a
        Router
6.  All-Active Multihoming
  6.1.  Local IGMP/MLD Membership Report Synchronization
  6.2.  Local IGMP/MLD Leave Group Synchronization
    6.2.1.  Remote Leave Group Synchronization
    6.2.2.  Common Leave Group Synchronization
  6.3.  Mass Withdraw of the Multicast Membership Report Synch
        Route in Case of Failure
7.  Single-Active Multihoming
8.  Selective Multicast Procedures for IR Tunnels
9.  BGP Encoding
  9.1.  Selective Multicast Ethernet Tag Route
    9.1.1.  Constructing the Selective Multicast Ethernet Tag Route
    9.1.2.  Reconstructing IGMP/MLD Membership Reports from the
            Selective Multicast Route
    9.1.3.  Default Selective Multicast Route
  9.2.  Multicast Membership Report Synch Route
    9.2.1.  Constructing the Multicast Membership Report Synch
            Route
    9.2.2.  Reconstructing IGMP/MLD Membership Reports from a
            Multicast Membership Report Synch Route
  9.3.  Multicast Leave Synch Route
    9.3.1.  Constructing the Multicast Leave Synch Route
    9.3.2.  Reconstructing IGMP/MLD Leave from a Multicast Leave
            Synch Route
  9.4.  Multicast Flags Extended Community
  9.5.  EVI-RT Extended Community
  9.6.  Rewriting of RT ECs and EVI-RT ECs by ASBRs
  9.7.  BGP Error Handling
10. IGMP Version 1 Membership Report
11. Security Considerations
12. IANA Considerations
  12.1.  EVPN Extended Community Sub-Types Registration
  12.2.  EVPN Route Types Registration
  12.3.  Multicast Flags Extended Community Registry
13. References
  13.1.  Normative References
  13.2.  Informative References
Acknowledgements
Contributors
Authors' Addresses

1. Introduction 🦋

Okay so picture a data center 🍓. A point of delivery (POD) is a bunch of servers hanging off some top-of-rack (ToR) and spine switches. That whole cluster is self-contained and can have its own control protocol for talking inside the POD and getting orchestrated. BUT EVPN is the standard way PODs talk to each other, both within a DC and between DCs. A subnet can stretch across several PODs and DCs, and EVPN gives you a robust multi-tenant setup with loads of multihoming options to make that happen. And you can have hundreds of hosts on a subnet stretched like that. Literally so many hosts 😭.

Those hosts tell the network which multicast groups they care about on a given subnet or VLAN by sending IGMP/MLD Membership Reports. Meanwhile, an IGMP/MLD router keeps sending Membership Queries to check whether hosts on the subnet still want traffic for that group. The IGMP/MLD Proxy solution in this doc has three goals 💅:

  1. Cut down on IGMP/MLD flooding. Same idea as the ARP/Neighbor Discovery (ND) suppression in EVPN, which reduces ARP flooding over EVPN. We want the same kind of thing for IGMP/MLD messages, both Queries and Membership Reports, over EVPN 🧚.
  2. Be a distributed anycast multicast proxy. The EVPN network should act like one distributed anycast multicast router for the IGMP/MLD Proxy function, for every host attached to that subnet ✨.
  3. Selective multicast. Multicast traffic only gets forwarded to the PEs that actually want that multicast group. This doc shows how that works when ingress replication moves the traffic between PEs. For Point-to-Multipoint (P2MP) tunnels, check out [EVPN-BUM] 🌈.

Goals one and two come from the IGMP/MLD Proxy on the PE. Goal three comes from setting up a multicast tunnel only among the PEs interested in the group, triggered by the IGMP/MLD Proxy processes 🫶. The solutions for each goal are in the sections that follow 💖.

2. Specification of Requirements 📜

Okay this part is important, so listen up 🙈. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜.

3. Terminology 🧚

Here's the vocab list, bestie 💅:

AC: Attachment Circuit.

All-Active Redundancy Mode: When every PE attached to an Ethernet segment is allowed to forward known unicast traffic to and from that Ethernet segment for a given VLAN, the Ethernet segment is in All-Active redundancy mode 🔥.

BD: Broadcast Domain. Per [RFC7432], an EVPN instance (EVI) consists of a single BD or multiple BDs. With a VLAN bundle or a VLAN-aware bundle service model, an EVI has multiple BDs. Also, in this doc, BD and subnet mean the same thing 🦋.

DC: Data Center.

ES: Ethernet segment. This is when a customer site (device or network) is connected to one or more PEs over a set of Ethernet links 🌸.

ESI: Ethernet Segment Identifier. A unique non-zero identifier for an Ethernet segment 🎀.

Ethernet Tag: Identifies a particular broadcast domain, like a VLAN. An EVPN instance has one or more broadcast domains 💖.

EVI: EVPN Instance. It spans the Provider Edge (PE) devices participating in that EVPN ✨.

EVPN: Ethernet Virtual Private Network.

IGMP: Internet Group Management Protocol.

IR: Ingress Replication.

MLD: Multicast Listener Discovery.

OIF: Outgoing Interface for multicast. It can be a physical interface, a virtual interface, or a tunnel 🌈.

PE: Provider Edge.

POD: Point of Delivery.

S-PMSI: Selective P-Multicast Service Interface. It's a conceptual interface a PE uses to send customer multicast traffic to some of the PEs in the same VPN 🫶.

Single-Active Redundancy Mode: When only one PE among all the PEs attached to an Ethernet segment is allowed to forward traffic to and from that Ethernet segment for a given VLAN, the Ethernet segment is in Single-Active redundancy mode 💜.

SMET: Selective Multicast Ethernet Tag.

ToR: Top of Rack.

This doc also assumes you're familiar with the terminology of [RFC7432], [RFC3376], and [RFC2236] 🧚. When it says "IGMP Membership Report," that applies to MLD Membership Reports too. Same deal for IGMPv2 and MLDv1, and IGMPv3 and MLDv2. IGMP/MLD version encoding in the BGP update is covered in Section 9 🎀.

One more thing, bestie: anywhere the text talks about a PE indicating support for IGMP proxying, there's a natural analog for indicating support for MLD proxying, and the analogous requirements apply too 👑 ✨.

Part 1 of 8. More parts coming, so stay tuned 🦋💖

4. IGMP/MLD Proxy ✨

okay so the IGMP Proxy mechanism is here to cut down on the flooding of IGMP messages over an EVPN network 🦋, kinda like how the ARP proxy does the same thing for ARP messages over EVPN. it also gives the PEs a trigger to set up their underlay multicast tunnels 💅. the IGMP Proxy mechanism has two components:

  1. Proxy for IGMP Membership Reports
  2. Proxy for IGMP Membership Queries

bestie, the whole goal of IGMP and MLD proxying is to make EVPN feel totally seamless for the tenant systems when it comes to multicast 🫶, while using a way more efficient delivery system for signaling and delivery across the VPN. so group state has to be tracked synchronously among the PEs serving the VPN 😭. join and leave events get propagated to the peer PEs, and each PE tracks the state of each of its peers: whether there are locally attached group members (and in some cases senders), which version(s) of IGMP/MLD are in use for those locally attached group members, etc. to pull off this translation, each PE acts as an IGMP router for its locally attached domain 👑, maintains the requisite state on locally attached nodes, sends periodic Membership Queries, and so on. the role of EVPN Selective Multicast Ethernet Tag (SMET) route propagation is to make sure each PE's local state gets propagated to the other PEs, so they all share a consistent view of the overall IGMP Membership Request and Leave Group state 🌸. it's important to note that the need to keep this local state can be triggered by either local IGMP traffic or BGP EVPN signaling. in most cases a local IGMP event will need to be signaled over EVPN 💜, though state initiated by received EVPN traffic won't always need to be relayed to the locally attached domain 🙈.

4.1. Proxy Reporting

when IGMP is used between hosts and their first hop EVPN router (EVPN PE), proxy reporting is how the EVPN PE summarizes reports from downstream hosts (when possible) and propagates them in BGP to the other PEs that are interested in that info 🍓. it works by terminating the IGMP Membership Reports in the first hop PE, then translating and exchanging the relevant info among EVPN BGP speakers. at the recipient EVPN speaker, the info gets translated back into an IGMP message. so yeah, it basically helps create an IGMP overlay subnet using BGP ✨. to make that overlay work, this document also defines a new EVPN route type Network Layer Reachability Information (NLRI) and the EVPN SMET route, along with its procedures to help exchange and register IGMP multicast groups; see Section 9.

4.1.1. IGMP/MLD Membership Report Advertisement in BGP

when a PE wants to advertise an IGMP Membership Report using the BGP EVPN route, it follows the rules below (BGP encoding is stated in Section 9). the first four rules apply to the originator PE, and the last three apply to remote PE processing of SMET routes:

Processing at the BGP route originator:

  1. When the first hop PE receives IGMP Membership Reports belonging to the same IGMP version from different attached hosts for the same (,G) or (S,G), it SHOULD send a single BGP message corresponding to the very first IGMP Membership Request (BGP update as soon as possible) for that (,G) or (S,G). this is because BGP is a stateful protocol, so no further transmission of the same report is needed 🧠. if the IGMP Membership Request is for (,G), then the Multicast Group Address MUST be sent along with the corresponding version flag (v2 or v3) set. in case of IGMPv3, the exclude flag MUST also be set to indicate that no source IP address must be excluded (include all sources ""). if the IGMP Membership Report is for (S,G), then besides setting the Multicast Group Address along with the v3 flag, the source IP address and the Include/Exclude (IE) flag MUST be set. it's worth noting that when advertising the EVPN route for (S,G), the only valid version flag is v3 (v2 flags MUST be set to 0).
  2. When the first hop PE receives an IGMPv3 Membership Report for (S,G) on a given BD, it MUST advertise the corresponding EVPN SMET route, regardless of whether the source (S) is attached to itself or not, in order to facilitate the source move in the future.
  3. When the first hop PE receives an IGMP version-X Membership Report first for (,G) and then later receives an IGMP version-Y Membership Report for the same (,G), then it MUST re-advertise the same EVPN SMET route with the flag for version-Y set in addition to any previously set version flag(s). in other words, the first hop PE MUST NOT withdraw the EVPN route before sending the new route, because the Flags field is not part of BGP route key processing.
  4. When the first hop PE receives an IGMP version-X Membership Report first for (*,G) and then later receives an IGMPv3 Membership Report for the same Multicast Group Address but for a specific source address S, then the PE MUST advertise a new EVPN SMET route with the v3 flag set (and v2 reset). the IE flag also needs to be set accordingly. since the source IP address is used as part of BGP route key processing, it is considered to be a new BGP route advertisement. when different versions of IGMP Membership Report are received, the final state MUST be as per Section 5.1 of [RFC3376]. at the end of the route processing, local and remote group record state MUST be as per Section 5.1 of [RFC3376].

Processing at the BGP route receiver:

  1. When a PE receives an EVPN SMET route with more than one version flag set, it will generate the corresponding IGMP Report for (,G) for each version specified in the Flags field. with multiple version flags set, there must not be a source IP address in the received EVPN route. if there is, then an error SHOULD be logged. if the v3 flag is set (in addition to v2), then the IE flag MUST indicate "exclude". if not, then an error SHOULD be logged. the PE MUST generate an IGMP Membership Report for that (,G) and each IGMP version in the version flag.
  2. When a PE receives a list of EVPN SMET NLRIs in its BGP update message, each with a different source IP address and the same Multicast Group Address, and the version flag is set to v3, then the PE generates an IGMPv3 Membership Report with a record corresponding to the list of source IP addresses and the group address, along with the proper indication of inclusion/exclusion.
  3. Upon receiving an EVPN SMET route(s) and before generating the corresponding IGMP Membership Request(s), the PE checks to see whether it has a Customer Edge (CE) multicast router for that BD on any of its ESs. The PE provides such a check by listening for PIM Hello messages on that AC, i.e., (ES,BD). If the PE does have the router's ACs, then the generated IGMP Membership Request(s) is sent to those ACs. If it doesn't have any of the router's ACs, then no IGMP Membership Request(s) needs to be generated. this is because sending IGMP Membership Requests to other hosts can result in unintentionally preventing a host from joining a specific multicast group using IGMPv2, i.e., if the PE does not receive a Membership Report from the host, it will not forward multicast data to it. Per [RFC4541], when an IGMPv2 host receives a Membership Report for a group address that it intends to join, the host will suppress its own Membership Report for the same group, and if the PE does not receive an IGMP Membership Report from the host, it will not forward multicast data to it. in other words, an IGMPv2 Membership Report MUST NOT be sent on an AC that does not lead to a CE multicast router. this message suppression is a requirement for IGMPv2 hosts. this is not a problem for hosts running IGMPv3, because there is no suppression of IGMP Membership Reports.

4.1.2. IGMP/MLD Leave Group Advertisement in BGP

when a PE wants to withdraw an EVPN SMET route corresponding to an IGMPv2 Leave Group or IGMPv3 "Leave" equivalent message, it follows the rules below. the first rule defines the procedure at the originator PE, and the last two rules talk about procedures at the remote PE:

Processing at the BGP route originator:

  1. When a PE receives an IGMPv2 Leave Group or its "Leave" equivalent message for IGMPv3 from its attached host, it checks to see if this host is the last host that is interested in this multicast group by sending a query for the multicast group. If the host was indeed the last one (i.e., no responses are received for the query), then the PE MUST re-advertise the EVPN SMET route with the corresponding version flag reset. If this is the last version flag to be reset, then instead of re-advertising the EVPN route with all version flags reset, the PE MUST withdraw the EVPN route for that (*,G).

Processing at the BGP route receiver:

  1. When a PE receives an EVPN SMET route for a given (,G), it compares the received version flags from the route with its per-PE stored version flags. If the PE finds that a version flag associated with the (,G) for the remote PE is reset, then the PE MUST generate IGMP Leave for that (*,G) toward its local interface (if any), which is attached to the multicast router for that multicast group. It should be noted that the received EVPN route MUST have at least one version flag set. If all version flags are reset, it is an error because the PE should have received an EVPN route withdraw for the last version flag. An error MUST be considered as a BGP error, and the PE MUST apply the "treat-as-withdraw" procedure per [RFC7606].
  2. When a PE receives an EVPN SMET route withdraw, it removes the remote PE from its OIF list for that multicast group, and if there are no more OIF entries for that multicast group (either locally or remotely), then the PE MUST stop responding to Membership Queries from the locally attached router (if any). If there is a source for that multicast group, the PE stops sending multicast traffic for that source.

4.2. Proxy Querier

as mentioned in the previous sections, each PE has to be a proxy querier for the following reasons 💛:

Hmm, that line changed the requirement wording. Correcting it below to keep the original force:

as mentioned in the previous sections, there are a couple of reasons why each PE MUST have proxy querier functionality 💛:

  1. to enable the collection of EVPN PEs providing Layer 2 Virtual Private Network (L2VPN) service to act as a distributed multicast router with an anycast IP address for all attached hosts in that subnet
  2. to enable suppression of IGMP Membership Reports and Membership Queries over MPLS/IP core

5. Operation ✨

Okay so picture this 🎀 an EVPN network (Figure 1) with one EVPN instance running across the PEs: PE1, PE2, and PE3. That instance is one single bridge domain, aka one subnet, and every host, source, and the multicast router are plugged into it. PE1 only has hosts (labeled Hx) hanging off it. PE2 has a mix of hosts and a multicast source. PE3 is the chaos one 💀 with a mix of hosts, a multicast source (labeled Sx), and a multicast router (labeled Rx). For (S1,G1), R1 is the multicast router being used. The subsections below walk through how IGMP Proxy behaves on each PE, depending on whether the devices locally attached to that subnet are:

  • only hosts,
  • a mix of hosts and a multicast source, or
  • a mix of hosts, a multicast source, and a multicast router.
                         +--------------+
                         |              |
                         |              |
                  +----+ |              | +----+
   H1:(*,G1)v2 ---|    | |              | |    |---- H6(*,G1)v2
   H2:(*,G1)v2 ---| PE1| |   IP/MPLS    | | PE2|---- H7(S2,G2)v3
   H3:(*,G1)v3 ---|    | |   Network    | |    |---- S2
   H4:(S2,G2)v3 --|    | |              | |    |
                  +----+ |              | +----+
                         |              |
                  +----+ |              |
   H5:(S1,G1)v3 --|    | |              |
            S1 ---| PE3| |              |
            R1 ---|    | |              |
                  +----+ |              |
                         |              |
                         +--------------+

                       Figure 1: EVPN Network

5.1. PE with Only Attached Hosts for a Given Subnet

When PE1 gets an IGMPv2 Membership Report from H1, it doesn't forward that report out any of its other ports for this subnet, because all of those local ports belong to hosts 🙅‍♀️. Instead, PE1 sends an EVPN SMET route for (*,G1) and sets the v2 flag. PE2 and PE3 both receive this EVPN route, since they're members of the same BD (same EVI for a VLAN-based service, or EVI plus VLAN for a VLAN-aware bundle service) 🦋. PE3 rebuilds the IGMPv2 Membership Report from that BGP route and only sends it out the port(s) with multicast routers attached (for that subnet). In this example, that means PE3 sends the rebuilt report for (*,G1) only to R1. PE2 also gets the EVPN BGP route, but it doesn't send it to any of its subnet ports (the ones tied to H6 and H7). Not on its watch 💅

Now when PE1 gets the second IGMPv2 Membership Report from H2 for the same group (*,G1), it just adds that port to its OIF list. No new EVPN BGP routes get sent, because nothing has changed in the info. But when PE1 gets the IGMPv3 Membership Report from H3 for that same (*,G1), it adds the port to its OIF list AND re-advertises the EVPN SMET route it sent earlier, this time with the v3 and exclude flag set ✨

Finally, when PE1 gets the IGMPv3 Membership Report from H4 for (S2,G2), it advertises a brand new EVPN SMET route for that one 🌸

5.2. PE with a Mix of Attached Hosts and a Multicast Source

The big difference here is that when PE2 gets the IGMPv3 Membership Report from H7 for (S2,G2), it advertises that in BGP anyway to support the source moving 🏃‍♀️, even though PE2 knows S2 is attached to its local AC. PE2 also adds the port tied to H7 to its OIF list for (S2,G2). The IGMPv2 handling for the report from H6 is the same as the IGMPv2 Membership Report we already covered in the previous section 🫶

5.3. PE with a Mix of Attached Hosts, a Multicast Source, and a Router

The main difference in this case, compared to the previous two sections, is that IGMPv2/v3 Membership Reports received locally need to be sent to the port associated with router R1 👑. On top of that, the Membership Reports received via BGP (SMET) need to be passed to the R1 port, but filtered for all the other ports. Main character energy for R1, honestly 😭

6. All-Active Multihoming

Okay this one is a whole thing 🧚 The LAG flow hashing algorithm the CE uses is unknown to the PE, so in an All-Active redundancy mode, you have to assume the CE can send a given IGMP message to any one of the multihomed PEs, whether that PE is the Designated Forwarder (DF) or a non-DF. So different IGMP Membership Request messages can land on different PEs in the redundancy group. And their matching Leave messages can hit PEs that are different from the ones that got the Membership Report 🙈 So all PEs attached to a given Ethernet segment (ES) have to coordinate the IGMP Membership Request and Leave Group (x,G) state, where x is either "*" or a particular source S, for each BD on that ES. Each PE keeps a local copy of that state, and EVPN signaling is what keeps the state synced across PEs. This is what lets the DF for that (ES,BD) correctly advertise or withdraw a SMET route for that (x,G) group in that BD when it needs to. Honestly, the whole point is coordination, bestie 💜 All-Active multihoming PEs for a given ES MUST support the IGMP synchronization procedures described in this section, if they need to do IGMP Proxy for hosts connected to that ES.

6.1. Local IGMP/MLD Membership Report Synchronization

When a PE (DF or non-DF) gets an IGMP Membership Report for (x,G) on a given multihomed ES running in All-Active redundancy mode, it figures out which BD that report belongs to. If the PE doesn't already have the local IGMP Membership Request (x,G) state for that BD on that ES, it MUST instantiate that local state and MUST advertise a BGP IGMP Membership Report Synch route for that (ES,BD). The local IGMP Membership Request (x,G) state is the state created when the PE processes an IGMP Membership Report for (x,G), so it's basically the origin story 🌈

The IGMP Membership Report Synch route MUST carry the ES-Import Route Target (RT) for the ES where the IGMP Membership Report came in. Because of that, it MUST only be imported by the PEs attached to that ES and not by any other PEs 🔒

When a PE (DF or non-DF) receives an IGMP Membership Report Synch route, it installs that route. If it doesn't already have the IGMP Membership Request (x,G) state for that (ES,BD), it MUST instantiate that state. The IGMP Membership Request (x,G) state ends up being the union of the local IGMP Membership Report (x,G) state and the installed IGMP Membership Report Synch route 🧩 And if the DF hasn't already advertised (originated) a SMET route for that (x,G) group in that BD, it MUST do so now.

When a PE (DF or non-DF) deletes its local IGMP Membership Request (x,G) state for that (ES,BD), it MUST withdraw its BGP IGMP Membership Report Synch route for that (ES,BD). Cleanup crew, activate 🧹

When a PE (DF or non-DF) gets the withdrawal of an IGMP Membership Report Synch route from another PE, it MUST remove that route. If a PE has no local IGMP Membership Request (x,G) state and no installed IGMP Membership Report Synch routes, it MUST remove that IGMP Membership Request (x,G) state for that (ES,BD). And if the DF no longer has IGMP Membership Request (x,G) state for that BD on any ES where it's the DF, it MUST withdraw its SMET route for that (x,G) group in that BD. Gone, gone, gone 👋

In other words, a PE advertises a SMET route for that (x,G) group in that BD when it has IGMP Membership Request (x,G) state on at least one ES where it's the DF. It withdraws that SMET route once it has no IGMP Membership Request (x,G) state in that BD on any ES where it's the DF. So basically: it's a vibe check based on the DF status 💅

6.2. Local IGMP/MLD Leave Group Synchronization

When a PE (DF or non-DF) gets an IGMP Leave Group message for (x,G) from the attached CE on a given multihomed ES running in All-Active redundancy mode, it figures out which BD the IGMPv2 Leave Group belongs to. Whether or not it has IGMP Membership Request (x,G) state for that (ES,BD), it kicks off the (x,G) leave group synchronization procedure. That procedure has these steps:

  1. It computes the Maximum Response Time, which is how long the (x,G) leave group synchronization procedure lasts. This is the product of two locally configured values, Last Member Query Count and Last Member Query Interval (described in Section 3 of [RFC2236]), plus a delta for the time it takes a BGP advertisement to travel between the PEs attached to the multihomed ES. (The delta has to be consistently configured on every PE attached to that multihomed ES 🎀)
  2. It starts the Maximum Response Time timer. Quick note: any later IGMP Leave Group messages or BGP Leave Synch routes for (x,G) do NOT reset a timer that's already running, and the PE just ignores them 🙅‍♀️
  3. It starts the Last Member Query procedure described in Section 3 of [RFC2236]. In other words, it sends a number of Group-Specific Query (x,G) messages (the Last Member Query Count) at a fixed interval (the Last Member Query Interval) to the attached CE.
  4. It advertises an IGMP Leave Synch route for that (ES,BD). This route tells the other multihomed PEs on that ES that it has started an (x,G) leave group synchronization procedure. It carries the ES-Import RT for the ES where the IGMP Leave Group came in, and it also contains the Maximum Response Time 📣
  5. When the Maximum Response Time timer expires, the PE that advertised the IGMP Leave Synch route withdraws it. Done and dusted ✨

6.2.1. Remote Leave Group Synchronization

When a PE (DF or non-DF) receives an IGMP Leave Synch route, it installs that route and starts a timer for (x,G) on the specified (ES,BD). The timer is set to the Maximum Response Time from the received IGMP Leave Synch route. Same rule as before, though: if more IGMPv2 Leave Group messages or BGP Leave Synch routes for (x,G) show up while that timer is already running, they don't change its value, and the PE ignores them 🫶

6.2.2. Common Leave Group Synchronization

okay so this is the part where both PEs on a multihomed ES are in the group chat 💅 If a PE attached to the multihomed ES gets an IGMP Membership Report for (x,G) before the Maximum Response Time timer runs out, it advertises a BGP IGMP Membership Report Synch route for that (ES,BD) 🦋 If it doesn't already have the local IGMP Membership Request (x,G) state for that (ES,BD), it creates that local state. If the DF isn't currently advertising (originating) a SMET route for that (x,G) group in that BD, it does so now ✨

If a PE attached to the multihomed ES receives an IGMP Membership Report Synch route for (x,G) before the Maximum Response Time timer expires, it installs that route. If it doesn't already have the IGMP Membership Request (x,G) state for that BD on that ES, it creates that state too 🫶 If the DF hasn't already advertised (originated) a SMET route for that (x,G) group in that BD, it does so now. Main character energy from the DF, honestly 👑

When the Maximum Response Time timer expires, a PE that has advertised an IGMP Leave Synch route withdraws it 🧚 Any PE attached to the multihomed ES that started the Maximum Response Time, and that has no local IGMP Membership Request (x,G) state and no installed IGMP Membership Report Synch routes, removes the IGMP Membership Request (x,G) state for that (ES,BD). If the DF no longer has the IGMP Membership Request (x,G) state for that BD on any ES where it is the DF, it withdraws its SMET route for that (x,G) group in that BD 💀

6.3. Mass Withdraw of the Multicast Membership Report Synch Route in Case of Failure

okay this one is a little dramatic 😭 A PE that has received an IGMP Membership Request would have synced the IGMP Membership Report using the procedure in Section 6.1. If a PE holding the local Membership Report state goes down, or the PE to CE link goes down, that leads to a mass withdraw of multicast routes. The remote PEs (the PEs where these routes were remote IGMP Membership Reports) SHOULD NOT remove the state immediately. Instead, General Query SHOULD be generated to refresh the states 🌸 There are a few ways to detect failure at a peer, e.g., using IGP next-hop tracking or ES route withdraw 🔥

7. Single-Active Multihoming ✨

Quick note, bestie: to make state synchronization after failover smooth, the PEs attached to a multihomed ES that's running in Single-Active redundancy mode SHOULD also coordinate the IGMP Membership Report (x,G) state 🎀 In this setup, all IGMP Membership Report messages are received by the DF and then distributed to the non-DF PEs using the procedures described above. The DF is the one doing the heavy lifting here 💜

8. Selective Multicast Procedures for IR Tunnels

(Covered earlier, so we're moving right along 💖)

9. BGP Encoding

okay this is where it gets really fun 🦋 This document defines three new BGP EVPN routes to carry IGMP Membership Reports. The route types are:

6 -  Selective Multicast Ethernet Tag Route
7 -  Multicast Membership Report Synch Route
8 -  Multicast Leave Synch Route

The detailed encoding and procedures for these route types are described in the subsequent sections 🌈

9.1. Selective Multicast Ethernet Tag Route

the SMET route-type-specific EVPN NLRI is made up of the following fields 🧚

                 +---------------------------------------+
                 |  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) |
                 +---------------------------------------+
                 |  Flags (1 octet)                      |
                 +---------------------------------------+

For BGP route key processing, all of these fields count as part of the prefix in the NLRI, except for the 1-octet Flags field. The Flags field is laid out like this 💅

                           0  1  2  3  4  5  6  7
                         +--+--+--+--+--+--+--+--+
                         | reserved  |IE|v3|v2|v1|
                         +--+--+--+--+--+--+--+--+
  • The least significant bit (bit 7) indicates support for IGMP version 1. Since IGMPv1 is being deprecated, the sender MUST set it to 0 for IGMP, and the receiver MUST ignore it 💀
  • The second least significant bit (bit 6) indicates support for IGMP version 2 ✨
  • The third least significant bit (bit 5) indicates support for IGMP version 3 🎀
  • The fourth least significant bit (bit 4) indicates whether the (S,G) information carried in the route type is of an Include Group type (bit value 0) or an Exclude Group type (bit value 1). The Exclude Group type bit MUST be ignored if bit 5 is not set 🙈
  • This EVPN route type carries tenant IGMP multicast group information. The Flags field helps distribute the IGMP Membership Report of a given host for a given multicast route. The version bits help associate the IGMP version of the receivers participating in the EVPN domain 🍓
  • The IE bit helps create filters for a given multicast route 🦋
  • If the route is used for IPv6 (MLD), then bit 7 indicates support for MLD version 1. The second least significant bit (bit 6) indicates support for MLD version 2. Since there is no MLD version 3, for IPv6 routes the third least significant bit MUST be 0. For IPv6 routes, the fourth least significant bit MUST be ignored if bit 6 is not set 🌸
  • Reserved bits MUST be set to 0 by the sender, and the receiver MUST ignore the Reserved bits 🫶

9.1.1. Constructing the Selective Multicast Ethernet Tag Route

This section walks through how to build the SMET route 🧁

The Route Distinguisher (RD) SHOULD be a Type 1 RD [RFC4364]. Its value field holds an IP address of the PE (typically the loopback address), followed by a number that is unique to the PE 🌈

The Ethernet Tag ID MUST be set, following the procedure defined in [RFC7432] 💜

The Multicast Source Length MUST be set to the length of the Multicast Source Address in bits. If the Multicast Source Address field contains an IPv4 address, the Multicast Source Length is 32. If it contains an IPv6 address, the Multicast Source Length is 128. For a (*,G) Membership Report, the Multicast Source Length is set to 0 🙈

The Multicast Source Address is the source IP address from the IGMP Membership Report. For a (*,G) Membership Report, this field isn't used ✨

The Multicast Group Length MUST be set to the length of the Multicast Group Address in bits. If the Multicast Group Address field contains an IPv4 address, the Multicast Group Length is 32. If it contains an IPv6 address, the Multicast Group Length is 128 🦋

The Multicast Group Address is the group address from the IGMP or MLD Membership Report 🎀

The Originator Router Length is the length of the Originator Router Address in bits 🧚

The Originator Router Address is the IP address of the router originating this route. The SMET Originator Router IP address MUST match that of the IMET (or S-PMSI Authentic Data (AD)) route originated for the same EVI by the same downstream PE 🔥

The Flags field indicates the version of IGMP from which the Membership Report was received. It also indicates whether the multicast group had the Include/Exclude bit set 💅

Reserved bits MUST be set to 0. They can be defined by other documents in the future 🫶

IGMP is used to receive group membership information from hosts by Top-of-the-Rack (ToR) switches. When a host expresses interest in a particular group membership, this information is forwarded using the SMET route. The NLRI also keeps track of the receiver's IGMP version and any source filtering for a given group membership 🌸 All EVPN SMET routes are announced per EVI Route Target extended communities (EVI-RT ECs) 👑

9.1.2. Reconstructing IGMP/MLD Membership Reports from the Selective Multicast Route

This section explains how to rebuild IGMP/MLD Membership Reports from the SMET route 💖

  • If the Multicast Group Length is 32, the route is translated to an IGMP Membership Request. If the Multicast Group Length is 128, the route is translated to an MLD Membership Request 🧚
  • The Multicast Group Address field is translated to the IGMP/MLD group address 🌈
  • If the Multicast Source Length is set to 0, it is translated to any source (*). If the Multicast Source Length is non-zero, the Multicast Source Address field is translated to the IGMP/MLD source address 🦋
  • If flag bit 7 is set, the Membership Report is translated to IGMPv1 or MLDv1 🍓
  • If flag bit 6 is set, the Membership Report is translated to IGMPv2 or MLDv2 🫶
  • Flag bit 5 is only valid for the IGMP Membership Report. If it is set, it translates to the IGMPv3 report 🎀
  • If the IE flag is set, it translates to the IGMP/MLD Exclude mode Membership Report. If the IE flag is not set (0), it translates to the Include mode Membership Report 💅

9.1.3. Default Selective Multicast Route 🌸

Okay so, if there's a multicast router hanging out behind the EVPN domain, the PE MAY originate a default SMET ((*,*)) to grab all the multicast traffic in the domain. 💖

                             +--------------+
                             |              |
                             |              |
                             |              | +----+
                             |              | |    |---- H1(*,G1)v2
                             |   IP/MPLS    | | PE1|---- H2(S2,G2)v3
                             |   Network    | |    |---- S2
                             |              | |    |
                             |              | +----+
                             |              |
                      +----+ |              |
      +----+          |    | |              |
      |    |    S1 ---| PE2| |              |
      |PIM |----R1 ---|    | |              |
      |ASM |          +----+ |              |
      |    |                 |              |
      +----+                 +--------------+

             Figure 2: Multicast Router behind the EVPN Domain

Let's look at Figure 2, where there's an EVPN instance configured across the PEs. Say PE2 is connected to multicast router R1, and there's a PIM ASM network running behind R1. If there are receivers behind that PIM ASM network, the PIM Join gets forwarded to the PIM Rendezvous Point (RP). 🦋 Now if those receivers want a multicast flow from multicast source S2 (which sits behind PE1), PE2 needs to receive that multicast traffic. In this situation, PE2 MUST originate a (*,*) SMET route so it can receive all of the multicast traffic in the EVPN domain. ✨ To generate those wildcard (*,*) routes, the procedure from [RFC6625] MUST be used. 🫶

9.2. Multicast Membership Report Synch Route 🧚

This EVPN route type is used to coordinate the IGMP Membership Report (x,G) state for a given BD between the PEs attached to a given ES that's operating in All-Active (or Single-Active) redundancy mode. It's made up of the following fields: 👑

        +--------------------------------------------------+
        |  RD (8 octets)                                   |
        +--------------------------------------------------+
        |  Ethernet Segment Identifier (10 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)            |
        +--------------------------------------------------+
        |  Flags (1 octet)                                 |
        +--------------------------------------------------+

For BGP route key processing, every one of these fields counts as part of the prefix in the NLRI, except for the 1-octet Flags field. The Flags field is laid out like this: 🌈

                       0  1  2  3  4  5  6  7
                     +--+--+--+--+--+--+--+--+
                     | reserved  |IE|v3|v2|v1|
                     +--+--+--+--+--+--+--+--+
  • The least significant bit (bit 7) indicates support for IGMP version 1. 🍓
  • The second least significant bit (bit 6) indicates support for IGMP version 2. 🍓
  • The third least significant bit (bit 5) indicates support for IGMP version 3. 🍓
  • The fourth least significant bit (bit 4) indicates whether the (S, G) information carried within the route type is of an Include Group type (bit value 0) or an Exclude Group type (bit value 1). The Exclude Group type bit MUST be ignored if bit 5 is not set. 💅
  • Reserved bits MUST be set to 0. 🫶

The Flags field helps distribute the IGMP Membership Report of a given host for a given multicast route. ✨ The version bits help associate the IGMP version of receivers participating within the EVPN domain, and the Include/Exclude bit helps create filters for a given multicast route. 🔥

If the route is being prepared for IPv6 (MLD), then bit 7 indicates support for MLD version 1. The second least significant bit (bit 6) indicates support for MLD version 2. Since there's no MLD version 3, the third least significant bit MUST be 0 for an IPv6 route. 🙈 For an IPv6 route, the fourth least significant bit MUST be ignored if bit 6 is not set. 💜

9.2.1. Constructing the Multicast Membership Report Synch Route 🛠️

This section walks through how to build the IGMP Membership Report Synch route. Support for these route types is optional. If a PE doesn't support this route, then it MUST NOT indicate that it supports "IGMP Proxy" in the Multicast Flags Extended Community for the EVIs that correspond to its multihomed ESs. 🙅‍♀️

An IGMP Membership Report Synch route MUST carry exactly one ES-Import Route Target extended community, the one that corresponds to the ES where the IGMP Membership Report was received. It MUST also carry exactly one EVI-RT EC, the one that corresponds to the EVI where the IGMP Membership Report was received. See Section 9.5 for details on how to encode and construct the EVI-RT EC. 💖

The RD SHOULD be Type 1 [RFC4364]. Its value field holds an IP address of the PE (typically, the loopback address), followed by a number that's unique to the PE. 🌸

The Ethernet Segment Identifier (ESI) MUST be set to the 10-octet value defined for the ES. 🦋

The Ethernet Tag ID MUST be set, following the procedure defined in [RFC7432]. ✨

The Multicast Source Length MUST be set to the length of the Multicast Source Address in bits. If the Multicast Source field contains an IPv4 address, the Multicast Source Length is 32. If the Multicast Source field contains an IPv6 address, the Multicast Source Length is 128. For a (*,G) Membership Report, the Multicast Source Length is set to 0. 🧚

The Multicast Source is the source IP address of the IGMP Membership Report. For a (*,G) Membership Report, this field doesn't exist at all. 🙈

The Multicast Group Length MUST be set to the length of the Multicast Group Address in bits. If the Multicast Group field contains an IPv4 address, the Multicast Group Length is 32. If the Multicast Group field contains an IPv6 address, the Multicast Group Length is 128. 👑

The Multicast Group is the group address of the IGMP Membership Report. 🌈

The Originator Router Length is the length of the Originator Router Address in bits. 🍓

The Originator Router Address is the IP address of the router originating the prefix. 💜

The Flags field indicates the version of IGMP that the Membership Report was received from. It also indicates whether the multicast group had the Include/Exclude bit set. 🔥

Reserved bits MUST be set to 0. 💅

9.2.2. Reconstructing IGMP/MLD Membership Reports from a Multicast Membership Report Synch Route 🔄

This section covers how to rebuild IGMP/MLD Membership Reports from a Multicast Membership Report Synch route. 🫶

  • If the Multicast Group Length is 32, the route gets translated into an IGMP Membership Request. If the Multicast Group Length is 128, the route gets translated into an MLD Membership Request. 🦋
  • The Multicast Group Address field gets translated into the IGMP/MLD group address. ✨
  • If the Multicast Source Length is set to 0, it gets translated into any source (*). If the Multicast Source Length is non-zero, the Multicast Source Address field gets translated into the IGMP/MLD source address. 🧚
  • If flag bit 7 is set, the Membership Report gets translated into IGMPv1 or MLDv1. 🍓
  • If flag bit 6 is set, the Membership Report gets translated into IGMPv2 or MLDv2. 🍓
  • Flag bit 5 is only valid for the IGMP Membership Report. If it's set, it translates into the IGMPv3 report. 👑
  • If the IE flag is set, it translates into the IGMP/MLD Exclude mode Membership Report. If the IE flag isn't set (0), it translates into the Include mode Membership Report. 💅

9.3. Multicast Leave Synch Route ✨

okay bestie, this EVPN route type is how PEs keep the IGMP Leave Group (x,G) state in sync for a given BD. It works between all the PEs attached to the same ES, whether that ES is running in All-Active or Single-Active redundancy mode 🫶 Here's the layout:

           +--------------------------------------------------+
           |  RD (8 octets)                                   |
           +--------------------------------------------------+
           |  Ethernet Segment Identifier (10 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)            |
           +--------------------------------------------------+
           |  Reserved (4 octets)                             |
           +--------------------------------------------------+
           |  Maximum Response Time (1 octet)                 |
           +--------------------------------------------------+
           |  Flags (1 octet)                                 |
           +--------------------------------------------------+

Now, for BGP route key processing, everything counts as part of the prefix in the NLRI except the Reserved, Maximum Response Time, and 1-octet Flags fields 🎀 Those three have their own little rules, and the Flags field looks like this:

 0  1  2  3  4  5  6  7
+--+--+--+--+--+--+--+--+
| reserved  |IE|v3|v2|v1|
+--+--+--+--+--+--+--+--+
  • The least significant bit (bit 7) indicates support for IGMP version 1. 💖
  • The second least significant bit (bit 6) indicates support for IGMP version 2. 💖
  • The third least significant bit (bit 5) indicates support for IGMP version 3. 💖
  • The fourth least significant bit (bit 4) indicates whether the (S, G) information carried within the route type is of an Include Group type (bit value 0) or an Exclude Group type (bit value 1). The Exclude Group type bit MUST be ignored if bit 5 is not set. 🙈
  • Reserved bits MUST be set to 0. They can be defined by other documents in the future. 🌸

The Flags field is what helps distribute a host's IGMP Membership Report for a given multicast route 🧚 The version bits tell you which IGMP version the receivers in the EVPN domain are using, and the Include/Exclude bit is what helps build the filters for that route. Literally so useful.

If the route is for IPv6 (MLD), then bit 7 indicates support for MLD version 1, and the second least significant bit (bit 6) indicates support for MLD version 2. There's no MLD version 3, so for an IPv6 route the third least significant bit MUST be 0. Also for IPv6, the fourth least significant bit MUST be ignored if bit 6 is not set 🦋

Reserved bits in the flag MUST be set to 0. They can be defined by other documents in the future. 🫶

9.3.1. Constructing the Multicast Leave Synch Route 🛠️

okay so this section is all about how to build the IGMP Leave Synch route. Support for these route types is optional 💅 But if a PE doesn't support this route, then it MUST NOT indicate that it supports "IGMP Proxy" in the Multicast Flags Extended Community for the EVIs that match its multihomed Ethernet segments. No cap, that would be a mismatch 💀

An IGMP Leave Synch route MUST carry exactly one ES-Import Route Target extended community, which is the one for the ES where the IGMP Leave came in. It MUST also carry exactly one EVI-RT EC, the one for the EVI where the IGMP Leave came in. Check Section 9.5 for how to form the EVI-RT EC 🔥

The RD SHOULD be Type 1 [RFC4364]. Its value field is an IP address of the PE (usually the loopback address), followed by a number that's unique to that PE 🌈

The ESI MUST be set to the 10-octet value defined for the ES ✨

The Ethernet Tag ID MUST be set, following the procedure defined in [RFC7432] 🎀

The Multicast Source Length MUST be set to the length of the Multicast Source Address in bits. If the Multicast Source field has an IPv4 address, the length is 32. If it has an IPv6 address, the length is 128. For a (*,G) Membership Report, the Multicast Source Length is set to 0 🌸

The Multicast Source is the source IP address of the IGMP Membership Report. For a (*,G) Membership Report, this field doesn't exist at all 🙈

The Multicast Group Length MUST be set to the length of the Multicast Group Address in bits. An IPv4 group address gives you 32, and an IPv6 group address gives you 128 🦋

The Multicast Group is the group address of the IGMP Membership Report 💜

The Originator Router Length is the length of the Originator Router Address in bits 🧚

The Originator Router Address is the IP address of the router that's originating the prefix 🍓

The Reserved field is not part of the route key. The originator MUST set the Reserved field to 0. The receiver SHOULD ignore it, and if it needs to be propagated, it MUST propagate it unchanged 🫶

The Maximum Response Time is the value you use when you send a query, as defined in [RFC2236] ⭐

The Flags field tells you which version of IGMP the Membership Report came from, and whether the multicast group had an Include/Exclude bit set 👑

9.3.2. Reconstructing IGMP/MLD Leave from a Multicast Leave Synch Route 🔁

this is the reverse trip, where we rebuild an IGMP/MLD Leave from the Multicast Leave Synch route 🥹

  • If the Multicast Group Length is 32, the route turns into an IGMP Leave. If the Multicast Group Length is 128, it turns into an MLD Leave. 💖
  • The Multicast Group Address field gets translated into an IGMP/MLD group address. ✨
  • If the Multicast Source Length is 0, it gets translated to any source (*). If the Multicast Source Length is non-zero, the Multicast Source Address field gets translated into the IGMP/MLD source address. 🦋
  • If flag bit 7 is set, the Membership Report gets translated to IGMPv1 or MLDv1. 🌸
  • If flag bit 6 is set, the Membership Report gets translated to IGMPv2 or MLDv2. 🌸
  • Flag bit 5 is only valid for the IGMP Membership Report. If it's set, it translates to the IGMPv3 report. 🧚
  • If the IE flag is set, it translates to the IGMP/MLD Exclude mode Leave. If the IE flag is not set (0), it translates to the Include mode Leave. 💅

9.4. Multicast Flags Extended Community 💜

The Multicast Flags Extended Community is a brand-new EVPN Extended Community 🎀 EVPN Extended Communities are transitive extended communities with a Type Value of 0x06. IANA has assigned 0x09 to the Multicast Flags Extended Community in the "EVPN Extended Community Sub-Types" subregistry 🌈

A PE that supports IGMP and/or MLD Proxy on a given BD MUST attach this extended community to the IMET route it advertises for that BD, and it MUST set the IGMP and/or MLD Proxy Support flags to 1. Heads up: a PE that's compliant with [RFC7432] won't advertise this extended community, so if it's missing, that just means the advertising PE doesn't support IGMP or MLD Proxies 👀

Advertising this extended community makes multicast tunnel setup from the source PE way more efficient, especially for ingress replication. If an egress PE supports IGMP Proxy but has no interest in a given (x,G), it advertises its IGMP Proxy capability using this extended community, but it does NOT advertise any SMET route for that (x,G). When the source PE (the ingress PE) gets those advertisements, it skips replicating the multicast traffic to that egress PE. It still replicates to the egress PEs that don't advertise the capability, even if they have no interest in that (x,G) 🧠✨

A Multicast Flags Extended Community is an 8-octet value laid out like this:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type=0x06     |Sub-Type=0x09  |     Flags (2 Octets)      |M|I|
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                           Reserved=0                          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The two lowest-order (least significant) bits are the "IGMP Proxy Support" and "MLD Proxy Support" bits (see Section 12.3). The absence of this extended community also means the PE doesn't support IGMP Proxy, and here's the breakdown:

  • The Type is 0x06, which is registered with IANA for EVPN Extended Communities. 🍓
  • The Sub-Type is 0x09. 🍓
  • Flags are 2-octet values. 🦋
    • Bit 15 (shown as I) defines IGMP Proxy Support. A value of 1 means the PE supports IGMP Proxy. A value of 0 means it doesn't. 💖
    • Bit 14 (shown as M) defines MLD Proxy Support. A value of 1 means the PE supports MLD Proxy. A value of 0 means it doesn't. 💖
    • Bits 0 to 13 are reserved for the future. The sender MUST set them to 0, and the receiver MUST ignore them. 🌸
  • Reserved bits are set to 0. The sender MUST set them to 0, and the receiver MUST ignore them. 🌸
🚨 If a router doesn't support this specification, it MUST NOT add the Multicast Flags Extended Community to the BGP route. When a router gets a BGP update where both the M and I flags are 0, it MUST treat that update as malformed. The receiver of such an update MUST ignore the extended community. Bestie, don't skip this one 💀

9.5. EVI-RT Extended Community 🎀

okay so in EVPN, every EVI has one or more Route Targets (RTs), and they're doing two jobs at once 💅

  1. Distribution control: RTs decide where routes go. If a route carries the RT for a particular EVI, it gets distributed to all the PEs where that EVI exists.
  2. EVI identification: once a route reaches a particular PE, the RT tells that PE which EVI the route applies to 🧚

An IGMP Membership Report Synch or IGMP Leave Synch route is tied to one specific combo of ES and EVI 🦋 These routes only need to reach the PEs attached to that ES, so they carry the ES-Import RT for that ES.

BUT 😭 these routes don't go to every PE where the EVI lives, so they can't carry the RT for that EVI. That means when one shows up at a PE, the route's RTs can't tell it which EVI it belongs to. Some other means of associating the route with an EVI must be used. 💜

This document specifies four new ECs that tell you which EVI a route is for, but that have zero effect on where the route gets distributed 🙈 They're called "Type 0 EVI-RT EC", "Type 1 EVI-RT EC", "Type 2 EVI-RT EC", and "Type 3 EVI-RT EC":

  • A Type 0 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xA.
  • A Type 1 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xB.
  • A Type 2 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xC.
  • A Type 3 EVI-RT EC is an EVPN EC (type 6) of sub-type 0xD.

Each IGMP Membership Report Synch or IGMP Leave Synch route MUST carry exactly one EVI-RT EC 🔥 Here's how that EVI-RT EC gets built. Each of these routes comes from receiving an IGMP Membership Report or an IGMP Leave message from a particular BD, and the route is said to be associated with that BD. Every BD has a matching RT that makes sure routes "about" that BD get distributed to all the PEs attached to it 🌸 So say a route is associated with BD1, and the RT for BD1 is RT1. Then:

  • If RT1 is a Transitive Two-Octet AS-specific EC, the EVI-RT EC on the route is a Type 0 EVI-RT EC, and its value field is identical to the value field of RT1.
  • If RT1 is a Transitive IPv4-Address-specific EC, the EVI-RT EC on the route is a Type 1 EVI-RT EC, and its value field is identical to the value field of RT1.
  • If RT1 is a Transitive Four-Octet AS-specific EC, the EVI-RT EC on the route is a Type 2 EVI-RT EC, and its value field is identical to the value field of RT1.
  • If RT1 is a Transitive IPv6-Address-specific EC, the EVI-RT EC on the route is a Type 3 EVI-RT EC, and its value field is identical to the value field of RT1.

Again, because it's super important ✨ an IGMP Membership Report Synch or Leave Synch route MUST carry exactly one EVI-RT EC.

Now the receiving side 👀 Say a PE gets a particular IGMP Membership Report Synch or IGMP Leave Synch route, which we'll call R1, and R1 carries an ES-Import RT that's one of the PE's Import RTs. If R1 has no EVI-RT EC, or more than one, the PE MUST apply the "treat-as-withdraw" procedure per [RFC7606] 💀

Heads up bestie: an EVI-RT EC is NOT a Route Target extended community. It's invisible to the RT Constrain mechanism [RFC4684], and it's not meant to change how BGP propagates routes at all. Don't mix them up 🙅‍♀️

Here's the layout of the EVI-RT EC:

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Type=0x06     |  Sub-Type=n   |       RT associated with EVI  |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             RT associated with the EVI  (cont.)               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The value of n is 0x0A, 0x0B, 0x0C, or 0x0D, matching EVI-RT types 0, 1, 2, or 3 respectively 🧁

9.6. Rewriting of RT ECs and EVI-RT ECs by ASBRs 🌍

Sometimes an ES is attached to a bunch of PEs that aren't all in the same AS, or aren't all run by the same provider 😬 In that case, the RT for a given EVI might be different in each AS. When a route gets passed from AS1 to AS2, an ASBR on the AS1/AS2 border can have a policy that swaps out the EVI RTs for AS1 with the matching EVI RTs for AS2. This is called RT-rewriting 🦋

If an ASBR is set up to do RT-rewriting of the EVI RTs in EVPN routes, it MUST also be set up to do RT-rewriting of the matching EVI-RT extended communities in IGMP Join Synch and IGMP Leave Synch Routes 💖

9.7. BGP Error Handling 🚨

If a received BGP update has Flags that don't match the IGMP/MLD version-X expectation, the PE MUST apply the "treat-as-withdraw" procedure per [RFC7606] 🙃

If a received BGP update is malformed so that BGP route keys can't be extracted, then the BGP update MUST be considered invalid. The receiving PE MUST apply the "session reset" procedure per [RFC7606] 💥

10. IGMP Version 1 Membership Report 📼

This document doesn't go into any detail about IGMPv1 processing 🤷‍♀️ Implementations are expected to only use IGMPv2 and above for IPv4, and MLDv1 and above for IPv6. IGMPv1 routes are considered invalid, and the PE MUST apply the "treat-as-withdraw" procedure per [RFC7606] 🚫

11. Security Considerations 🔐

Okay, this part is SERIOUS bestie, so listen up 🫶 This document describes a way to run IGMP and MLD efficiently on a subnet that's built across multiple PODs or DCs using an EVPN solution. The security considerations for the underlying EVPN and BGP substrates are covered in [RFC7432], and multicast-specific considerations are outlined in [RFC6513] and [RFC6514]. The EVPN plus the associated IGMP Proxy gives you a single broadcast domain, so the same security considerations from IGMPv2 [RFC2236], IGMPv3 [RFC3376], MLD [RFC2710], or MLDv2 [RFC3810] all apply. Main character energy in the security department: take this seriously, periodt 👑⚠️

12. IANA Considerations 🌈

12.1. EVPN Extended Community Sub-Types Registration ✨

IANA has allocated the following codepoints in the "EVPN Extended Community Sub-Types" subregistry under the "Border Gateway Protocol (BGP) Extended Communities" registry 🎀

 +================+====================================+===========+
 | Sub-Type Value | Name                               | Reference |
 +================+====================================+===========+
 | 0x09           | Multicast Flags Extended Community | RFC 9251  |
 +----------------+------------------------------------+-----------+
 | 0x0A           | EVI-RT Type 0                      | RFC 9251  |
 +----------------+------------------------------------+-----------+
 | 0x0B           | EVI-RT Type 1                      | RFC 9251  |
 +----------------+------------------------------------+-----------+
 | 0x0C           | EVI-RT Type 2                      | RFC 9251  |
 +----------------+------------------------------------+-----------+
 | 0x0D           | EVI-RT Type 3                      | RFC 9251  |
 +----------------+------------------------------------+-----------+

        Table 1: EVPN Extended Community Sub-Types Subregistry
                         Allocated Codepoints

12.2. EVPN Route Types Registration 🧚

IANA has allocated the following EVPN route types in the "EVPN Route Types" subregistry 💜

6 -  Selective Multicast Ethernet Tag Route

7 -  Multicast Membership Report Synch Route

8 -  Multicast Leave Synch Route

12.3. Multicast Flags Extended Community Registry 🍓

IANA has created and now maintains a brand-new subregistry called "Multicast Flags Extended Community" under the "Border Gateway Protocol (BGP) Extended Communities" registry. The registration procedure is First Come First Served [RFC8126]. For the 16-bit Flags field, the bits are numbered 0-15, from high order to low order. The registry was initialized like this:

    +======+====================+===========+===================+
    | Bit  | Name               | Reference | Change Controller |
    +======+====================+===========+===================+
    | 0-13 | Unassigned         |           |                   |
    +------+--------------------+-----------+-------------------+
    | 14   | MLD Proxy Support  | RFC 9251  | IETF              |
    +------+--------------------+-----------+-------------------+
    | 15   | IGMP Proxy Support | RFC 9251  | IETF              |
    +------+--------------------+-----------+-------------------+

             Table 2: Multicast Flags Extended Community

13. References 📚

Bestie, the reference list wasn't included in the part of the RFC I was given, so I'm not going to make any up. Sorry, I know, a cliffhanger 😭🙈

13.1. Normative References ✨

Here are the must-read refs, the ones the spec leans on for real. 💅

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2236] Fenner, W., "Internet Group Management Protocol, Version 2", RFC 2236, DOI 10.17487/RFC2236, November 1997, <https://www.rfc-editor.org/info/rfc2236>.

[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <https://www.rfc-editor.org/info/rfc2710>.

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <https://www.rfc-editor.org/info/rfc3376>.

[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <https://www.rfc-editor.org/info/rfc3810>.

[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <https://www.rfc-editor.org/info/rfc4364>.

[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, R., Patel, K., and J. Guichard, "Constrained Route Distribution for Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684, November 2006, <https://www.rfc-editor.org/info/rfc4684>.

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <https://www.rfc-editor.org/info/rfc6513>.

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <https://www.rfc-editor.org/info/rfc6514>.

[RFC6625] Rosen, E., Ed., Rekhter, Y., Ed., Hendrickx, W., and R. Qiu, "Wildcards in Multicast VPN Auto-Discovery Routes", RFC 6625, DOI 10.17487/RFC6625, May 2012, <https://www.rfc-editor.org/info/rfc6625>.

[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015, <https://www.rfc-editor.org/info/rfc7432>.

[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <https://www.rfc-editor.org/info/rfc7606>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

13.2. Informative References 🦋

These are the bonus reads, the deep-dive stuff that's super helpful but not required to get the core ideas. 🧚

[EVPN-BUM] Zhang, Z., Lin, W., Rabadan, J., Patel, K., and A. Sajassi, "Updates on EVPN BUM Procedures", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-bum-procedure-updates-14, 18 November 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-14>.

[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, DOI 10.17487/RFC4541, May 2006, <https://www.rfc-editor.org/info/rfc4541>.

[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.

Acknowledgements ✨

Huge thank-yous to Stephane Litkowski, Jorge Rabadan, Anoop Ghanwani, Jeffrey Haas, Krishna Muddenahally Ananthamurthy, and Swadesh Agrawal for reviewing this and dropping such valuable comments. 🫶

Contributors 💖

Derek Yeung Arrcus Email: derek@arrcus.com

Authors' Addresses 🌸

Here's where to find the authors. Slide into their inbox 💌

Ali Sajassi
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: sajassi@cisco.com
Samir Thoria
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: sthoria@cisco.com
Mankamana Mishra
Cisco Systems
821 Alder Drive
Milpitas, CA 95035
United States of America
Email: mankamis@cisco.com
Keyur Patel
Arrcus
United States of America
Email: keyur@arrcus.com
John Drake
Juniper Networks
Email: jdrake@juniper.net
Wen Lin
Juniper Networks
Email: wlin@juniper.net
📦 where this page comes from