draft-ietf-bess-dci-evpn-overlay-08.txt   draft-ietf-bess-dci-evpn-overlay-09.txt 
BESS Workgroup J. Rabadan (Ed.) BESS Workgroup J. Rabadan (Ed.)
Internet Draft S. Sathappan Internet Draft S. Sathappan
Intended status: Standards Track W. Henderickx Intended status: Standards Track W. Henderickx
Nokia Updates: 7432 Nokia
A. Sajassi A. Sajassi
Cisco Cisco
J. Drake J. Drake
Juniper Juniper
Expires: August 12, 2018 February 8, 2018 Expires: August 24, 2018 February 20, 2018
Interconnect Solution for EVPN Overlay networks Interconnect Solution for EVPN Overlay networks
draft-ietf-bess-dci-evpn-overlay-08 draft-ietf-bess-dci-evpn-overlay-09
Abstract Abstract
This document describes how Network Virtualization Overlays (NVO) can This document describes how Network Virtualization Overlays (NVO) can
be connected to a Wide Area Network (WAN) in order to extend the be connected to a Wide Area Network (WAN) in order to extend the
layer-2 connectivity required for some tenants. The solution analyzes layer-2 connectivity required for some tenants. The solution analyzes
the interaction between NVO networks running Ethernet Virtual Private the interaction between NVO networks running Ethernet Virtual Private
Networks (EVPN) and other L2VPN technologies used in the WAN, such as Networks (EVPN) and other L2VPN technologies used in the WAN, such as
Virtual Private LAN Services (VPLS), VPLS extensions for Provider Virtual Private LAN Services (VPLS), VPLS extensions for Provider
Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how
the existing Technical Specifications apply to the Interconnection the existing technical specifications apply to the Interconnection
and extends the EVPN procedures needed in some cases. In particular, and extends the EVPN procedures needed in some cases. In particular,
this document describes how EVPN routes are processed on Gateways this document describes how EVPN routes are processed on Gateways
(GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well
as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, as the Interconnect Ethernet Segment (I-ES) to provide multi-homing,
and the use of the Unknown MAC route to avoid MAC scale issues on and the use of the Unknown MAC route to avoid MAC scale issues on
Data Center Network Virtualization Edge (NVE) devices. Data Center Network Virtualization Edge (NVE) devices. The document
updates [RFC7432].
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 16 skipping to change at page 2, line 16
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 12, 2018. This Internet-Draft will expire on August 24, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 38 skipping to change at page 2, line 38
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3 1. Conventions and Terminology . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Decoupled Interconnect solution for EVPN overlay networks . . . 6 3. Decoupled Interconnect solution for EVPN overlay networks . . . 6
3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 6 3.1. Interconnect requirements . . . . . . . . . . . . . . . . . 7
3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 7 3.2. VLAN-based hand-off . . . . . . . . . . . . . . . . . . . . 8
3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 8 3.3. PW-based (Pseudowire-based) hand-off . . . . . . . . . . . 8
3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 8 3.4. Multi-homing solution on the GWs . . . . . . . . . . . . . 9
3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 9 3.5. Gateway Optimizations . . . . . . . . . . . . . . . . . . . 10
3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 9 3.5.1. MAC Address Advertisement Control . . . . . . . . . . . 10
3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 9 3.5.2. ARP/ND flooding control . . . . . . . . . . . . . . . . 11
3.5.3. Handling failures between GW and WAN Edge routers . . . 10 3.5.3. Handling failures between GW and WAN Edge routers . . . 11
4. Integrated Interconnect solution for EVPN overlay networks . . 10 4. Integrated Interconnect solution for EVPN overlay networks . . 12
4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 11 4.1. Interconnect requirements . . . . . . . . . . . . . . . . . 12
4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 12 4.2. VPLS Interconnect for EVPN-Overlay networks . . . . . . . . 13
4.2.1. Control/Data Plane setup procedures on the GWs . . . . 12 4.2.1. Control/Data Plane setup procedures on the GWs . . . . 13
4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 13 4.2.2. Multi-homing procedures on the GWs . . . . . . . . . . 14
4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 13 4.3. PBB-VPLS Interconnect for EVPN-Overlay networks . . . . . . 14
4.3.1. Control/Data Plane setup procedures on the GWs . . . . 13 4.3.1. Control/Data Plane setup procedures on the GWs . . . . 14
4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 14 4.3.2. Multi-homing procedures on the GWs . . . . . . . . . . 15
4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 14 4.4. EVPN-MPLS Interconnect for EVPN-Overlay networks . . . . . 15
4.4.1. Control Plane setup procedures on the GWs . . . . . . . 14 4.4.1. Control Plane setup procedures on the GWs . . . . . . . 15
4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 16 4.4.2. Data Plane setup procedures on the GWs . . . . . . . . 17
4.4.3. Multi-homing procedure extensions on the GWs . . . . . 17 4.4.3. Multi-homing procedure extensions on the GWs . . . . . 18
4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 19 4.4.4. Impact on MAC Mobility procedures . . . . . . . . . . . 20
4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 19 4.4.5. Gateway optimizations . . . . . . . . . . . . . . . . . 21
4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 20 4.4.6. Benefits of the EVPN-MPLS Interconnect solution . . . . 21
4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 21 4.5. PBB-EVPN Interconnect for EVPN-Overlay networks . . . . . . 22
4.5.1. Control/Data Plane setup procedures on the GWs . . . . 21 4.5.1. Control/Data Plane setup procedures on the GWs . . . . 22
4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 21 4.5.2. Multi-homing procedures on the GWs . . . . . . . . . . 23
4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 22 4.5.3. Impact on MAC Mobility procedures . . . . . . . . . . . 23
4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 22 4.5.4. Gateway optimizations . . . . . . . . . . . . . . . . . 23
4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 22 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks . . . . . 23
4.6.1. Globally unique VNIs in the Interconnect network . . . 23 4.6.1. Globally unique VNIs in the Interconnect network . . . 24
4.6.2. Downstream assigned VNIs in the Interconnect network . 23 4.6.2. Downstream assigned VNIs in the Interconnect network . 25
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 24 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 25
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 25 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . . 25 7.1. Normative References . . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . . 26 7.2. Informative References . . . . . . . . . . . . . . . . . . 27
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 28
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 27 10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
1. Conventions and Terminology 1. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
AC: Attachment Circuit. AC: Attachment Circuit.
ARP: Address Resolution Protocol. ARP: Address Resolution Protocol.
BUM: it refers to the Broadcast, Unknown unicast and Multicast BUM: it refers to the Broadcast, Unknown unicast and Multicast
traffic. traffic.
CE: Customer Equipment.
CFM: Connectivity Fault Management. CFM: Connectivity Fault Management.
DC and DCI: Data Center and Data Center Interconnect. DC and DCI: Data Center and Data Center Interconnect.
DC RR(s) and WAN RR(s): it refers to the Data Center and Wide Area DC RR(s) and WAN RR(s): it refers to the Data Center and Wide Area
Network Route Reflectors, respectively. Network Route Reflectors, respectively.
DF and NDF: Designated Forwarder and Non-Designated Forwarder. DF and NDF: Designated Forwarder and Non-Designated Forwarder.
EVPN: Ethernet Virtual Private Network, as in [RFC7432]. EVPN: Ethernet Virtual Private Network, as in [RFC7432].
skipping to change at page 4, line 44 skipping to change at page 4, line 46
NVE: Network Virtualization Edge. NVE: Network Virtualization Edge.
NVGRE: Network Virtualization using Generic Routing Encapsulation. NVGRE: Network Virtualization using Generic Routing Encapsulation.
NVO: refers to Network Virtualization Overlays. NVO: refers to Network Virtualization Overlays.
OAM: Operations and Maintenance. OAM: Operations and Maintenance.
PBB: Provider Backbone Bridging. PBB: Provider Backbone Bridging.
PE: Provider Edge.
PW: Pseudowire. PW: Pseudowire.
RD: Route-Distinguisher. RD: Route-Distinguisher.
RT: Route-Target. RT: Route-Target.
S/C-TAG: It refers to a combination of Service Tag and Customer Tag S/C-TAG: It refers to a combination of Service Tag and Customer Tag
in a 802.1Q frame. in a 802.1Q frame.
TOR: Top-Of-Rack switch. TOR: Top-Of-Rack switch.
UMR: Unknown MAC Route.
VNI/VSID: refers to VXLAN/NVGRE virtual identifiers. VNI/VSID: refers to VXLAN/NVGRE virtual identifiers.
VPLS: Virtual Private LAN Service. VPLS: Virtual Private LAN Service.
VSI: Virtual Switch Instance or VPLS instance in a particular PE. VSI: Virtual Switch Instance or VPLS instance in a particular PE.
VXLAN: Virtual eXtensible LAN. VXLAN: Virtual eXtensible LAN.
2. Introduction 2. Introduction
skipping to change at page 5, line 31 skipping to change at page 5, line 36
encapsulation options. encapsulation options.
While this model provides a scalable and efficient multi-tenant While this model provides a scalable and efficient multi-tenant
solution within the Data Center, it might not be easily extended to 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 the Wide Area Network (WAN) in some cases due to the requirements and
existing deployed technologies. For instance, a Service Provider existing deployed technologies. For instance, a Service Provider
might have an already deployed Virtual Private LAN Service (VPLS) might have an already deployed Virtual Private LAN Service (VPLS)
[RFC4761][RFC4762], VPLS extensions for Provider Backbone Bridging [RFC4761][RFC4762], VPLS extensions for Provider Backbone Bridging
(PBB-VPLS) [RFC7041], EVPN [RFC7432] or PBB-EVPN [RFC7623] network (PBB-VPLS) [RFC7041], EVPN [RFC7432] or PBB-EVPN [RFC7623] network
that has to be used to interconnect Data Centers and WAN VPN users. A that has to be used to interconnect Data Centers and WAN VPN users. A
Gateway (GW) function is required in these cases. [EVPN-Overlays] Gateway (GW) function is required in these cases. In fact, [EVPN-
refers to the architectures described in this document as "DCI using Overlays] discusses two main Data Center Interconnect solution
GWs". groups: "DCI using GWs" and "DCI using ASBRs". This document
specifies the solutions that correspond to the "DCI using GWs" group.
This document describes a Interconnect solution for EVPN overlay This document describes a Interconnect solution for EVPN overlay
networks, assuming that the NVO Gateway (GW) and the WAN Edge networks, assuming that the NVO Gateway (GW) and the WAN Edge
functions can be decoupled in two separate systems or integrated into functions can be decoupled in two separate systems or integrated into
the same system. The former option will be referred as "Decoupled the same system. The former option will be referred as "Decoupled
Interconnect solution" throughout the document, whereas the latter Interconnect solution" throughout the document, whereas the latter
one will be referred as "Integrated Interconnect solution". one will be referred as "Integrated Interconnect solution".
The specified procedures are local to the redundant GWs connecting a The specified procedures are local to the redundant GWs connecting a
DC to the WAN. The document does not preclude any combination across DC to the WAN. The document does not preclude any combination across
different DCs for the same tenant. For instance, a "Decoupled" 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 GW1 and GW2 (for DC1) and an "Integrated"
solution can be used in GW3 and GW4 (for DC2). solution can be used in GW3 and GW4 (for DC2).
While the Gateways and WAN PEs use existing Technical Specifications While the Gateways and WAN PEs use existing specifications in some
in some cases, the document also defines extensions to these cases, the document also defines extensions so that the requirements
Technical Specifications so that the requirements of the of the Interconnection can be met. In particular, the document
Interconnection can be met. In particular, the following EVPN updates [RFC7432] on several aspects:
extensions are described:
o The Interconnect Ethernet Segment (I-ES). o The Interconnect Ethernet Segment (I-ES), an Ethernet Segment that
can be associated not only to a set of Ethernet links, as in
[RFC7432], but also to a set of PWs or other tunnels.
o The use of the Unknown MAC route in a DCI scenario. o The use of the Unknown MAC route in a DCI scenario.
o The processing of EVPN routes on Gateways with MAC-VRFs connecting o The processing of EVPN routes on Gateways with MAC-VRFs connecting
EVPN-Overlay to EVPN-MPLS networks. EVPN-Overlay and EVPN-MPLS networks, or EVPN-Overlay and EVPN-
Overlay networks.
3. Decoupled Interconnect solution for EVPN overlay networks 3. Decoupled Interconnect solution for EVPN overlay networks
This section describes the interconnect solution when the GW and WAN This section describes the interconnect solution when the GW and WAN
Edge functions are implemented in different systems. Figure 1 depicts Edge functions are implemented in different systems. Figure 1 depicts
the reference model described in this section. the reference model described in this section. Note that, although
not shown in Figure 1, GWs may have local ACs (Attachment Circuits).
+--+ +--+
|CE| |CE|
+--+ +--+
| |
+----+ +----+
+----| PE |----+ +----| PE |----+
+---------+ | +----+ | +---------+ +---------+ | +----+ | +---------+
+----+ | +---+ +----+ +----+ +---+ | +----+ +----+ | +---+ +----+ +----+ +---+ | +----+
|NVE1|--| | | |WAN | |WAN | | | |--|NVE3| |NVE1|--| | | |WAN | |WAN | | | |--|NVE3|
skipping to change at page 8, line 32 skipping to change at page 9, line 16
o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI o If a FEC128-based PW is used between the MAC-VRF (GW) and the VSI
(WAN Edge), the corresponding VCID MUST be provisioned on the MAC- (WAN Edge), the corresponding VCID MUST be provisioned on the MAC-
VRF and match the VCID used in the peer VSI at the WAN Edge router. VRF and match the VCID used in the peer VSI at the WAN Edge router.
o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used o If BGP Auto-discovery [RFC6074] and FEC129-based PWs are used
between the GW MAC-VRF and the WAN Edge VSI, the provisioning of 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 the VPLS-ID MUST be supported on the MAC-VRF and MUST match the
VPLS-ID used in the WAN Edge VSI. 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, as
opposed to only VLAN IDs as in [RFC7432]. Therefore the [RFC7432]
mapping definitions of VLAN-based, VLAN-bundle or VLAN-aware bundle
service interfaces are updated in this document to include the PW
label as follows:
o VLAN-Based Service Interface: the AC mapping to the MAC-VRF is
given by a unique combination of (PW label, optional inner VLAN
ID). In this context "optional VLAN ID" means a unique combination
of S/C-TAG or no tag at all. In case of no-tag, the point of
attachment to the MAC-VRF is strictly based on the PW label and the
service interface may be referred to as PW-Based Service Interface.
The rest of the VLAN-Based service characteristics are as per
[RFC7432].
o VLAN-Bundle Service Interface: the AC mapping to the MAC-VRF is
given by a unique combination of (PW label, VLAN ID range), where
VLAN ID range represents the S/C-TAG values included in a range.
The rest of the VLAN-Bundle service characteristics are as per
[RFC7432].
o VLAN-Aware Bundle Service Interface: the AC mapping to the Bridge
Table is given by a unique combination of (PW VC label, VLAN ID).
In this service interface, there are multiple Bridge Tables per
MAC-VRF, and each point of attachment to a Bridge Table has a
different (PW label, VLAN ID) combination. The rest of the VLAN-
Aware Bundle service characteristics are as per [RFC7432].
3.4. Multi-homing solution on the GWs 3.4. Multi-homing solution on the GWs
EVPN single-active multi-homing, i.e. per-service load-balancing EVPN single-active multi-homing, i.e. per-service load-balancing
multi-homing is required in this type of interconnect. multi-homing is required in this type of interconnect.
The GWs will be provisioned with a unique ES per WAN interconnect, The GWs will be provisioned with a unique ES per WAN interconnect,
and the hand-off attachment circuits or PWs between the GW and the and the hand-off attachment circuits or PWs between the GW and the
WAN Edge router will be assigned an ESI for such ES. The ESI will be WAN Edge router will be assigned an ESI for such ES. The ESI will be
administratively configured on the GWs according to the procedures in administratively configured on the GWs according to the procedures in
[RFC7432]. This Interconnect ES will be referred as "I-ES" hereafter, [RFC7432]. This Interconnect ES will be referred as "I-ES" hereafter,
skipping to change at page 9, line 22 skipping to change at page 10, line 37
The use of EVPN in NVO networks brings a significant number of The use of EVPN in NVO networks brings a significant number of
benefits as described in [EVPN-Overlays]. However, if multiple DCs benefits as described in [EVPN-Overlays]. However, if multiple DCs
are interconnected into a single EVI, each DC will have to import all are interconnected into a single EVI, each DC will have to import all
of the MAC addresses from each of the other DCs. of the MAC addresses from each of the other DCs.
Even if optimized BGP techniques like RT-constraint [RFC4684] are Even if optimized BGP techniques like RT-constraint [RFC4684] are
used, the number of MAC addresses to advertise or withdraw (in case 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 of failure) by the GWs of a given DC could overwhelm the NVEs within
that DC, particularly when the NVEs reside in the hypervisors. that DC, particularly when the NVEs reside in the hypervisors.
The solution specified in this document uses the 'Unknown MAC' route The solution specified in this document uses the 'Unknown MAC Route'
which is advertised into a given DC by each of the DC's GWs. This (UMR) which is advertised into a given DC by each of the DC's GWs.
route is a regular EVPN MAC/IP Advertisement route in which the MAC This route is defined in [RFC7543] and is a regular EVPN MAC/IP
Address Length is set to 48, the MAC address is set to Advertisement route in which the MAC Address Length is set to 48, the
00:00:00:00:00:00, the IP length is set to 0, and the ESI field is MAC address is set to 0, and the ESI field is set to the DC GW's I-
set to the DC GW's I-ESI. ESI.
An NVE within that DC that understands and process the Unknown MAC An NVE within that DC that understands and process the UMR will send
route will send unknown unicast frames to one of the DCs GWs, which unknown unicast frames to one of the DCs GWs, which will then forward
will then forward that packet to the correct egress PE. Note that, that packet to the correct egress PE. Note that, because the ESI is
because the ESI is set to the DC GW's I-ESI, all-active multi-homing set to the DC GW's I-ESI, all-active multi-homing can be applied to
can be applied to unknown unicast MAC addresses. An NVE that does not unknown unicast MAC addresses. An NVE that does not understand the
understand the Unknown MAC route will handle unknown unicast as Unknown MAC route will handle unknown unicast as described in
described in [RFC7432]. [RFC7432].
This document proposes that local policy determines whether MAC This document proposes that local policy determines whether MAC
addresses and/or the Unknown MAC route are advertised into a given addresses and/or the UMR are advertised into a given DC. As an
DC. As an example, when all the DC MAC addresses are learned in the example, when all the DC MAC addresses are learned in the
control/management plane, it may be appropriate to advertise only the control/management plane, it may be appropriate to advertise only the
Unknown MAC route. Advertising all the DC MAC addresses in the UMR. Advertising all the DC MAC addresses in the control/management
control/management plane is usually the case when the NVEs reside in plane is usually the case when the NVEs reside in hypervisors. Refer
hypervisors. Refer to [EVPN-Overlays] section 7. to [EVPN-Overlays] 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 DMG, until the V-spokes
learn each other's MAC addresses. In this document, two leaf switches
in the same DC are recommended 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 3.5.2. ARP/ND flooding control
Another optimization mechanism, naturally provided by EVPN in the Another optimization mechanism, naturally provided by EVPN in the
GWs, is the Proxy ARP/ND function. The GWs should build a Proxy 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 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 request/solicitation coming from the WAN, the GW does a Proxy
ARP/ND table lookup and replies as long as the information is ARP/ND table lookup and replies as long as the information is
available in its table. available in its table.
skipping to change at page 10, line 36 skipping to change at page 12, line 14
used to detect individual PW failures on both, the GW and WAN Edge used to detect individual PW failures on both, the GW and WAN Edge
router. router.
4. Integrated Interconnect solution for EVPN overlay networks 4. Integrated Interconnect solution for EVPN overlay networks
When the DC and the WAN are operated by the same administrative When the DC and the WAN are operated by the same administrative
entity, the Service Provider can decide to integrate the GW and WAN entity, the Service Provider can decide to integrate the GW and WAN
Edge PE functions in the same router for obvious CAPEX and OPEX Edge PE functions in the same router for obvious CAPEX and OPEX
saving reasons. This is illustrated in Figure 2. Note that this model saving reasons. This is illustrated in Figure 2. Note that this model
does not provide an explicit demarcation link between DC and WAN does not provide an explicit demarcation link between DC and WAN
anymore. anymore. Although not shown in Figure 2, note that the GWs may have
local ACs.
+--+ +--+
|CE| |CE|
+--+ +--+
| |
+----+ +----+
+----| PE |----+ +----| PE |----+
+---------+ | +----+ | +---------+ +---------+ | +----+ | +---------+
+----+ | +---+ +---+ | +----+ +----+ | +---+ +---+ | +----+
|NVE1|--| | | | | |--|NVE3| |NVE1|--| | | | | |--|NVE3|
skipping to change at page 12, line 17 skipping to change at page 13, line 29
not need to be the same as in the DC. not need to be the same as in the DC.
4.2. VPLS Interconnect for EVPN-Overlay networks 4.2. VPLS Interconnect for EVPN-Overlay networks
4.2.1. Control/Data Plane setup procedures on the GWs 4.2.1. Control/Data Plane setup procedures on the GWs
Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN Regular MPLS tunnels and TLDP/BGP sessions will be setup to the WAN
PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay PEs and RRs as per [RFC4761], [RFC4762], [RFC6074] and overlay
tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that tunnels and EVPN will be setup as per [EVPN-Overlays]. Note that
different route-targets for the DC and for the WAN are normally different route-targets for the DC and for the WAN are normally
required. A single type-1 RD per service may be used. 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 multi-homing, the GWs will be provisioned with an In order to support multi-homing, the GWs will be provisioned with an
I-ESI (see section 3.4), that will be unique per interconnection. All I-ESI (see section 3.4), that will be unique per interconnection. The
the [RFC7432] procedures are still followed for the I-ES, e.g. any I-ES in this case will represent the group of PWs to the WAN PEs and
MAC address learned from the WAN will be advertised to the DC with GWs. All the [RFC7432] procedures are still followed for the I-ES,
the I-ESI in the ESI field. 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 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 two different types of tunnel bindings instantiated in two different
split-horizon-groups: split-horizon-groups:
o VPLS PWs will be instantiated in the "WAN split-horizon-group". o VPLS PWs will be instantiated in the "WAN split-horizon-group".
o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated o Overlay tunnel bindings (e.g. VXLAN, NVGRE) will be instantiated
in the "DC split-horizon-group". in the "DC split-horizon-group".
Attachment circuits are also supported on the same MAC-VRF, but they Attachment circuits are also supported on the same MAC-VRF (although
will not be part of any of the above split-horizon-groups. 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 Traffic received in a given split-horizon-group will never be
forwarded to a member of the same split-horizon-group. forwarded to a member of the same split-horizon-group.
As far as BUM flooding is concerned, a flooding list will be composed As far as BUM flooding is concerned, a flooding list will be composed
of the sub-list created by the inclusive multicast routes and the of the sub-list created by the inclusive multicast routes and the
sub-list created for VPLS in the WAN. BUM frames received from a sub-list created for VPLS in the WAN. BUM frames received from a
local Attachment Circuit (AC) will be forwarded to the flooding list. 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 BUM frames received from the DC or the WAN will be forwarded to the
flooding list observing the split-horizon-group rule described above. flooding list observing the split-horizon-group rule described above.
skipping to change at page 19, line 51 skipping to change at page 21, line 17
from a different ES and the MAC Mobility procedures will kick in. from a different ES and the MAC Mobility procedures will kick in.
The sticky bit indication in the MAC Mobility extended community MUST The sticky bit indication in the MAC Mobility extended community MUST
be propagated between domains. be propagated between domains.
4.4.5. Gateway optimizations 4.4.5. Gateway optimizations
All the Gateway optimizations described in section 3.5 MAY be applied All the Gateway optimizations described in section 3.5 MAY be applied
to the GWs when the Interconnect is based on EVPN-MPLS. to the GWs when the Interconnect is based on EVPN-MPLS.
In particular, the use of the Unknown MAC route, as described in In particular, the use of the Unknown MAC Route, as described in
section 3.5.1, solves some transient packet duplication issues in section 3.5.1, solves some transient packet duplication issues in
cases of all-active multi-homing, as explained below. cases of all-active multi-homing, as explained below.
Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all- Consider the diagram in Figure 2 for EVPN-MPLS Interconnect and all-
active multi-homing, and the following sequence: active multi-homing, and the following sequence:
a) MAC Address M1 is advertised from NVE3 in EVI-1. 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 b) GW3 and GW4 learn M1 for EVI-1 and re-advertise M1 to the WAN
with I-ESI-2 in the ESI field. with I-ESI-2 in the ESI field.
c) GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following c) GW1 and GW2 learn M1 and install GW3/GW4 as next-hops following
the EVPN aliasing procedures. the EVPN aliasing procedures.
d) Before NVE1 learns M1, a packet arrives at NVE1 with d) Before NVE1 learns M1, a packet arrives at NVE1 with
destination M1. If the Unknown MAC route had not been destination M1. If the Unknown MAC Route had not been
advertised into the DC, NVE1 would have flooded the packet advertised into the DC, NVE1 would have flooded the packet
throughout the DC, in particular to both GW1 and GW2. If the throughout the DC, in particular to both GW1 and GW2. If the
same VNI/VSID is used for both known unicast and BUM traffic, same VNI/VSID is used for both known unicast and BUM traffic,
as is typically the case, there is no indication in the packet 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 that it is a BUM packet and both GW1 and GW2 would have
forwarded it, creating packet duplication. However, because the forwarded it, creating packet duplication. However, because the
Unknown MAC route had been advertised into the DC, NVE1 will Unknown MAC Route had been advertised into the DC, NVE1 will
unicast the packet to either GW1 or GW2. unicast the packet to either GW1 or GW2.
e) Since both GW1 and GW2 know M1, the GW receiving the packet e) Since both GW1 and GW2 know M1, the GW receiving the packet
will forward it to either GW3 or GW4. will forward it to either GW3 or GW4.
4.4.6. Benefits of the EVPN-MPLS Interconnect solution 4.4.6. Benefits of the EVPN-MPLS Interconnect solution
Besides retaining the EVPN attributes between Data Centers and The [EVPN-Overlays] "DCI using ASBRs" solution and the GW solution
throughout the WAN, the EVPN-MPLS Interconnect solution on the GWs with EVPN-MPLS Interconnect may be seen similar since they both
has some benefits compared to pure BGP EVPN RR or Inter-AS model B retain the EVPN attributes between Data Centers and throughout the
solutions without a gateway: WAN. However the EVPN-MPLS Interconnect solution on the GWs has
significant benefits compared to the "DCI using ASBRs" solution:
o The solution supports the connectivity of local attachment o As in any of the described GW models, this solution supports the
circuits on the GWs. connectivity of local attachment circuits on the GWs. This is
not possible in a "DCI using ASBRs" solution.
o Different data plane encapsulations can be supported in the DC o Different data plane encapsulations can be supported in the DC
and the WAN. and the WAN, while a uniform encapsulation is needed in the "DCI
using ASBRs" solution.
o Optimized multicast solution, with independent inclusive o Optimized multicast solution, with independent inclusive
multicast trees in DC and WAN. multicast trees in DC and WAN.
o MPLS Label aggregation: for the case where MPLS labels are o MPLS Label aggregation: for the case where MPLS labels are
signaled from the NVEs for MAC/IP Advertisement routes, this signaled from the NVEs for MAC/IP Advertisement routes, this
solution provides label aggregation. A remote PE MAY receive a solution provides label aggregation. A remote PE MAY receive a
single label per GW MAC-VRF as opposed to a label per NVE/MAC- 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 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 would receive only one label for all the routes advertised for a
skipping to change at page 22, line 27 skipping to change at page 23, line 43
from the B-component are considered local. from the B-component are considered local.
4.5.4. Gateway optimizations 4.5.4. Gateway optimizations
All the considerations explained in section 4.4.5 are applicable to All the considerations explained in section 4.4.5 are applicable to
the PBB-EVPN Interconnect option. the PBB-EVPN Interconnect option.
4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks 4.6. EVPN-VXLAN Interconnect for EVPN-Overlay networks
If EVPN for Overlay tunnels is supported in the WAN and a GW function 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. This is required, an end-to-end EVPN solution can be deployed. While
section focuses on the specific case of EVPN for VXLAN (EVPN-VXLAN multiple Overlay tunnel combinations at the WAN and the DC are
hereafter) and the impact on the [RFC7432] procedures. 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, The procedures described in section 4.4 apply to this section too,
only replacing EVPN-MPLS for EVPN-VXLAN control plane specifics and only replacing EVPN-MPLS for EVPN-VXLAN control plane specifics and
using [EVPN-Overlays] "Local Bias" procedures instead of section using [EVPN-Overlays] "Local Bias" procedures instead of section
4.4.3. Since there are no ESI-labels in VXLAN, GWs need to rely on 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- "Local Bias" to apply split-horizon on packets generated from the I-
ES and sent to the peer GW. ES and sent to the peer GW.
This use-case assumes that NVEs need to use the VNIs or VSIDs as a This use-case assumes that NVEs need to use the VNIs or VSIDs as a
globally unique identifiers within a data center, and a Gateway needs globally unique identifiers within a data center, and a Gateway needs
skipping to change at page 23, line 11 skipping to change at page 24, line 31
In this case, the GWs and PEs in the Interconnect network will 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 agree on a common VNI for a given EVI. The RT to be used in the
Interconnect network can be auto-derived from the agreed Interconnect network can be auto-derived from the agreed
Interconnect VNI. The VNI used inside each DC MAY be the same Interconnect VNI. The VNI used inside each DC MAY be the same
as the Interconnect VNI. as the Interconnect VNI.
b) Downstream assigned VNIs in the Interconnect network. b) Downstream assigned VNIs in the Interconnect network.
In this case, the GWs and PEs MUST use the proper RTs to 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 import/export the EVPN routes. Note that even if the VNI is
downstream assigned in the Interconnect network, and unlike downstream assigned in the Interconnect network, and unlike
option B, it only identifies the <Ethernet Tag, GW> pair and option (a), it only identifies the <Ethernet Tag, GW> pair and
not the <Ethernet Tag, egress PE> pair. The VNI used inside not the <Ethernet Tag, egress PE> pair. The VNI used inside
each DC MAY be the same as the Interconnect VNI. GWs SHOULD each DC MAY be the same as the Interconnect VNI. GWs SHOULD
support multiple VNI spaces per EVI (one per Interconnect support multiple VNI spaces per EVI (one per Interconnect
network they are connected to). network they are connected to).
In both options, NVEs inside a DC only have to be aware of a single 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 VNI space, and only GWs will handle the complexity of managing
multiple VNI spaces. In addition to VNI translation above, the GWs multiple VNI spaces. In addition to VNI translation above, the GWs
will provide translation of the tunnel source IP for the packets will provide translation of the tunnel source IP for the packets
generated from the NVEs, using their own IP address. GWs will use generated from the NVEs, using their own IP address. GWs will use
skipping to change at page 24, line 16 skipping to change at page 25, line 36
GW can translate the VNI received in an EVPN update to a locally GW can translate the VNI received in an EVPN update to a locally
assigned VNI advertised to the Interconnect network. Each GW can use assigned VNI advertised to the Interconnect network. Each GW can use
a different Interconnect VNI, hence this VNI does not need to be a different Interconnect VNI, hence this VNI does not need to be
agreed on all the GWs and PEs of the Interconnect network. agreed on all the GWs and PEs of the Interconnect network.
The procedures described in section 4.4 will be followed, taking the The procedures described in section 4.4 will be followed, taking the
considerations above for the VNI translation. considerations above for the VNI translation.
5. Security Considerations 5. Security Considerations
This document applies existing Technical Specifications to a number This document applies existing specifications to a number of
of Interconnect models. The Security Considerations included in those Interconnect models. The Security Considerations included in those
documents, such as [RFC7432], [EVPN-Overlays], [RFC7623], [RFC4761] documents, such as [RFC7432], [EVPN-Overlays], [RFC7623], [RFC4761]
and [RFC4762] apply to this document whenever those technologies are and [RFC4762] apply to this document whenever those technologies are
used. used.
[EVPN-Overlays] discusses two main DCI solution groups: "DCI using As discussed, [EVPN-Overlays] discusses two main DCI solution groups:
GWs" and "DCI using ASBRs". This document specifies the solutions "DCI using GWs" and "DCI using ASBRs". This document specifies the
that correspond to the "DCI using GWs" group. It is important to note solutions that correspond to the "DCI using GWs" group. It is
that use of GWs provide a superior level of security on a per tenant important to note that the use of GWs provide a superior level of
basis, compared to the use of ASBRs. This is due to the fact that GWs security on a per tenant basis, compared to the use of ASBRs. This is
need to perform a MAC lookup on the frames being received from the due to the fact that GWs need to perform a MAC lookup on the frames
WAN, and they apply security procedures, such as filtering of being received from the WAN, and they apply security procedures, such
undesired frames, filtering of frames with a source MAC that matches as filtering of undesired frames, filtering of frames with a source
a protected MAC in the DC or application of MAC duplication MAC that matches a protected MAC in the DC or application of MAC
procedures defined in [RFC7432]. On ASBRs though, traffic is duplication procedures defined in [RFC7432]. On ASBRs though, traffic
forwarded based on a label or VNI swap and there is usually no is forwarded based on a label or VNI swap and there is usually no
visibility of the encapsulated frames, which can carry malicious visibility of the encapsulated frames, which can carry malicious
traffic. traffic.
In addition, the GW optimizations specified in this document, provide In addition, the GW optimizations specified in this document, provide
additional protection of the DC Tenant Systems. For instance, the MAC additional protection of the DC Tenant Systems. For instance, the MAC
address advertisement control and Unknown MAC route defined in address advertisement control and Unknown MAC Route defined in
section 3.5.1 protect the DC NVEs from being overwhelmed with an section 3.5.1 protect the DC NVEs from being overwhelmed with an
excessive number MAC/IP routes being learned on the GWs from the WAN. excessive number MAC/IP routes being learned on the GWs from the WAN.
The ARP/ND flooding control described in 3.5.2 can reduce/suppress The ARP/ND flooding control described in 3.5.2 can reduce/suppress
broadcast storms being injected from the WAN. broadcast storms being injected from the WAN.
Finally, the reader should be aware of the potential security Finally, the reader should be aware of the potential security
implications of designing a DCI with the Decoupled Interconnect implications of designing a DCI with the Decoupled Interconnect
solution (section 2) or the Integrated Interconnect solution (section solution (section 3) or the Integrated Interconnect solution (section
3). In the Decoupled Interconnect solution the DC is typically easier 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 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 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 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 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 place in the GWs in order to protect the DC from potential attacks
coming from the WAN. coming from the WAN.
6. IANA Considerations 6. IANA Considerations
This document has no IANA actions. This document has no IANA actions.
skipping to change at page 26, line 17 skipping to change at page 27, line 36
January 11, 2018. January 11, 2018.
[RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with [RFC7623] Sajassi et al., "Provider Backbone Bridging Combined with
Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, <http://www.rfc- Ethernet VPN (PBB-EVPN)", RFC 7623, September, 2015, <http://www.rfc-
editor.org/info/rfc7623>. editor.org/info/rfc7623>.
[EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization [EVPN-Overlays] Sajassi-Drake et al., "A Network Virtualization
Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt, Overlay Solution using EVPN", draft-ietf-bess-evpn-overlay-11.txt,
work in progress, January, 2018 work in progress, January, 2018
[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>.
7.2. Informative References 7.2. Informative References
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk, [RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route Distribution for R., Patel, K., and J. Guichard, "Constrained Route Distribution for
Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS) Border Gateway Protocol/MultiProtocol Label Switching (BGP/MPLS)
Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684, Internet Protocol (IP) Virtual Private Networks (VPNs)", RFC 4684,
DOI 10.17487/RFC4684, November 2006, <http://www.rfc- DOI 10.17487/RFC4684, November 2006, <http://www.rfc-
editor.org/info/rfc4684>. editor.org/info/rfc4684>.
[RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
 End of changes. 38 change blocks. 
111 lines changed or deleted 176 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/