EVPN Multicast Forwarding for EVPN to EVPN Gateways

This document proposes an EVPN extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains. The extensions are applied in two separate scenarios: EVPN Layer-2 Interconnect EVPN Layer-3 Interconnect In Layer-2 Interconnect scenarios, this document extends the procedures in so that IP Multicast can be forwarded efficiently in Service Gateways that Interconnect two or more EVPN domains. Note that , in sections 4.4 and 4.6, specifies the Service Gateway solution for EVPN layer-2 multi-point services, including the procedures for layer-2 unicast and Broadcast, Unknown unicast and Multicast (BUM) traffic, however, it does not specify procedures to optimize the forwarding of IP Multicast on the Service Gateways that interconnect domains that use EVPN IGMP or MLD proxy procedures. In Layer-3 Interconnect scenarios, this document extends the procedures in , so that Service Gateways that interconnect two or more EVPN layer-3 domains as in for IP unicast traffic can forward Inter-Subnet Multicast traffic efficiently across EVPN layer-3 domains. defines procedures to support efficient Inter-Subnet Multicast forwarding on Service Gateways that interconnect EVPN domains to MVPN or PIM domains . This document completes the procedures to support efficient Inter-Subnet Multicast forwarding on Service Gateways that interconnect EVPN domains to other EVPN domains. In both scenarios, we refer to the Service Gateway that implements this specification as an EVPN to EVPN Gateway (EEG).

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 when, and only when, they appear in all capitals, as shown here. 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 BD, then the Ethernet segment is defined to be operating in All-Active redundancy mode. BD: Broadcast Domain. An EVI may be comprised of one BD (VLAN-based or VLAN Bundle services) or multiple BDs (VLAN-aware Bundle services). This document makes use of the term BD as described in section 1.1.4. BUM traffic: Broadcast, Unknown unicast and Multicast traffic. CE: Customer Edge device, e.g., a host, router, or switch. DF and non-DF: Designated Forwarder and non Designated Forwarder. In an Ethernet Segment, the Designated Forwarder PE or Service Gateway forwards unicast and BUM traffic. The non-Designated Forwarder PE or Service Gateway blocks BUM traffic (if working in All-Active redundancy mode) or unicast and BUM (if working in Single-Active redundancy mode). EEG: EVPN to EVPN Gateway, or a Service Gateway that interconnects two or more EVPN domains for the purpose of forwarding IP Multicast traffic. ES: Ethernet Segment. When a customer site (device or network) is connected to one or more PEs via a set of Ethernet links, then that set of links is referred to as an Ethernet segment. ESI: Ethernet Segment Identifier. A unique non-zero identifier that identifies an Ethernet segment is called an 'Ethernet Segment Identifier'. EVI: An EVPN instance spanning the Provider Edge (PE) devices participating in that EVPN. EVPN domain: two PEs are in the same EVPN domain if they are attached to the same service and the packets between them do not require a data path lookup of the inner frame (e.g., in the BD of a MAC-VRF) in any intermediate router. An Service Gateway in this document interconnects two or more EVPN domains and is configured with a domain identifier per EVPN domain (referred to as EVPN domain-ID). The EVPN domain-ID is encoded in the D-PATH attribute as specified in for Layer-2 interconnect scenarios and in for Layer-3 interconnect scenarios. I-ES: Interconnect Ethernet Segment or a especial Ethernet Segment used to provide multi-homing on Service Gateways that follow the procedures in . IRB: Integrated Routing and Bridging IRB Interface: Integrated Bridging and Routing Interface. A virtual interface that connects the Bridge Table and the IP-VRF on an NVE. IIF: Incoming Interface. Refers to the Layer-3 interface in the IP-VRF that is identified as the one receiving a particular IP Multicast flow. IP-VRF: A VPN Routing and Forwarding table for IP routes on an NVE/PE. The IP routes could be populated by any routing protocol, E.g., EVPN, IP-VPN and BGP PE-CE IP address families. An IP-VRF is also an instantiation of a layer 3 VPN in a PE. MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on a PE. In VLAN-based or VLAN Bundle modes a BD is equivalent to a MAC-VRF. OIF list and OIF entry: Outgoing Interface list or entry. Refers to the list of interfaces or interface entry in the IP-VRF (Layer-3 OIF) or BD (Layer-2 OIF) that are identified as output interfaces for a given multicast group. PE: Provider Edge device. In this document a PE can be a Leaf node in a Data Center or a traditional Provider Edge router in an MPLS network. SBD: Supplementary Broadcast Domain, a especial BD that has an IRB interface to an IP-VRF and it is used in the Optimized Inter-Subnet Multicast model, as described in . SMET route: Selective Multicast Ethernet Tag route, as defined in . 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 BD, then the Ethernet segment is defined to be operating in Single-Active redundancy mode.

This section describes an example of the first use-case for which this document specifies extensions. Consider a pair of multi-homing Service Gateways (EEG1 and EEG2) that interconnect EVPN domain 1:1 and domain 2:2, as illustrated in (with 1:1 and 2:2 being the respective domain-IDs ). In addition to EEG1 and EEG2, PE1 and PE2 are also attached to EVPN domain 1:1 (with 1:1 being the EVPN domain-ID), and PE3, PE4 and PE5 are also attached to domain 2:2. Source S1, Receiver-1, Receiver-2 and Receiver-3 are all connected to the same IP subnet and EVPN Broadcast Domain BD1. For unicast traffic, EEG1 and EEG2 follow the procedures in sections 4.4 and 4.6. In particular, the Interconnect Ethernet Segment I-ES1 is instantiated in EEG1 and EEG2 and determines the redundancy and forwarding of the traffic between the two domains. In this example, EEG1 is the Designated Forwarder and EEG2 the non-Designated Forwarder router in I-ES1. 'Encap1' and 'encap2' in refer to any possible encapsulation that is supported by EVPN and BD1 uses to transmit or receive packets; for instance: MPLS, Segment Routing MPLS (SR-MPLS), VXLAN or SRv6. The procedures in this document apply irrespective of the combination of encapsulations being used in the EVPN domains that the EEG routers are interconnecting. In this scenario, IP Multicast sources and receivers can be attached to either domain and the EEG routers must be able to forward IP Multicast traffic efficiently across domains. PE1, PE2, PE3, PE4 and PE5 follow the procedures of , and they are not aware of the fact that the may be attached to different EVPN domains.

| +---+ | | | +-------+ | +-------+ | | ^ | <--- | | | | SMET EVPN | | SMET | *,G2 IGMP/MLD proxy | *,G2 | PE2 domain 1:1 | | EEG1 v | | +-------------+ +-------------+ | | EEG1 | +- - - - -+ | | +- - - - -+ | EEG2 | +---------+ | encap-1 | | | | encap-1 | +----------+ I-ES1 | +-+-----+-+ | | +-+-----+-+ | I-ES1 - - - - | | | |- - | | | | - - - - DF | | BD1 | | | | BD1 | | non-DF +---------+ | | | | | | +----------+ | | +-+-----+-+ | | +-+-----+-+ | | | | | encap-2 | | | | encap-2 | | | | | +- - - - -+ | | +- - - - -+ | | | +-------------+ +-------------+ | | ^ | ^ | | | | | EVPN | | SMET +--------+ SMET IGMP/MLD proxy | *,G2 | | S1,G2 domain 2:2 | | PE3 | | PE4 | | | | | | | | | | PE3 v v PE4 PE5 | | +-------+ +-------+ +-------+ | | | +---+ | | +---+ | | +---+ | | +-------| |BD1| |-----| |BD1| |------| |BD1| |--------+ | +---+ | | +---+ | | +---+ | +-------+ +-------+ +-------+ join ^ | join ^ | *,G2 | | S1,G2 | | | v | v Receiver-2 Receiver-3 ]]> Suppose S1 (with source IP address S1) sends IP multicast traffic to group G2, and Receiver-1 and Receiver-2 issue an IGMP (or MLD) join (*,G2). Receiver-3 sends an IGMP (or MLD) join (S1,G2). With the extensions in this document: The EEG routers import the EVPN Selective Multicast Ethernet Tag (SMET) routes issued by the PE routers in the domains that they interconnect. They perform a proxy function for the multicast groups learned from the imported SMET routes of a domain and advertise the resulting proxy membership to the other domains through SMET routes, using their own IP address as the Originator IP of the SMET route. As an example in , EEG1 and EEG2 import the SMET routes for (*,G2) and (S1,G2) that they receive from PE3 and PE4, respectively. EEG1 and EEG2 create state for the two groups and the I-ES1 Designated Forwarder, i.e., EEG1, advertises an SMET route for (*,G2) using its own network parameters for the destination domain (EEG1's Originator IP, Route Distinguisher and Route Target of domain 1:1). Although not represented in , the EEG routers also import the SMET route for (*,G2) issued by PE2 in domain 1:1. Upon the OIF creation for PE2, EEG1 triggers the advertisement of an SMET route for (*,G2) into domain 2:2 with its own network parameters in domain 2:2. The EEG routers advertise the minimal set of SMET routes needed to attract traffic for a given multicast group. For example, even if the EEG routers receive SMET routes for both (*,G2) and (S1,G2), EEG1 only advertises an SMET route for (*,G2), as this is the minimal set necessary to receive traffic for any flow destined to G2. The EEG routers do not require the use of Multicast Membership Report Synch or Multicast Leave Synch routes to synchronize the multicast states received via SMET routes from each domain. This is because all EEG routers within a domain import the same set of SMET routes. The EEG routers forward IP multicast traffic between domains in the same way BUM traffic is forwarded in an Interconnect Ethernet Segment in , that is, only the Designated Forwarder EEG forwards IP multicast traffic from sources in one domain to the other domains.

This section describes an example of the second use-case for which this document specifies extensions. Similar to consider a pair of multi-homing Service Gateways (EEG1 and EEG2) that interconnect EVPN domain 1:1 and domain 2:2 that are now EVPN OISM domains for the same tenant, as illustrated in . Note that is an example; the procedures described in this document apply regardless of whether the PEs are connected to the same or different Broadcast Domains. Sources and receivers may be attached to any PE or Broadcast Domain in the network and can reside in either the same or different subnets. The IP-VRF of the EEG routers imports EVPN IP Prefix routes from one domain, install the routes in the IP-VRF and export the routes into EVPN IP Prefix routes into the other domains. In order to do that, the EEG nodes follow the gateway procedures in . The unicast routes in the IP-VRF of the EEG routers are used to create IIF entries in the layer-3 multicast states. In case the same IP prefix is received in two different EVPN IP Prefix routes, one from each EVPN domain, regular best path selection determines what EVPN IP Prefix route is selected and therefore what route is installed and exported into the other domain. The encapsulations used in the EVPN domains can be any possible encapsulation that is supported by EVPN, for instance, MPLS, Segment Routing MPLS (SR-MPLS), VXLAN or SRv6. The procedures in this document apply irrespective of the combinations of encapsulations being used in the EVPN domains that the EEG routers are interconnecting. In this scenario, IP Multicast sources and receivers can be attached to either domain and the EEG routers must be able to forward IP Multicast traffic efficiently across domains. PE1, PE2, PE3, PE4 and PE5 follow the procedures of . We assume PE1 and PE2 are attached to the Supplementary Broadcast Domain SBD1, whereas PE3, PE4 and PE5 are attached to the Supplementary Broadcast Domain SBD2. In this model, existing EVPN OISM PEs are unaware that certain sources or receivers are part of a different EVPN OISM Domain. The existing EVPN OISM nodes run only their standard procedures and are entirely unaware of the remote EVPN OISM domains. Interworking is achieved by having some of the EVPN OISM PEs function as EVPN to EVPN Gateways (EEGs) running OISM procedures in all the domains they interconnect, as detailed in this document.

|SBD1|---+ | | | | +----+| | |+----+ | | | +--------------+ | +-------------+ | | ^ | | | | | EVPN OISM | | SMET +------+ domain 1:1 | | *,G2 | | | EEG1 | | | +---v----+ +--------+ | | EEG1 | +----+ | | +----+ | EEG2 | | DR | |SBD1| | | |SBD1| | non-DR | +----------++------++ ++------++-------------+ ||IP-VRF|| ||IP-VRF|| +-----------------++------++ ++------++-------------------+ | | |SBD2| | | |SBD2| | | | | +----+ | | +----+ | | | +----|---+ +--------+ ^ EVPN OISM | | | domain 2:2 | +-----------+--------+ SMET | | | | S1,G2 | | PE3 ^ | | PE5 PE5 | | +--------------+ | | +--v-----------+ | +---+ +----+| SMET | |+----+ | | | +------|SBD2|| *,G2 | ||SBD2|----+ |---+ | |IP-VRF+----+| PE4 PE4 | |+----+ | | +--+ |+---+ | | +-----------v--+ | |IP-VRF+---+| |S2|--->||BD3|----+ | | +----+| | +------|BD4|| +--+ |+---+ | | +------|SBD2|| | +---+| S2,G3 +--------------+ | |IP-VRF+----+| +--------------+ |+---+ | | join ^ | ||BD3|----+ | S1,G2 | v |+---+ | | Receiver-3 +--------------+ | join ^ | *,G2 | v | Receiver-2 ]]> In the example of , suppose S1 (with source IP address S1) sends IP multicast traffic for group G2, and Receiver-1 and Receiver-2 issue an IGMP (or MLD) join (*,G2). Receiver-3 sends an IGMP (or MLD) join (S1,G2). With the extensions in this document: The EEG routers import the SMET routes issued by the PE routers in the domains that they interconnect. Since the PEs on both domains follow and are attached to the Supplementary Broadcast Domain of their respective OISM domain (SBD1 and SBD2), the EEG routers must be attached to the Supplementary Broadcast Domains of both domains that they interconnect, SBD1 and SBD2. Out of the received SMET routes in one domain, the EEG routers create layer-2 OIF entries in the Supplementary Broadcast Domain of that domain, in addition to layer-3 IIF and OIF entries in the IP-VRF. The procedures to create layer-2 and layer-3 state in the Supplementary Broadcast Domain and IP-VRF of the EEG routers out of SMET routes follow the same procedures as in for MVPN to EVPN Gateways (MEGs), only that the EEGs do not generate MVPN C-multicast routes, but SMET routes to attract the traffic for the group from the other EVPN OISM domain. In case of EEG redundancy, that is, more than one EEG are attached to the same two EVPN OISM domains as in , the EEG routers need to select the Supplementary Broadcast Domain Designated Router (SBD-DR) in each of the SBDs. The procedures to select an SBD-DR are described in . The selected SBD-DR has the First Hop Router function in the Supplementary Broadcast Domain where it is selected. In the example of , if EEG1 is the SBD-DR for SBD2, EEG advertises an SMET route for (*,G2) in order to attract the multicast flow to G2 and forward it to domain 2:2. EEG2 is a non-Designated Router in SBD2, therefore EEG2 does not issue an SMET route for (*,G2) and it does not forward multicast traffic for G2 into domain 2:2 (EEG2 does not add the SBD2 IRB interface to the layer-3 OIF list). The EEG routers distribute the minimum set of SMET routes between domains to attract the traffic for a given multicast group. As an example, in spite of the EEG routers receiving SMETs routes for (*,G2) and (S1,G2), EEG1 (the SBD2 Designated Router) only advertises an SMET route for (*,G2) since that is the minimum set required to attract the traffic for any flow to G2. In the Supplementary Broadcast Domain IRB interface is used in the OIF list only for traffic from external sources. This document extends the procedures so that an EEG router can be attached to multiple SBDs of the same IP-VRF and the Supplementary Broadcast Domain IRB can be added in the OIF list for a group, when the IIF for the group is the IRB of another SBD attached to the same IP-VRF. In the example of , EEG1 adds SBD2 IRB in the layer-3 OIF list for (S1,G2) and SBD1 IRB is the IIF for the same group.

This section provides the specification for EVPN to EVPN Gateways (EEGs) when configured for layer-2 interconnect, as in the use case of . An EEG configured for layer-2 interconnect of two or more domains MUST support the procedures in in sections 4.4 or 4.6 for unicast and BUM traffic forwarding. In addition, this specification uses the concept of the EVPN domain in : An EGG interconnecting two EVPN domains of the same BD "redistributes" EVPN MAC/IP routes and carries out a proxy function for EVPN SMET routes between the domains. In this document, the EEG proxy function for SMET routes refers to importing SMET routes in one domain of the BD, creating OIF entries within that domain, and exporting the SMET routes to the other domain(s) of the BD - provided that no other SMET route for the same multicast group has already been exported. An EEG MUST import SMET routes received for the BD to which the EEG is attached. An "SMET route received for" a BD in this context means that the SMET route has the route target that matches the BD import route target in one of the EVPN domains and it is a valid route based on the SMET definition in . The imported SMET routes create layer-2 OIF entries for a given multicast group in the EVPN domain, and received multicast traffic for that group in a different EVPN domain of the BD will be forwarded using the multicast tree created by the imported EVPN Inclusive Multicast Ethernet Tag routes as in , or the multicast tree created by the EVPN Selective Provider Multicast Service Interface Auto Discovery routes (S-PMSI A-D routes as in ). Upon receiving and importing an SMET route in a domain, an EEG that is not part of an Interconnect Ethernet Segment MUST perform the proxy function for that SMET route into the other domain(s) of the Broadcast Domains, as follows: When doing proxy of SMET routes, the EEG MUST set its own IP address in the Originator IP field of the NLRI and MUST use its own route distinguisher for the domain. An EEG with two domains in the same BD SHOULD use different route distinguishers when exporting routes into different domains and MAY use different route targets for different domains. The proxy SMET route MUST preserve the Ethernet Tag ID, Multicast Source and Group information as well as the Flags of the SMET routes for which it provides the proxy function. The proxy function on the EEG also includes "aggregation" of (S,G) and (*,G) states of the same IGMP/MLD version. That is, when at least one (*,G) for a group G has been imported via SMET route in one domain, only the SMET route for (*,G) is exported to the other domain. The (S,G) SMET routes for the same group G, which specify individual sources, SHOULD NOT be exported to the other domain. In other words, the minimum set of SMET routes for a group and version is distributed between domains. Two or more EEG routers attached to the same two EVPN domains of a BD SHOULD use an Interconnect Ethernet Segment (I-ES) to handle the redundancy and avoid multicast duplication, as follows: Upon receiving and importing SMET routes in a domain, the I-ES Designated Forwarder MUST proxy the SMET routes to the other domain, and forward the multicast traffic between domains, assuming that it has OIF entries for the group in the domain of destination. The non-Designated Forwarder MAY do proxy of the SMET routes but MUST NOT forward multicast traffic between domains as per , irrespective of the existence of OIF entries created by the received SMET routes. The operator can decide, by configuration, whether the non-Designated Forwarder exports SMET routes, depending on the trade-off between additional traffic and faster convergence in case of failure of the Designated Forwarder EEG. In case of two or more EEG routers are attached to the same two EVPN domains of a BD, a control plane loop may be produced if the non-Designated Forwarder does proxy of the received SMET routes from the peer EEG into the other domain. In order to avoid that, the D-PATH attribute SHOULD be used as follows: An EEG doing proxy of SMET routes between domains SHOULD add or modify the D-PATH BGP attribute in the exported SMET route, by prepending the domain-ID of the source domain (domain in which the route is imported). If the EEG is doing proxy of multiple received SMET routes which (some or all) already contain the D-PATH attribute, the resulting proxy SMET route MUST contain the best D-PATH of all the contributing SMET routes. The "best" D-PATH is the shortest D-PATH in terms of number of domain-IDs, where no D-PATH means a length of zero. In case two routes with the same number of domain-IDs are left in the selection, a route with the numerically lowest left-most Domain-ID is preferred. In addition, the EEG prepends the domain-ID indicated in point 'a'. As an example, if EEG1 in receives three SMET routes, route 1 with no D-PATH, route 2 with D-PATH (3:3) and route 3 with D-PATH (4:4,3:3), when doing proxy, EEG1 selects the best D-PATH, i.e., zero length D-PATH, and when exporting into domain 1:1, EEG1 adds the D-PATH with domain 2:2 (as per point 'a'). Upon importing an SMET route, an EEG SHOULD NOT proxy an SMET route into another domain if the route contains a D-PATH with at least one domain-ID that is locally configured in any of the domains of the BD. EVPN Multicast Membership Report Synch or Multicast Leave Synch routes for the Interconnect Ethernet Segment MUST NOT be generated or imported. An EEG router MAY support local sources and receivers attached to the BD. Local sources/receivers are considered to be part of a "local" domain in the BD, as described in for local Attachment Circuits on the Service Gateways. Local receivers sending IGMP/MLD membership reports create OIF entries on the connected EEG, and the EGG MUST do proxy of the state into all the EVPN domains for which the EEG is Designated Forwarder. The EEG MAY do also proxy of the SMET routes into the EVPN domains for which the EEG is non-Designated Forwarder. That is, consider two EEG routers attached to the same two EVPN domains of the same BD as in , and EEG1 being the Designated Forwarder router of the Interconnect Ethernet Segment in the domain 2:2, and a local receiver is attached to EEG2. Assuming EGG2 did not export an SMET for a group G earlier, upon receiving a membership report from the local receiver, EEG2 MUST export an SMET route for G into domain 1:1. EEG2 MAY optionally export an SMET route into domain 2:2. SMET routes exported for local receivers SHOULD include the D-PATH attribute with the domain-ID associated with the local domain. Consider a local source for group G connected to an Interconnect Ethernet Segment non-Designated Forwarder EEG, and a receiver on one of the domains the EEG is interconnecting, e.g., domain 1:1. In this case, the EGG receives an SMET route from domain 1:1 and also from the Designated Forwarder EEG in a different domain. Even if the EEG has OIF entries for domain 1:1, the EEG MUST NOT send multicast traffic to domain 1:1 due to its non-Designated Forwarder state. This prevents the EGG from sending duplicate traffic to the receiver on domain 1:1. Local sources and receivers MAY be attached to Ethernet Segments. In this case, the EGG follows the procedures in for synchronizing multicast state and other procedures. This specification is compatible with section 4 (Warm Standby solution) irrespective of the sources being attached to the same or different EVPN domains.

This section provides the specification for EVPN to EVPN Gateways (EEGs) when configured for layer-3 interconnect, as in the use case of . It is important to note that this specification uses a Supplementary Broadcast Domain (SBD) per domain that the EEG is interconnecting as a way to explain the procedures as simplified as possible, however, any implementation that uses a single SBD per tenant, and produces the same control plane and data plane behavior from an external standpoint, is considered compliant with this document. An EEG configured for layer-3 interconnect of two or more domains MUST support the gateway procedures in section 8, for IP unicast forwarding between two EVPN domains. To differentiate an EVPN domain in from an EVPN domain in a layer-3 interconnect context, this section refers to EVPN domains "of an IP-VRF" on the EEG, as opposed to EVPN domains "of a BD" in . An EEG interconnecting two EVPN domains of the same IP-VRF "redistributes" EVPN IP Prefix (and/or MAC/IP) routes and EVPN SMET routes between the domains. "Redistribution" of SMET routes between domains of the same IP-VRF, in this document, refers to the procedures related to importing the SMET route, programing the associated multicast state in the SBD and exporting the SMET route into a different domain. When performing this redistribution of SMET routes, the EEG exports the minimum set of SMET routes to attract the traffic for a given multicast group. That is, when at least one (*,G) for a group G has been imported via SMET route in one domain, only an SMET route for (*,G) is exported to the other domain and the (S,G) SMET routes for the same group G (but with specific sources) SHOULD NOT be exported to the other domain. An EEG creates one SBD instance per domain the IP-VRF is interconnecting. The SBD concept is specified in , only that this specification allows more than one SBD per IP-VRF on the EEG routers. Each SBD attached to the same IP-VRF SHOULD use different route distinguisher and MAY use a different set of route targets when exporting SMET routes. An SBD imports and exports SMET routes as per the procedures in . Also this document extends so that the SBD IRB can be added to the IP-VRF layer-3 OIF list for a group, when the IIF for the group is the IRB of another SBD attached to the same IP-VRF. An EEG originates an EVPN Inclusive Multicast Ethernet Tag route for each SBD to which the IP-VRF is attached. We refer to these routes as SBD-IMET routes and they include a Multicast Flags Extended Community with the EEG Flag set. In addition, the SBD-IMET routes SHOULD also carry a Designated Election Extended Community, as described in for the SBD-IMET routes on MVPN to EVPN Gateways (MEGs). After collecting all the SBD-IMET routes with the EEG flag set (including the local one), the EEG MUST perform a Designated Router election. The Designated Router election for an SBD: MUST follow the procedures of section 6.1.2.4 MUST be done only among EEGs that are attached to the same set of SBDs. That is, suppose the local EEG is attached to SBD1 and SBD2. Upon receiving an SBD-IMET route for SBD1 from a remote EEG1, EEG1 is considered a candidate Designated Router for SBD1 only if an SBD-IMET route for SBD2 is also received from EEG1. produces a single winner for the SBD, referred to as the SBD-DR (Supplementary Broadcast Domain Designated Router). Upon programming a multicast group G, the SBD-DR in one SBD is responsible for redistributing the SMET route for G received on that SBD into the common set of SBDs of the same IP-VRF (common set to all candidate EEGs which run the election for that SBD). A non-Designated Router for the SBD (non-SBD-DR) MAY redistribute SMET routes between domains but it MUST NOT add the SBD IRB for which it is non-SBD-DR as layer-3 OIF entry. The operator can decide via configuration whether the non-SBD-DR router redistributes SMET routes to other domains. This is a trade-off between attracting unnecessary traffic and speeding up convergence in case of a failure on the SBD-DR. An SBD-DR MUST be selected for each SBD to which the EEG is attached, however, the SBD-DR election MAY be run into only one of the SBDs of the IP-VRF, and the same SBD-DR EEG derived for all SBDs of the IP-VRF. For example, if SBD1 and SBD2 are SBDs of the same IP-VRF in EEG1 and EEG2, an implementation MAY run the SBD-DR election only in the context of SBD1 and extrapolate the result to SBD2. That is, if EEG1 is the SBD-DR for SBD1, EEG1 will be the SBD-DR for SBD2 as well. An implementation that runs the SBD-DR election in only one of the SBDs of the IP-VRF MUST set the EEG Flag and carry the Designated Election Extended Community only in the IMET routes for the SBD(s) that run SBD-DR election. On reception, if an EEG is attached to two (or more) SBDs of the same IP-VRF and receives an IMET per SBD from the redundant EEG, but only one IMET route has the EEG Flag set, the EEG MUST apply the SBD-DR election result to all the SBDs of the IP-VRF. An EEG router MAY support local sources and receivers, that are attached to Broadcast Domains (BDs) that have IRB interfaces into the IP-VRF of the EEG. Procedures for local sources and receivers follow . The MEG (MVPN to EVPN Gateway), PEG (PIM to EVPN Gateway) and EEG (EVPN to EVPN Gateway) procedures MAY be used for the same tenant on the same Service Gateways. This specification is compatible with section 4 (Warm Standby solution) irrespective of the sources being attached to the same or different EVPN domains.

This document extends the procedures of and , in the scenarios described by and . Therefore it inherits all the Security Considerations described in all those specifications. In addition, this document now allows the distribution of SMET routes across EVPN domains, and therefore provides a new tool for an attacker to be able to leak SMET routes into a remote EVPN domain that could not receive SMET routes from a remote domain prior to this specification. An attacker that manages to leak SMET routes into remote domains, may attract multicast traffic that may not be leaked otherwise into the local domain.

This document requests a new Flag in the subregistry called "Multicast Flags Extended Community", under the "Border Gateway Protocol (BGP) Extended Communities" registry, to indicate EEG support along with the IMET routes.