1. Reduce flooding of IGMP/MLD messages: Just like the ARP/Neighbor Discovery (ND) suppression mechanism in EVPN to reduce the flooding of ARP messages over EVPN, it is also desired to have a mechanism to reduce the flooding of IGMP/MLD messages (both Queries and Membership Reports) in EVPN.
2. Distributed anycast multicast proxy: It is desirable for the EVPN network to act as a distributed anycast multicast router with respect to IGMP/MLD Proxy function for all the hosts attached to that subnet.
3. Selective multicast: This describes forwarding multicast traffic over the EVPN network such that it only gets forwarded to the PEs that have interests in the multicast group(s). This document shows how this objective may be achieved when ingress replication is used to distribute the multicast traffic among the PEs. Procedures for supporting selective multicast using Point-to-Multipoint (P2MP) tunnels can be found in [EVPN-BUM].

AC:

Attachment Circuit

All-Active Redundancy Mode:

When all PEs attached to an Ethernet segment are allowed to forward known unicast traffic to/from that Ethernet segment for a given VLAN, then the Ethernet segment is defined to be operating in All-Active redundancy mode.

BD:

Broadcast Domain. As per [RFC 7432], an EVPN instance (EVI) consists of a single BD or multiple BDs. In case of a VLAN bundle and a VLAN-aware bundle service model, an EVI contains multiple BDs. Also, in this document, BD and subnet are equivalent terms.

DC:

Data Center

ES:

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

ESI:

Ethernet Segment Identifier. This is a unique non-zero identifier that identifies an Ethernet segment.

Ethernet Tag:

It identifies a particular broadcast domain, e.g., a VLAN. An EVPN instance consists of one or more broadcast domains.

EVI:

EVPN Instance. This 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, virtual interface, or tunnel.

PE:

Provider Edge

POD:

Point of Delivery

S-PMSI:

Selective P-Multicast Service Interface. This is a conceptual interface for a PE to send customer multicast traffic to some of the PEs in the same VPN.

Single-Active Redundancy Mode:

When only a single PE, among all the PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet segment for a given VLAN, then the Ethernet segment is defined to be operating in Single-Active redundancy mode.

SMET:

Selective Multicast Ethernet Tag

ToR:

Top of Rack

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

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, and 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 should be noted 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 RFC 3376. At the end of the route processing, local and remote group record state MUST be as per Section 5.1 of RFC 3376.

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 [RFC 4541] , 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.

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).

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 [RFC 7606].
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.

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

• 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 ---|    | |              |
               +----+ |              |
                      |              |
                      +--------------+	

1. It computes the Maximum Response Time, which is the duration of the (x,G) leave group synchronization procedure. This is the product of two locally configured values, Last Member Query Count and Last Member Query Interval (described in Section 3 of RFC 2236), plus a delta corresponding to the time it takes for a BGP advertisement to propagate between the PEs attached to the multihomed ES (delta is a consistently configured value on all PEs attached to the multihomed ES).
2. It starts the Maximum Response Time timer. Note that the receipt of subsequent IGMP Leave Group messages or BGP Leave Synch routes for (x,G) do not change the value of a currently running Maximum Response Time timer and are ignored by the PE.
3. It initiates the Last Member Query procedure described in Section 3 of RFC 2236; viz., it sends a number of Group-Specific Query (x,G) messages (Last Member Query Count) at a fixed interval (Last Member Query Interval) to the attached CE.
4. It advertises an IGMP Leave Synch route for that (ES,BD). This route notifies the other multihomed PEs attached to the given multihomed ES that it has initiated an (x,G) leave group synchronization procedure, i.e., it carries the ES-Import RT for the ES on which the IGMP Leave Group was received. It also contains the Maximum Response Time.
5. When the Maximum Response Time timer expires, the PE that has advertised the IGMP Leave Synch route withdraws it.

1. It sends (x,G) traffic to the set of PEs not supporting IGMP or MLD Proxies. This set consists of any PE that has advertised an Inclusive Multicast Ethernet Tag (IMET) route for the BD without a Multicast Flags Extended Community or with a Multicast Flags Extended Community in which neither the IGMP Proxy support nor the MLD Proxy support flags are set.
2. It sends (x,G) traffic to the set of PEs supporting IGMP or MLD Proxies and has listeners for that (x,G) group in that BD. This set consists of any PE that has advertised an IMET route for the BD with a Multicast Flags Extended Community in which the IGMP Proxy support and/or the MLD Proxy support flags are set and that has advertised a SMET route for that (x,G) group in that BD.

6 -

Selective Multicast Ethernet Tag Route

7 -

Multicast Membership Report Synch Route

8 -

Multicast Leave Synch Route

+---------------------------------------+
|  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)                      |
+---------------------------------------+	

  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 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.
• This EVPN route type is used to carry tenant IGMP multicast group information. The Flags field assists in distributing 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.
• The IE bit helps in creating 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, in case of IPv6 routes, the third least significant bit MUST be 0. In case of 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.

• If the Multicast Group Length is 32, the route is translated to the 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, it translates the Membership Report to be IGMPv1 or MLDv1.
• If flag bit 6 is set, it translates the Membership Report to be 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.

+--------------------------------------------------+
|  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)                                 |
+--------------------------------------------------+	

  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.

• If the Multicast Group Length is 32, the route is translated to the 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, it translates the Membership Report to be IGMPv1 or MLDv1.
• If flag bit 6 is set, it translates the Membership Report to be 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.

+--------------------------------------------------+
|  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)                                 |
+--------------------------------------------------+

  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.

• If the Multicast Group Length is 32, the route is translated to IGMP Leave. If the Multicast Group Length is 128, the route is translated to MLD Leave.
• The Multicast Group Address field is translated to an 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, it translates the Membership Report to be IGMPv1 or MLDv1.
• If flag bit 6 is set, it translates the Membership Report to be 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 Leave. If the IE flag is not set (0), it translates to the Include mode Leave.

 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 Type is 0x06, as 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. The value of 1 for bit 15 means that the PE supports the IGMP Proxy. The value of 0 for bit 15 means that the PE does not support the IGMP Proxy.
  • Bit 14 (shown as M) defines MLD Proxy Support. The value of 1 for bit 14 means that the PE supports the MLD Proxy. The value of 0 for bit 14 means that the PE does not support the MLD Proxy.
  • Bits 0 to 13 are reserved for the future. The sender MUST set it to 0, and the receiver MUST ignore it.
• Reserved bits are set to 0. The sender MUST set it to 0, and the receiver MUST ignore it.

1. Distribution control: RTs control the distribution of the routes. If a route carries the RT associated with a particular EVI, it will be distributed to all the PEs on which that EVI exists.
2. EVI identification: Once a route has been received by a particular PE, the RT is used to identify the EVI to which it applies.

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

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

                     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.)               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    

6 -

Selective Multicast Ethernet Tag Route

7 -

Multicast Membership Report Synch Route

8 -

Multicast Leave Synch Route

[RFC2119]

S. Bradner, "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]

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

[RFC2710]

S. Deering, W. Fenner, 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]

B. Cain, S. Deering, I. Kouvelas, B. Fenner, 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]

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

[RFC4364]

E. Rosen, 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]

P. Marques, R. Bonica, L. Fang, L. Martini, R. Raszuk, K. Patel, 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]

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

[RFC6514]

R. Aggarwal, E. Rosen, T. Morin, 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]

E. Rosen, Y. Rekhter, W. Hendrickx, 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]

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

[RFC7606]

E. Chen, J. Scudder, P. Mohapatra, 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]

B. Leiba, "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>.

[EVPN-BUM]

Cisco Systems, , , , , and , "Updates on EVPN BUM Procedures", Internet-Draft draft-ietf-bess-evpn-bum-procedure-updates-14, November 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-14>.

[RFC4541]

M. Christensen, K. Kimball, 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]

M. Cotton, B. Leiba, 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>.

Derek Yeung

Ali Sajassi

Samir Thoria

Mankamana Mishra

Keyur Patel

John Drake

Wen Lin