doc: Add RFC documents

1 files changed, 1365 insertions, 0 deletions

diff --git a/doc/rfc/rfc9014.txt b/doc/rfc/rfc9014.txt
new file mode 100644
index 0000000..c628fba
--- /dev/null
+++ b/doc/rfc/rfc9014.txt
@@ -0,0 +1,1365 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                   J. Rabadan, Ed.
+Request for Comments: 9014                                  S. Sathappan
+Category: Standards Track                                  W. Henderickx
+ISSN: 2070-1721                                                    Nokia
+                                                              A. Sajassi
+                                                                   Cisco
+                                                                J. Drake
+                                                                 Juniper
+                                                                May 2021
+
+
+     Interconnect Solution for Ethernet VPN (EVPN) Overlay Networks
+
+Abstract
+
+   This document describes how Network Virtualization Overlays (NVOs)
+   can be connected to a Wide Area Network (WAN) in order to extend the
+   Layer 2 connectivity required for some tenants.  The solution
+   analyzes the interaction between NVO networks running Ethernet
+   Virtual Private Networks (EVPNs) and other Layer 2 VPN (L2VPN)
+   technologies used in the WAN, such as Virtual Private LAN Services
+   (VPLSs), VPLS extensions for Provider Backbone Bridging (PBB-VPLS),
+   EVPN, or PBB-EVPN.  It also describes how the existing technical
+   specifications apply to the interconnection and extends the EVPN
+   procedures needed in some cases.  In particular, this document
+   describes how EVPN routes are processed on Gateways (GWs) that
+   interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the
+   Interconnect Ethernet Segment (I-ES), to provide multihoming.  This
+   document also describes the use of the Unknown MAC Route (UMR) to
+   avoid issues of a Media Access Control (MAC) scale on Data Center
+   Network Virtualization Edge (NVE) devices.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc9014.
+
+Copyright Notice
+
+   Copyright (c) 2021 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 Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Conventions and Terminology
+   3.  Decoupled Interconnect Solution for EVPN-Overlay Networks
+     3.1.  Interconnect Requirements
+     3.2.  VLAN-Based Handoff
+     3.3.  PW-Based Handoff
+     3.4.  Multihoming Solution on the GWs
+     3.5.  Gateway Optimizations
+       3.5.1.  MAC Address Advertisement Control
+       3.5.2.  ARP/ND Flooding Control
+       3.5.3.  Handling Failures between GW and WAN Edge Routers
+   4.  Integrated Interconnect Solution for EVPN-Overlay Networks
+     4.1.  Interconnect Requirements
+     4.2.  VPLS Interconnect for EVPN-Overlay Networks
+       4.2.1.  Control/Data Plane Setup Procedures on the GWs
+       4.2.2.  Multihoming Procedures on the GWs
+     4.3.  PBB-VPLS Interconnect for EVPN-Overlay Networks
+       4.3.1.  Control/Data Plane Setup Procedures on the GWs
+       4.3.2.  Multihoming Procedures on the GWs
+     4.4.  EVPN-MPLS Interconnect for EVPN-Overlay Networks
+       4.4.1.  Control plane Setup Procedures on the GWs
+       4.4.2.  Data Plane Setup Procedures on the GWs
+       4.4.3.  Multihoming Procedure Extensions on the GWs
+       4.4.4.  Impact on MAC Mobility Procedures
+       4.4.5.  Gateway Optimizations
+       4.4.6.  Benefits of the EVPN-MPLS Interconnect Solution
+     4.5.  PBB-EVPN Interconnect for EVPN-Overlay Networks
+       4.5.1.  Control/Data Plane Setup Procedures on the GWs
+       4.5.2.  Multihoming Procedures on the GWs
+       4.5.3.  Impact on MAC Mobility Procedures
+       4.5.4.  Gateway Optimizations
+     4.6.  EVPN-VXLAN Interconnect for EVPN-Overlay Networks
+       4.6.1.  Globally Unique VNIs in the Interconnect Network
+       4.6.2.  Downstream-Assigned VNIs in the Interconnect Network
+   5.  Security Considerations
+   6.  IANA Considerations
+   7.  References
+     7.1.  Normative References
+     7.2.  Informative References
+   Acknowledgments
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   [RFC8365] discusses the use of Ethernet Virtual Private Networks
+   (EVPNs) [RFC7432] as the control plane for Network Virtualization
+   Overlays (NVOs), where VXLAN [RFC7348], NVGRE [RFC7637], or MPLS over
+   GRE [RFC4023] can be used as possible data plane encapsulation
+   options.
+
+   While this model provides a scalable and efficient multitenant
+   solution within the Data Center, it might not be easily extended to
+   the Wide Area Network (WAN) in some cases, due to the requirements
+   and existing deployed technologies.  For instance, a Service Provider
+   might have an already deployed Virtual Private LAN Service (VPLS)
+   [RFC4761] [RFC4762], VPLS extensions for Provider Backbone Bridging
+   (PBB-VPLS) [RFC7041], EVPN [RFC7432], or PBB-EVPN [RFC7623] network
+   that has to be used to interconnect Data Centers and WAN VPN users.
+   A Gateway (GW) function is required in these cases.  In fact,
+   [RFC8365] discusses two main Data Center Interconnect (DCI) solution
+   groups: "DCI using GWs" and "DCI using ASBRs".  This document
+   specifies the solutions that correspond to the "DCI using GWs" group.
+
+   It is assumed that the NVO GW and the WAN Edge functions can be
+   decoupled into two separate systems or integrated into the same
+   system.  The former option will be referred to as "decoupled
+   interconnect solution" throughout the document, whereas the latter
+   one will be referred to as "integrated interconnect solution".
+
+   The specified procedures are local to the redundant GWs connecting a
+   DC to the WAN.  The document does not preclude any combination across
+   different DCs for the same tenant.  For instance, a "Decoupled"
+   solution can be used in GW1 and GW2 (for DC1), and an "Integrated"
+   solution can be used in GW3 and GW4 (for DC2).
+
+   While the Gateways and WAN Provider Edges (PEs) use existing
+   specifications in some cases, the document also defines extensions
+   that are specific to DCI.  In particular, those extensions are:
+
+   *  The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that
+      can be associated to a set of pseudowires (PWs) or other tunnels.
+      The I-ES defined in this document is not associated with a set of
+      Ethernet links, as per [RFC7432], but rather with a set of virtual
+      tunnels (e.g., a set of PWs).  This set of virtual tunnels is
+      referred to as vES [VIRTUAL-ES].
+
+   *  The use of the Unknown MAC Route (UMR) in a DCI scenario.
+
+   *  The processing of EVPN routes on Gateways with MAC-VRFs connecting
+      EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-
+      Overlay networks.
+
+2.  Conventions and Terminology
+
+   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.
+
+   AC:  Attachment Circuit
+
+   ARP:  Address Resolution Protocol
+
+   BUM:  Broadcast, Unknown Unicast and Multicast (traffic)
+
+   CE:  Customer Equipment
+
+   CFM:  Connectivity Fault Management
+
+   DC:  Data Center
+
+   DCI:  Data Center Interconnect
+
+   DF:  Designated Forwarder
+
+   EVI:  EVPN Instance
+
+   EVPN:  Ethernet Virtual Private Network, as in [RFC7432]
+
+   EVPN Tunnel binding:  refers to a tunnel to a remote PE/NVE for a
+      given EVI.  Ethernet packets in these bindings are encapsulated
+      with the Overlay or MPLS encapsulation and the EVPN label at the
+      bottom of the stack.
+
+   ES:  Ethernet Segment
+
+   ESI:  Ethernet Segment Identifier
+
+   GW:  Gateway or Data Center Gateway
+
+   I-ES and I-ESI:  Interconnect Ethernet Segment and Interconnect
+      Ethernet Segment Identifier.  An I-ES is defined on the GWs for
+      multihoming to/from the WAN.
+
+   MAC  Media Access Control
+
+   MAC-VRF:  refers to an EVI instance in a particular node
+
+   MP2P and LSM tunnels:  refer to multipoint-to-point and label
+      switched multicast tunnels
+
+   ND:  Neighbor Discovery
+
+   NDF:  Non-Designated Forwarder
+
+   NVE:  Network Virtualization Edge
+
+   NVGRE:  Network Virtualization using Generic Routing Encapsulation
+
+   NVO:  Network Virtualization Overlay
+
+   OAM:  Operations, Administration, and Maintenance
+
+   PBB:  Provider Backbone Bridging
+
+   PE:  Provider Edge
+
+   PW:  Pseudowire
+
+   RD:  Route Distinguisher
+
+   RR:  Route Reflector
+
+   RT:  Route Target
+
+   S/C-TAG:  refers to a combination of Service Tag and Customer Tag in
+      a 802.1Q frame
+
+   TOR:  Top-Of-Rack
+
+   UMR:  Unknown MAC Route
+
+   vES:  virtual Ethernet Segment
+
+   VNI/VSID:  refers to VXLAN/NVGRE virtual identifiers
+
+   VPLS:  Virtual Private LAN Service
+
+   VSI:  Virtual Switch Instance or VPLS instance in a particular PE
+
+   VXLAN:  Virtual eXtensible LAN
+
+3.  Decoupled Interconnect Solution for EVPN-Overlay Networks
+
+   This section describes the interconnect solution when the GW and WAN
+   Edge functions are implemented in different systems.  Figure 1
+   depicts the reference model described in this section.  Note that,
+   although not shown in Figure 1, GWs may have local Attachment
+   Circuits (ACs).
+
+                                   +--+
+                                   |CE|
+                                   +--+
+                                     |
+                                  +----+
+                             +----| PE |----+
+           +---------+       |    +----+    |       +---------+
+   +----+  |        +---+  +----+        +----+  +---+        |  +----+
+   |NVE1|--|        |   |  |WAN |        |WAN |  |   |        |--|NVE3|
+   +----+  |        |GW1|--|Edge|        |Edge|--|GW3|        |  +----+
+           |        +---+  +----+        +----+  +---+        |
+           |  NVO-1   |      |     WAN      |      |   NVO-2  |
+           |        +---+  +----+        +----+  +---+        |
+           |        |   |  |WAN |        |WAN |  |   |        |
+   +----+  |        |GW2|--|Edge|        |Edge|--|GW4|        |  +----+
+   |NVE2|--|        +---+  +----+        +----+  +---+        |--|NVE4|
+   +----+  +---------+       |              |       +---------+  +----+
+                             +--------------+
+
+   |<-EVPN-Overlay-->|<-VLAN->|<-WAN L2VPN->|<--PW-->|<--EVPN-Overlay->|
+                      handoff               handoff
+
+                   Figure 1: Decoupled Interconnect Model
+
+   The following section describes the interconnect requirements for
+   this model.
+
+3.1.  Interconnect Requirements
+
+   The decoupled interconnect architecture is intended to be deployed in
+   networks where the EVPN-Overlay and WAN providers are different
+   entities and a clear demarcation is needed.  This solution solves the
+   following requirements:
+
+   *  A simple connectivity handoff between the EVPN-Overlay network
+      provider and the WAN provider so that QoS and security enforcement
+      are easily accomplished.
+
+   *  Independence of the L2VPN technology deployed in the WAN.
+
+   *  Multihoming between GW and WAN Edge routers, including per-service
+      load balancing.  Per-flow load balancing is not a strong
+      requirement, since a deterministic path per service is usually
+      required for an easy QoS and security enforcement.
+
+   *  Support of Ethernet OAM and Connectivity Fault Management (CFM)
+      [IEEE.802.1AG] [Y.1731] functions between the GW and the WAN Edge
+      router to detect individual AC failures.
+
+   *  Support for the following optimizations at the GW:
+
+      -  Flooding reduction of unknown unicast traffic sourced from the
+         DC Network Virtualization Edge (NVE) devices.
+
+      -  Control of the WAN MAC addresses advertised to the DC.
+
+      -  Address Resolution Protocol (ARP) and Neighbor Discovery (ND)
+         flooding control for the requests coming from the WAN.
+
+3.2.  VLAN-Based Handoff
+
+   In this option, the handoff between the GWs and the WAN Edge routers
+   is based on VLANs [IEEE.802.1Q].  This is illustrated in Figure 1
+   (between the GWs in NVO-1 and the WAN Edge routers).  Each MAC-VRF in
+   the GW is connected to a different VSI/MAC-VRF instance in the WAN
+   Edge router by using a different C-TAG VLAN ID or a different
+   combination of S/C-TAG VLAN IDs that matches at both sides.
+
+   This option provides the best possible demarcation between the DC and
+   WAN providers, and it does not require control plane interaction
+   between both providers.  The disadvantage of this model is the
+   provisioning overhead, since the service has to be mapped to a C-TAG
+   or S/C-TAG VLAN ID combination at both GW and WAN Edge routers.
+
+   In this model, the GW acts as a regular Network Virtualization Edge
+   (NVE) towards the DC.  Its control plane, data plane procedures, and
+   interactions are described in [RFC8365].
+
+   The WAN Edge router acts as a (PBB-)VPLS or (PBB-)EVPN PE with
+   Attachment Circuits (ACs) to the GWs.  Its functions are described in
+   [RFC4761], [RFC4762], [RFC6074], [RFC7432], and [RFC7623].
+
+3.3.  PW-Based Handoff
+
+   If MPLS between the GW and the WAN Edge router is an option, a PW-
+   based interconnect solution can be deployed.  In this option, the
+   handoff between both routers is based on FEC128-based PWs [RFC4762]
+   or FEC129-based PWs (for a greater level of network automation)
+   [RFC6074].  Note that this model still provides a clear demarcation
+   between DC and WAN (since there is a single PW between each MAC-VRF
+   and peer VSI), and security/QoS policies may be applied on a per-PW
+   basis.  This model provides better scalability than a C-TAG-based
+   handoff and less provisioning overhead than a combined C/S-TAG
+   handoff.  The PW-based handoff interconnect is illustrated in
+   Figure 1 (between the NVO-2 GWs and the WAN Edge routers).
+
+   In this model, besides the usual MPLS procedures between GW and WAN
+   Edge router [RFC3031], the GW MUST support an interworking function
+   in each MAC-VRF that requires extension to the WAN:
+
+   *  If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI
+      (WAN Edge), the corresponding Virtual Connection Identifier (VCID)
+      MUST be provisioned on the MAC-VRF and match the VCID used in the
+      peer VSI at the WAN Edge router.
+
+   *  If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used
+      between the GW MAC-VRF and the WAN Edge VSI, the provisioning of
+      the VPLS-ID MUST be supported on the MAC-VRF and MUST match the
+      VPLS-ID used in the WAN Edge VSI.
+
+   If a PW-based handoff is used, the GW's AC (or point of attachment to
+   the EVPN instance) uses a combination of a PW label and VLAN IDs.
+   PWs are treated as service interfaces, defined in [RFC7432].
+
+3.4.  Multihoming Solution on the GWs
+
+   EVPN single-active multihoming -- i.e., per-service load-balancing
+   multihoming -- is required in this type of interconnect.
+
+   The GWs will be provisioned with a unique ES for each WAN
+   interconnect, and the handoff attachment circuits or PWs between the
+   GW and the WAN Edge router will be assigned an ESI for each such ES.
+   The ESI will be administratively configured on the GWs according to
+   the procedures in [RFC7432].  This I-ES will be referred to as "I-ES"
+   hereafter, and its identifier will be referred to as "I-ESI".
+   Different ESI types are described in [RFC7432].  The use of Type 0
+   for the I-ESI is RECOMMENDED in this document.
+
+   The solution (on the GWs) MUST follow the single-active multihoming
+   procedures as described in [RFC8365] for the provisioned I-ESI --
+   i.e., Ethernet A-D routes per ES and per EVI will be advertised to
+   the DC NVEs for the multihoming functions, and ES routes will be
+   advertised so that ES discovery and Designated Forwarder (DF)
+   procedures can be followed.  The MAC addresses learned (in the data
+   plane) on the handoff links will be advertised with the I-ESI encoded
+   in the ESI field.
+
+3.5.  Gateway Optimizations
+
+   The following GW features are optional and optimize the control plane
+   and data plane in the DC.
+
+3.5.1.  MAC Address Advertisement Control
+
+   The use of EVPN in NVO networks brings a significant number of
+   benefits, as described in [RFC8365].  However, if multiple DCs are
+   interconnected into a single EVI, each DC will have to import all of
+   the MAC addresses from each of the other DCs.
+
+   Even if optimized BGP techniques like RT constraint [RFC4684] are
+   used, the number of MAC addresses to advertise or withdraw (in case
+   of failure) by the GWs of a given DC could overwhelm the NVEs within
+   that DC, particularly when the NVEs reside in the hypervisors.
+
+   The solution specified in this document uses the Unknown MAC Route
+   (UMR) that is advertised into a given DC by each of the DC's GWs.
+   This route is defined in [RFC7543] and is a regular EVPN MAC/IP
+   Advertisement route in which the MAC Address Length is set to 48, the
+   MAC address is set to 0, and the ESI field is set to the DC GW's
+   I-ESI.
+
+   An NVE within that DC that understands and processes the UMR will
+   send unknown unicast frames to one of the DC's GWs, which will then
+   forward that packet to the correct egress PE.  Note that, because the
+   ESI is set to the DC GW's I-ESI, all-active multihoming can be
+   applied to unknown unicast MAC addresses.  An NVE that does not
+   understand the Unknown MAC Route will handle unknown unicast as
+   described in [RFC7432].
+
+   This document proposes that local policy determine whether MAC
+   addresses and/or the UMR are advertised into a given DC.  As an
+   example, when all the DC MAC addresses are learned in the control/
+   management plane, it may be appropriate to advertise only the UMR.
+   Advertising all the DC MAC addresses in the control/management plane
+   is usually the case when the NVEs reside in hypervisors.  Refer to
+   [RFC8365], Section 7.
+
+   It is worth noting that the UMR usage in [RFC7543] and the UMR usage
+   in this document are different.  In the former, a Virtual Spoke
+   (V-spoke) does not necessarily learn all the MAC addresses pertaining
+   to hosts in other V-spokes of the same network.  The communication
+   between two V-spokes is done through the Default MAC Gateway (DMG)
+   until the V-spokes learn each other's MAC addresses.  In this
+   document, two leaf switches in the same DC are recommended for
+   V-spokes to learn each other's MAC addresses for the same EVI.  The
+   leaf-to-leaf communication is always direct and does not go through
+   the GW.
+
+3.5.2.  ARP/ND Flooding Control
+
+   Another optimization mechanism, naturally provided by EVPN in the
+   GWs, is the Proxy ARP/ND function.  The GWs should build a Proxy ARP/
+   ND cache table, as per [RFC7432].  When the active GW receives an
+   ARP/ND request/solicitation coming from the WAN, the GW does a Proxy
+   ARP/ND table lookup and replies as long as the information is
+   available in its table.
+
+   This mechanism is especially recommended on the GWs, since it
+   protects the DC network from external ARP/ND-flooding storms.
+
+3.5.3.  Handling Failures between GW and WAN Edge Routers
+
+   Link/PE failures are handled on the GWs as specified in [RFC7432].
+   The GW detecting the failure will withdraw the EVPN routes, as per
+   [RFC7432].
+
+   Individual AC/PW failures may be detected by OAM mechanisms.  For
+   instance:
+
+   *  If the interconnect solution is based on a VLAN handoff, Ethernet-
+      CFM [IEEE.802.1AG] [Y.1731] may be used to detect individual AC
+      failures on both the GW and WAN Edge router.  An individual AC
+      failure will trigger the withdrawal of the corresponding A-D per
+      EVI route as well as the MACs learned on that AC.
+
+   *  If the interconnect solution is based on a PW handoff, the Label
+      Distribution Protocol (LDP) PW Status bits TLV [RFC6870] may be
+      used to detect individual PW failures on both the GW and WAN Edge
+      router.
+
+4.  Integrated Interconnect Solution for EVPN-Overlay Networks
+
+   When the DC and the WAN are operated by the same administrative
+   entity, the Service Provider can decide to integrate the GW and WAN
+   Edge PE functions in the same router for obvious reasons to save as
+   relates to Capital Expenditure (CAPEX) and Operating Expenses (OPEX).
+   This is illustrated in Figure 2.  Note that this model does not
+   provide an explicit demarcation link between DC and WAN anymore.
+   Although not shown in Figure 2, note that the GWs may have local ACs.
+
+                             +--+
+                             |CE|
+                             +--+
+                               |
+                            +----+
+                       +----| PE |----+
+           +---------+ |    +----+    | +---------+
+   +----+  |        +---+            +---+        |  +----+
+   |NVE1|--|        |   |            |   |        |--|NVE3|
+   +----+  |        |GW1|            |GW3|        |  +----+
+           |        +---+            +---+        |
+           |  NVO-1   |       WAN      |   NVO-2  |
+           |        +---+            +---+        |
+           |        |   |            |   |        |
+   +----+  |        |GW2|            |GW4|        |  +----+
+   |NVE2|--|        +---+            +---+        |--|NVE4|
+   +----+  +---------+ |              | +---------+  +----+
+                       +--------------+
+
+   |<--EVPN-Overlay--->|<-----VPLS--->|<---EVPN-Overlay-->|
+                       |<--PBB-VPLS-->|
+     Interconnect  ->  |<-EVPN-MPLS-->|
+      options          |<--EVPN-Ovl-->|*
+                       |<--PBB-EVPN-->|
+
+   * EVPN-Ovl stands for EVPN-Overlay (and it's an interconnect option).
+
+                  Figure 2: Integrated Interconnect Model
+
+4.1.  Interconnect Requirements
+
+   The integrated interconnect solution meets the following
+   requirements:
+
+   *  Control plane and data plane interworking between the EVPN-Overlay
+      network and the L2VPN technology supported in the WAN,
+      irrespective of the technology choice -- i.e., (PBB-)VPLS or
+      (PBB-)EVPN, as depicted in Figure 2.
+
+   *  Multihoming, including single-active multihoming with per-service
+      load balancing or all-active multihoming -- i.e., per-flow load-
+      balancing -- as long as the technology deployed in the WAN
+      supports it.
+
+   *  Support for end-to-end MAC Mobility, Static MAC protection and
+      other procedures (e.g., proxy-arp) described in [RFC7432] as long
+      as EVPN-MPLS is the technology of choice in the WAN.
+
+   *  Independent inclusive multicast trees in the WAN and in the DC.
+      That is, the inclusive multicast tree type defined in the WAN does
+      not need to be the same as in the DC.
+
+4.2.  VPLS Interconnect for EVPN-Overlay Networks
+
+4.2.1.  Control/Data Plane Setup Procedures on the GWs
+
+   Regular MPLS tunnels and Targeted LDP (tLDP) / BGP sessions will be
+   set up to the WAN PEs and RRs as per [RFC4761], [RFC4762], and
+   [RFC6074], and overlay tunnels and EVPN will be set up as per
+   [RFC8365].  Note that different route targets for the DC and the WAN
+   are normally required (unless [RFC4762] is used in the WAN, in which
+   case no WAN route target is needed).  A single type-1 RD per service
+   may be used.
+
+   In order to support multihoming, the GWs will be provisioned with an
+   I-ESI (see Section 3.4), which will be unique for each
+   interconnection.  In this case, the I-ES will represent the group of
+   PWs to the WAN PEs and GWs.  All the [RFC7432] procedures are still
+   followed for the I-ES -- e.g., any MAC address learned from the WAN
+   will be advertised to the DC with the I-ESI in the ESI field.
+
+   A MAC-VRF per EVI will be created in each GW.  The MAC-VRF will have
+   two different types of tunnel bindings instantiated in two different
+   split-horizon groups:
+
+   *  VPLS PWs will be instantiated in the WAN split-horizon group.
+
+   *  Overlay tunnel bindings (e.g., VXLAN, NVGRE) will be instantiated
+      in the DC split-horizon group.
+
+   Attachment circuits are also supported on the same MAC-VRF (although
+   not shown in Figure 2), but they will not be part of any of the above
+   split-horizon groups.
+
+   Traffic received in a given split-horizon group will never be
+   forwarded to a member of the same split-horizon group.
+
+   As far as BUM flooding is concerned, a flooding list will be composed
+   of the sublist created by the inclusive multicast routes and the
+   sublist created for VPLS in the WAN.  BUM frames received from a
+   local Attachment Circuit (AC) will be forwarded to the flooding list.
+   BUM frames received from the DC or the WAN will be forwarded to the
+   flooding list, observing the split-horizon group rule described
+   above.
+
+   Note that the GWs are not allowed to have an EVPN binding and a PW to
+   the same far end within the same MAC-VRF, so that loops and packet
+   duplication are avoided.  In case a GW can successfully establish
+   both an EVPN binding and a PW to the same far-end PE, the EVPN
+   binding will prevail, and the PW will be brought down operationally.
+
+   The optimization procedures described in Section 3.5 can also be
+   applied to this model.
+
+4.2.2.  Multihoming Procedures on the GWs
+
+   This model supports single-active multihoming on the GWs.  All-active
+   multihoming is not supported by VPLS; therefore, it cannot be used on
+   the GWs.
+
+   In this case, for a given EVI, all the PWs in the WAN split-horizon
+   group are assigned to I-ES.  All the single-active multihoming
+   procedures as described by [RFC8365] will be followed for the I-ES.
+
+   The non-DF GW for the I-ES will block the transmission and reception
+   of all the PWs in the WAN split-horizon group for BUM and unicast
+   traffic.
+
+4.3.  PBB-VPLS Interconnect for EVPN-Overlay Networks
+
+4.3.1.  Control/Data Plane Setup Procedures on the GWs
+
+   In this case, there is no impact on the procedures described in
+   [RFC7041] for the B-component.  However, the I-component instances
+   become EVI instances with EVPN-Overlay bindings and potentially local
+   attachment circuits.  A number of MAC-VRF instances can be
+   multiplexed into the same B-component instance.  This option provides
+   significant savings in terms of PWs to be maintained in the WAN.
+
+   The I-ESI concept described in Section 4.2.1 will also be used for
+   the PBB-VPLS-based interconnect.
+
+   B-component PWs and I-component EVPN-Overlay bindings established to
+   the same far end will be compared.  The following rules will be
+   observed:
+
+   *  Attempts to set up a PW between the two GWs within the B-component
+      context will never be blocked.
+
+   *  If a PW exists between two GWs for the B-component and an attempt
+      is made to set up an EVPN binding on an I-component linked to that
+      B-component, the EVPN binding will be kept down operationally.
+      Note that the BGP EVPN routes will still be valid but not used.
+
+   *  The EVPN binding will only be up and used as long as there is no
+      PW to the same far end in the corresponding B-component.  The EVPN
+      bindings in the I-components will be brought down before the PW in
+      the B-component is brought up.
+
+   The optimization procedures described in Section 3.5 can also be
+   applied to this interconnect option.
+
+4.3.2.  Multihoming Procedures on the GWs
+
+   This model supports single-active multihoming on the GWs.  All-active
+   multihoming is not supported by this scenario.
+
+   The single-active multihoming procedures as described by [RFC8365]
+   will be followed for the I-ES for each EVI instance connected to the
+   B-component.  Note that in this case, for a given EVI, all the EVPN
+   bindings in the I-component are assigned to the I-ES.  The non-DF GW
+   for the I-ES will block the transmission and reception of all the
+   I-component EVPN bindings for BUM and unicast traffic.  When learning
+   MACs from the WAN, the non-DF MUST NOT advertise EVPN MAC/IP routes
+   for those MACs.
+
+4.4.  EVPN-MPLS Interconnect for EVPN-Overlay Networks
+
+   If EVPN for MPLS tunnels (referred to as "EVPN-MPLS" hereafter) are
+   supported in the WAN, an end-to-end EVPN solution can be deployed.
+   The following sections describe the proposed solution as well as its
+   impact on the procedures from [RFC7432].
+
+4.4.1.  Control plane Setup Procedures on the GWs
+
+   The GWs MUST establish separate BGP sessions for sending/receiving
+   EVPN routes to/from the DC and to/from the WAN.  Normally, each GW
+   will set up one BGP EVPN session to the DC RR (or two BGP EVPN
+   sessions if there are redundant DC RRs) and one session to the WAN RR
+   (or two sessions if there are redundant WAN RRs).
+
+   In order to facilitate separate BGP processes for DC and WAN, EVPN
+   routes sent to the WAN SHOULD carry a different Route Distinguisher
+   (RD) than the EVPN routes sent to the DC.  In addition, although
+   reusing the same value is possible, different route targets are
+   expected to be handled for the same EVI in the WAN and the DC.  Note
+   that the EVPN service routes sent to the DC RRs will normally include
+   a [RFC9012] BGP encapsulation extended community with a different
+   tunnel type than the one sent to the WAN RRs.
+
+   As in the other discussed options, an I-ES and its assigned I-ESI
+   will be configured on the GWs for multihoming.  This I-ES represents
+   the WAN EVPN-MPLS PEs to the DC but also the DC EVPN-Overlay NVEs to
+   the WAN.  Optionally, different I-ESI values are configured for
+   representing the WAN and the DC.  If different EVPN-Overlay networks
+   are connected to the same group of GWs, each EVPN-Overlay network
+   MUST get assigned a different I-ESI.
+
+   Received EVPN routes will never be reflected on the GWs but instead
+   will be consumed and re-advertised (if needed):
+
+   *  Ethernet A-D routes, ES routes, and Inclusive Multicast routes are
+      consumed by the GWs and processed locally for the corresponding
+      [RFC7432] procedures.
+
+   *  MAC/IP advertisement routes will be received and imported, and if
+      they become active in the MAC-VRF, the information will be re-
+      advertised as new routes with the following fields:
+
+      -  The RD will be the GW's RD for the MAC-VRF.
+
+      -  The ESI will be set to the I-ESI.
+
+      -  The Ethernet-tag value will be kept from the received NLRI the
+         received NLRI.
+
+      -  The MAC length, MAC address, IP Length, and IP address values
+         will be kept from the received NLRI.
+
+      -  The MPLS label will be a local 20-bit value (when sent to the
+         WAN) or a DC-global 24-bit value (when sent to the DC for
+         encapsulations using a VNI).
+
+      -  The appropriate Route Targets (RTs) and [RFC9012] BGP
+         encapsulation extended community will be used according to
+         [RFC8365].
+
+   The GWs will also generate the following local EVPN routes that will
+   be sent to the DC and WAN, with their corresponding RTs and [RFC9012]
+   BGP encapsulation extended community values:
+
+   *  ES route(s) for the I-ESI(s).
+
+   *  Ethernet A-D routes per ES and EVI for the I-ESI(s).  The A-D per-
+      EVI routes sent to the WAN and the DC will have consistent
+      Ethernet-Tag values.
+
+   *  Inclusive Multicast routes with independent tunnel-type value for
+      the WAN and DC.  For example, a P2MP Label Switched Path (LSP) may
+      be used in the WAN, whereas ingress replication may be used in the
+      DC.  The routes sent to the WAN and the DC will have a consistent
+      Ethernet-Tag.
+
+   *  MAC/IP advertisement routes for MAC addresses learned in local
+      attachment circuits.  Note that these routes will not include the
+      I-ESI value in the ESI field.  These routes will include a zero
+      ESI or a non-zero ESI for local multihomed Ethernet Segments (ES).
+      The routes sent to the WAN and the DC will have a consistent
+      Ethernet-Tag.
+
+   Assuming GW1 and GW2 are peer GWs of the same DC, each GW will
+   generate two sets of the above local service routes: set-DC will be
+   sent to the DC RRs and will include an A-D per EVI, Inclusive
+   Multicast, and MAC/IP routes for the DC encapsulation and RT.  Set-
+   WAN will be sent to the WAN RRs and will include the same routes but
+   using the WAN RT and encapsulation.  GW1 and GW2 will receive each
+   other's set-DC and set-WAN.  This is the expected behavior on GW1 and
+   GW2 for locally generated routes:
+
+   *  Inclusive multicast routes: When setting up the flooding lists for
+      a given MAC-VRF, each GW will include its DC peer GW only in the
+      EVPN-MPLS flooding list (by default) and not the EVPN-Overlay
+      flooding list.  That is, GW2 will import two Inclusive Multicast
+      routes from GW1 (from set-DC and set-WAN) but will only consider
+      one of the two, giving the set-WAN route higher priority.  An
+      administrative option MAY change this preference so that the set-
+      DC route is selected first.
+
+   *  MAC/IP advertisement routes for local attachment circuits: As
+      above, the GW will select only one, giving the route from the set-
+      WAN a higher priority.  As with the Inclusive multicast routes, an
+      administrative option MAY change this priority.
+
+4.4.2.  Data Plane Setup Procedures on the GWs
+
+   The procedure explained at the end of the previous section will make
+   sure there are no loops or packet duplication between the GWs of the
+   same EVPN-Overlay network (for frames generated from local ACs),
+   since only one EVPN binding per EVI (or per Ethernet Tag in the case
+   of VLAN-aware bundle services) will be set up in the data plane
+   between the two nodes.  That binding will by default be added to the
+   EVPN-MPLS flooding list.
+
+   As for the rest of the EVPN tunnel bindings, they will be added to
+   one of the two flooding lists that each GW sets up for the same MAC-
+   VRF:
+
+   *  EVPN-Overlay flooding list (composed of bindings to the remote
+      NVEs or multicast tunnel to the NVEs).
+
+   *  EVPN-MPLS flooding list (composed of MP2P or LSM tunnel to the
+      remote PEs).
+
+   Each flooding list will be part of a separate split-horizon group:
+   the WAN split-horizon group or the DC split-horizon group.  Traffic
+   generated from a local AC can be flooded to both split-horizon
+   groups.  Traffic from a binding of a split-horizon group can be
+   flooded to the other split-horizon group and local ACs, but never to
+   a member of its own split-horizon group.
+
+   When either GW1 or GW2 receives a BUM frame on an MPLS tunnel,
+   including an ESI label at the bottom of the stack, they will perform
+   an ESI label lookup and split-horizon filtering as per [RFC7432], in
+   case the ESI label identifies a local ESI (I-ESI or any other nonzero
+   ESI).
+
+4.4.3.  Multihoming Procedure Extensions on the GWs
+
+   This model supports single-active as well as all-active multihoming.
+
+   All the [RFC7432] multihoming procedures for the DF election on
+   I-ES(s), as well as the backup-path (single-active) and aliasing
+   (all-active) procedures, will be followed on the GWs.  Remote PEs in
+   the EVPN-MPLS network will follow regular [RFC7432] aliasing or
+   backup-path procedures for MAC/IP routes received from the GWs for
+   the same I-ESI.  So will NVEs in the EVPN-Overlay network for MAC/IP
+   routes received with the same I-ESI.
+
+   As far as the forwarding plane is concerned, by default, the EVPN-
+   Overlay network will have an analogous behavior to the access ACs in
+   [RFC7432] multihomed Ethernet Segments.
+
+   The forwarding behavior on the GWs is described below:
+
+   *  Single-active multihoming; assuming a WAN split-horizon group
+      (comprised of EVPN-MPLS bindings), a DC split-horizon group
+      (comprised of EVPN-Overlay bindings), and local ACs on the GWs:
+
+      -  Forwarding behavior on the non-DF: The non-DF MUST block
+         ingress and egress forwarding on the EVPN-Overlay bindings
+         associated to the I-ES.  The EVPN-MPLS network is considered to
+         be the core network, and the EVPN-MPLS bindings to the remote
+         PEs and GWs will be active.
+
+      -  Forwarding behavior on the DF: The DF MUST NOT forward BUM or
+         unicast traffic received from a given split-horizon group to a
+         member of its own split-horizon group.  Forwarding to other
+         split-horizon groups and local ACs is allowed (as long as the
+         ACs are not part of an ES for which the node is non-DF).  As
+         per [RFC7432] and for split-horizon purposes, when receiving
+         BUM traffic on the EVPN-Overlay bindings associated to an I-ES,
+         the DF GW SHOULD add the I-ESI label when forwarding to the
+         peer GW over EVPN-MPLS.
+
+      -  When receiving EVPN MAC/IP routes from the WAN, the non-DF MUST
+         NOT reoriginate the EVPN routes and advertise them to the DC
+         peers.  In the same way, EVPN MAC/IP routes received from the
+         DC MUST NOT be advertised to the WAN peers.  This is consistent
+         with [RFC7432] and allows the remote PE/NVEs to know who the
+         primary GW is, based on the reception of the MAC/IP routes.
+
+   *  All-active multihoming; assuming a WAN split-horizon group
+      (comprised of EVPN-MPLS bindings), a DC split-horizon group
+      (comprised of EVPN-Overlay bindings), and local ACs on the GWs:
+
+      -  Forwarding behavior on the non-DF: The non-DF follows the same
+         behavior as the non-DF in the single-active case, but only for
+         BUM traffic.  Unicast traffic received from a split-horizon
+         group MUST NOT be forwarded to a member of its own split-
+         horizon group but can be forwarded normally to the other split-
+         horizon groups and local ACs.  If a known unicast packet is
+         identified as a "flooded" packet, the procedures for BUM
+         traffic MUST be followed.
+
+      -  Forwarding behavior on the DF: The DF follows the same behavior
+         as the DF in the single-active case, but only for BUM traffic.
+         Unicast traffic received from a split-horizon group MUST NOT be
+         forwarded to a member of its own split-horizon group but can be
+         forwarded normally to the other split-horizon group and local
+         ACs.  If a known unicast packet is identified as a "flooded"
+         packet, the procedures for BUM traffic MUST be followed.  As
+         per [RFC7432] and for split-horizon purposes, when receiving
+         BUM traffic on the EVPN-Overlay bindings associated to an I-ES,
+         the DF GW MUST add the I-ESI label when forwarding to the peer
+         GW over EVPN-MPLS.
+
+      -  Contrary to the single-active multihoming case, both DF and
+         non-DF reoriginate and advertise MAC/IP routes received from
+         the WAN/DC peers, adding the corresponding I-ESI so that the
+         remote PE/NVEs can perform regular aliasing, as per [RFC7432].
+
+   The example in Figure 3 illustrates the forwarding of BUM traffic
+   originated from an NVE on a pair of all-active multihoming GWs.
+
+        |<--EVPN-Overlay--->|<--EVPN-MPLS-->|
+
+                +---------+ +--------------+
+         +----+ BUM       +---+             |
+         |NVE1+----+----> |   +-+-----+     |
+         +----+  | |   DF |GW1| |     |     |
+                 | |      +-+-+ |     |    ++--+
+                 | |        |   |     +--> |PE1|
+                 | +--->X +-+-+ |          ++--+
+                 |     NDF|   | |           |
+         +----+  |        |GW2<-+           |
+         |NVE2+--+        +-+-+             |
+         +----+  +--------+ |  +------------+
+                            v
+                          +--+
+                          |CE|
+                          +--+
+
+                    Figure 3: Multihoming BUM Forwarding
+
+   GW2 is the non-DF for the I-ES and blocks the BUM forwarding.  GW1 is
+   the DF and forwards the traffic to PE1 and GW2.  Packets sent to GW2
+   will include the ESI label for the I-ES.  Based on the ESI label, GW2
+   identifies the packets as I-ES-generated packets and will only
+   forward them to local ACs (CE in the example) and not back to the
+   EVPN-Overlay network.
+
+4.4.4.  Impact on MAC Mobility Procedures
+
+   MAC Mobility procedures described in [RFC7432] are not modified by
+   this document.
+
+   Note that an intra-DC MAC move still leaves the MAC attached to the
+   same I-ES, so under the rules of [RFC7432], this is not considered a
+   MAC Mobility event.  Only when the MAC moves from the WAN domain to
+   the DC domain (or from one DC to another) will the MAC be learned
+   from a different ES, and the MAC Mobility procedures will kick in.
+
+   The sticky-bit indication in the MAC Mobility extended community MUST
+   be propagated between domains.
+
+4.4.5.  Gateway Optimizations
+
+   All the Gateway optimizations described in Section 3.5 MAY be applied
+   to the GWs when the interconnect is based on EVPN-MPLS.
+
+   In particular, the use of the Unknown MAC Route, as described in
+   Section 3.5.1, solves some transient packet-duplication issues in
+   cases of all-active multihoming, as explained below.
+
+   Consider the diagram in Figure 2 for EVPN-MPLS interconnect and all-
+   active multihoming, and the following sequence:
+
+   (a)  MAC Address M1 is advertised from NVE3 in EVI-1.
+
+   (b)  GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN
+        with I-ESI-2 in the ESI field.
+
+   (c)  GW1 and GW2 learn M1 and install GW3/GW4 as next hops following
+        the EVPN aliasing procedures.
+
+   (d)  Before NVE1 learns M1, a packet arrives at NVE1 with destination
+        M1.  If the Unknown MAC Route had not been advertised into the
+        DC, NVE1 would have flooded the packet throughout the DC, in
+        particular to both GW1 and GW2.  If the same VNI/VSID is used
+        for both known unicast and BUM traffic, as is typically the
+        case, there is no indication in the packet that it is a BUM
+        packet, and both GW1 and GW2 would have forwarded it, creating
+        packet duplication.  However, because the Unknown MAC Route had
+        been advertised into the DC, NVE1 will unicast the packet to
+        either GW1 or GW2.
+
+   (e)  Since both GW1 and GW2 know M1, the GW receiving the packet will
+        forward it to either GW3 or GW4.
+
+4.4.6.  Benefits of the EVPN-MPLS Interconnect Solution
+
+   The "DCI using ASBRs" solution described in [RFC8365] and the GW
+   solution with EVPN-MPLS interconnect may be seen as similar, since
+   they both retain the EVPN attributes between Data Centers and
+   throughout the WAN.  However, the EVPN-MPLS interconnect solution on
+   the GWs has significant benefits compared to the "DCI using ASBRs"
+   solution:
+
+   *  As in any of the described GW models, this solution supports the
+      connectivity of local attachment circuits on the GWs.  This is not
+      possible in a "DCI using ASBRs" solution.
+
+   *  Different data plane encapsulations can be supported in the DC and
+      the WAN, while a uniform encapsulation is needed in the "DCI using
+      ASBRs" solution.
+
+   *  Optimized multicast solution, with independent inclusive multicast
+      trees in DC and WAN.
+
+   *  MPLS label aggregation: For the case where MPLS labels are
+      signaled from the NVEs for MAC/IP advertisement routes, this
+      solution provides label aggregation.  A remote PE MAY receive a
+      single label per GW MAC-VRF, as opposed to a label per NVE/MAC-VRF
+      connected to the GW MAC-VRF.  For instance, in Figure 2, PE would
+      receive only one label for all the routes advertised for a given
+      MAC-VRF from GW1, as opposed to a label per NVE/MAC-VRF.
+
+   *  The GW will not propagate MAC Mobility for the MACs moving within
+      a DC.  Mobility intra-DC is solved by all the NVEs in the DC.  The
+      MAC Mobility procedures on the GWs are only required in case of
+      mobility across DCs.
+
+   *  Proxy-ARP/ND function on the DC GWs can be leveraged to reduce
+      ARP/ND flooding in the DC or/and the WAN.
+
+4.5.  PBB-EVPN Interconnect for EVPN-Overlay Networks
+
+   PBB-EVPN [RFC7623] is yet another interconnect option.  It requires
+   the use of GWs where I-components and associated B-components are
+   part of EVI instances.
+
+4.5.1.  Control/Data Plane Setup Procedures on the GWs
+
+   EVPN will run independently in both components, the I-component MAC-
+   VRF and B-component MAC-VRF.  Compared to [RFC7623], the DC customer
+   MACs (C-MACs) are no longer learned in the data plane on the GW but
+   in the control plane through EVPN running on the I-component.  Remote
+   C-MACs coming from remote PEs are still learned in the data plane.
+   B-MACs in the B-component will be assigned and advertised following
+   the procedures described in [RFC7623].
+
+   An I-ES will be configured on the GWs for multihoming, but its I-ESI
+   will only be used in the EVPN control plane for the I-component EVI.
+   No unreserved ESIs will be used in the control plane of the
+   B-component EVI, as per [RFC7623].  That is, the I-ES will be
+   represented to the WAN PBB-EVPN PEs using shared or dedicated B-MACs.
+
+   The rest of the control plane procedures will follow [RFC7432] for
+   the I-component EVI and [RFC7623] for the B-component EVI.
+
+   From the data plane perspective, the I-component and B-component EVPN
+   bindings established to the same far end will be compared, and the
+   I-component EVPN-Overlay binding will be kept down following the
+   rules described in Section 4.3.1.
+
+4.5.2.  Multihoming Procedures on the GWs
+
+   This model supports single-active as well as all-active multihoming.
+
+   The forwarding behavior of the DF and non-DF will be changed based on
+   the description outlined in Section 4.4.3, substituting the WAN
+   split-horizon group for the B-component, and using [RFC7623]
+   procedures for the traffic sent or received on the B-component.
+
+4.5.3.  Impact on MAC Mobility Procedures
+
+   C-MACs learned from the B-component will be advertised in EVPN within
+   the I-component EVI scope.  If the C-MAC was previously known in the
+   I-component database, EVPN would advertise the C-MAC with a higher
+   sequence number, as per [RFC7432].  From the perspective of Mobility
+   and the related procedures described in [RFC7432], the C-MACs learned
+   from the B-component are considered local.
+
+4.5.4.  Gateway Optimizations
+
+   All the considerations explained in Section 4.4.5 are applicable to
+   the PBB-EVPN interconnect option.
+
+4.6.  EVPN-VXLAN Interconnect for EVPN-Overlay Networks
+
+   If EVPN for Overlay tunnels is supported in the WAN, and a GW
+   function is required, an end-to-end EVPN solution can be deployed.
+   While multiple Overlay tunnel combinations at the WAN and the DC are
+   possible (MPLSoGRE, NVGRE, etc.), VXLAN is described here, given its
+   popularity in the industry.  This section focuses on the specific
+   case of EVPN for VXLAN (EVPN-VXLAN hereafter) and the impact on the
+   [RFC7432] procedures.
+
+   The procedures described in Section 4.4 apply to this section, too,
+   only substituting EVPN-MPLS for EVPN-VXLAN control plane specifics
+   and using [RFC8365] "Local Bias" procedures instead of Section 4.4.3.
+   Since there are no ESI labels in VXLAN, GWs need to rely on "Local
+   Bias" to apply split horizon on packets generated from the I-ES and
+   sent to the peer GW.
+
+   This use case assumes that NVEs need to use the VNIs or VSIDs as
+   globally unique identifiers within a Data Center, and a Gateway needs
+   to be employed at the edge of the Data-Center network to translate
+   the VNI or VSID when crossing the network boundaries.  This GW
+   function provides VNI and tunnel-IP-address translation.  The use
+   case in which local downstream-assigned VNIs or VSIDs can be used
+   (like MPLS labels) is described by [RFC8365].
+
+   While VNIs are globally significant within each DC, there are two
+   possibilities in the interconnect network:
+
+   1.  Globally unique VNIs in the interconnect network.  In this case,
+       the GWs and PEs in the interconnect network will agree on a
+       common VNI for a given EVI.  The RT to be used in the
+       interconnect network can be autoderived from the agreed-upon
+       interconnect VNI.  The VNI used inside each DC MAY be the same as
+       the interconnect VNI.
+
+   2.  Downstream-assigned VNIs in the interconnect network.  In this
+       case, the GWs and PEs MUST use the proper RTs to import/export
+       the EVPN routes.  Note that even if the VNI is downstream
+       assigned in the interconnect network, and unlike option (a), it
+       only identifies the <Ethernet Tag, GW> pair and not the <Ethernet
+       Tag, egress PE> pair.  The VNI used inside each DC MAY be the
+       same as the interconnect VNI.  GWs SHOULD support multiple VNI
+       spaces per EVI (one per interconnect network they are connected
+       to).
+
+   In both options, NVEs inside a DC only have to be aware of a single
+   VNI space, and only GWs will handle the complexity of managing
+   multiple VNI spaces.  In addition to VNI translation above, the GWs
+   will provide translation of the tunnel source IP for the packets
+   generated from the NVEs, using their own IP address.  GWs will use
+   that IP address as the BGP next hop in all the EVPN updates to the
+   interconnect network.
+
+   The following sections provide more details about these two options.
+
+4.6.1.  Globally Unique VNIs in the Interconnect Network
+
+   Considering Figure 2, if a host H1 in NVO-1 needs to communicate with
+   a host H2 in NVO-2, and assuming that different VNIs are used in each
+   DC for the same EVI (e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2), then
+   the VNIs MUST be translated to a common interconnect VNI (e.g., VNI-
+   100) on the GWs.  Each GW is provisioned with a VNI translation
+   mapping so that it can translate the VNI in the control plane when
+   sending BGP EVPN route updates to the interconnect network.  In other
+   words, GW1 and GW2 MUST be configured to map VNI-10 to VNI-100 in the
+   BGP update messages for H1's MAC route.  This mapping is also used to
+   translate the VNI in the data plane in both directions: that is,
+   VNI-10 to VNI-100 when the packet is received from NVO-1 and the
+   reverse mapping from VNI-100 to VNI-10 when the packet is received
+   from the remote NVO-2 network and needs to be forwarded to NVO-1.
+
+   The procedures described in Section 4.4 will be followed, considering
+   that the VNIs advertised/received by the GWs will be translated
+   accordingly.
+
+4.6.2.  Downstream-Assigned VNIs in the Interconnect Network
+
+   In this case, if a host H1 in NVO-1 needs to communicate with a host
+   H2 in NVO-2, and assuming that different VNIs are used in each DC for
+   the same EVI, e.g., VNI-10 in NVO-1 and VNI-20 in NVO-2, then the
+   VNIs MUST be translated as in Section 4.6.1.  However, in this case,
+   there is no need to translate to a common interconnect VNI on the
+   GWs.  Each GW can translate the VNI received in an EVPN update to a
+   locally assigned VNI advertised to the interconnect network.  Each GW
+   can use a different interconnect VNI; hence, this VNI does not need
+   to be agreed upon on all the GWs and PEs of the interconnect network.
+
+   The procedures described in Section 4.4 will be followed, taking into
+   account the considerations above for the VNI translation.
+
+5.  Security Considerations
+
+   This document applies existing specifications to a number of
+   interconnect models.  The security considerations included in those
+   documents, such as [RFC7432], [RFC8365], [RFC7623], [RFC4761], and
+   [RFC4762] apply to this document whenever those technologies are
+   used.
+
+   As discussed, [RFC8365] discusses two main DCI solution groups: "DCI
+   using GWs" and "DCI using ASBRs".  This document specifies the
+   solutions that correspond to the "DCI using GWs" group.  It is
+   important to note that the use of GWs provides a superior level of
+   security on a per-tenant basis, compared to the use of ASBRs.  This
+   is due to the fact that GWs need to perform a MAC lookup on the
+   frames being received from the WAN, and they apply security
+   procedures, such as filtering of undesired frames, filtering of
+   frames with a source MAC that matches a protected MAC in the DC, or
+   application of MAC-duplication procedures defined in [RFC7432].  On
+   ASBRs, though, traffic is forwarded based on a label or VNI swap, and
+   there is usually no visibility of the encapsulated frames, which can
+   carry malicious traffic.
+
+   In addition, the GW optimizations specified in this document provide
+   additional protection of the DC tenant systems.  For instance, the
+   MAC-address advertisement control and Unknown MAC Route defined in
+   Section 3.5.1 protect the DC NVEs from being overwhelmed with an
+   excessive number of MAC/IP routes being learned on the GWs from the
+   WAN.  The ARP/ND flooding control described in Section 3.5.2 can
+   reduce/suppress broadcast storms being injected from the WAN.
+
+   Finally, the reader should be aware of the potential security
+   implications of designing a DCI with the decoupled interconnect
+   solution (Section 3) or the integrated interconnect solution
+   (Section 4).  In the decoupled interconnect solution, the DC is
+   typically easier to protect from the WAN, since each GW has a single
+   logical link to one WAN PE, whereas in the Integrated solution, the
+   GW has logical links to all the WAN PEs that are attached to the
+   tenant.  In either model, proper control plane and data plane
+   policies should be put in place in the GWs in order to protect the DC
+   from potential attacks coming from the WAN.
+
+6.  IANA Considerations
+
+   This document has no IANA actions.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4761]  Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
+              LAN Service (VPLS) Using BGP for Auto-Discovery and
+              Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
+              <https://www.rfc-editor.org/info/rfc4761>.
+
+   [RFC4762]  Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
+              LAN Service (VPLS) Using Label Distribution Protocol (LDP)
+              Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
+              <https://www.rfc-editor.org/info/rfc4762>.
+
+   [RFC6074]  Rosen, E., Davie, B., Radoaca, V., and W. Luo,
+              "Provisioning, Auto-Discovery, and Signaling in Layer 2
+              Virtual Private Networks (L2VPNs)", RFC 6074,
+              DOI 10.17487/RFC6074, January 2011,
+              <https://www.rfc-editor.org/info/rfc6074>.
+
+   [RFC7041]  Balus, F., Ed., Sajassi, A., Ed., and N. Bitar, Ed.,
+              "Extensions to the Virtual Private LAN Service (VPLS)
+              Provider Edge (PE) Model for Provider Backbone Bridging",
+              RFC 7041, DOI 10.17487/RFC7041, November 2013,
+              <https://www.rfc-editor.org/info/rfc7041>.
+
+   [RFC7432]  Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
+              Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
+              Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
+              2015, <https://www.rfc-editor.org/info/rfc7432>.
+
+   [RFC7543]  Jeng, H., Jalil, L., Bonica, R., Patel, K., and L. Yong,
+              "Covering Prefixes Outbound Route Filter for BGP-4",
+              RFC 7543, DOI 10.17487/RFC7543, May 2015,
+              <https://www.rfc-editor.org/info/rfc7543>.
+
+   [RFC7623]  Sajassi, A., Ed., Salam, S., Bitar, N., Isaac, A., and W.
+              Henderickx, "Provider Backbone Bridging Combined with
+              Ethernet VPN (PBB-EVPN)", RFC 7623, DOI 10.17487/RFC7623,
+              September 2015, <https://www.rfc-editor.org/info/rfc7623>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8365]  Sajassi, A., Ed., Drake, J., Ed., Bitar, N., Shekhar, R.,
+              Uttaro, J., and W. Henderickx, "A Network Virtualization
+              Overlay Solution Using Ethernet VPN (EVPN)", RFC 8365,
+              DOI 10.17487/RFC8365, March 2018,
+              <https://www.rfc-editor.org/info/rfc8365>.
+
+   [RFC9012]  Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
+              "The BGP Tunnel Encapsulation Attribute", RFC 9012,
+              DOI 10.17487/RFC9012, April 2021,
+              <https://www.rfc-editor.org/info/rfc9012>.
+
+7.2.  Informative References
+
+   [IEEE.802.1AG]
+              IEEE, "IEEE Standard for Local and Metropolitan Area
+              Networks Virtual Bridged Local Area Networks Amendment 5:
+              Connectivity Fault Management", IEEE standard 802.1ag-
+              2007, January 2008.
+
+   [IEEE.802.1Q]
+              IEEE, "IEEE Standard for Local and metropolitan area
+              networks--Bridges and Bridged Networks", IEEE standard 
+              802.1Q-2014, DOI 10.1109/IEEESTD.2014.6991462, December
+              2014, <https://doi.org/10.1109/IEEESTD.2014.6991462>.
+
+   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
+              Label Switching Architecture", RFC 3031,
+              DOI 10.17487/RFC3031, January 2001,
+              <https://www.rfc-editor.org/info/rfc3031>.
+
+   [RFC4023]  Worster, T., Rekhter, Y., and E. Rosen, Ed.,
+              "Encapsulating MPLS in IP or Generic Routing Encapsulation
+              (GRE)", RFC 4023, DOI 10.17487/RFC4023, March 2005,
+              <https://www.rfc-editor.org/info/rfc4023>.
+
+   [RFC4684]  Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
+              R., Patel, K., and J. Guichard, "Constrained Route
+              Distribution for Border Gateway Protocol/MultiProtocol
+              Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
+              Private Networks (VPNs)", RFC 4684, DOI 10.17487/RFC4684,
+              November 2006, <https://www.rfc-editor.org/info/rfc4684>.
+
+   [RFC6870]  Muley, P., Ed. and M. Aissaoui, Ed., "Pseudowire
+              Preferential Forwarding Status Bit", RFC 6870,
+              DOI 10.17487/RFC6870, February 2013,
+              <https://www.rfc-editor.org/info/rfc6870>.
+
+   [RFC7348]  Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
+              L., Sridhar, T., Bursell, M., and C. Wright, "Virtual
+              eXtensible Local Area Network (VXLAN): A Framework for
+              Overlaying Virtualized Layer 2 Networks over Layer 3
+              Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014,
+              <https://www.rfc-editor.org/info/rfc7348>.
+
+   [RFC7637]  Garg, P., Ed. and Y. Wang, Ed., "NVGRE: Network
+              Virtualization Using Generic Routing Encapsulation",
+              RFC 7637, DOI 10.17487/RFC7637, September 2015,
+              <https://www.rfc-editor.org/info/rfc7637>.
+
+   [VIRTUAL-ES]
+              Sajassi, A., Brissette, P., Schell, R., Drake, J. E., and
+              J. Rabadan, "EVPN Virtual Ethernet Segment", Work in
+              Progress, Internet-Draft, draft-ietf-bess-evpn-virtual-
+              eth-segment-06, 9 March 2020,
+              <https://tools.ietf.org/html/draft-ietf-bess-evpn-virtual-
+              eth-segment-06>.
+
+   [Y.1731]   ITU-T, "OAM functions and mechanisms for Ethernet based
+              networks", ITU-T Recommendation Y.1731, August 2019.
+
+Acknowledgments
+
+   The authors would like to thank Neil Hart, Vinod Prabhu, and Kiran
+   Nagaraj for their valuable comments and feedback.  We would also like
+   to thank Martin Vigoureux and Alvaro Retana for their detailed
+   reviews and comments.
+
+Contributors
+
+   In addition to the authors listed on the front page, the following
+   coauthors have also contributed to this document:
+
+   Ravi Shekhar
+   Juniper Networks
+
+
+   Anil Lohiya
+   Juniper Networks
+
+
+   Wen Lin
+   Juniper Networks
+
+
+   Florin Balus
+   Cisco
+
+
+   Patrice Brissette
+   Cisco
+
+
+   Senad Palislamovic
+   Nokia
+
+
+   Dennis Cai
+   Alibaba
+
+
+Authors' Addresses
+
+   Jorge Rabadan (editor)
+   Nokia
+   777 E. Middlefield Road
+   Mountain View, CA 94043
+   United States of America
+
+   Email: jorge.rabadan@nokia.com
+
+
+   Senthil Sathappan
+   Nokia
+
+   Email: senthil.sathappan@nokia.com
+
+
+   Wim Henderickx
+   Nokia
+
+   Email: wim.henderickx@nokia.com
+
+
+   Ali Sajassi
+   Cisco
+
+   Email: sajassi@cisco.com
+
+
+   John Drake
+   Juniper
+
+   Email: jdrake@juniper.net