1.1. Terminology

In this document, we make frequent use of the following terminology:¶

OISM:

Optimized Inter-Subnet Multicast. EVPN PEs that follow the procedures of this document will be known as "OISM" Provider Edges (PEs). EVPN PEs that do not follow the procedures of this document will be known as "non-OISM" PEs.¶

IP Multicast Packet:

An IP packet whose IP Destination Address field is a multicast address that is not a link-local address. (Link-local addresses are IPv4 addresses in the 224/24 range and IPv6 addresses in the FF02/16 range.)¶

IP Multicast Frame:

An Ethernet frame whose payload is an IP multicast packet (as defined above).¶

(S,G) Multicast Packet:

An IP multicast packet whose Source IP Address field contains S and whose IP Destination Address field contains G.¶

(S,G) Multicast Frame:

An IP multicast frame whose payload contains S in its Source IP Address field and G in its IP Destination Address field.¶

EVI:

EVPN Instance. An EVPN instance spanning the PE devices participating in that EVPN.¶

BD:

Broadcast Domain. An emulated Ethernet, such that two systems on the same BD will receive each other's link-local broadcasts.¶

Note that EVPN supports service models in which a single EVI contains only one BD and service models in which a single EVI contains multiple BDs. Both types of service models are supported by this document. In all models, a given BD belongs to only one EVI.¶

DF:

Designated Forwarder. As defined in [RFC7432], an Ethernet segment may be multihomed (attached to more than one PE). An Ethernet segment may also contain multiple BDs of one or more EVIs. For each such EVI, one of the PEs attached to the segment becomes that EVI's DF for that segment. Since a BD may belong to only one EVI, we can speak unambiguously of the BD's DF for a given segment.¶

AC:

Attachment Circuit. An AC connects the bridging function of an EVPN PE to an Ethernet segment of a particular BD. ACs are not visible at the Layer 3.¶

If a given Ethernet segment, attached to a given PE, contains n BDs, we say that the PE has n ACs to that segment.¶

L3 Gateway:

An L3 Gateway is a PE that connects an EVPN Tenant Domain to an external multicast domain by performing both the OISM procedures and the Layer 3 multicast procedures of the external domain.¶

PEG:

PIM/EVPN Gateway. An L3 Gateway that connects an EVPN Tenant Domain to an external multicast domain whose Layer 3 multicast procedures are those of PIM [RFC7761].¶

MEG:

MVPN/EVPN Gateway. An L3 Gateway that connects an EVPN Tenant Domain to an external multicast domain whose Layer 3 multicast procedures are those of Multicast VPN (MVPN) [RFC6513] [RFC6514].¶

IPMG:

IP Multicast Gateway. A PE that is used for interworking OISM EVPN PEs with non-OISM EVPN PEs.¶

DR:

Designated Router. A PE that has special responsibilities for handling multicast on a given BD.¶

FHR:

First Hop Router. The FHR is a PIM router [RFC7761] with special responsibilities. It is the first multicast router to see (S,G) packets from source S, and if G is an Any-Source Multicast (ASM) group, the FHR is responsible for sending PIM Register messages to the PIM Rendezvous Point (RP) for group G.¶

LHR:

Last Hop Router. The LHR is a PIM router [RFC7761] with special responsibilities. Generally, it is attached to a LAN, and it determines whether there are any hosts on the LAN that need to receive a given multicast flow. If so, it creates and sends the PIM Join messages that are necessary to receive the flow.¶

EC:

Extended Community. A BGP Extended Communities attribute [RFC4360] [RFC7153] is a BGP path attribute that consists of one or more Extended Communities.¶

RT:

Route Target. A Route Target is a particular kind of BGP Extended Community. A BGP Extended Community consists of a type field, a sub-type field, and a value field. Certain type/sub-type combinations indicate that a particular Extended Community is an RT. RT1 and RT2 are considered to be the same RT if and only if they have the same type, sub-type, and value fields.¶

C- prefix:

In many documents on VPN multicast, the prefix C- appears before any address or wildcard that refers to an address or addresses in a tenant's address space rather than to an address of addresses in the address space of the backbone network. This document omits the C- prefix in many cases where it is clear from the context that the reference is to the tenant's address space.¶

This document also assumes familiarity with the terminology of [RFC4364], [RFC6514], [RFC7432], [RFC7761], [RFC9136], [RFC9251], and [RFC9572].¶

1.2. Background

Ethernet VPN (EVPN) [RFC7432] provides a Layer 2 VPN (L2VPN) solution, which allows an IP or MPLS backbone provider to offer Ethernet service to a set of customers, known as "tenants".¶

In this section (as well as in [RFC9135]), we provide some essential background information on EVPN.¶

1.3. Need for EVPN-Aware Multicast Procedures

Inter-subnet IP multicast among a set of BDs can be achieved, in a non-optimal manner, without any specific EVPN procedures. For instance, if a particular tenant has n BDs among which it wants to send IP multicast traffic, it can simply attach a conventional multicast router to all n BDs. Or more generally, as long as each BD has at least one IP multicast router, and the IP multicast routers communicate multicast control information with each other, conventional IP multicast procedures will work normally, and no special EVPN functionality is needed.¶

However, that technique does not provide optimal routing for multicast. In conventional multicast routing, for a given multicast flow, there is only one multicast router on each BD that is permitted to send traffic of that flow to the BD. If that BD has receivers for a given flow, but the source of the flow is not on that BD, then the flow must pass through that multicast router. This leads to the hairpinning problem described (for unicast) in Appendix A.¶

For example, consider an (S,G) flow that is sourced by a TS S and needs to be received by TSs R1 and R2. Suppose S is on a segment of BD1, R1 is on a segment of BD2, but both are attached to PE1. Also suppose that the tenant has a multicast router attached to a segment of BD1 and to a segment of BD2. However, the segments to which that router is attached are both attached to PE2. Then, the flow from S to R would have to follow the path: S-->PE1-->PE2-->tenant multicast router-->PE2-->PE1-->R1. Obviously, the path S-->PE1-->R would be preferred.¶

                 +---+                      +---+
                 |PE1+----------------------+PE2|
                 +---+-+                  +-+---+
                  | \   \                /  / |
                 BD1 BD2 BD3          BD3 BD2 BD1
                  |   |   |              \  | |
                  S  R1   R2             router

Now suppose that there is a second receiver, R2. R2 is attached to a third BD, BD3. However, it is attached to a segment of BD3 that is attached to PE1. And suppose that the tenant multicast router is attached to a segment of BD3 that attaches to PE2. In this case, the tenant multicast router will make two copies of the packet, one for BD2 and one for BD3. PE2 will send both copies back to PE1. Not only is the routing sub-optimal, but PE2 also sends multiple copies of the same packet to PE1, which is a further sub-optimality.¶

This is only an example; many more examples of sub-optimal multicast routing can easily be given. To eliminate sub-optimal routing and extra copies, it is necessary to have a multicast solution that is EVPN-aware and that can use its knowledge of the internal structure of a Tenant Domain to ensure that multicast traffic gets routed optimally. The procedures in this document allow us to avoid all such sub-optimalities when routing inter-subnet multicast traffic within a Tenant Domain.¶

1.4. Additional Requirements That Must Be Met by the Solution

In addition to providing optimal routing of multicast flows within a Tenant Domain, the EVPN-aware multicast solution is intended to satisfy the following requirements:¶

• The solution must integrate well with the procedures specified in [RFC9251]. That is, an integrated set of procedures must handle both intra-subnet multicast and inter-subnet multicast.¶

• With regard to intra-subnet multicast, the solution MUST maintain the integrity of the multicast Ethernet service. This means:¶

  • If a source and a receiver are on the same subnet, the MAC Source Address (SA) of the multicast frame sent by the source will not get rewritten.¶

  • If a source and a receiver are on the same subnet, no IP processing of the Ethernet payload is done. The IP TTL is not decremented, the IPv4 header checksum is not changed, no fragmentation is done, etc.¶

• On the other hand, if a source and a receiver are on different subnets, the frame received by the receiver will not have the MAC Source Address of the source, as the frame will appear to have come from a multicast router. Also, proper processing of the IP header is done, e.g., TTL decrements by 1, header checksum modification, possible fragmentation, etc.¶

• If a Tenant Domain contains several BDs, it MUST be possible for a multicast flow (even when the multicast group address is an ASM address) to have sources in one of those BDs and receivers in one or more of the other BDs without requiring the presence of any system performing PIM RP functions [RFC7761].¶

• Sometimes a MAC address used by one TS on a particular BD is also used by another TS on a different BD. Inter-subnet routing of multicast traffic MUST NOT make any assumptions about the uniqueness of a MAC address across several BDs.¶

• If two EVPN PEs attached to the same Tenant Domain both support the OISM procedures, each may receive inter-subnet multicasts from the other, even if the egress PE is not attached to any segment of the BD from which the multicast packets are being sourced. It MUST NOT be necessary to provision the egress PE with knowledge of the ingress BD.¶

• There must be a procedure that allows EVPN PE routers supporting OISM procedures to send/receive multicast traffic to/from EVPN PE routers that support only [RFC7432] but that does not support the OISM procedures or even the procedures of [RFC9135]. However, when interworking with such routers (which we call "non-OISM PE routers"), optimal routing may not be achievable.¶

• It MUST be possible to support scenarios in which multicast flows with sources inside a Tenant Domain have external receivers, i.e., receivers that are outside the domain. It must also be possible to support scenarios where multicast flows with external sources (sources outside the Tenant Domain) have receivers inside the domain.¶

  This presupposes that unicast routes to multicast sources outside the domain can be distributed to EVPN PEs attached to the domain and that unicast routes to multicast sources within the domain can be distributed outside the domain.¶

  Of particular importance are the scenarios in which the external sources and/or receivers are reachable via L3VPN/MVPN or via IP/PIM.¶

  The solution for external interworking MUST allow for deployment scenarios in which EVPN does not need to export a host route for every multicast source.¶

• The solution for external interworking must not presuppose that the same tunneling technology is used within both the EVPN domain and the external domain. For example, MVPN interworking must be possible when MVPN is using MPLS Point-to-Multipoint (P2MP) tunneling and when EVPN is using Ingress Replication (IR) or Virtual eXtensible Local Area Network (VXLAN) tunneling.¶

• The solution must not be overly dependent on the details of a small set of use cases but must be adaptable to new use cases as they arise. (That is, the solution must be robust.)¶

1.5. Model of Operation: Overview

2.1. Supplementary Broadcast Domain

Suppose a given Tenant Domain contains three BDs (BD1, BD2, and BD3) and two PEs (PE1 and PE2). PE1 attaches to BD1 and BD2, while PE2 attaches to BD2 and BD3.¶

To carry out the procedures described above, all the PEs attached to the Tenant Domain must be provisioned with the SBD for that Tenant Domain. An RT must be associated with the SBD and provisioned on each of those PEs. We will refer to that RT as the "SBD-RT".¶

A Tenant Domain is also configured with an IP-VRF [RFC9135], and the IP-VRF is associated with an RT. This RT MAY be the same as the SBD-RT.¶

Suppose an (S,G) multicast frame originating on BD1 has a receiver on BD3. PE1 will transmit the packet to PE2 as a frame, and the encapsulation will identify the frame's source BD as BD1. Since PE2 is not provisioned with BD1, it will treat the packet as if its source BD were the SBD. That is, a packet can be transmitted from BD1 to BD3 even though its ingress PE is not configured for BD3 and/or its egress PE is not configured for BD1.¶

EVPN supports service models in which a given EVI can contain only one BD. It also supports service models in which a given EVI can contain multiple BDs. No matter which service model is being used for a particular tenant, it is highly RECOMMENDED that an EVI containing only the SBD be provisioned for that tenant.¶

If, for some reason, it is not feasible to provision an EVI that contains only the SBD, it is possible to put the SBD in an EVI that contains other BDs. However, in that case, the SBD-RT MUST be different than the RT associated with any other BD. Otherwise, the procedures of this document (as detailed in Sections 2.2 and 3.1) will not produce correct results.¶

2.2. Detecting When a Route is for/from a Particular BD

In this document, we frequently say that a particular multicast route is "from" or "for" a particular BD or is "related to" or "associated with" a particular BD. These terms are used interchangeably. Subsequent sections of this document explain when various routes must be originated for particular BDs. In this section, we explain how the PE originating a route marks the route to indicate which BD it is for. We also explain how a PE receiving the route determines which BD the route is for.¶

In EVPN, each BD is assigned an RT. An RT is a BGP Extended Community that can be attached to the BGP routes used by the EVPN control plane. In some EVPN service models, each BD is assigned a unique RT. In other service models, a set of BDs (all in the same EVI) may be assigned the same RT. The RT that is assigned to the SBD is called the "SBD-RT".¶

In those service models that allow a set of BDs to share a single RT, each BD is assigned a non-zero Tag ID. The Tag ID appears in the Network Layer Reachability Information (NLRI) of many of the BGP routes that are used by the EVPN control plane.¶

A given route may be for the SBD or an ordinary BD (a BD that is not the SBD). An RT that has been assigned to an ordinary BD will be known as an "ordinary BD-RT".¶

When constructing an IMET, SMET, S-PMSI, or Leaf [RFC9572] route that is for a given BD, the following rules apply:¶

• If the route is for an ordinary BD, say BD1, then:¶

  • the route MUST carry the ordinary BD-RT associated with BD1 and¶

  • the route MUST NOT carry any RT that is associated with an ordinary BD other than BD1.¶

• If the route is for the SBD, the route MUST carry the SBD-RT and MUST NOT carry any RT that is associated with any other BD.¶

• As detailed in subsequent sections, under certain circumstances, a route that is for BD1 may carry both the RT of BD1 and also the SBD-RT.¶

The IMET route for the SBD MUST carry a Multicast Flags Extended Community in which an OISM SBD flag is set.¶

The IMET route for a BD other than the SBD SHOULD carry an EVI-RT EC as defined in [RFC9251]. The EC is constructed from the SBD-RT to indicate the BD's corresponding SBD. This allows all PEs to check that they have consistent SBD provisioning and allows an Assisted Replication (AR) replicator to automatically determine a BD's corresponding SBD without any provisioning, as explained in Section 3.2.3.1.¶

When receiving an IMET, SMET, S-PMSI, or Leaf route, it is necessary for the receiving PE to determine the BD to which the route belongs. This is done by examining the RTs carried by the route, as well as the Tag ID field of the route's NLRI. There are several cases to consider. Some of these cases are error cases that arise when the route has not been properly constructed.¶

When one of the error cases is detected, the route MUST be regarded as a malformed route, and the treat-as-withdraw procedure of [RFC7606] MUST be applied. Note that these error cases are only detectable by EVPN procedures at the receiving PE; BGP procedures at intermediate nodes will generally not detect the existence of such error cases and in general SHOULD NOT attempt to do so.¶

Case 1:

The receiving PE recognizes more than one of the route's RTs as being an SBD-RT (i.e., the route carries SBD-RTs of more than one Tenant Domain).¶

This is an error case; the route has not been properly constructed.¶

Case 2:

The receiving PE recognizes one of the route's RTs as being associated with an ordinary BD and recognizes one of the route's other RTs as being associated with a different ordinary BD.¶

This is an error case; the route has not been properly constructed.¶

Case 3:

The receiving PE recognizes one of the route's RTs as being associated with an ordinary BD in a particular Tenant Domain and recognizes another of the route's RTs as being associated with the SBD of a different Tenant Domain.¶

This is an error case; the route has not been properly constructed.¶

Case 4:

The receiving PE does not recognize any of the route's RTs as being associated with an ordinary BD in any of its Tenant Domains but does recognize one of the RTs as the SBD-RT of one of its Tenant Domains.¶

In this case, the receiving PE associates the route with the SBD of that Tenant Domain. This association is made even if the Tag ID field of the route's NLRI is not the Tag ID of the SBD.¶

This is a normal use case where either (a) the route is for a BD to which the receiving PE is not attached or (b) the route is for the SBD. In either case, the receiving PE associates the route with the SBD.¶

Case 5:

The receiving PE recognizes exactly one of the RTs as an ordinary BD-RT that is associated with one of the PE's EVIs, say EVI-1. The receiving PE also recognizes one of the RTs as being the SBD-RT of the Tenant Domain containing EVI-1.¶

In this case, the route is associated with the BD in EVI-1 that is identified (in the context of EVI-1) by the Tag ID field of the route's NLRI. (If EVI-1 contains only a single BD, the Tag ID is likely to be zero.)¶

This is the case where the route is for a BD to which the receiving PE is attached, but the route also carries the SBD-RT. In this case, the receiving PE associates the route with the ordinary BD, not with the SBD.¶

Note that according to the above rules, the mapping from BD to RT is a many-to-one or one-to-one mapping. A route that an EVPN PE originates for a particular BD carries that BD's RT, and an EVPN PE that receives the route associates it with a BD as described above. However, RTs are not used only to help identify the BD to which a route belongs; they may also be used by BGP to determine the path along which the route is distributed and to determine which PEs receive the route. There may be cases where it is desirable to originate a route for a particular BD but have that route distributed to only some of the EVPN PEs attached to that BD. Or one might want the route distributed to some intermediate set of systems, where it might be modified or replaced before being propagated further. Such situations are outside the scope of this document.¶

Additionally, there may be situations where it is desirable to exchange routes among two or more different Tenant Domains (EVPN Extranet). Such situations are outside the scope of this document.¶

2.3. Use of IRB Interfaces at Ingress PE

When an (S,G) multicast frame is received from an AC belonging to a particular BD, say BD1:¶

1. The frame is sent unchanged to other EVPN PEs that are interested in (S,G) traffic. The encapsulation used to send the frame to the other EVPN PEs depends on the tunnel type being used for multicast transmission. (For our purposes, we consider IR, AR, and BIER to be tunnel types, even though IR, AR, and BIER do not actually use P2MP tunnels.) At the egress PE, the apparent source BD of the frame can be inferred from the tunnel encapsulation. If the egress PE is not attached to the actual source BD, it will infer that the apparent source BD is the SBD.¶

   Note that the inter-PE transmission of a multicast frame among EVPN PEs of the same Tenant Domain does NOT involve the IRB interfaces as long as the multicast frame was received over an AC attached to one of the Tenant Domain's BDs.¶

2. The frame is also sent up the IRB interface that attaches BD1 to the Tenant Domain's L3 routing instance in this PE. That is, the L3 routing instance, behaving as if it were a multicast router, receives the IP multicast frames that arrive at the PE from its local ACs. The L3 routing instance decapsulates the frame's payload to extract the IP multicast packet, decrements the IP TTL, adjusts the header checksum, and does any other necessary IP processing (e.g., fragmentation).¶

3. The L3 routing instance keeps track of which BDs have local receivers for (S,G) traffic. (A local receiver is a TS, reachable via a local AC, that has expressed interest in (S,G) traffic.) If the L3 routing instance has an IRB interface to BD2, and it knows that BD2 has a LOCAL receiver interested in (S,G) traffic, it encapsulates the packet in an Ethernet header for BD2, putting its own MAC address in the MAC SA field. Then, it sends the packet down the IRB interface to BD2.¶

If a packet is sent from the L3 routing instance to a particular BD via the IRB interface (step 3 in the above list), and if the BD in question is NOT the SBD, the packet is sent ONLY to LOCAL ACs of that BD. If the packet needs to go to other PEs, it has already been sent to them in step 1. Note that this is a change in the IRB interface semantics from what is described in [RFC9135] and Figure 3.¶

If a given locally attached segment is multihomed, existing EVPN procedures ensure that a packet is not sent by a given PE to that segment unless the PE is the DF for that segment. Those procedures also ensure that a packet is never sent by a PE to its segment of origin. Thus, EVPN segment multihoming is fully supported; duplicate delivery to a segment or looping on a segment are thereby prevented without the need for any new procedures to be defined in this document.¶

What if an IP multicast packet is received from outside the Tenant Domain? For instance, perhaps PE1's IP-VRF for a particular Tenant Domain also has a physical interface leading to an external switch, host, or router and PE1 receives an IP multicast packet or frame on that interface, or perhaps the packet is from an L3VPN or a different EVPN Tenant Domain.¶

Such a packet is first processed by the L3 routing instance, which decrements TTL and does any other necessary IP processing. Then, the packet is sent into the Tenant Domain by sending it down the IRB interface to the SBD of that Tenant Domain. This requires encapsulating the packet in an Ethernet header. The MAC SA field will contain the PE's own MAC on the SBD.¶

An IP multicast packet sent by the L3 routing instance down the IRB interface to the SBD is treated as if it had arrived from a local AC, and steps 1-3 are applied. Note that the semantics of sending a packet down the IRB interface to the SBD are thus slightly different than the semantics of sending a packet down other IRB interfaces. IP multicast packets sent down the SBD's IRB interface may be distributed to other PEs, but IP multicast packets sent down other IRB interfaces are distributed only to local ACs.¶

If a PE sends a link-local multicast packet down the SBD IRB interface, that packet will be distributed (as an Ethernet frame) to other PEs of the Tenant Domain but will not appear on any of the actual BDs.¶

2.4. Use of IRB Interfaces at an Egress PE

Suppose an egress EVPN PE receives an (S,G) multicast frame from the frame's ingress EVPN PE. As described above, the packet will arrive as an Ethernet frame over a tunnel from the ingress PE, and the tunnel encapsulation will identify the source BD of the Ethernet frame.¶

We define the notion of the frame's apparent source BD as follows. If the egress PE is attached to the actual source BD, the actual source BD is the apparent source BD. If the egress PE is not attached to the actual source BD, the SBD is the apparent source BD.¶

The egress PE now takes the following steps:¶

1. If the egress PE has ACs belonging to the apparent source BD of the frame, it sends the frame unchanged to any ACs of that BD that have interest in (S,G) packets. The MAC SA of the frame is not modified, and the IP header of the frame's payload is not modified in any way.¶

2. The frame is also sent to the L3 routing instance by being sent up the IRB interface that attaches the L3 routing instance to the apparent source BD. Steps 2 and 3 listed in Section 2.3 are then applied.¶

2.5. Announcing Interest in (S,G)

[RFC9251] defines procedures used by an egress PE to announce its interest in a multicast flow or set of flows. If an egress PE determines it has LOCAL receivers in a particular BD, say BD1, that are interested in a particular set of flows, it originates one or more SMET routes for BD1. Each SMET route specifies a particular (S,G) or (*,G) flow. By originating a SMET route for BD1, a PE is announcing "I have receivers for (S,G) or (*,G) in BD1". Such a SMET route carries the RT for BD1, ensuring that it will be distributed to all PEs that are attached to BD1.¶

The OISM procedures for originating SMET routes differ slightly from those in [RFC9251]. In most cases, the SMET routes are considered to be for the SBD rather than the BD containing local receivers. These SMET routes carry the SBD-RT and do not carry any ordinary BD-RT. Details on the processing of SMET routes can be found in Section 3.3.¶

Since the SMET routes carry the SBD-RT, every ingress PE attached to a particular Tenant Domain will learn of all other PEs (attached to the same Tenant Domain) that have interest in a particular set of flows. Note that a PE that receives a given SMET route does not necessarily have any BDs (other than the SBD) in common with the PE that originates that SMET route.¶

If all the sources and receivers for a given (*,G) are in the Tenant Domain, inter-subnet ASM traffic will be properly routed without requiring any RPs, shared trees, or other complex aspects of multicast routing infrastructure. Suppose, for example, that:¶

• PE1 has a local receiver, on BD1, for (*,G) and¶

• PE2 has a local source, on BD2, for (*,G).¶

PE1 will originate a SMET(*,G) route for the SBD, and PE2 will receive that route, even if PE2 is not attached to BD1. PE2 will thus know to forward (S,G) traffic to PE1. PE1 does not need to do any source discovery. (This does assume that source S does not send the same (S,G) datagram on two different BDs and that the Tenant Domain does not contain two or more sources with the same IP address S. The use of multicast sources that have IP anycast addresses is outside the scope of this document.)¶

If some PE attached to the Tenant Domain does not support [RFC9251], it will be assumed to be interested in all flows. Whether a particular remote PE supports [RFC9251] or not is determined by the presence of the Multicast Flags Extended Community in its IMET route; this is specified in [RFC9251].¶

2.6. Tunneling Frames from Ingress PEs to Egress PEs

[RFC7432] specifies the procedures for setting up and using BUM tunnels. A BUM tunnel is a tunnel used to carry traffic on a particular BD if that traffic is (a) broadcast traffic, (b) unicast traffic with an unknown Destination MAC Address, or (c) Ethernet multicast traffic.¶

This document allows the BUM tunnels to be used as the default tunnels for transmitting IP multicast frames. It also allows a separate set of tunnels to be used, instead of the BUM tunnels, as the default tunnels for carrying IP multicast frames. Let's call these "IP multicast tunnels".¶

When the tunneling is done via IR or via BIER, this difference is of no significance. However, when P2MP tunnels are used, there is a significant advantage to having separate IP multicast tunnels.¶

It is desirable for an ingress PE to transmit a copy of a given (S,G) multicast frame on only one P2MP tunnel. All egress PEs interested in (S,G) packets then have to join that tunnel. If the source BD and PE for an (S,G) frame are BD1 and PE1, respectively, and if PE2 has receivers on BD2 for (S,G), then PE2 must join the P2MP Label Switched Path (LSP) on which PE1 transmits the (S,G) frame. PE2 must join this P2MP LSP even if PE2 is not attached to the source BD, BD1. If PE1 was transmitting the multicast frame on its BD1 BUM tunnel, then PE2 would have to join the BD1 BUM tunnel, even though PE2 has no BD1 Attachment Circuits. This would cause PE2 to pull all the BUM traffic from BD1, most of which it would just have to discard. Thus, it is RECOMMENDED that the default IP multicast tunnels be distinct from the BUM tunnels.¶

Notwithstanding the above, link-local IP multicast traffic MUST always be carried on the BUM tunnels and ONLY on the BUM tunnels. Link-local IP multicast traffic consists of IPv4 traffic with a destination address prefix of 224/24 and IPv6 traffic with a destination address prefix of FF02/16. In this document, the terms "IP multicast packet" and "IP multicast frame" are defined in Section 1.1 so as to exclude link-local traffic.¶

Note that it is also possible to use selective tunnels to carry particular multicast flows (see Section 3.2). When an (S,G) frame is transmitted on a selective tunnel, it is not transmitted on the BUM tunnel or on the default IP multicast tunnel.¶

2.7. Advanced Scenarios

There are some deployment scenarios that require special procedures:¶

1. Some multicast sources or receivers are attached to PEs that support [RFC7432] but do not support this document or [RFC9135]. To interoperate with these non-OISM PEs, it is necessary to have one or more gateway PEs that interface the tunnels discussed in this document with the BUM tunnels of the legacy PEs. This is discussed in Section 5.¶

2. Sometimes multicast traffic originates from outside the EVPN domain or needs to be sent outside the EVPN domain. This is discussed in Section 6. An important special case of this, integration with MVPN, is discussed in Section 6.1.2.¶

3. In some scenarios, one or more of the tenant systems is a PIM router, and the Tenant Domain is used as a transit network that is part of a larger multicast domain. This is discussed in Section 7.¶

3.1. Supplementary Broadcast Domain (SBD) and Route Targets

As discussed in Section 2.1, every Tenant Domain is associated with a single SBD. Recall that a Tenant Domain is defined to be a set of BDs that can freely send and receive IP multicast traffic to/from each other. If an EVPN PE has one or more ACs in a BD of a particular Tenant Domain, and if the EVPN PE supports the procedures of this document, that EVPN PE MUST be provisioned with the SBD of that Tenant Domain.¶

At each EVPN PE attached to a given Tenant Domain, there is an IRB interface leading from the L3 routing instance of that Tenant Domain to the SBD. However, the SBD has no ACs.¶

Each SBD is provisioned with an RT. All the EVPN PEs supporting a given SBD are provisioned with that RT as an import RT. That RT MUST NOT be the same as the RT associated with any other BD.¶

We will use the term "SBD-RT" to denote the RT that has been assigned to the SBD. Routes carrying this RT will be propagated to all EVPN PEs in the same Tenant Domain as the originator.¶

Section 2.2 specifies the rules by which an EVPN PE that receives a route determines whether a received route belongs to a particular ordinary BD or SBD.¶

Section 2.2 also specifies additional rules that must be followed when constructing routes that belong to a particular BD, including the SBD.¶

The SBD SHOULD be in an EVI of its own. Even if the SBD is not in an EVI of its own, the SBD-RT MUST be different than the RT associated with any other BD. This restriction is necessary in order for the rules of Sections 2.2 and 3.1 to work correctly.¶

Note that an SBD, just like any other BD, is associated on each EVPN PE with a MAC-VRF. Per [RFC7432], each MAC-VRF is associated with a Route Distinguisher (RD). When constructing a route that is for an SBD, an EVPN PE will place the RD of the associated MAC-VRF in the Route Distinguisher field of the NLRI. (If the Tenant Domain has several MAC-VRFs on a given PE, the EVPN PE has a choice of which RD to use.)¶

If AR [RFC9574] is used, each AR-REPLICATOR for a given Tenant Domain must be provisioned with the SBD of that Tenant Domain, even if the AR-REPLICATOR does not have any L3 routing instances.¶

3.2. Advertising the Tunnels Used for IP Multicast

The procedures used for advertising the tunnels that carry IP multicast traffic depend upon the type of tunnel being used. If the tunnel type is neither IR, AR, nor BIER, there are procedures for advertising both inclusive tunnels and selective tunnels.¶

When IR, AR, or BIER are used to transmit IP multicast packets across the core, there are no P2MP tunnels. Once an ingress EVPN PE determines the set of egress EVPN PEs for a given flow, the IMET routes contain all the information needed to transport packets of that flow to the egress PEs.¶

If AR is used, the ingress EVPN PE is also an AR-LEAF, and the IMET route coming from the selected AR-REPLICATOR contains the information needed. The AR-REPLICATOR will behave as an ingress EVPN PE when sending a flow to the egress EVPN PEs.¶

If the tunneling technique requires P2MP tunnels to be set up (e.g., RSVP-TE P2MP, Multipoint LDP (mLDP), or PIM), some of the tunnels may be selective tunnels and some may be inclusive tunnels.¶

Selective P2MP tunnels are always advertised by the ingress PE using S-PMSI Auto-Discovery (A-D) routes [RFC9572].¶

For inclusive tunnels, there is a choice between using a BD's ordinary BUM tunnel as the default inclusive tunnel for carrying IP multicast traffic or using a separate IP multicast tunnel as the default inclusive tunnel for carrying IP multicast. In the former case, the inclusive tunnel is advertised in an IMET route. In the latter case, the inclusive tunnel is advertised in a (C-*,C-*) S-PMSI A-D route [RFC9572]. Details may be found in subsequent sections.¶

3.3. Advertising SMET Routes

[RFC9251] allows an egress EVPN PE to express its interest in a particular multicast flow or set of flows by originating a SMET route. The NLRI of the SMET route identifies the flow or set of flows as (C-*,C-*), (C-*,C-G), or (C-S,C-G).¶

Each SMET route belongs to a particular BD. The Tag ID for the BD appears in the NLRI of the route, and the route carries the RT associated with that BD. From this <RT, tag> pair, other EVPN PEs can identify the BD to which a received SMET route belongs. (Remember though that the route may be carrying multiple RTs.)¶

There are three cases to consider:¶

Case 1:

It is known that no BD of a Tenant Domain contains a multicast router.¶

In this case, an egress PE advertises its interest in a flow or set of flows by originating a SMET route that belongs to the SBD. We refer to this as an SBD-SMET route. The SBD-SMET route carries the SBD-RT and has the Tag ID for the SBD in its NLRI. SMET routes for the individual BDs are not needed, because there is no need for a PE that receives a SMET route to send a corresponding IGMP/MLD Join message on any of its ACs.¶

Case 2:

It is known that more than one BD of a Tenant Domain may contain a multicast router.¶

This is much like Case 1. An egress PE advertises its interest in a flow or set of flows by originating an SBD-SMET route. The SBD-SMET route carries the SBD-RT and has the Tag ID for the SBD in its NLRI.¶

In this case, it is important to be sure that SMET routes for the individual BDs are not originated. For example, suppose that PE1 had local receivers for a given flow on both BD1 and BD2 and that it originated SMET routes for both those BDs. Then, PEs receiving those SMET routes might send IGMP/MLD Joins on both those BDs. This could cause externally sourced multicast traffic to enter the Tenant Domain at both BDs, which could result in duplication of data.¶

Note that if it is possible that more than one BD contains a tenant multicast router, then in order to receive multicast data originating from outside EVPN, the PEs MUST follow the procedures of Section 6.¶

Case 3:

It is known that only a single BD of a Tenant Domain contains a multicast router.¶

Suppose that an egress PE is attached to a BD on which there might be a tenant multicast router. (The tenant router is not necessarily on a segment that is attached to that PE.) And suppose that the PE has one or more ACs attached to that BD, which are interested in a given multicast flow. In this case, in addition to the SMET route for the SBD, the egress PE MAY originate a SMET route for that BD. This will enable the ingress PE(s) to send IGMP/MLD messages on ACs for the BD, as specified in [RFC9251]. As long as that is the only BD on which there is a tenant multicast router, there is no possibility of duplication of data.¶

This document does not specify procedures for dynamically determining which of the three cases applies to a given deployment; the PEs of a given Tenant Domain MUST be provisioned to know which case applies.¶

As detailed in [RFC9251], a SMET route carries flags indicating whether IGMP (v1, v2, or v3) or MLD (v1 or v2) messages should be triggered on the ACs of the BD to which the SMET route belongs. For IGMP v3 and MLD v2, the Include/Exclude (IE) flag also indicates whether the source information in the SMET route is of an Include Group type or Exclude Group type. If an SBD PE needs to generate IGMP/MLD reports (as it is the case in Section 6.2) or the route is for an (S, G) state, the value of the flags MUST be set according to the rules in [RFC9251]. Otherwise, the flags SHOULD be set to 0.¶

Note that a PE only needs to originate the set of SBD-SMET routes that are needed in order to receive multicast traffic that the PE is interested in. Suppose PE1 has ACs attached to BD1 that are interested in (C-*,C-G) traffic and ACs attached to BD2 that are interested in (C-S,C-G) traffic. A single SBD-SMET route specifying (C-*,C-G) will attract all the necessary flows.¶

As another example, suppose the ACs attached to BD1 are interested in (C-*,C-G) but not in (C-S,C-G), while the ACs attached to BD2 are interested in (C-S,C-G). A single SBD-SMET route specifying (C-*,C-G) will pull in all the necessary flows.¶

In other words, to determine the set of SBD-SMET routes that have to be sent for a given C-G, the PE has to merge the IGMP/MLD state for all the BDs (of the given Tenant Domain) to which it is attached.¶

Per [RFC9251], importing a SMET route for a particular BD will cause the IGMP/MLD state to be instantiated for the IRB interface to that BD. This also applies when the BD is the SBD.¶

However, traffic that originates in one of the actual BDs of a particular Tenant Domain MUST NOT be sent down the IRB interface that connects the L3 routing instance of that Tenant Domain to the SBD. That would cause duplicate delivery of traffic, since such traffic will have already been distributed throughout the Tenant Domain. Therefore, when setting up the IGMP/MLD state based on SBD-SMET routes, care must be taken to ensure that the IRB interface to the SBD is not added to the Outgoing Interface (OIF) list if the traffic originates within the Tenant Domain.¶

There are some multicast scenarios that make use of anycast sources. For example, two different sources may share the same anycast IP address, say S1, and each may transmit an (S1,G) multicast flow. In such a scenario, the two (S1,G) flows are typically identical. Ordinary PIM procedures will cause only one of the flows to be delivered to each receiver that has expressed interest in either (*,G) or (S1,G). However, the OISM procedures described in this document will result in both of the (S1,G) flows being distributed in the Tenant Domain, and duplicate delivery will result. Therefore, if there are receivers for (*,G) in a given Tenant Domain, there MUST NOT be anycast sources for G within that Tenant Domain. (This restriction could be lifted by defining additional procedures; however, that is outside the scope of this document.)¶

4.1. Layer 2 Multicast State

An EVPN PE maintains Layer 2 multicast state for each BD to which it is attached. Note that this is used for forwarding IP multicast frames based on the inner IP header. The state is learned through IGMP/MLD snooping [RFC4541] and procedures in this document.¶

Let PE1 be an EVPN PE and BD1 be a BD to which it is attached. At PE1, BD1's Layer 2 multicast state for a given (C-S,C-G) or (C-*,C-G) governs the disposition of an IP multicast packet that is received by BD1's Layer 2 multicast function on an EVPN PE.¶

An IP multicast (S,G) packet is considered to have been received by BD1's Layer 2 multicast function in PE1 in the following cases:¶

• The packet is the payload of an Ethernet frame received by PE1 from an AC that attaches to BD1.¶

• The packet is the payload of an Ethernet frame whose apparent source BD is BD1, which is received by the PE1 over a tunnel from another EVPN PE.¶

• The packet is received from BD1's IRB interface (i.e., has been transmitted by PE1's L3 routing instance down BD1's IRB interface).¶

According to the procedures of this document, all transmissions of IP multicast packets from one EVPN PE to another are done at Layer 2. That is, the packets are transmitted as Ethernet frames, according to the Layer 2 multicast state.¶

Each Layer 2 multicast state (S,G) or (*,G) contains a set of outgoing interfaces (an OIF list). The disposition of an (S,G) multicast frame received by BD1's Layer 2 multicast function is determined as follows:¶

• The OIF list is taken from BD1's Layer 2 (S,G) state, or if there is no such (S,G) state, then it is taken from BD1's (*,G) state. (If neither state exists, the OIF list is considered to be null.)¶

• The rules of Section 4.1.2 are applied to the OIF list. This will generally result in the frame being transmitted to some, but not all, elements of the OIF list.¶

Note that there is no Reverse Path Forwarding (RPF) check at Layer 2.¶

4.2. Layer 3 Forwarding State

If an EVPN PE is performing IGMP/MLD procedures on the ACs of a given BD, it processes those messages at Layer 2 to help form the Layer 2 multicast state. It also sends those messages up that BD's IRB interface to the L3 routing instance of a particular Tenant Domain. This causes the (C-S,C-G) or (C-*,C-G) L3 state to be created/updated.¶

A Layer 3 multicast state has both an Input Interface (IIF) and an OIF list.¶

For a (C-S,C-G) state, if the source BD is present on the PE, the IIF is set to the IRB interface that attaches to that BD. Otherwise, the IIF is set to the SBD IRB interface.¶

For (C-*,C-G) states, traffic can arrive from any BD, so the IIF needs to be set to a wildcard value meaning "any IRB interface".¶

The OIF list of these states includes one or more of the IRB interfaces of the Tenant Domain. In general, maintenance of the OIF list does not require any EVPN-specific procedures. However, there is one EVPN-specific rule:¶

If the IIF is one of the IRB interfaces (or the wildcard meaning "any IRB interface"), then the SBD IRB interface MUST NOT be added to the OIF list. Traffic originating from within a particular EVPN Tenant Domain must not be sent down the SBD IRB interface, as such traffic has already been distributed to all EVPN PEs attached to that Tenant Domain.¶

Please also see Section 6.1.1, which states a modification of this rule for the case where OISM is interworking with external Layer 3 multicast routing.¶

5.1. IPMG Designated Forwarder

Every PE that is eligible for selection as an IPMG-DF for a particular BD originates both an IMET route for that BD and an SBD-IMET route. As stated in Section 5, these SBD-IMET routes carry a Multicast Flags EC with the IPMG flag set.¶

These SBD-IMET routes SHOULD also carry a DF Election EC. The DF Election EC and its use is specified in [RFC8584]. When the route is originated, the AC-DF bit in the DF Election EC SHOULD NOT be set. This bit is not used when selecting an IPMG-DF, i.e., it MUST be ignored by the receiver of an SBD-IMET route.¶

In the context of a given Tenant Domain, to select the IPMG-DF for a particular BD, say BD1, the IPMGs of the Tenant Domain perform the following procedures:¶

• From the set of received SBD-IMET routes for the given Tenant Domain, determine the candidate set of PEs that support IPMG functionality for that domain.¶

• From that candidate set, eliminate any PEs from which an IMET route for BD1 has not been received.¶

• Select a DF election algorithm as specified in [RFC8584]. Some of the possible algorithms can be found, e.g., in [RFC8584], [RFC7432], and [EVPN-DF].¶

• Apply the DF election algorithm (see [RFC8584]) to the candidate set of PEs. The winner becomes the IPMG-DF for BD1.¶

Note that even if a given PE supports MEG (Section 6.1.2) and/or PEG (Section 6.1.4) functionality, as well as IPMG functionality, its SBD-IMET routes carry only one DF Election EC.¶

5.2. Ingress Replication

The procedures of this section are used when IR is used to transmit packets from one PE to another.¶

When a non-OISM PE-S transmits a multicast frame from BD-S to another PE, say PE-R, PE-S will use the encapsulation specified in the BD-S IMET route that was originated by PE-R. This encapsulation will include the label that appears in the MPLS Label field of the PTA of the IMET route. If the tunnel type is VXLAN, the label is actually a Virtual Network Identifier (VNI); for other tunnel types, the label is an MPLS label. In either case, the frames are transmitted with a label that was assigned to a particular BD by the PE-R to which the frame is being transmitted.¶

To support OISM/non-OISM interworking, an OISM PE-R MUST originate, for each of its BDs, both an IMET route and an (C-*,C-*) S-PMSI A-D route. Note that even when IR is being used, interworking between OISM and non-OISM PEs requires the OISM PEs to follow the rules of Section 3.2.5.2, as modified below.¶

Non-OISM PEs will not understand S-PMSI A-D routes. So when a non-OISM PE-S transmits an IP multicast frame with a particular source BD to an IPMG, it encapsulates the frame using the label specified in that IPMG's BD-S IMET route. (This is just the procedure of [RFC7432].)¶

The (C-*,C-*) S-PMSI A-D route originated by a given OISM PE will have a PTA that specifies IR.¶

• If MPLS tunneling is being used, the MPLS Label field SHOULD contain a non-zero value, and the LIR flag SHOULD be zero. (The case where the MPLS Label field is zero or the LIR flag is set is outside the scope of this document.)¶

• If the tunnel encapsulation is VXLAN, the MPLS Label field MUST contain a non-zero value, and the LIR flag MUST be zero.¶

When an OISM PE-S transmits an IP multicast frame to an IPMG, it will use the label specified in that IPMG's (C-*,C-*) S-PMSI A-D route.¶

When a PE originates both an IMET route and a (C-*,C-*) S-PMSI A-D route, the values of the MPLS Label field in the respective PTAs must be distinct. Further, each MUST map uniquely (in the context of the originating PE) to the route's BD.¶

As a result, an IPMG receiving an MPLS-encapsulated IP multicast frame can always tell by the label whether the frame's ingress PE is an OISM PE or a non-OISM PE. When an IPMG receives a VXLAN-encapsulated IP multicast frame, it may need to determine the identity of the ingress PE from the outer IP encapsulation; it can then determine whether the ingress PE is an OISM PE or a non-OISM PE by looking at the IMET route from that PE.¶

Suppose an IPMG receives an IP multicast frame from another EVPN PE in the Tenant Domain and the IPMG is not the IPMG-DF for the frame's source BD. Then, the IPMG performs only the ordinary OISM functions; it does not perform the IPMG-specific functions for that frame. In the remainder of this section, when we discuss the procedures applied by an IPMG when it receives an IP multicast frame, we are presuming that the source BD of the frame is a BD for which the IPMG is the IPMG-DF.¶

We have two basic cases to consider: (1) a frame's ingress PE is a non-OISM node and (2) a frame's ingress PE is an OISM node.¶

5.3. P2MP Tunnels

When IR is used to distribute the multicast traffic among the EVPN PEs, the procedures described in Section 5.2 ensure that there will be no duplicate delivery of multicast traffic. That is, no egress PE will ever send a frame twice on any given AC. If P2MP tunnels are being used to distribute the multicast traffic, it is necessary to have additional procedures to prevent duplicate delivery.¶

At the present time, it is not clear that there will be a use case in which OISM nodes need to interwork with non-OISM nodes that use P2MP tunnels. If it is determined that there is such a use case, procedures for P2MP may be specified in a separate document.¶

6.1. Layer 3 Interworking via EVPN OISM PEs

                  src1                       rcvr1
                  |                          |
                  R1           RP            R2

                            PIM/MVPN
                             Domain
                 +---+                      +---+
            -----|GW1|----------------------|GW2|----
                 +---+                      +---+
                  | \ \                    / / |
                  |  \ \                  / /  |
                BD1 BD2 SBD            SBD BD2 BD1

                           EVPN Domain

                        SBD            SBD
                       /                  \
                      /                    \
                 +---+                      +---+
                 |PE1|                      |PE2|
                 +---+                      +---+
                  | \                       / |
                 BD1 BD2                  BD2 BD1
                  |   |                    |  |
                 src2 rcvr2              src3 rcvr3

6.2. Interworking with PIM via an External PIM Router

Section 6.1 describes how to use an OISM PE router as the gateway to a non-EVPN multicast domain when the EVPN Tenant Domain is not being used as an intermediate transit network for multicast. An alternative approach is to have one or more external PIM routers (perhaps operated by a tenant) on one of the BDs of the Tenant Domain. We will refer to this BD as the "gateway BD".¶

In this model:¶

• The EVPN Tenant Domain is treated as a stub network attached to the external PIM routers.¶

• The external PIM routers follow normal PIM procedures and provide the FHR and LHR functionality for the entire Tenant Domain.¶

• The OISM PEs do not run PIM.¶

• There MUST NOT be more than one gateway BD.¶

• If an OISM PE not attached to the gateway BD has interest in a given multicast flow, it conveys that interest, following normal OISM procedures, by originating an SBD-SMET route for that flow.¶

• If a PE attached to the gateway BD receives an SBD-SMET, it may need to generate and transmit a corresponding IGMP/MLD Join on one or more of its ACs. (Procedures for generating an IGMP/MLD Join as a result of receiving a SMET route are given in [RFC9251].) The PE MUST know which BD is the gateway BD and MUST NOT transmit an IGMP/MLD Join to any other BDs. Furthermore, even if a particular AC is part of that BD, the PE SHOULD NOT transmit an IGMP/MLD Join on that AC unless there is an external PIM router attached via that AC.¶

  As a result, IGMP/MLD messages will be received by the external PIM routers on the gateway BD, and those external PIM routers will send PIM Join messages externally as required. Traffic for the given multicast flow will then be received by one of the external PIM routers, and that traffic will be forwarded by that router to the gateway BD.¶

  The normal OISM procedures will then cause the given multicast flow to be tunneled to any PEs of the EVPN Tenant Domain that have interest in the flow. PEs attached to the gateway BD will see the flow as originating from the gateway BD, and other PEs will see the flow as originating from the SBD.¶

• An OISM PE attached to a gateway BD MUST set its Layer 2 multicast state to indicate that each AC to the gateway BD has interest in all multicast flows. It MUST also originate a SMET route for (*,*). The procedures for originating SMET routes are discussed in Section 2.5.¶

  This will cause the OISM PEs attached to the gateway BD to receive all the IP multicast traffic that is sourced within the EVPN Tenant Domain and to transmit that traffic to the gateway BD, where the external PIM routers will receive it. This enables the external PIM routers to perform FHR functions on behalf of the entire Tenant Domain. (Of course, if the gateway BD has a multihomed segment, only the PE that is the DF for that segment will transmit the multicast traffic to the segment.)¶