< draft-rabadan-nvo3-evpn-applicability-00.txt   draft-rabadan-nvo3-evpn-applicability-01.txt >
NVO3 Workgroup J. Rabadan, Ed. NVO3 Workgroup J. Rabadan, Ed.
Internet Draft M. Bocci Internet Draft M. Bocci
Intended status: Informational Nokia Intended status: Informational Nokia
S. Boutros S. Boutros
WMware WMware
Expires: May 3, 2018 October 30, 2017 A. Sajassi
Cisco
Expires: August 13, 2018 February 9, 2018
Applicability of EVPN to NVO3 Networks Applicability of EVPN to NVO3 Networks
draft-rabadan-nvo3-evpn-applicability-00 draft-rabadan-nvo3-evpn-applicability-01
Abstract Abstract
In NVO3 networks, Network Virtualization Edge (NVE) devices sit at In NVO3 networks, Network Virtualization Edge (NVE) devices sit at
the edge of the underlay network and provide Layer-2 and Layer-3 the edge of the underlay network and provide Layer-2 and Layer-3
connectivity among Tenant Systems (TSes) of the same tenant. The NVEs connectivity among Tenant Systems (TSes) of the same tenant. The NVEs
need to build and maintain mapping tables so that they can deliver need to build and maintain mapping tables so that they can deliver
encapsulated packets to their intended destination NVE(s). While encapsulated packets to their intended destination NVE(s). While
there are different options to create and disseminate the mapping there are different options to create and disseminate the mapping
table entries, NVEs may exchange that information directly among table entries, NVEs may exchange that information directly among
skipping to change at page 1, line 44 skipping to change at page 2, line 4
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 3, 2018. This Internet-Draft will expire on August 13, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. EVPN and NVO3 Terminology . . . . . . . . . . . . . . . . . . . 3 2. EVPN and NVO3 Terminology . . . . . . . . . . . . . . . . . . . 3
3. Why Is EVPN Needed In NVO3 Networks? . . . . . . . . . . . . . 5 3. Why Is EVPN Needed In NVO3 Networks? . . . . . . . . . . . . . 6
4. Applicability of EVPN to NVO3 Networks . . . . . . . . . . . . 7 4. Applicability of EVPN to NVO3 Networks . . . . . . . . . . . . 8
4.1. EVPN Route Types used in NVO3 Networks . . . . . . . . . . 7 4.1. EVPN Route Types used in NVO3 Networks . . . . . . . . . . 8
4.2. EVPN Basic Applicability For Layer-2 Services . . . . . . . 8 4.2. EVPN Basic Applicability For Layer-2 Services . . . . . . . 9
4.2.1. Auto-Provisioning of the NVE services . . . . . . . . . 9 4.2.1. Auto-Discovery and Auto-Provisioning of ES,
4.2.2. Remote NVE Auto-Discovery . . . . . . . . . . . . . . . 10 Multi-Homing PEs and NVE services . . . . . . . . . . . 10
4.2.3. Distribution Of Tenant MAC and IP Information . . . . . 10 4.2.2. Remote NVE Auto-Discovery . . . . . . . . . . . . . . . 11
4.3. EVPN Basic Applicability for Layer-3 Services . . . . . . . 11 4.2.3. Distribution Of Tenant MAC and IP Information . . . . . 12
4.3. EVPN Basic Applicability for Layer-3 Services . . . . . . . 13
4.4. EVPN as a Control Plane for NVO3 Encapsulations and 4.4. EVPN as a Control Plane for NVO3 Encapsulations and
GENEVE . . . . . . . . . . . . . . . . . . . . . . . . . . 13 GENEVE . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.5. EVPN OAM and application to NVO3 . . . . . . . . . . . . . 14 4.5. EVPN OAM and application to NVO3 . . . . . . . . . . . . . 15
4.6. EVPN as the control plane for NVO3 security . . . . . . . . 14 4.6. EVPN as the control plane for NVO3 security . . . . . . . . 16
4.7. Advanced EVPN Features For NVO3 Networks . . . . . . . . . 14 4.7. Advanced EVPN Features For NVO3 Networks . . . . . . . . . 16
4.7.1. Virtual Machine (VM) Mobility . . . . . . . . . . . . . 14 4.7.1. Virtual Machine (VM) Mobility . . . . . . . . . . . . . 16
4.7.2. MAC Protection, Duplication Detection and Loop 4.7.2. MAC Protection, Duplication Detection and Loop
Protection . . . . . . . . . . . . . . . . . . . . . . 15 Protection . . . . . . . . . . . . . . . . . . . . . . 16
4.7.3. Reduction/Optimization of BUM Traffic In Layer-2 4.7.3. Reduction/Optimization of BUM Traffic In Layer-2
Services . . . . . . . . . . . . . . . . . . . . . . . 15 Services . . . . . . . . . . . . . . . . . . . . . . . 17
4.7.4. Ingress Replication (IR) Optimization For BUM Traffic . 16
4.7.5. EVPN Multi-homing . . . . . . . . . . . . . . . . . . . 17 4.7.4. Ingress Replication (IR) Optimization For BUM Traffic . 18
4.7.5. EVPN Multi-homing . . . . . . . . . . . . . . . . . . . 18
4.7.6. EVPN Recursive Resolution for Inter-Subnet Unicast 4.7.6. EVPN Recursive Resolution for Inter-Subnet Unicast
Forwarding . . . . . . . . . . . . . . . . . . . . . . 18 Forwarding . . . . . . . . . . . . . . . . . . . . . . 19
4.7.7. EVPN Optimized Inter-Subnet Multicast Forwarding . . . 19 4.7.7. EVPN Optimized Inter-Subnet Multicast Forwarding . . . 21
4.7.8. Data Center Interconnect (DCI) . . . . . . . . . . . . 19 4.7.8. Data Center Interconnect (DCI) . . . . . . . . . . . . 21
5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 20 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 22
6. Conventions used in this document . . . . . . . . . . . . . . . 20 6. Conventions used in this document . . . . . . . . . . . . . . . 22
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1 Normative References . . . . . . . . . . . . . . . . . . . . 21 9.1 Normative References . . . . . . . . . . . . . . . . . . . . 23
9.2 Informative References . . . . . . . . . . . . . . . . . . . 21 9.2 Informative References . . . . . . . . . . . . . . . . . . . 23
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 25
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
In NVO3 networks, Network Virtualization Edge (NVE) devices sit at In NVO3 networks, Network Virtualization Edge (NVE) devices sit at
the edge of the underlay network and provide Layer-2 and Layer-3 the edge of the underlay network and provide Layer-2 and Layer-3
connectivity among Tenant Systems (TSes) of the same tenant. The NVEs connectivity among Tenant Systems (TSes) of the same tenant. The NVEs
need to build and maintain mapping tables so that they can deliver need to build and maintain mapping tables so that they can deliver
encapsulated packets to their intended destination NVE(s). While encapsulated packets to their intended destination NVE(s). While
there are different options to create and disseminate the mapping there are different options to create and disseminate the mapping
table entries, NVEs may exchange that information directly among table entries, NVEs may exchange that information directly among
skipping to change at page 3, line 45 skipping to change at page 3, line 48
TOR/Leaf switches or Data Center Gateways. Note that Network TOR/Leaf switches or Data Center Gateways. Note that Network
Virtualization Authorities (NVAs) may be used to provide the Virtualization Authorities (NVAs) may be used to provide the
forwarding information to the NVEs, and in that case, EVPN could be forwarding information to the NVEs, and in that case, EVPN could be
used to disseminate the information across multiple federated NVAs. used to disseminate the information across multiple federated NVAs.
The applicability of EVPN would then be similar to the one described The applicability of EVPN would then be similar to the one described
in this document. However, for simplicity, the description assumes in this document. However, for simplicity, the description assumes
control-plane communication among NVE(s). control-plane communication among NVE(s).
2. EVPN and NVO3 Terminology 2. EVPN and NVO3 Terminology
o EVPN: Ethernet Virtual Private Networks, as described in [RFC7432].
o PE: Provider Edge router.
o NVO3 or Overlay tunnels: Network Virtualization Over Layer-3
tunnels. In this document, NVO3 tunnels or simply Overlay tunnels
will be used interchangeably. Both terms refer to a way to
encapsulate tenant frames or packets into IP packets whose IP
Source Addresses (SA) or Destination Addresses (DA) belong to the
underlay IP address space, and identify NVEs connected to the same
underlay network. Examples of NVO3 tunnel encapsulations are VXLAN
[RFC7348], [GENEVE] or MPLSoUDP [RFC7510].
o VXLAN: Virtual eXtensible Local Area Network, an NVO3 encapsulation
defined in [RFC7348].
o GENEVE: Generic Network Virtualization Encapsulation, an NVO3
encapsulation defined in [GENEVE].
o CLOS: a multistage network topology described in [CLOS1953], where
all the edge switches (or Leafs) are connected to all the core
switches (or Spines). Typically used in Data Centers nowadays.
o ECMP: Equal Cost Multi-Path.
o NVE: Network Virtualization Edge is a network entity that sits at o NVE: Network Virtualization Edge is a network entity that sits at
the edge of an underlay network and implements L2 and/or L3 network the edge of an underlay network and implements L2 and/or L3 network
virtualization functions. The network-facing side of the NVE uses virtualization functions. The network-facing side of the NVE uses
the underlying L3 network to tunnel tenant frames to and from other the underlying L3 network to tunnel tenant frames to and from other
NVEs. The tenant-facing side of the NVE sends and receives Ethernet NVEs. The tenant-facing side of the NVE sends and receives Ethernet
frames to and from individual Tenant Systems. In this document, an frames to and from individual Tenant Systems. In this document, an
NVE could be implemented as a virtual switch within a hypervisor, a NVE could be implemented as a virtual switch within a hypervisor, a
switch or a router, and runs EVPN in the control-plane. switch or a router, and runs EVPN in the control-plane.
o EVI: or EVPN Instance. It is a Layer-2 Virtual Network that uses an o EVI: or EVPN Instance. It is a Layer-2 Virtual Network that uses an
skipping to change at page 5, line 26 skipping to change at page 6, line 5
logical interface that connects a BD instance (or a BT) to an IP- logical interface that connects a BD instance (or a BT) to an IP-
VRF and allows to forward packets with destination in a different VRF and allows to forward packets with destination in a different
subnet. subnet.
o ES: Ethernet Segment. When a Tenant System (TS) is connected to one o ES: Ethernet Segment. When a Tenant System (TS) is connected to one
or more NVEs via a set of Ethernet links, then that set of links is or more NVEs via a set of Ethernet links, then that set of links is
referred to as an 'Ethernet segment'. Each ES is represented by a referred to as an 'Ethernet segment'. Each ES is represented by a
unique Ethernet Segment Identifier (ESI) in the NVO3 network and unique Ethernet Segment Identifier (ESI) in the NVO3 network and
the ESI is used in EVPN routes that are specific to that ES. the ESI is used in EVPN routes that are specific to that ES.
o NVO3 or Overlay tunnels: Network Virtualization Over Layer-3 o DF and NDF: they refer to Designated Forwarder and Non-Designated
tunnels. In this document, NVO3 tunnels or simply Overlay tunnels Forwarder, which are the roles that a given PE can have in a given
will be used interchangeably. Both terms refer to a way to ES.
encapsulate tenant frames or packets into IP packets whose IP
Source Addresses (SA) or Destination Addresses (DA) belong to the
underlay IP address space, and identify NVEs connected to the same
underlay network. Examples of NVO3 tunnel encapsulations are VXLAN
[RFC7348], [GENEVE] or MPLSoUDP [RFC7510].
o VNI: Virtual Network Identifier. Irrespective of the NVO3 o VNI: Virtual Network Identifier. Irrespective of the NVO3
encapsulation, the tunnel header always includes a VNI that is encapsulation, the tunnel header always includes a VNI that is
added at the ingress NVE (based on the mapping table lookup) and added at the ingress NVE (based on the mapping table lookup) and
identifies the BT at the egress NVE. This VNI is called VNI in identifies the BT at the egress NVE. This VNI is called VNI in
VXLAN or GENEVE, VSID in nvGRE or Label in MPLSoGRE or MPLSoUDP. VXLAN or GENEVE, VSID in nvGRE or Label in MPLSoGRE or MPLSoUDP.
This document will refer to VNI as a generic Virtual Network This document will refer to VNI as a generic Virtual Network
Identifier for any NVO3 encapsulation. Identifier for any NVO3 encapsulation.
o BUM: Broadcast, Unknown unicast and Multicast frames. o BUM: Broadcast, Unknown unicast and Multicast frames.
o SA and DA: they refer to Source Address and Destination Address. o SA and DA: they refer to Source Address and Destination Address.
They are used along with MAC or IP, e.g. IP SA or MAC DA. They are used along with MAC or IP, e.g. IP SA or MAC DA.
o RT and RD: they refer to Route Target and Route Distinguisher.
o PTA: Provider Multicast Service Interface Tunnel Attribute.
o RT-1, RT-2, RT-3, etc.: they refer to Route Type followed by the
type number as defined in the IANA registry for EVPN route types.
o TS: Tenant System.
o ARP and ND: they refer to Address Resolution Protocol and Neighbor
Discovery protocol.
3. Why Is EVPN Needed In NVO3 Networks? 3. Why Is EVPN Needed In NVO3 Networks?
Data Centers have adopted NVO3 architectures mostly due to the issues Data Centers have adopted NVO3 architectures mostly due to the issues
discussed in [RFC7364]. The architecture of a Data Center is nowadays discussed in [RFC7364]. The architecture of a Data Center is nowadays
based on a CLOS design, where every Leaf is connected to a layer of based on a CLOS design, where every Leaf is connected to a layer of
Spines, and there is a number of ECMP paths between any two leaf Spines, and there is a number of ECMP paths between any two leaf
nodes. All the links between Leaf and Spine nodes are routed links, nodes. All the links between Leaf and Spine nodes are routed links,
forming what we also know as an underlay IP Fabric. The underlay IP forming what we also know as an underlay IP Fabric. The underlay IP
Fabric does not have issues with loops or flooding (like old Spanning Fabric does not have issues with loops or flooding (like old Spanning
Tree Data Center designs did), convergence is fast and ECMP provides Tree Data Center designs did), convergence is fast and ECMP provides
a fairly optimal bandwidth utilization on all the links. a fairly optimal bandwidth utilization on all the links.
On this architecture and as discussed by [RFC7364] multi-tenant On this architecture and as discussed by [RFC7364] multi-tenant
intra-subnet and inter-subnet connectivity services are provided by intra-subnet and inter-subnet connectivity services are provided by
NVO3 tunnels, being VXLAN [RFC7348] or [GENEVE] two examples of such NVO3 tunnels, being VXLAN [RFC7348] or [GENEVE] two examples of such
tunnels. tunnels.
Why is a control-plane protocol along with NVO3 tunnels required? Why is a control-plane protocol along with NVO3 tunnels required?
There are three main reasons: There are three main reasons:
a) Auto-discovery of the remote NVEs that are attached to the same BD a) Auto-discovery of the remote NVEs that are attached to the same
as the ingress NVE is. VPN instance (Layer-2 and/or Layer-3) as the ingress NVE is.
b) Dissemination of the MAC/IP host information so that mapping b) Dissemination of the MAC/IP host information so that mapping
tables can be populated on the remote NVEs. tables can be populated on the remote NVEs.
c) Advanced features such as MAC Mobility, MAC Protection, BUM c) Advanced features such as MAC Mobility, MAC Protection, BUM and
traffic reduction/suppression, Multi-homing, etc. ARP/ND traffic reduction/suppression, Multi-homing, Prefix
Independent Convergence (PIC) like functionality, Fast
Convergence, etc.
A possible approach to achieve points (a) and (b) above is "Flood and A possible approach to achieve points (a) and (b) above for
Learn". "Flood and Learn" refers to not using a specific control- multipoint Ethernet services, is "Flood and Learn". "Flood and Learn"
plane on the NVEs, but rather "Flood" BUM traffic from the ingress refers to not using a specific control-plane on the NVEs, but rather
NVE to all the egress NVEs attached to the same BD. The egress NVEs "Flood" BUM traffic from the ingress NVE to all the egress NVEs
may then use data path MAC SA "Learning" on the frames received over attached to the same BD. The egress NVEs may then use data path MAC
the NVO3 tunnels. When the destination host replies back and the SA "Learning" on the frames received over the NVO3 tunnels. When the
frames arrive at the NVE that initially flooded BUM frames, the NVE destination host replies back and the frames arrive at the NVE that
will also "Learn" the MAC SA of the frame encapsulated on the NVO3 initially flooded BUM frames, the NVE will also "Learn" the MAC SA of
tunnel. This approach has the following drawbacks: the frame encapsulated on the NVO3 tunnel. This approach has the
following drawbacks:
o In order to Flood a given BUM frame, the ingress NVE must know the o In order to Flood a given BUM frame, the ingress NVE must know the
IP addresses of the remote NVEs attached to the same BD. This may IP addresses of the remote NVEs attached to the same BD. This may
be done as follows: be done as follows:
- The remote tunnel IP addresses can be statically provisioned on - The remote tunnel IP addresses can be statically provisioned on
the ingress NVE. If the ingress NVE receives an access BUM frame the ingress NVE. If the ingress NVE receives a BUM frame for the
for the BD, it will do ingress replication and will send the BD on an ingress AC, it will do ingress replication and will send
frame to all the configured egress NVE IP DAs in the BD. the frame to all the configured egress NVE IP DAs in the BD.
- All the NVEs attached to the same BD can subscribe to an underlay - All the NVEs attached to the same BD can subscribe to an underlay
IP Multicast Group that is dedicated to that BD. When an ingress IP Multicast Group that is dedicated to that BD. When an ingress
NVE receives a BUM frame on an ingress AC, it will send a single NVE receives a BUM frame on an ingress AC, it will send a single
copy of the frame encapsulated into an NVO3 tunnel, using the copy of the frame encapsulated into an NVO3 tunnel, using the
multicast address as IP DA of the tunnel. This solution requires multicast address as IP DA of the tunnel. This solution requires
PIM in the underlay network and the association of individual BDs PIM in the underlay network and the association of individual BDs
to underlay IP multicast groups. to underlay IP multicast groups.
o "Flood and Learn" solves the issues of auto-discovery and learning o "Flood and Learn" solves the issues of auto-discovery and learning
skipping to change at page 8, line 18 skipping to change at page 9, line 18
|1 |Ethernet Auto-Discovery |Multi-homing: | |1 |Ethernet Auto-Discovery |Multi-homing: |
| | | Per-ES: Mass withdrawal | | | | Per-ES: Mass withdrawal |
| | | Per-EVI: aliasing/backup | | | | Per-EVI: aliasing/backup |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|2 |MAC/IP Advertisement |Host MAC/IP dissemination | |2 |MAC/IP Advertisement |Host MAC/IP dissemination |
| | |Supports MAC mobility and protection | | | |Supports MAC mobility and protection |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|3 |Inclusive Multicast |NVE discovery and BUM flooding tree | |3 |Inclusive Multicast |NVE discovery and BUM flooding tree |
| |Ethernet Tag |setup | | |Ethernet Tag |setup |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|4 |Ethernet Segment |Multi-homing: DF Election | |4 |Ethernet Segment |Multi-homing: ES auto-discovery and |
| | |DF Election |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|5 |IP Prefix |IP Prefix dissemination | |5 |IP Prefix |IP Prefix dissemination |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|6 |Selective Multicast |Indicate interest for a multicast | |6 |Selective Multicast |Indicate interest for a multicast |
| |Ethernet Tag |S,G or *,G | | |Ethernet Tag |S,G or *,G |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|7 |IGMP Join Synch |Multi-homing: S,G or *,G state synch | |7 |IGMP Join Synch |Multi-homing: S,G or *,G state synch |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
|8 |IGMP Leave Synch |Multi-homing: S,G or *,G leave synch | |8 |IGMP Leave Synch |Multi-homing: S,G or *,G leave synch |
+----+------------------------+-------------------------------------+ +----+------------------------+-------------------------------------+
skipping to change at page 9, line 42 skipping to change at page 10, line 42
TS3 are connected to it. The five represented NVEs are attached to TS3 are connected to it. The five represented NVEs are attached to
BD1 and are connected to the same underlay IP network. That is, BD1 and are connected to the same underlay IP network. That is,
each NVE learns the remote NVEs' loopback addresses via underlay each NVE learns the remote NVEs' loopback addresses via underlay
routing protocol. routing protocol.
o NVE1 is deployed as a virtual switch in a Hypervisor with IP-A as o NVE1 is deployed as a virtual switch in a Hypervisor with IP-A as
underlay loopback IP address. The rest of the NVEs in Figure 1 are underlay loopback IP address. The rest of the NVEs in Figure 1 are
physical switches and TS2/TS3 are multi-homed to them. TS1 is a physical switches and TS2/TS3 are multi-homed to them. TS1 is a
virtual machine, identified by MAC1 and IP1. virtual machine, identified by MAC1 and IP1.
4.2.1. Auto-Provisioning of the NVE services 4.2.1. Auto-Discovery and Auto-Provisioning of ES, Multi-Homing PEs and
NVE services
When deploying a Layer-2 Service for a tenant in an NVO3 network, all Auto-discovery is one of the basic capabilities of EVPN. The
the NVEs attached to the same subnet must be configured with a MAC- provisioning of EVPN components in NVEs is significantly automated,
VRF and the BD for the subnet, as well as certain parameters for simplifying the deployment of services and minimizing manual
them. Note that, if the EVPN service model is VLAN-based or VLAN- operations that are prone to human error.
bundle, implementations do not normally have a specific provisioning
for the BD (since it is in that case the same construct as the MAC-
VRF).
EVPN allows auto-deriving as many MAC-VRF parameters as possible. As These are some of the Auto-Discovery and Auto-Provisioning
an example: capabilities available in EVPN:
o The MAC-VRF's RT and RD for the EVPN routes may be auto-derived. o Automation on Ethernet Segments (ES): an ES is defined as a group
of NVEs that are attached to the same TS or network. An ES is
identified by an Ethernet Segment Identifier (ESI) in the control
plane, but neither the ESI nor the NVEs that share the same ES are
required to be manually provisioned in the local NVE:
- If the multi-homed TS or network are running protocols such as
LACP (Link Aggregation Control Protocol), MSTP (Multiple-instance
Spanning Tree Protocol), G.8032, etc. and all the NVEs in the ES
can listen to the protocol PDUs to uniquely identify the multi-
homed TS/network, then the ESI can be "auto-sensed" or "auto-
provisioned" following the guidelines in [RFC7432] section 5.
- As described in [RFC7432], EVPN can also auto-derive the BGP
parameters required to advertise the presence of a local ES in
the control plane (RT and RD). Local ESes are advertised using
RT-4s and the ESI-import Route-Target used by RT-4s can be auto-
derived based on the procedures of [RFC7432], section 7.6.
- By listening to other RT-4s that match the local ESI and import
RT, an NVE can also auto-discover the other NVEs participating in
the multi-homing for the ES.
- Once the NVE has auto-discovered all the NVEs attached to the
same ES, the NVE can automatically perform the DF Election
algorithm (which determines the NVE that will forward traffic to
the multi-homed TS/network). EVPN guarantees that all the NVEs in
the ES have a consistent DF Election.
o Auto-provisioning of services: when deploying a Layer-2 Service for
a tenant in an NVO3 network, all the NVEs attached to the same
subnet must be configured with a MAC-VRF and the BD for the subnet,
as well as certain parameters for them. Note that, if the EVPN
service model is VLAN-based or VLAN-bundle, implementations do not
normally have a specific provisioning for the BD (since it is in
that case the same construct as the MAC-VRF). EVPN allows auto-
deriving as many MAC-VRF parameters as possible. As an example, the
MAC-VRF's RT and RD for the EVPN routes may be auto-derived.
Section 5.1.2.1 in [EVPN-OVERLAY] specifies how to auto-derive a Section 5.1.2.1 in [EVPN-OVERLAY] specifies how to auto-derive a
MAC-VRF's RT as long as VLAN-based service model is implemented. MAC-VRF's RT as long as VLAN-based service model is implemented.
[RFC7432] specifies how to auto-derive the RD. [RFC7432] specifies how to auto-derive the RD.
o The EVPN Multi-homing parameters can also be auto-derived. If the
TS is connected to the multi-homed NVEs via LAG and LACP, the ESI
can be auto-derived from the LACP information as described in
[RFC7432], section 5. The ESI-import Route-Target can also be auto-
derived based on the procedures of [RFC7432], section 7.6.
4.2.2. Remote NVE Auto-Discovery 4.2.2. Remote NVE Auto-Discovery
Auto-discovery is one of the basic capabilities of EVPN. Auto- Auto-discovery via MP-BGP is used to discover the remote NVEs
discovery via MP-BGP is used to discover the remote NVEs attached to attached to a given BD, NVEs participating in a given redundancy
a given BD, NVEs participating in a given redundancy group, the group, the tunnel encapsulation types supported by an NVE, etc.
tunnel encapsulation types supported by an NVE, etc.
In particular, when a new MAC-VRF and BD are enabled, the NVE will In particular, when a new MAC-VRF and BD are enabled, the NVE will
advertise a new RT-3. Besides other fields, the RT-3 will encode the advertise a new RT-3. Besides other fields, the RT-3 will encode the
IP address of the advertising NVE, the Ethernet Tag (which is zero in IP address of the advertising NVE, the Ethernet Tag (which is zero in
case of VLAN-based and VLAN-bundle models) and also a PMSI Tunnel case of VLAN-based and VLAN-bundle models) and also a PMSI Tunnel
Attribute (PTA) that indicates the information about the intended way Attribute (PTA) that indicates the information about the intended way
to deliver BUM traffic for the BD. to deliver BUM traffic for the BD.
In the example of Figure 1, when MAC-VRF1/BD1 are enabled, NVE1 will In the example of Figure 1, when MAC-VRF1/BD1 are enabled, NVE1 will
send an RT-3 including its own IP address, Ethernet-Tag for BD1 and send an RT-3 including its own IP address, Ethernet-Tag for BD1 and
skipping to change at page 14, line 4 skipping to change at page 15, line 30
applicable to any other NVO3 encapsulation, in particular GENEVE. applicable to any other NVO3 encapsulation, in particular GENEVE.
The NVO3 working group has been working on different data plane The NVO3 working group has been working on different data plane
encapsulations. The Generic Network Virtualization Encapsulation encapsulations. The Generic Network Virtualization Encapsulation
[GENEVE] has been recommended to be the proposed standard for NVO3 [GENEVE] has been recommended to be the proposed standard for NVO3
Encapsulation. The EVPN control plane can signal the GENEVE Encapsulation. The EVPN control plane can signal the GENEVE
encapsulation type in the BGP Tunnel Encapsulation Extended Community encapsulation type in the BGP Tunnel Encapsulation Extended Community
(see [TUNNEL-ENCAP]). (see [TUNNEL-ENCAP]).
The NVO3 encapsulation design team has made a recommendation in The NVO3 encapsulation design team has made a recommendation in
[NVO3-ENCAP] for a control plane to: [NVO3-ENCAP] for a control plane to:
1- Negotiate a subset of GENEVE option TLVs that can be carried on a 1- Negotiate a subset of GENEVE option TLVs that can be carried on a
GENEVE tunnel GENEVE tunnel
2- Enforce an order for GENEVE option TLVs and 2- Enforce an order for GENEVE option TLVs and
3- Limit the total number of options that could be carried on a 3- Limit the total number of options that could be carried on a
GENEVE tunnel. GENEVE tunnel.
The EVPN control plane can easily extend the BGP Tunnel Encapsulation The EVPN control plane can easily extend the BGP Tunnel Encapsulation
Attribute sub-TLV [TUNNEL-ENCAP] to specify the GENEVE tunnel options Attribute sub-TLV [TUNNEL-ENCAP] to specify the GENEVE tunnel options
that can be received or transmitted over a GENEVE tunnels by a given that can be received or transmitted over a GENEVE tunnels by a given
NVE. NVE. [EVPN-GENEVE] describes the EVPN control plane extensions to
support GENEVE.
4.5. EVPN OAM and application to NVO3 4.5. EVPN OAM and application to NVO3
EVPN OAM (as in [EVPN-LSP-PING]) defines mechanisms to detect data EVPN OAM (as in [EVPN-LSP-PING]) defines mechanisms to detect data
plane failures in an EVPN deployment over an MPLS network. These plane failures in an EVPN deployment over an MPLS network. These
mechanisms detect failures related to P2P and P2MP connectivity, for mechanisms detect failures related to P2P and P2MP connectivity, for
multi-tenant unicast and multicast L2 traffic, between multi-tenant multi-tenant unicast and multicast L2 traffic, between multi-tenant
access nodes connected to EVPN PE(s), and in a single-homed, single- access nodes connected to EVPN PE(s), and in a single-homed, single-
active or all-active redundancy model. active or all-active redundancy model.
skipping to change at page 19, line 31 skipping to change at page 21, line 31
Figure 4 EVPN for L3 - Recursive Resolution example Figure 4 EVPN for L3 - Recursive Resolution example
4.7.7. EVPN Optimized Inter-Subnet Multicast Forwarding 4.7.7. EVPN Optimized Inter-Subnet Multicast Forwarding
The concept of the SBD described in section 4.7.6 is also used in The concept of the SBD described in section 4.7.6 is also used in
[OISM] for the procedures related to Inter Subnet Multicast [OISM] for the procedures related to Inter Subnet Multicast
Forwarding across BDs of the same tenant. For instance, [OISM] allows Forwarding across BDs of the same tenant. For instance, [OISM] allows
the efficient forwarding of IP multicast traffic from any BD to any the efficient forwarding of IP multicast traffic from any BD to any
other BD (or even to the same BD where the Source resides). The other BD (or even to the same BD where the Source resides). The
[OISM] procedures are supported along with EVPN multi-homing, and for [OISM] procedures are supported along with EVPN multi-homing, and for
any tree allowed on NVO3 networks, including IR or AR. any tree allowed on NVO3 networks, including IR or AR. [OISM] also
describes the interoperability between EVPN and other multicast
technologies such as MVPN (Multicast VPN) and PIM for inter-subnet
multicast.
[EVPN-MVPN] describes another potential solution to support EVPN to
MVPN interoperability.
4.7.8. Data Center Interconnect (DCI) 4.7.8. Data Center Interconnect (DCI)
Tenant Layer-2 and Layer-3 services deployed on NVO3 networks must be Tenant Layer-2 and Layer-3 services deployed on NVO3 networks must be
extended to remote NVO3 networks that are connected via non-NOV3 WAN extended to remote NVO3 networks that are connected via non-NOV3 WAN
networks (mostly MPLS based WAN networks). [EVPN-DCI] defines some networks (mostly MPLS based WAN networks). [EVPN-DCI] defines some
architectural models that can be used to interconnect NVO3 networks architectural models that can be used to interconnect NVO3 networks
via MPLS WAN networks. via MPLS WAN networks.
When NVO3 networks are connected by MPLS WAN networks, [EVPN-DCI] When NVO3 networks are connected by MPLS WAN networks, [EVPN-DCI]
skipping to change at page 20, line 24 skipping to change at page 22, line 30
underlay network and maintain multicast states for tenant BDs. underlay network and maintain multicast states for tenant BDs.
This document justifies the use of EVPN for NVO3 networks, discusses This document justifies the use of EVPN for NVO3 networks, discusses
its applicability to basic Layer-2 and Layer-3 connectivity its applicability to basic Layer-2 and Layer-3 connectivity
requirements, as well as advanced features such as MAC-mobility, MAC requirements, as well as advanced features such as MAC-mobility, MAC
Protection and Loop Protection, multi-homing, DCI and much more. Protection and Loop Protection, multi-homing, DCI and much more.
6. Conventions used in this document 6. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC-2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
In this document, these words will appear with that interpretation capitals, as shown here.
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
In this document, the characters ">>" preceding an indented line(s)
indicates a compliance requirement statement using the key words
listed above. This convention aids reviewers in quickly identifying
or finding the explicit compliance requirements of this RFC.
7. Security Considerations 7. Security Considerations
This section will be added in future versions. This section will be added in future versions.
8. IANA Considerations 8. IANA Considerations
None. None.
9. References 9. References
skipping to change at page 21, line 21 skipping to change at page 23, line 21
[RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y. [RFC7365] Lasserre, M., Balus, F., Morin, T., Bitar, N., and Y.
Rekhter, "Framework for Data Center (DC) Network Virtualization", Rekhter, "Framework for Data Center (DC) Network Virtualization",
RFC 7365, DOI 10.17487/RFC7365, October 2014, <http://www.rfc- RFC 7365, DOI 10.17487/RFC7365, October 2014, <http://www.rfc-
editor.org/info/rfc7365>. editor.org/info/rfc7365>.
[RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L., [RFC7364] Narten, T., Ed., Gray, E., Ed., Black, D., Fang, L.,
Kreeger, L., and M. Napierala, "Problem Statement: Overlays for Kreeger, L., and M. Napierala, "Problem Statement: Overlays for
Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October Network Virtualization", RFC 7364, DOI 10.17487/RFC7364, October
2014, <http://www.rfc-editor.org/info/rfc7364>. 2014, <http://www.rfc-editor.org/info/rfc7364>.
[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>.
[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>.
9.2 Informative References 9.2 Informative References
[IP-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN", [IP-PREFIX] Rabadan et al., "IP Prefix Advertisement in EVPN",
draft-ietf-bess-evpn-prefix-advertisement-08, work in progress, draft-ietf-bess-evpn-prefix-advertisement-08, work in progress,
October, 2017. October, 2017.
[INTER-SUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN", [INTER-SUBNET] Sajassi et al., "IP Inter-Subnet Forwarding in EVPN",
draft-ietf-bess-evpn-inter-subnet-forwarding-03, work in progress, draft-ietf-bess-evpn-inter-subnet-forwarding-03, work in progress,
February, 2017 February, 2017
skipping to change at page 23, line 18 skipping to change at page 25, line 26
editor.org/info/rfc7348>. editor.org/info/rfc7348>.
[RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black, [RFC7510] Xu, X., Sheth, N., Yong, L., Callon, R., and D. Black,
"Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April "Encapsulating MPLS in UDP", RFC 7510, DOI 10.17487/RFC7510, April
2015, <http://www.rfc-editor.org/info/rfc7510>. 2015, <http://www.rfc-editor.org/info/rfc7510>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006,
<http://www.rfc-editor.org/info/rfc4364>. <http://www.rfc-editor.org/info/rfc4364>.
[CLOS1953] Clos, C., "A Study of Non-Blocking Switching Networks",
The Bell System Technical Journal, Vol. 32(2), DOI 10.1002/j.1538-
7305.1953.tb01433.x, March 1953.
[EVPN-GENEVE] Boutros et al., "EVPN control plane for Geneve",
draft-boutros-bess-evpn-geneve-01, work in progress, February 2018.
[EVPN-MVPN] Sajassi et al., "Seamless Multicast Interoperability
between EVPN and MVPN PEs", draft-sajassi-bess-evpn-mvpn-seamless-
interop-00, work in progress, July 2017.
10. Acknowledgments 10. Acknowledgments
11. Contributors 11. Contributors
12. Authors' Addresses 12. Authors' Addresses
Jorge Rabadan Jorge Rabadan (Editor)
Nokia Nokia
777 E. Middlefield Road 777 E. Middlefield Road
Mountain View, CA 94043 USA Mountain View, CA 94043 USA
Email: jorge.rabadan@nokia.com Email: jorge.rabadan@nokia.com
Sami Boutros Sami Boutros
VMware VMware
Email: sboutros@vmware.com Email: sboutros@vmware.com
Matthew Bocci Matthew Bocci
Nokia Nokia
Email: matthew.bocci@nokia.com Email: matthew.bocci@nokia.com
Ali Sajassi
Cisco
Email: sajassi@cisco.com
 End of changes. 32 change blocks. 
96 lines changed or deleted 182 lines changed or added

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