EVPN Multicast Forwarding for EVPN to EVPN Gateways

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

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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:¶

• EVPN Layer-2 Interconnect¶
• EVPN Layer-3 Interconnect¶

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

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

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

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

Authors' Addresses