Internet-Draft EVPN Multicast on EEG April 2023
Rabadan, et al. Expires 30 October 2023 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-rabnic-bess-evpn-mcast-eeg-01
Published:
Intended Status:
Standards Track
Expires:
Authors:
J. Rabadan, Ed.
Nokia
O. Dornon
Nokia
V. Prabhu
Nokia
A. Nichol
Arista
Z. Zhang
Juniper Networks
W. Lin
Juniper Networks

EVPN Multicast Forwarding for EVPN to EVPN Gateways

Abstract

This document proposes an EVPN (Ethernet Virtual Private Network) extension to allow IP multicast forwarding on Service Gateways that interconnect two or more EVPN domains.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 30 October 2023.

Table of Contents

1. Introduction

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:

In Layer-2 Interconnect scenarios, this document extends the procedures in [RFC9251] so that IP Multicast can be forwarded efficiently in Service Gateways that Interconnect two or more EVPN domains. Note that [RFC9014], 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 [I-D.ietf-bess-evpn-irb-mcast], so that Service Gateways that interconnect two or more EVPN layer-3 domains as in [I-D.ietf-bess-evpn-ipvpn-interworking] for IP unicast traffic can forward Inter-Subnet Multicast traffic efficiently across EVPN layer-3 domains. [I-D.ietf-bess-evpn-irb-mcast] defines procedures to support efficient Inter-Subnet Multicast forwarding on Service Gateways that interconnect EVPN domains to MVPN [RFC6513] [RFC6514] or PIM domains [RFC7761]. 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).

1.1. Terminology and Conventions

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

  • 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.
  • 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 [I-D.ietf-bess-evpn-irb-mcast] 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).
  • 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 [I-D.sr-bess-evpn-dpath] for Layer-2 interconnect scenarios and in [I-D.ietf-bess-evpn-ipvpn-interworking] for Layer-3 interconnect scenarios.
  • MAC-VRF: A Virtual Routing and Forwarding table for Media Access Control (MAC) addresses on a PE. In VLAN-based or VLAN Bundle modes [I-D.ietf-bess-rfc7432bis] a BD is equivalent to a MAC-VRF.
  • EEG: EVPN to EVPN Gateway, or a Service Gateway that interconnects two or more EVPN domains for the purpose of forwarding IP Multicast traffic.
  • Ethernet Segment (ES): 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'.
  • Ethernet Segment Identifier (ESI): A unique non-zero identifier that identifies an Ethernet segment is called an 'Ethernet Segment Identifier'.
  • I-ES: Interconnect Ethernet Segment or a especial Ethernet Segment used to provide multi-homing on Service Gateways that follow the procedures in [RFC9014].
  • 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.
  • 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.
  • SMET route: Selective Multicast Ethernet Tag route, as defined in [RFC9251].
  • 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.
  • 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 [I-D.ietf-bess-evpn-irb-mcast].
  • 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.

1.2. Multicast Layer-2 Interconnect on EVPN to EVPN Gateways (EEG)

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 Figure 1 (with 1:1 and 2:2 being the respective domain-IDs [I-D.sr-bess-evpn-dpath]). 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 [RFC9014] 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, being e.g., EEG1 the Designated Forwarder and EEG2 the non-Designated Forwarder routers in I-ES1. 'Encap1' and 'encap2' in Figure 1 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 [RFC9251], and they are not aware of being attached to different EVPN domains.

         +--+
         |S1|
         +--+                            Receiver-1
          |S1,G2                             ^ | join
     PE1  |                             PE2  | | *,G2
      +---v---+                          +---|-v-+
+-----| +---+ |--------------------------| +---+ |----+
|     | |BD1| |                          | |BD1| |    |
|     | +---+ |-------+----------------> | +---+ |    |
|     +-------+       |                  +-------+    |
|           ^         |         <---                  |
|           |         |         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

Figure 1: Layer-2 EEGs

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 apply a proxy function for the multicast groups that they received in the imported SMET routes for a domain, and advertise the result of the proxy membership in SMET routes to the other domains, using their own IP address as Originator IP of the SMET route. As an example in Figure 1, 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 Figure 1, 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 send the minimum set of SMET routes 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 only advertises an SMET route for (*,G2) since that is the minimum set required to attract the traffic for any flow to G2. This assumes the same version flags are received on the SMET routes for (*,G2) and (S1,G2).
  • The EEG routers do not require the use of Multicast Membership Report Synch or Multicast Leave Synch routes [RFC9251] to synchronize the multicast states received via SMET routes from each domain. This is due to all the EEG routers in a domain importing the same 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 [RFC9014], that is, only the Designated Forwarder EEG forwards IP multicast traffic from sources in one domain to the other domains.

1.3. Multicast Layer-3 Interconnect on EVPN to EVPN Gateways (EEG)

This section describes an example of the second use-case for which this document specifies extensions.

Similar to Figure 1 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 [I-D.ietf-bess-evpn-irb-mcast] for the same tenant, as illustrated in Figure 2. Note that Figure 2 is an example, the procedures in this document apply irrespective of the PEs being attached to the same or different Broadcast Domains, and sources and receivers can be connected to any PE or Broadcast Domain in the network, and also be in the same or different subnets. The IP-VRF of the EEG routers imports EVPN IP Prefix routes [RFC9136] 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 [I-D.ietf-bess-evpn-ipvpn-interworking]. 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 [I-D.ietf-bess-evpn-irb-mcast]. 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 [I-D.ietf-bess-evpn-irb-mcast] 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.

                 +--+
                 |S1|                         Receiver-1
                 +--+                             ^ |
                  |S1,G2                          | | join
                  |      PE1             PE2      | v *,G2
               +--v-----------+         +-------------+
               |+---+------------+      |        +---+|
               ||BD1|----+    |  |      | +------|BD2||
               |+---+    |    |  |      | |IP-VRF+---+|
           +---| |IP-VRF+----+|  |      |+----+   |   |---+
           |   | +------|SBD1||  +------>|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

Figure 2: Layer-3 EEGs

In the example of Figure 2, 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 [I-D.ietf-bess-evpn-irb-mcast] 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 [I-D.ietf-bess-evpn-irb-mcast] 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 Figure 2, 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 Section 3. The selected SBD-DR has the First Hop Router function in the Supplementary Broadcast Domain where it is selected. In the example of Figure 2, 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. This assumes the same version flags are received on the SMET routes for (*,G2) and (S1,G2).
  • In [I-D.ietf-bess-evpn-irb-mcast] 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 Figure 2, EEG1 adds SBD2 IRB in the layer-3 OIF list for (S1,G2) and SBD1 IRB is the IIF for the same group.

2. Layer-2 EVPN to EVPN Gateway Procedures

This section provides the specification for EVPN to EVPN Gateways (EEGs) when configured for layer-2 interconnect, as in the use case of Section 1.2.

  1. An EEG configured for layer-2 interconnect of two or more domains MUST support the procedures in [RFC9014] 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 [I-D.sr-bess-evpn-dpath]:

    1. 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.
    2. This EEG "proxy" of SMET routes in this document means that the SMET routes are imported in one domain of the BD, create OIF entries on that domain and are exported into the other domain(s) of the BD as long as there is no other SMET route for the same multicast group already exported.
  2. An EEG MUST import SMET routes received for the BD to which the EEG is attached.

    1. 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 [RFC9251].
    2. 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 [RFC9251], or the multicast tree created by the EVPN Selective Provider Multicast Service Interface Auto Discovery routes (S-PMSI A-D routes as in [I-D.ietf-bess-evpn-bum-procedure-updates]).
  3. 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:

    1. 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.
    2. 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.
    3. 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.
    4. 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 and version 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 and version (but with specific 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.
  4. Two or more EEG routers attached to the same two EVPN domains of a BD SHOULD use an Interconnect Ethernet Segment (I-ES) [RFC9014] to handle the redundancy and avoid multicast duplication, as follows:

    1. 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.
    2. The non-Designated Forwarder MAY do proxy of the SMET routes but MUST NOT forward multicast traffic between domains as per [RFC9014], 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.
  5. 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 [I-D.sr-bess-evpn-dpath] attribute SHOULD be used as follows:

    1. An EEG doing proxy of SMET routes between domains SHOULD add or modify the D-PATH BGP attribute [I-D.sr-bess-evpn-dpath] in the exported SMET route, by prepending the domain-ID of the source domain (domain in which the route is imported).
    2. 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 Figure 1 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').
    3. 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.
  6. EVPN Multicast Membership Report Synch or Multicast Leave Synch routes [RFC9251] for the Interconnect Ethernet Segment MUST NOT be generated or imported.
  7. 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 [I-D.sr-bess-evpn-dpath] for local Attachment Circuits on the Service Gateways.

    1. 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 Figure 1, 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.
    2. 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.
    3. Local sources and receivers MAY be attached to Ethernet Segments. In this case, the EGG follows the procedures in [RFC9251] for synchronizing multicast state and other procedures.
  8. This specification is compatible with [I-D.ietf-bess-evpn-redundant-mcast-source] section 4 (Warm Standby solution) irrespective of the sources being attached to the same or different EVPN domains.

3. Layer-3 EVPN to EVPN Gateway Procedures

This section provides the specification for EVPN to EVPN Gateways (EEGs) when configured for layer-3 interconnect, as in the use case of Section 1.2. 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.

  1. An EEG configured for layer-3 interconnect of two or more domains MUST support the gateway procedures in [I-D.ietf-bess-evpn-ipvpn-interworking] section 8, for IP unicast forwarding between two EVPN domains. To differentiate an EVPN domain in Section 2 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 Section 2.

    1. 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.
    2. 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 and version 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 and version (but with specific sources) SHOULD NOT be exported to the other domain.
  2. An EEG creates one SBD instance per domain the IP-VRF is interconnecting. The SBD concept is specified in [I-D.ietf-bess-evpn-irb-mcast], only that this specification allows more than one SBD per IP-VRF on the EEG routers.

    1. 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.
    2. An SBD imports and exports SMET routes as per the procedures in [I-D.ietf-bess-evpn-irb-mcast].
    3. Also this document extends [I-D.ietf-bess-evpn-irb-mcast] 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.
  3. 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 carry 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 [I-D.ietf-bess-evpn-irb-mcast] 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. This election MUST follow the procedures of [I-D.ietf-bess-evpn-irb-mcast] section 6.1.2.4. The winner of the election is 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 resdistributing the SMET route for G into the other SBDs of the same IP-VRF.
  4. 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 unnecesary traffic and speeding up convergence in case of a failure on the SBD-DR.
  5. 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.

    1. 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.
    2. 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.
  6. 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 [I-D.ietf-bess-evpn-irb-mcast].
  7. The MEG (MVPN to EVPN Gateway), PEG (PIM to EVPN Gateway) [I-D.ietf-bess-evpn-irb-mcast] and EEG (EVPN to EVPN Gateway) procedures MAY be used for the same tenant on the same Service Gateways.
  8. This specification is compatible with [I-D.ietf-bess-evpn-redundant-mcast-source] section 4 (Warm Standby solution) irrespective of the sources being attached to the same or different EVPN domains.

4. Security Considerations

This document extends the procedures of [RFC9251] and [I-D.ietf-bess-evpn-irb-mcast], in the scenarios described by [RFC9014] and [I-D.ietf-bess-evpn-ipvpn-interworking]. 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.

5. IANA Considerations

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.

Bit         Name                           Reference
--------------------------------------------------------
TBD         EVPN to EVPN Gateway (EEG)     This document

Figure 3

6. Contributors

7. Acknowledgments

8. References

8.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC9136]
Rabadan, J., Ed., Henderickx, W., Drake, J., Lin, W., and A. Sajassi, "IP Prefix Advertisement in Ethernet VPN (EVPN)", RFC 9136, DOI 10.17487/RFC9136, , <https://www.rfc-editor.org/info/rfc9136>.
[I-D.ietf-bess-rfc7432bis]
Sajassi, A., Burdet, L. A., Drake, J., and J. Rabadan, "BGP MPLS-Based Ethernet VPN", Work in Progress, Internet-Draft, draft-ietf-bess-rfc7432bis-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-rfc7432bis-07>.
[RFC9251]
Sajassi, A., Thoria, S., Mishra, M., Patel, K., Drake, J., and W. Lin, "Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Proxies for Ethernet VPN (EVPN)", RFC 9251, DOI 10.17487/RFC9251, , <https://www.rfc-editor.org/info/rfc9251>.
[RFC9014]
Rabadan, J., Ed., Sathappan, S., Henderickx, W., Sajassi, A., and J. Drake, "Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks", RFC 9014, DOI 10.17487/RFC9014, , <https://www.rfc-editor.org/info/rfc9014>.
[I-D.ietf-bess-evpn-irb-mcast]
Lin, W., Zhang, Z. J., Drake, J., Rosen, E. C., Rabadan, J., and A. Sajassi, "EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-irb-mcast-09, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-irb-mcast-09>.
[I-D.ietf-bess-evpn-ipvpn-interworking]
Rabadan, J., Sajassi, A., Rosen, E. C., Drake, J., Lin, W., Uttaro, J., and A. Simpson, "EVPN Interworking with IPVPN", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-ipvpn-interworking-07, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-ipvpn-interworking-07>.
[I-D.sr-bess-evpn-dpath]
Rabadan, J., Sathappan, S., Gautam, M., Brissette, P., and W. Lin, "Domain Path (D-PATH) for Ethernet VPN (EVPN) Interconnect Networks", Work in Progress, Internet-Draft, draft-sr-bess-evpn-dpath-03, , <https://datatracker.ietf.org/doc/html/draft-sr-bess-evpn-dpath-03>.

8.2. Informative References

[RFC6513]
Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, , <https://www.rfc-editor.org/info/rfc6513>.
[RFC6514]
Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, , <https://www.rfc-editor.org/info/rfc6514>.
[RFC7761]
Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, , <https://www.rfc-editor.org/info/rfc7761>.
[I-D.ietf-bess-evpn-bum-procedure-updates]
Zhang, Z. J., Lin, W., Rabadan, J., Patel, K., and A. Sajassi, "Updates on EVPN BUM Procedures", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-bum-procedure-updates-14, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-bum-procedure-updates-14>.
[I-D.ietf-bess-evpn-redundant-mcast-source]
Rabadan, J., Kotalwar, J., Sathappan, S., Zhang, Z. J., Lin, W., and E. C. Rosen, "Multicast Source Redundancy in EVPN Networks", Work in Progress, Internet-Draft, draft-ietf-bess-evpn-redundant-mcast-source-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-bess-evpn-redundant-mcast-source-05>.

Authors' Addresses

Jorge Rabadan (editor)
Nokia
520 Almanor Avenue
Sunnyvale, CA 94085
United States of America
Olivier Dornon
Nokia
Vinod Prabhu
Nokia
Alex Nichol
Arista
Zhaohui Zhang
Juniper Networks
Wen Lin
Juniper Networks