draft-ietf-bess-evpn-overlay-07.txt   draft-ietf-bess-evpn-overlay-08.txt 
L2VPN Workgroup A. Sajassi (Editor) BESS Workgroup A. Sajassi (Editor)
INTERNET-DRAFT Cisco INTERNET-DRAFT Cisco
Intended Status: Standards Track J. Drake (Editor) Intended Status: Standards Track J. Drake (Editor)
Juniper Juniper
N. Bitar N. Bitar
Nokia Nokia
R. Shekhar R. Shekhar
Juniper Juniper
J. Uttaro J. Uttaro
AT&T AT&T
W. Henderickx W. Henderickx
Nokia Nokia
Expires: June 1, 2017 December 1, 2016 Expires: September 27, 2017 March 27, 2017
A Network Virtualization Overlay Solution using EVPN A Network Virtualization Overlay Solution using EVPN
draft-ietf-bess-evpn-overlay-07 draft-ietf-bess-evpn-overlay-08
Abstract Abstract
This document describes how Ethernet VPN (EVPN) [RFC7432] can be used This document describes how Ethernet VPN (EVPN) can be used as an
as an Network Virtualization Overlay (NVO) solution and explores the Network Virtualization Overlay (NVO) solution and explores the
various tunnel encapsulation options over IP and their impact on the various tunnel encapsulation options over IP and their impact on the
EVPN control-plane and procedures. In particular, the following EVPN control-plane and procedures. In particular, the following
encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE. encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF 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
skipping to change at page 2, line 7 skipping to change at page 2, line 7
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/1id-abstracts.html http://www.ietf.org/1id-abstracts.html
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
Copyright and License Notice Copyright and License Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Specification of Requirements . . . . . . . . . . . . . . . . . 4 2 Specification of Requirements . . . . . . . . . . . . . . . . . 5
3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 EVPN Features . . . . . . . . . . . . . . . . . . . . . . . . . 5 4 EVPN Features . . . . . . . . . . . . . . . . . . . . . . . . . 6
5 Encapsulation Options for EVPN Overlays . . . . . . . . . . . . 7 5 Encapsulation Options for EVPN Overlays . . . . . . . . . . . . 7
5.1 VXLAN/NVGRE Encapsulation . . . . . . . . . . . . . . . . . 7 5.1 VXLAN/NVGRE Encapsulation . . . . . . . . . . . . . . . . . 7
5.1.1 Virtual Identifiers Scope . . . . . . . . . . . . . . . 8 5.1.1 Virtual Identifiers Scope . . . . . . . . . . . . . . . 8
5.1.1.1 Data Center Interconnect with Gateway . . . . . . . 8 5.1.1.1 Data Center Interconnect with Gateway . . . . . . . 8
5.1.1.2 Data Center Interconnect without Gateway . . . . . . 8 5.1.1.2 Data Center Interconnect without Gateway . . . . . . 9
5.1.2 Virtual Identifiers to EVI Mapping . . . . . . . . . . . 9 5.1.2 Virtual Identifiers to EVI Mapping . . . . . . . . . . . 9
5.1.2.1 Auto Derivation of RT . . . . . . . . . . . . . . . 10 5.1.2.1 Auto Derivation of RT . . . . . . . . . . . . . . . 10
5.1.3 Constructing EVPN BGP Routes . . . . . . . . . . . . . 11 5.1.3 Constructing EVPN BGP Routes . . . . . . . . . . . . . 11
5.2 MPLS over GRE . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 MPLS over GRE . . . . . . . . . . . . . . . . . . . . . . . 13
6 EVPN with Multiple Data Plane Encapsulations . . . . . . . . . 13 6 EVPN with Multiple Data Plane Encapsulations . . . . . . . . . 13
7 NVE Residing in Hypervisor . . . . . . . . . . . . . . . . . . 14 7 Single-Homing NVEs - NVE Residing in Hypervisor . . . . . . . . 14
7.1 Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE 7.1 Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE
Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 14 Encapsulation . . . . . . . . . . . . . . . . . . . . . . . 14
7.2 Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation . . 15 7.2 Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation . . 15
8 NVE Residing in ToR Switch . . . . . . . . . . . . . . . . . . 15 8 Multi-Homing NVEs - NVE Residing in ToR Switch . . . . . . . . 16
8.1 EVPN Multi-Homing Features . . . . . . . . . . . . . . . . 16 8.1 EVPN Multi-Homing Features . . . . . . . . . . . . . . . . 16
8.1.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . 16 8.1.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . 16
8.1.2 Fast Convergence and Mass Withdraw . . . . . . . . . . . 16 8.1.2 Fast Convergence and Mass Withdraw . . . . . . . . . . . 16
8.1.3 Split-Horizon . . . . . . . . . . . . . . . . . . . . . 16 8.1.3 Split-Horizon . . . . . . . . . . . . . . . . . . . . . 17
8.1.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 16 8.1.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 17
8.1.5 DF Election . . . . . . . . . . . . . . . . . . . . . . 17 8.1.5 DF Election . . . . . . . . . . . . . . . . . . . . . . 18
8.2 Impact on EVPN BGP Routes & Attributes . . . . . . . . . . . 18 8.2 Impact on EVPN BGP Routes & Attributes . . . . . . . . . . . 18
8.3 Impact on EVPN Procedures . . . . . . . . . . . . . . . . . 18 8.3 Impact on EVPN Procedures . . . . . . . . . . . . . . . . . 18
8.3.1 Split Horizon . . . . . . . . . . . . . . . . . . . . . 18 8.3.1 Split Horizon . . . . . . . . . . . . . . . . . . . . . 19
8.3.2 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 19 8.3.2 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 20
8.3.3 Unknown Unicast Traffic Designation . . . . . . . . . . 19 8.3.3 Unknown Unicast Traffic Designation . . . . . . . . . . 20
9 Support for Multicast . . . . . . . . . . . . . . . . . . . . . 20 9 Support for Multicast . . . . . . . . . . . . . . . . . . . . . 20
10 Data Center Interconnections - DCI . . . . . . . . . . . . . . 21 10 Data Center Interconnections - DCI . . . . . . . . . . . . . . 21
10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 21 10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 22
10.2 DCI using ASBRs . . . . . . . . . . . . . . . . . . . . . . 22 10.2 DCI using ASBRs . . . . . . . . . . . . . . . . . . . . . . 22
10.2.1 ASBR Functionality with NVEs in Hypervisors . . . . . . 23 10.2.1 ASBR Functionality with Single-Homing NVEs . . . . . . 23
10.2.2 ASBR Functionality with NVEs in TORs . . . . . . . . . 23 10.2.2 ASBR Functionality with Multi-Homing NVEs . . . . . . . 23
11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25 11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26
12 Security Considerations . . . . . . . . . . . . . . . . . . . 25 12 Security Considerations . . . . . . . . . . . . . . . . . . . 26
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1 Normative References . . . . . . . . . . . . . . . . . . . 26 14.1 Normative References . . . . . . . . . . . . . . . . . . . 27
14.2 Informative References . . . . . . . . . . . . . . . . . . 27 14.2 Informative References . . . . . . . . . . . . . . . . . . 27
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
1 Introduction 1 Introduction
In the context of this document, a Network Virtualization Overlay In the context of this document, a Network Virtualization Overlay
(NVO) is a solution to address the requirements of a multi-tenant (NVO) is a solution to address the requirements of a multi-tenant
data center, especially one with virtualized hosts, e.g., Virtual data center, especially one with virtualized hosts, e.g., Virtual
Machines (VMs) or virtual workloads. The key requirements of such a Machines (VMs) or virtual workloads. The key requirements of such a
solution, as described in [Problem-Statement], are: solution, as described in [Problem-Statement], are:
- Isolation of network traffic per tenant - Isolation of network traffic per tenant
skipping to change at page 4, line 34 skipping to change at page 4, line 34
The underlay network for NVO solutions is assumed to provide IP The underlay network for NVO solutions is assumed to provide IP
connectivity between NVO endpoints (NVEs). connectivity between NVO endpoints (NVEs).
This document describes how Ethernet VPN (EVPN) can be used as an NVO This document describes how Ethernet VPN (EVPN) can be used as an NVO
solution and explores applicability of EVPN functions and procedures. solution and explores applicability of EVPN functions and procedures.
In particular, it describes the various tunnel encapsulation options In particular, it describes the various tunnel encapsulation options
for EVPN over IP, and their impact on the EVPN control-plane and for EVPN over IP, and their impact on the EVPN control-plane and
procedures for two main scenarios: procedures for two main scenarios:
a) when the NVE resides in the hypervisor, and a) single-homing NVEs - when a NVE resides in the hypervisor, and
b) when the NVE resides in a Top of Rack (ToR) device b) multi-homing NVEs - when a NVE resides in a Top of Rack (ToR)
device
The possible encapsulation options for EVPN overlays that are The possible encapsulation options for EVPN overlays that are
analyzed in this document are: analyzed in this document are:
- VXLAN and NVGRE - VXLAN and NVGRE
- MPLS over GRE - MPLS over GRE
Before getting into the description of the different encapsulation Before getting into the description of the different encapsulation
options for EVPN over IP, it is important to highlight the EVPN options for EVPN over IP, it is important to highlight the EVPN
solution's main features, how those features are currently supported, solution's main features, how those features are currently supported,
and any impact that the encapsulation has on those features. and any impact that the encapsulation has on those features.
2 Specification of Requirements 2 Specification of Requirements
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", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [KEYWORDS].
3 Terminology 3 Terminology
Most of the terminology used in this documents comes from [RFC7432]
and [NVO3-FRWK].
NVO: Network Virtualization Overlay NVO: Network Virtualization Overlay
NVE: Network Virtualization Endpoint NVE: Network Virtualization Endpoint
VNI: Virtual Network Identifier (for VXLAN) VNI: Virtual Network Identifier (for VXLAN)
VSID: Virtual Subnet Identifier (for NVGRE) VSID: Virtual Subnet Identifier (for NVGRE)
EVPN: Ethernet VPN EVPN: Ethernet VPN
skipping to change at page 6, line 4 skipping to change at page 6, line 9
PEs attached to an Ethernet segment, is allowed to forward traffic PEs attached to an Ethernet segment, is allowed to forward traffic
to/from that Ethernet segment for a given VLAN, then the Ethernet to/from that Ethernet segment for a given VLAN, then the Ethernet
segment is defined to be operating in Single-Active redundancy mode. segment is defined to be operating in Single-Active redundancy mode.
All-Active Redundancy Mode: When all PEs attached to an Ethernet All-Active Redundancy Mode: When all PEs attached to an Ethernet
segment are allowed to forward known unicast traffic to/from that segment are allowed to forward known unicast traffic to/from that
Ethernet segment for a given VLAN, then the Ethernet segment is Ethernet segment for a given VLAN, then the Ethernet segment is
defined to be operating in All-Active redundancy mode. defined to be operating in All-Active redundancy mode.
4 EVPN Features 4 EVPN Features
EVPN was originally designed to support the requirements detailed in EVPN was originally designed to support the requirements detailed in
[RFC7209] and therefore has the following attributes which directly [RFC7209] and therefore has the following attributes which directly
address control plane scaling and ease of deployment issues. address control plane scaling and ease of deployment issues.
1) Control plane traffic is distributed with BGP and Broadcast and 1) Control plane information is distributed with BGP and Broadcast
Multicast traffic is sent using a shared multicast tree or with and Multicast traffic is sent using a shared multicast tree or with
ingress replication. ingress replication.
2) Control plane learning is used for MAC (and IP) addresses instead 2) Control plane learning is used for MAC (and IP) addresses instead
of data plane learning. The latter requires the flooding of unknown of data plane learning. The latter requires the flooding of unknown
unicast and ARP frames; whereas, the former does not require any unicast and ARP frames; whereas, the former does not require any
flooding. flooding.
3) Route Reflector is used to reduce a full mesh of BGP sessions 3) Route Reflectors are used to reduce a full mesh of BGP sessions
among PE devices to a single BGP session between a PE and the RR. among PE devices to a single BGP session between a PE and the RR.
Furthermore, RR hierarchy can be leveraged to scale the number of BGP Furthermore, RR hierarchy can be leveraged to scale the number of BGP
routes on the RR. routes on the RR.
4) Auto-discovery via BGP is used to discover PE devices 4) Auto-discovery via BGP is used to discover PE devices
participating in a given VPN, PE devices participating in a given participating in a given VPN, PE devices participating in a given
redundancy group, tunnel encapsulation types, multicast tunnel type, redundancy group, tunnel encapsulation types, multicast tunnel type,
multicast members, etc. multicast members, etc.
5) All-Active multihoming is used. This allows a given customer 5) All-Active multihoming is used. This allows a given customer
skipping to change at page 7, line 45 skipping to change at page 8, line 4
discards the frames with an inner VLAN tag. This mode of operation in discards the frames with an inner VLAN tag. This mode of operation in
[RFC7348] maps to VLAN Based Service in [RFC7432], where a tenant [RFC7348] maps to VLAN Based Service in [RFC7432], where a tenant
VLAN ID gets mapped to an EVPN instance (EVI). VLAN ID gets mapped to an EVPN instance (EVI).
VXLAN also provides an option of including an inner VLAN tag in the VXLAN also provides an option of including an inner VLAN tag in the
encapsulated frame, if explicitly configured at the VTEP. This mode encapsulated frame, if explicitly configured at the VTEP. This mode
of operation can map to VLAN Bundle Service in [RFC7432] because all of operation can map to VLAN Bundle Service in [RFC7432] because all
the tenant's tagged frames map to a single bridge table / MAC-VRF, the tenant's tagged frames map to a single bridge table / MAC-VRF,
and the inner VLAN tag is not used for lookup by the disposition PE and the inner VLAN tag is not used for lookup by the disposition PE
when performing VXLAN decapsulation as described in section 6 of when performing VXLAN decapsulation as described in section 6 of
[RFC7348]. [RFC7348].
[NVGRE] encapsulation is based on [GRE] and it mandates the inclusion [NVGRE] encapsulation is based on GRE encapsulation and it mandates
of the optional GRE Key field which carries the VSID. There is a one- the inclusion of the optional GRE Key field which carries the VSID.
to-one mapping between the VSID and the tenant VLAN ID, as described There is a one-to-one mapping between the VSID and the tenant VLAN
in [NVGRE] and the inclusion of an inner VLAN tag is prohibited. This ID, as described in [NVGRE] and the inclusion of an inner VLAN tag is
mode of operation in [NVGRE] maps to VLAN Based Service in prohibited. This mode of operation in [NVGRE] maps to VLAN Based
[RFC7432]. Service in [RFC7432].
As described in the next section there is no change to the encoding As described in the next section there is no change to the encoding
of EVPN routes to support VXLAN or NVGRE encapsulation except for the of EVPN routes to support VXLAN or NVGRE encapsulation except for the
use of BGP Encapsulation extended community to indicate the use of the BGP Encapsulation extended community to indicate the
encapsulation type (e.g., VxLAN or NVGRE). However, there is encapsulation type (e.g., VxLAN or NVGRE). However, there is
potential impact to the EVPN procedures depending on where the NVE is potential impact to the EVPN procedures depending on where the NVE is
located (i.e., in hypervisor or TOR) and whether multi-homing located (i.e., in hypervisor or TOR) and whether multi-homing
capabilities are required. capabilities are required.
5.1.1 Virtual Identifiers Scope 5.1.1 Virtual Identifiers Scope
Although VNIs are defined as 24-bit globally unique values, there are Although VNIs are defined as 24-bit globally unique values, there are
scenarios in which it is desirable to use a locally significant value scenarios in which it is desirable to use a locally significant value
for VNI, especially in the context of data center interconnect: for VNI, especially in the context of data center interconnect:
skipping to change at page 9, line 34 skipping to change at page 10, line 5
|<------ DC 1 -----> <---- DC2 ------>| |<------ DC 1 -----> <---- DC2 ------>|
Figure 2: Data Center Interconnect with ASBR Figure 2: Data Center Interconnect with ASBR
5.1.2 Virtual Identifiers to EVI Mapping 5.1.2 Virtual Identifiers to EVI Mapping
When the EVPN control plane is used in conjunction with VXLAN (or When the EVPN control plane is used in conjunction with VXLAN (or
NVGRE encapsulation), two options for mapping the VXLAN VNI (or NVGRE NVGRE encapsulation), two options for mapping the VXLAN VNI (or NVGRE
VSID) to an EVI are possible: VSID) to an EVI are possible:
1. Option 1: Single Subnet per EVI 1. Option 1: Single Broadcast Domain per EVI
In this option, a single subnet represented by a VNI is mapped to a In this option, a single Ethernet broadcast domain (e.g., subnet)
unique EVI. This corresponds to the VLAN Based service in [RFC7432], represented by a VNI is mapped to a unique EVI. This corresponds to
where a tenant VLAN ID gets mapped to an EVPN instance (EVI). As the VLAN Based service in [RFC7432], where a tenant-facing interface,
such, a BGP RD and RT is needed per VNI on every NVE. The advantage logical interface (e.g., represented by a VLAN ID) or physical, gets
of this model is that it allows the BGP RT constraint mechanisms to mapped to an EVPN instance (EVI). As such, a BGP RD and RT are needed
be used in order to limit the propagation and import of routes to per VNI on every NVE. The advantage of this model is that it allows
only the NVEs that are interested in a given VNI. The disadvantage of the BGP RT constraint mechanisms to be used in order to limit the
this model may be the provisioning overhead if RD and RT are not propagation and import of routes to only the NVEs that are interested
derived automatically from VNI. in a given VNI. The disadvantage of this model may be the
provisioning overhead if RD and RT are not derived automatically from
VNI.
In this option, the MAC-VRF table is identified by the RT in the In this option, the MAC-VRF table is identified by the RT in the
control plane and by the VNI in the data-plane. In this option, the control plane and by the VNI in the data-plane. In this option, the
specific MAC-VRF table corresponds to only a single bridge table. specific MAC-VRF table corresponds to only a single bridge table.
2. Option 2: Multiple Subnets per EVI 2. Option 2: Multiple Broadcast Domains per EVI
In this option, multiple subnets each represented by a unique VNI are In this option, multiple subnets each represented by a unique VNI are
mapped to a single EVI. For example, if a tenant has multiple mapped to a single EVI. For example, if a tenant has multiple
segments/subnets each represented by a VNI, then all the VNIs for segments/subnets each represented by a VNI, then all the VNIs for
that tenant are mapped to a single EVI - e.g., the EVI in this case that tenant are mapped to a single EVI - e.g., the EVI in this case
represents the tenant and not a subnet . This corresponds to the represents the tenant and not a subnet . This corresponds to the
VLAN-aware bundle service in [RFC7432]. The advantage of this model VLAN-aware bundle service in [RFC7432]. The advantage of this model
is that it doesn't require the provisioning of RD/RT per VNI. is that it doesn't require the provisioning of RD/RT per VNI.
However, this is a moot point if option 1 with auto-derivation is However, this is a moot point when compared to option 1 where auto-
used. The disadvantage of this model is that routes would be imported derivation is used. The disadvantage of this model is that routes
by NVEs that may not be interested in a given VNI. would be imported by NVEs that may not be interested in a given VNI.
In this option the MAC-VRF table is identified by the RT in the In this option the MAC-VRF table is identified by the RT in the
control plane and a specific bridge table for that MAC-VRF is control plane and a specific bridge table for that MAC-VRF is
identified by the <RT, Ethernet Tag ID> in the control plane. In this identified by the <RT, Ethernet Tag ID> in the control plane. In this
option, the VNI in the data-plane is sufficient to identify a option, the VNI in the data-plane is sufficient to identify a
specific bridge table. specific bridge table.
5.1.2.1 Auto Derivation of RT 5.1.2.1 Auto Derivation of RT
When the option of a single VNI per EVI is used, it is important to When the option of a single VNI per EVI is used, in order to simplify
auto-derive RT for EVPN BGP routes in order to simplify configuration configuration, the RT used for EVPN can be auto-derived. RD can be
for data center operations. RD can be auto generated as described in auto generated as described in [RFC7432] and RT can be auto-derived
[RFC7432] and RT can be auto-derived as described next. as described next.
Since a gateway PE as depicted in figure-1 participates in both the Since a gateway PE as depicted in figure-1 participates in both the
DCN and WAN BGP sessions, it is important that when RT values are DCN and WAN BGP sessions, it is important that when RT values are
auto-derived for VNIs, there is no conflict in RT spaces between DCN auto-derived from VNIs, there is no conflict in RT spaces between DCN
and WAN networks assuming that both are operating within the same AS. and WAN networks assuming that both are operating within the same AS.
Also, there can be scenarios where both VXLAN and NVGRE Also, there can be scenarios where both VXLAN and NVGRE
encapsulations may be needed within the same DCN and their encapsulations may be needed within the same DCN and their
corresponding VNIs are administered independently which means VNI corresponding VNIs are administered independently which means VNI
spaces can overlap. In order to ensure that no such conflict in RT spaces can overlap. In order to ensure that no such conflict in RT
spaces arises, RT values for DCNs are auto-derived as follow: spaces arises, RT values for DCNs are auto-derived as follow:
0 1 2 3 4 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| AS # |A| TYPE| D-ID |Service Instance ID| | AS # |A| TYPE| D-ID | Service ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+ +-----------------------------------------------+---------------+
| Service ID (Cont.) |
+-------------------------------+
- 2 bytes of global admin field of the RT is set to the AS number. - 2 bytes of global admin field of the RT is set to the AS number.
- Three least significant bytes of the local admin field of the RT is - Three least significant bytes of the local admin field of the RT is
set to the VNI, VSID, I-SID, or VID. set to the VNI, VSID, I-SID, or VID.
- The most significant bit of the local admin field of the RT is set - The most significant bit of the local admin field of the RT is set
as follow: as follow:
0: auto-derived 0: auto-derived
1: manually-derived 1: manually-derived
- The next 3 bits of the most significant byte of the local admin - The next 3 bits of the most significant byte of the local admin
field of the RT identifies the space in which the other 3 bytes are field of the RT identifies the space in which the other 3 bytes are
defined. The following spaces are defined: defined. The following spaces are defined:
0 : VID 0 : VID (802.1Q VLAN ID)
1 : VXLAN 1 : VXLAN
2 : NVGRE 2 : NVGRE
3 : I-SID 3 : I-SID
4 : EVI 4 : EVI
5 : dual-VID 5 : dual-VID (QinQ VLAN ID)
- The remaining 4 bits of the most significant byte of the local - The remaining 4 bits of the most significant byte of the local
admin field of the RT identifies the domain-id. The default value of admin field of the RT identifies the domain-id. The default value of
domain-id is zero indicating that only a single numbering space exist domain-id is zero indicating that only a single numbering space exist
for a given technology. However, if there are more than one number for a given technology. However, if there are more than one number
space exist for a given technology (e.g., overlapping VXLAN spaces), space exist for a given technology (e.g., overlapping VXLAN spaces),
then each of the number spaces need to be identify by their then each of the number spaces need to be identify by their
corresponding domain-id starting from 1. corresponding domain-id starting from 1.
5.1.3 Constructing EVPN BGP Routes 5.1.3 Constructing EVPN BGP Routes
skipping to change at page 11, line 45 skipping to change at page 12, line 16
in the MPLS header of a given packet by the ingress PE. This label is in the MPLS header of a given packet by the ingress PE. This label is
used upon receipt of that packet by the egress PE for disposition of used upon receipt of that packet by the egress PE for disposition of
that packet. This is very similar to the use of the VNI by the egress that packet. This is very similar to the use of the VNI by the egress
NVE, with the difference being that an MPLS label has local NVE, with the difference being that an MPLS label has local
significance while a VNI typically has global significance. significance while a VNI typically has global significance.
Accordingly, and specifically to support the option of locally- Accordingly, and specifically to support the option of locally-
assigned VNIs, the MPLS Label1 field in the MAC/IP Advertisement assigned VNIs, the MPLS Label1 field in the MAC/IP Advertisement
route, the MPLS label field in the Ethernet AD per EVI route, and the route, the MPLS label field in the Ethernet AD per EVI route, and the
MPLS label field in the PMSI Tunnel Attribute of the Inclusive MPLS label field in the PMSI Tunnel Attribute of the Inclusive
Multicast Ethernet Tag (IMET) route are used to carry the VNI. For Multicast Ethernet Tag (IMET) route are used to carry the VNI. For
the balance of this memo, the MPLS label field will be referred to as the balance of this memo, the above MPLS label fields will be
the VNI field. The VNI field is used for both local and global VNIs, referred to as the VNI field. The VNI field is used for both local
and for either case the entire 24-bit field is used to encode the VNI and global VNIs, and for either case the entire 24-bit field is used
value. to encode the VNI value.
For the VLAN-based service (a single VNI per MAC-VRF), the Ethernet For the VLAN-based service (a single VNI per MAC-VRF), the Ethernet
Tag field in the MAC/IP Advertisement, Ethernet AD per EVI, and IMET Tag field in the MAC/IP Advertisement, Ethernet AD per EVI, and IMET
route MUST be set to zero just as in the VLAN Based service in route MUST be set to zero just as in the VLAN Based service in
[RFC7432]. [RFC7432].
For the VLAN-aware bundle service (multiple VNIs per MAC-VRF with For the VLAN-aware bundle service (multiple VNIs per MAC-VRF with
each VNI associated with its own bridge table), the Ethernet Tag each VNI associated with its own bridge table), the Ethernet Tag
field in the MAC Advertisement, Ethernet AD per EVI, and IMET route field in the MAC Advertisement, Ethernet AD per EVI, and IMET route
MUST identify a bridge table within a MAC-VRF and the set of Ethernet MUST identify a bridge table within a MAC-VRF and the set of Ethernet
skipping to change at page 12, line 22 skipping to change at page 12, line 41
within that EVI. For locally-assigned VNIs, the value advertised in within that EVI. For locally-assigned VNIs, the value advertised in
the Ethernet Tag field MUST be set to a VID just as in the VLAN-aware the Ethernet Tag field MUST be set to a VID just as in the VLAN-aware
bundle service in [RFC7432]. Such setting must be done consistently bundle service in [RFC7432]. Such setting must be done consistently
on all PE devices participating in that EVI within a given domain. on all PE devices participating in that EVI within a given domain.
For global VNIs, the value advertised in the Ethernet Tag field For global VNIs, the value advertised in the Ethernet Tag field
SHOULD be set to a VNI as long as it matches the existing semantics SHOULD be set to a VNI as long as it matches the existing semantics
of the Ethernet Tag, i.e., it identifies a bridge table within a MAC- of the Ethernet Tag, i.e., it identifies a bridge table within a MAC-
VRF and the set of VNIs are configured consistently on each PE in VRF and the set of VNIs are configured consistently on each PE in
that EVI. that EVI.
In order to indicate that which type of data plane encapsulation In order to indicate which type of data plane encapsulation (i.e.,
(i.e., VXLAN, NVGRE, MPLS, or MPLS in GRE) is to be used, the BGP VXLAN, NVGRE, MPLS, or MPLS in GRE) is to be used, the BGP
Encapsulation extended community defined in [TUNNEL-ENCAP] and Encapsulation extended community defined in [TUNNEL-ENCAP] and
[RFC5512] is included with all EVPN routes (i.e. MAC Advertisement, [RFC5512] is included with all EVPN routes (i.e. MAC Advertisement,
Ethernet AD per EVI, Ethernet AD per ESI, Inclusive Multicast Ethernet AD per EVI, Ethernet AD per ESI, Inclusive Multicast
Ethernet Tag, and Ethernet Segment) advertised by an egress PE. Five Ethernet Tag, and Ethernet Segment) advertised by an egress PE. Five
new values have been assigned by IANA to extend the list of new values have been assigned by IANA to extend the list of
encapsulation types defined in [TUNNEL-ENCAP] and they are listed in encapsulation types defined in [TUNNEL-ENCAP] and they are listed in
section 13. section 13.
The MPLS encapsulation tunnel type, listed in section 13, is needed The MPLS encapsulation tunnel type, listed in section 13, is needed
in order to distinguish between an advertising node that only in order to distinguish between an advertising node that only
supports non-MPLS encapsulations and one that supports MPLS and non- supports non-MPLS encapsulations and one that supports MPLS and non-
MPLS encapsulations. An advertising node that only supports MPLS MPLS encapsulations. An advertising node that only supports MPLS
encapsulation does not need to advertise any encapsulation tunnel encapsulation does not need to advertise any encapsulation tunnel
types; i.e., if the BGP Encapsulation extended community is not types; i.e., if the BGP Encapsulation extended community is not
present, then either MPLS encapsulation or a statically configured present, then either MPLS encapsulation or a statically configured
encapsulation is assumed. encapsulation is assumed.
The Ethernet Segment and Ethernet AD per ESI routes MAY be advertised The Ethernet Segment and Ethernet AD per ESI routes MAY be advertised
with multiple encapsulation types as long as they use the same EVPN with multiple encapsulation types as long as they use the same EVPN
multi-homing procedures - e.g., the mix of VXLAN and NVGRE multi-homing procedures (section 8.3.1, Split Horizon) - e.g., the
encapsulation types is a valid one but not the mix of VXLAN and MPLS mix of VXLAN and NVGRE encapsulation types is a valid one but not the
encapsulation types. mix of VXLAN and MPLS encapsulation types.
The Next Hop field of the MP_REACH_NLRI attribute of the route MUST The Next Hop field of the MP_REACH_NLRI attribute of the route MUST
be set to the IPv4 or IPv6 address of the NVE. The remaining fields be set to the IPv4 or IPv6 address of the NVE. The remaining fields
in each route are set as per [RFC7432]. in each route are set as per [RFC7432].
Note that the procedure defined here to use the MPLS Label field to Note that the procedure defined here to use the MPLS Label field to
carry the VNI in the presence of a Tunnel Encapsulation Extended carry the VNI in the presence of a Tunnel Encapsulation Extended
Community specifying the use of a VNI, is aligned with the procedures Community specifying the use of a VNI, is aligned with the procedures
described in section 8.2.2.2 of [tunnel-encap] ("When a Valid VNI has described in section 8.2.2.2 of [tunnel-encap] ("When a Valid VNI has
not been Signaled"). not been Signaled").
skipping to change at page 14, line 9 skipping to change at page 14, line 28
different encapsulation type. different encapsulation type.
It is the responsibility of the operator of a given EVI to ensure It is the responsibility of the operator of a given EVI to ensure
that all of the NVEs in that EVI support at least one common that all of the NVEs in that EVI support at least one common
encapsulation. If this condition is violated, it could result in encapsulation. If this condition is violated, it could result in
service disruption or failure. The use of the BGP Encapsulation service disruption or failure. The use of the BGP Encapsulation
extended community provides a method to detect when this condition is extended community provides a method to detect when this condition is
violated but the actions to be taken are at the discretion of the violated but the actions to be taken are at the discretion of the
operator and are outside the scope of this document. operator and are outside the scope of this document.
7 NVE Residing in Hypervisor 7 Single-Homing NVEs - NVE Residing in Hypervisor
When a NVE and its hosts/VMs are co-located in the same physical When a NVE and its hosts/VMs are co-located in the same physical
device, e.g., when they reside in a server, the links between them device, e.g., when they reside in a server, the links between them
are virtual and they typically share fate; i.e., the subject are virtual and they typically share fate; i.e., the subject
hosts/VMs are typically not multi-homed or if they are multi-homed, hosts/VMs are typically not multi-homed or if they are multi-homed,
the multi-homing is a purely local matter to the server hosting the the multi-homing is a purely local matter to the server hosting the
VM and the NVEs, and need not be "visible" to any other NVEs residing VM and the NVEs, and need not be "visible" to any other NVEs residing
on other servers, and thus does not require any specific protocol on other servers, and thus does not require any specific protocol
mechanisms. The most common case of this is when the NVE resides on mechanisms. The most common case of this is when the NVE resides on
the hypervisor. the hypervisor.
In the sub-sections that follow, we will discuss the impact on EVPN In the sub-sections that follow, we will discuss the impact on EVPN
procedures for the case when the NVE resides on the hypervisor and procedures for the case when the NVE resides on the hypervisor and
the VXLAN (or NVGRE) encapsulation is used. the VXLAN (or NVGRE) encapsulation is used.
7.1 Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulation 7.1 Impact on EVPN BGP Routes & Attributes for VXLAN/NVGRE Encapsulation
In scenarios where different groups of data centers are under In scenarios where different groups of data centers are under
different administrative domains, and these data centers are different administrative domains, and these data centers are
connected via one or more backbone core providers as described in connected via one or more backbone core providers as described in
[NOV3-Framework], the RD must be a unique value per EVI or per NVE as [NVO3-FRWK], the RD must be a unique value per EVI or per NVE as
described in [RFC7432]. In other words, whenever there is more than described in [RFC7432]. In other words, whenever there is more than
one administrative domain for global VNI, then a unique RD MUST be one administrative domain for global VNI, then a unique RD MUST be
used, or whenever the VNI value have local significance, then a used, or whenever the VNI value have local significance, then a
unique RD MUST be used. Therefore, it is recommend to use a unique RD unique RD MUST be used. Therefore, it is recommend to use a unique RD
as described in [RFC7432] at all time. as described in [RFC7432] at all time.
When the NVEs reside on the hypervisor, the EVPN BGP routes and When the NVEs reside on the hypervisor, the EVPN BGP routes and
attributes associated with multi-homing are no longer required. This attributes associated with multi-homing are no longer required. This
reduces the required routes and attributes to the following subset of reduces the required routes and attributes to the following subset of
four out of eight: four out of eight:
skipping to change at page 15, line 35 skipping to change at page 16, line 7
16 in [RFC7432]. 16 in [RFC7432].
However, as noted in section 8.6 of [RFC7432] in order to enable a However, as noted in section 8.6 of [RFC7432] in order to enable a
single-homing ingress NVE to take advantage of fast convergence, single-homing ingress NVE to take advantage of fast convergence,
aliasing, and back-up path when interacting with multi-homed egress aliasing, and back-up path when interacting with multi-homed egress
NVEs attached to a given Ethernet segment, a single-homing ingress NVEs attached to a given Ethernet segment, a single-homing ingress
NVE SHOULD implement the ingress node processing of Ethernet AD per NVE SHOULD implement the ingress node processing of Ethernet AD per
ES and Ethernet AD per EVI routes as defined in sections 8.2 Fast ES and Ethernet AD per EVI routes as defined in sections 8.2 Fast
Convergence and 8.4 Aliasing and Backup-Path of [RFC7432]. Convergence and 8.4 Aliasing and Backup-Path of [RFC7432].
8 NVE Residing in ToR Switch 8 Multi-Homing NVEs - NVE Residing in ToR Switch
In this section, we discuss the scenario where the NVEs reside in the In this section, we discuss the scenario where the NVEs reside in the
Top of Rack (ToR) switches AND the servers (where VMs are residing) Top of Rack (ToR) switches AND the servers (where VMs are residing)
are multi-homed to these ToR switches. The multi-homing may operate are multi-homed to these ToR switches. The multi-homing NVE operate
in All-Active or Single-Active redundancy mode. If the servers are in All-Active or Single-Active redundancy mode. If the servers are
single-homed to the ToR switches, then the scenario becomes similar single-homed to the ToR switches, then the scenario becomes similar
to that where the NVE resides on the hypervisor, as discussed in to that where the NVE resides on the hypervisor, as discussed in
Section 7, as far as the required EVPN functionality are concerned. Section 7, as far as the required EVPN functionality are concerned.
[RFC7432] defines a set of BGP routes, attributes and procedures to [RFC7432] defines a set of BGP routes, attributes and procedures to
support multi-homing. We first describe these functions and support multi-homing. We first describe these functions and
procedures, then discuss which of these are impacted by the VxLAN procedures, then discuss which of these are impacted by the VxLAN
(or NVGRE) encapsulation and what modifications are required. As it (or NVGRE) encapsulation and what modifications are required. As it
will be seen later in this section, the only EVPN procedure that is will be seen later in this section, the only EVPN procedure that is
impacted by IP underlay tunnels is that of split-horizon filtering impacted by non-MPLS overlay encapsulation (e.g., VxLAN or NVGRE)
for multi-homed Ethernet Segments described in section 8.3.1. where it provides space for one ID rather than stack of labels, is
that of split-horizon filtering for multi-homed Ethernet Segments
described in section 8.3.1.
8.1 EVPN Multi-Homing Features 8.1 EVPN Multi-Homing Features
In this section, we will recap the multi-homing features of EVPN to In this section, we will recap the multi-homing features of EVPN to
highlight the encapsulation dependencies. The section only describes highlight the encapsulation dependencies. The section only describes
the features and functions at a high-level. For more details, the the features and functions at a high-level. For more details, the
reader is to refer to [RFC7432]. reader is to refer to [RFC7432].
8.1.1 Multi-homed Ethernet Segment Auto-Discovery 8.1.1 Multi-homed Ethernet Segment Auto-Discovery
skipping to change at page 17, line 50 skipping to change at page 18, line 24
one of these NVEs, termed the Designated Forwarder (DF) is one of these NVEs, termed the Designated Forwarder (DF) is
responsible for sending it broadcast, multicast, and, if configured responsible for sending it broadcast, multicast, and, if configured
for that EVI, unknown unicast frames. for that EVI, unknown unicast frames.
This is required in order to prevent duplicate delivery of multi- This is required in order to prevent duplicate delivery of multi-
destination frames to a multi-homed host or VM, in case of all-active destination frames to a multi-homed host or VM, in case of all-active
redundancy. redundancy.
In NVEs where .1Q tagged frames are received from hosts, the DF In NVEs where .1Q tagged frames are received from hosts, the DF
election SHOULD BE performed based on host VLAN IDs (VIDs) per election SHOULD BE performed based on host VLAN IDs (VIDs) per
section 8.5 of [RFC 7432]. Furthermore, multi-homing PEs of a given section 8.5 of [RFC7432]. Furthermore, multi-homing PEs of a given
Ethernet Segment MAY perform DF election using configured IDs such as Ethernet Segment MAY perform DF election using configured IDs such as
VNI, EVI, normalized VIDs, and etc. as along the IDs are configured VNI, EVI, normalized VIDs, and etc. as along the IDs are configured
consistently across the multi-homing PEs. consistently across the multi-homing PEs.
In GWs where VxLAN encapsulated frames are received, the DF election In GWs where VxLAN encapsulated frames are received, the DF election
is performed on VNIs. Again, it is assumed that for a given Ethernet is performed on VNIs. Again, it is assumed that for a given Ethernet
Segment, VNIs are unique and consistent (e.g., no duplicate VNIs Segment, VNIs are unique and consistent (e.g., no duplicate VNIs
exist). exist).
8.2 Impact on EVPN BGP Routes & Attributes 8.2 Impact on EVPN BGP Routes & Attributes
skipping to change at page 19, line 39 skipping to change at page 20, line 12
In order to prevent unhealthy interactions between the split horizon In order to prevent unhealthy interactions between the split horizon
procedures defined in [RFC7432] and the local bias procedures procedures defined in [RFC7432] and the local bias procedures
described in this document, a mix of MPLS over GRE encapsulations on described in this document, a mix of MPLS over GRE encapsulations on
the one hand and VXLAN/NVGRE encapsulations on the other on a given the one hand and VXLAN/NVGRE encapsulations on the other on a given
Ethernet Segment is prohibited. Ethernet Segment is prohibited.
8.3.2 Aliasing and Backup-Path 8.3.2 Aliasing and Backup-Path
The Aliasing and the Backup-Path procedures for VXLAN/NVGRE The Aliasing and the Backup-Path procedures for VXLAN/NVGRE
encapsulation is very similar to the ones for MPLS. In case of MPLS, encapsulation are very similar to the ones for MPLS. In case of MPLS,
Ethernet A-D route per EVI is used for Aliasing when the Ethernet A-D route per EVI is used for Aliasing when the
corresponding Ethernet Segment operates in All-Active multi-homing, corresponding Ethernet Segment operates in All-Active multi-homing,
and the same route is used for Backup-Path when the corresponding and the same route is used for Backup-Path when the corresponding
Ethernet Segment operates in Single-Active multi-homing. In case of Ethernet Segment operates in Single-Active multi-homing. In case of
VxLAN/NVGRE, the same route is used for the Aliasing and the Backup- VxLAN/NVGRE, the same route is used for the Aliasing and the Backup-
Path with the difference that the Ethernet Tag and VNI fields in Path with the difference that the Ethernet Tag and VNI fields in
Ethernet A-D per EVI route is set as described in section 5.1.3. Ethernet A-D per EVI route are set as described in section 5.1.3.
8.3.3 Unknown Unicast Traffic Designation 8.3.3 Unknown Unicast Traffic Designation
In EVPN, when an ingress PE uses ingress replication to flood unknown In EVPN, when an ingress PE uses ingress replication to flood unknown
unicast traffic to egress PEs, the ingress PE uses a different EVPN unicast traffic to egress PEs, the ingress PE uses a different EVPN
MPLS label (from the one used for known unicast traffic) to identify MPLS label (from the one used for known unicast traffic) to identify
such BUM traffic. The egress PEs use this label to identify such BUM such BUM traffic. The egress PEs use this label to identify such BUM
traffic and thus apply DF filtering for All-Active multi-homed sites. traffic and thus apply DF filtering for All-Active multi-homed sites.
In absence of unknown unicast traffic designation and in presence of In absence of unknown unicast traffic designation and in presence of
enabling unknown unicast flooding, there can be transient duplicate enabling unknown unicast flooding, there can be transient duplicate
skipping to change at page 20, line 30 skipping to change at page 21, line 4
redundancy mode, b) flooding of unknown unicast is enabled in the redundancy mode, b) flooding of unknown unicast is enabled in the
network, c) ingress replication is used, and d) traffic for the network, c) ingress replication is used, and d) traffic for the
destination host is arrived on the ingress PE before it learns the destination host is arrived on the ingress PE before it learns the
host MAC address via BGP EVPN advertisement. In order to prevent such host MAC address via BGP EVPN advertisement. In order to prevent such
occurrence of packet duplication (however low probability that may occurrence of packet duplication (however low probability that may
be), the ingress PE MAY use a flag-bit in the VxLAN header to be), the ingress PE MAY use a flag-bit in the VxLAN header to
indicate BUM traffic type. Bit 6 of flag field in the VxLAN header is indicate BUM traffic type. Bit 6 of flag field in the VxLAN header is
used for this purpose per section 3.1 of [VXLAN-GPE]. used for this purpose per section 3.1 of [VXLAN-GPE].
9 Support for Multicast 9 Support for Multicast
The E-VPN Inclusive Multicast Ethernet Tag (IMET) route is used to
The E-VPN Inclusive Multicast BGP route is used to discover the discover the multicast tunnels among the endpoints associated with a
multicast tunnels among the endpoints associated with a given EVI given EVI (e.g., given VNI) for VLAN-based service and a given
(e.g., given VNI) for VLAN-based service and a given <EVI,VLAN> for <EVI,VLAN> for VLAN-aware bundle service. All fields of this route is
VLAN-aware bundle service. All fields of this route is set as set as described in section 5.1.3. The Originating router's IP
described in section 5.1.3. The Originating router's IP address field address field is set to the NVE's IP address. This route is tagged
is set to the NVE's IP address. This route is tagged with the PMSI with the PMSI Tunnel attribute, which is used to encode the type of
Tunnel attribute, which is used to encode the type of multicast multicast tunnel to be used as well as the multicast tunnel
tunnel to be used as well as the multicast tunnel identifier. The identifier. The tunnel encapsulation is encoded by adding the BGP
tunnel encapsulation is encoded by adding the BGP Encapsulation Encapsulation extended community as per section 5.1.1. For example,
extended community as per section 5.1.1. For example, the PMSI Tunnel the PMSI Tunnel attribute may indicate the multicast tunnel is of
attribute may indicate the multicast tunnel is of type PIM-SM; type PIM-SM; whereas, the BGP Encapsulation extended community may
whereas, the BGP Encapsulation extended community may indicate the indicate the encapsulation for that tunnel is of type VxLAN. The
encapsulation for that tunnel is of type VxLAN. The following tunnel following tunnel types as defined in [RFC6514] can be used in the
types as defined in [RFC6514] can be used in the PMSI tunnel PMSI tunnel attribute for VXLAN/NVGRE:
attribute for VXLAN/NVGRE:
+ 3 - PIM-SSM Tree + 3 - PIM-SSM Tree
+ 4 - PIM-SM Tree + 4 - PIM-SM Tree
+ 5 - BIDIR-PIM Tree + 5 - BIDIR-PIM Tree
+ 6 - Ingress Replication + 6 - Ingress Replication
Except for Ingress Replication, this multicast tunnel is used by the Except for Ingress Replication, this multicast tunnel is used by the
PE originating the route for sending multicast traffic to other PEs, PE originating the route for sending multicast traffic to other PEs,
and is used by PEs that receive this route for receiving the traffic and is used by PEs that receive this route for receiving the traffic
originated by hosts connected to the PE that originated the route. originated by hosts connected to the PE that originated the route.
skipping to change at page 22, line 12 skipping to change at page 22, line 33
convergence time upon a link or NVE failure in a multi-homed network convergence time upon a link or NVE failure in a multi-homed network
or device redundancy scenario, because the failure related BGP routes or device redundancy scenario, because the failure related BGP routes
(such as mass withdraw message) do not need to get propagated all the (such as mass withdraw message) do not need to get propagated all the
way to the remote NVEs in the remote DCs. This approach is described way to the remote NVEs in the remote DCs. This approach is described
in details in section 3.4 of [DCI-EVPN-OVERLAY]. in details in section 3.4 of [DCI-EVPN-OVERLAY].
10.2 DCI using ASBRs 10.2 DCI using ASBRs
This approach can be considered as the opposite of the first approach This approach can be considered as the opposite of the first approach
and it favors simplification at DCI devices over NVEs such that and it favors simplification at DCI devices over NVEs such that
larger MAC-VRF (and IP-VRF) tables are need to be maintained on NVEs; larger MAC-VRF (and IP-VRF) tables need to be maintained on NVEs;
whereas, DCI devices don't need to maintain any MAC (and IP) whereas, DCI devices don't need to maintain any MAC (and IP)
forwarding tables. Furthermore, DCI devices do not need to terminate forwarding tables. Furthermore, DCI devices do not need to terminate
and processed routes related to multi-homing but rather to relay and process routes related to multi-homing but rather to relay these
these messages for the establishment of an end-to-end LSP path. In messages for the establishment of an end-to-end LSP path. In other
other words, DCI devices in this approach operate similar to ASBRs words, DCI devices in this approach operate similar to ASBRs for
for inter-AS options B. This requires locally assigned VNIs to be inter-AS option B - section 10 of [RFC4364]. This requires locally
used just like downstream assigned MPLS VPN label where for all assigned VNIs to be used just like downstream assigned MPLS VPN label
practical purposes the VNIs function like 24-bit VPN labels. This where for all practical purposes the VNIs function like 24-bit VPN
approach is equally applicable to data centers (or Carrier Ethernet labels. This approach is equally applicable to data centers (or
networks) with MPLS encapsulation. Carrier Ethernet networks) with MPLS encapsulation.
In inter-AS option B, when ASBR receives an EVPN route from its DC In inter-AS option B, when ASBR receives an EVPN route from its DC
over iBGP and re-advertises it to other ASBRs, it re-advertises the over iBGP and re-advertises it to other ASBRs, it re-advertises the
EVPN route by re-writing the BGP next-hops to itself, thus losing the EVPN route by re-writing the BGP next-hops to itself, thus losing the
identity of the PE that originated the advertisement. This re-write identity of the PE that originated the advertisement. This re-write
of BGP next-hop impacts the EVPN Mass Withdraw route (Ethernet A-D of BGP next-hop impacts the EVPN Mass Withdraw route (Ethernet A-D
per ES) and its procedure adversely. However, it does not impact EVPN per ES) and its procedure adversely. However, it does not impact EVPN
Aliasing mechanism/procedure because when the Aliasing routes (Ether Aliasing mechanism/procedure because when the Aliasing routes (Ether
A-D per EVI) are advertised, the receiving PE first resolves a MAC A-D per EVI) are advertised, the receiving PE first resolves a MAC
address for a given EVI into its corresponding <ES,EVI> and address for a given EVI into its corresponding <ES,EVI> and
skipping to change at page 23, line 12 skipping to change at page 23, line 33
Withdraw route (Ether A-D per ES) and its corresponding MAC routes Withdraw route (Ether A-D per ES) and its corresponding MAC routes
cannot be made based on their RDs and RTs because the RD for Mass cannot be made based on their RDs and RTs because the RD for Mass
Withdraw route is different than the one for the MAC routes. Withdraw route is different than the one for the MAC routes.
Therefore, the functionality needed at the ASBRs and the receiving Therefore, the functionality needed at the ASBRs and the receiving
PEs depends on whether the Mass Withdraw route is originated and PEs depends on whether the Mass Withdraw route is originated and
whether there is a need to handle route resolution ambiguity for this whether there is a need to handle route resolution ambiguity for this
route. The following two subsections describe the functionality route. The following two subsections describe the functionality
needed by the ASBRs and the receiving PEs depending on whether the needed by the ASBRs and the receiving PEs depending on whether the
NVEs reside in a Hypervisors or in TORs. NVEs reside in a Hypervisors or in TORs.
10.2.1 ASBR Functionality with NVEs in Hypervisors 10.2.1 ASBR Functionality with Single-Homing NVEs
When NVEs reside in hypervisors as described in section 7.1, there is When NVEs reside in hypervisors as described in section 7.1, there is
no multi-homing and thus there is no need for the originating NVE to no multi-homing and thus there is no need for the originating NVE to
send Ethernet A-D per ES or Ethernet A-D per EVI routes. However, as send Ethernet A-D per ES or Ethernet A-D per EVI routes. However, as
noted in section 7, in order to enable a single-homing ingress NVE to noted in section 7, in order to enable a single-homing ingress NVE to
take advantage of fast convergence, aliasing, and backup-path when take advantage of fast convergence, aliasing, and backup-path when
interacting with multi-homing egress NVEs attached to a given interacting with multi-homing egress NVEs attached to a given
Ethernet segment, the single-homing NVE SHOULD be able to receive and Ethernet segment, the single-homing NVE SHOULD be able to receive and
process Ethernet AD per ES and Ethernet AD per EVI routes. The process Ethernet AD per ES and Ethernet AD per EVI routes. The
handling of these routes are described in the next section. handling of these routes are described in the next section.
10.2.2 ASBR Functionality with NVEs in TORs 10.2.2 ASBR Functionality with Multi-Homing NVEs
When NVEs reside in TORs and operate in multi-homing redundancy mode, When NVEs reside in TORs and operate in multi-homing redundancy mode,
then as described in section 8, there is a need for the originating then as described in section 8, there is a need for the originating
NVE to send Ethernet A-D per ES route(s) (used for mass withdraw) and multi-homing NVE to send Ethernet A-D per ES route(s) (used for mass
Ethernet A-D per EVI routes (used for aliasing). As described above, withdraw) and Ethernet A-D per EVI routes (used for aliasing). As
the re-write of BGP next-hop by ASBRs creates ambiguities when described above, the re-write of BGP next-hop by ASBRs creates
Ethernet A-D per ES routes are received by the remote NVE in a ambiguities when Ethernet A-D per ES routes are received by the
different ASBR because the receiving NVE cannot associated that route remote NVE in a different ASBR because the receiving NVE cannot
with the MAC/IP routes of that Ethernet Segment advertised by the associated that route with the MAC/IP routes of that Ethernet Segment
same originating NVE. This ambiguity inhibits the function of mass- advertised by the same originating NVE. This ambiguity inhibits the
withdraw per ES by the receiving NVE in a different AS. function of mass-withdraw per ES by the receiving NVE in a different
AS.
As an example consider a scenario where CE is multi-homed to PE1 and As an example consider a scenario where CE is multi-homed to PE1 and
PE2 where these PEs are connected via ASBR1 and then ASBR2 to the PE2 where these PEs are connected via ASBR1 and then ASBR2 to the
remote PE3. Furthermore, consider that PE1 receives M1 from CE1 but remote PE3. Furthermore, consider that PE1 receives M1 from CE1 but
not PE2. Therefore, PE1 advertises Eth A-D per ES1, Eth A-D per EVI1, not PE2. Therefore, PE1 advertises Eth A-D per ES1, Eth A-D per EVI1,
and M1; whereas, PE2 only advertises Eth A-D per ES1 and Eth A-D per and M1; whereas, PE2 only advertises Eth A-D per ES1 and Eth A-D per
EVI1. ASBR1 receives all these five advertisements and passes them to EVI1. ASBR1 receives all these five advertisements and passes them to
ASBR2 (with itself as the BGP next hop). ASBR2, in turn, passes them ASBR2 (with itself as the BGP next hop). ASBR2, in turn, passes them
to the remote PE3 with itself as the BGP next hop. PE3 receives these to the remote PE3 with itself as the BGP next hop. PE3 receives these
five routes where all of them have the same BGP next-hop (i.e., five routes where all of them have the same BGP next-hop (i.e.,
skipping to change at page 25, line 22 skipping to change at page 25, line 47
withdrawal of the Ethernet AD Per ES routes is not actionable. withdrawal of the Ethernet AD Per ES routes is not actionable.
However, a remote PE is able to correlate a previously advertised However, a remote PE is able to correlate a previously advertised
Ethernet AD Per EVI route with any MAC/IP Advertisement routes also Ethernet AD Per EVI route with any MAC/IP Advertisement routes also
advertised by the withdrawing PE for that <ES, EVI, BD>. Hence, when advertised by the withdrawing PE for that <ES, EVI, BD>. Hence, when
it receives the withdrawal of an Ethernet AD Per EVI route, it SHOULD it receives the withdrawal of an Ethernet AD Per EVI route, it SHOULD
remove the withdrawing PE as a next-hop for all MAC addresses remove the withdrawing PE as a next-hop for all MAC addresses
associated with that <ES, EVI, BD>. associated with that <ES, EVI, BD>.
In the previous example, when the AC between PE2 and the CE fails, In the previous example, when the AC between PE2 and the CE fails,
PE2 will withdraw its Ethernet AD Per ES and Per EVI routes. When PE2 will withdraw its Ethernet AD Per ES and Per EVI routes. When
PE3 receives the withdrawal of an Ethernet AD Per EVI route, it PE3 receives the withdrawal of an Ethernet AD Per EVI route, it
removes PE2 as a valid next-hop for all MAC addresses associated with removes PE2 as a valid next-hop for all MAC addresses associated with
the corresponding <ES, EVI, BD>. Therefore, all the MAC next-hops the corresponding <ES, EVI, BD>. Therefore, all the MAC next-hops
for that <ES,EVI, BD> will now have a single next-hop, viz the LSP to for that <ES,EVI, BD> will now have a single next-hop, viz the LSP to
PE1. PE1.
In summary, it can be seen that aliasing (and backup path) In summary, it can be seen that aliasing (and backup path)
functionality should work as is for inter-AS option B without functionality should work as is for inter-AS option B without
requiring any addition functionality in ASBRs or PEs. However, the requiring any addition functionality in ASBRs or PEs. However, the
mass-withdraw functionality falls back from per-ES mode to per-EVI mass-withdraw functionality falls back from per-ES mode to per-EVI
mode for inter-AS option B - i.e., PEs receiving mass-withdraw route mode for inter-AS option B - i.e., PEs receiving mass-withdraw route
from the same AS take action on Ether A-D per ES route; whereas, PEs from the same AS take action on Ether A-D per ES route; whereas, PEs
receiving mass-withdraw route from different AS take action on Ether receiving mass-withdraw route from different AS take action on Ether
skipping to change at page 26, line 34 skipping to change at page 27, line 10
It should be noted that a BGP session may itself be transported over It should be noted that a BGP session may itself be transported over
an IPsec tunnel. Such IPsec tunnels can provide additional security an IPsec tunnel. Such IPsec tunnels can provide additional security
to a BGP session. The management of such IPsec tunnels is outside to a BGP session. The management of such IPsec tunnels is outside
the scope of this document. the scope of this document.
13 IANA Considerations 13 IANA Considerations
IANA has allocated the following BGP Tunnel Encapsulation Attribute IANA has allocated the following BGP Tunnel Encapsulation Attribute
Tunnel Types: Tunnel Types:
8 VXLAN Encapsulation 8 VXLAN Encapsulation
9 NVGRE Encapsulation 9 NVGRE Encapsulation
10 MPLS Encapsulation 10 MPLS Encapsulation
11 MPLS in GRE Encapsulation 11 MPLS in GRE Encapsulation
12 VXLAN GPE Encapsulation 12 VXLAN GPE Encapsulation
14 References 14 References
14.1 Normative References 14.1 Normative References
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border [RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border
Gateway Protocol 4 (BGP-4)", January 2006. Gateway Protocol 4 (BGP-4)", January 2006.
[RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis.",
January 2006.
[RFC4301] S. Kent, K. Seo., "Security Architecture for the [RFC4301] S. Kent, K. Seo., "Security Architecture for the
Internet Protocol.", December 2005. Internet Protocol.", December 2005.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, April 2009. Tunnel Encapsulation Attribute", RFC 5512, April 2009.
[RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432, [RFC7432] Sajassi et al., "BGP MPLS Based Ethernet VPN", RFC 7432,
February 2014 February 2014
14.2 Informative References 14.2 Informative References
[RFC7209] Sajassi et al., "Requirements for Ethernet VPN (EVPN)", RFC [RFC7209] Sajassi et al., "Requirements for Ethernet VPN (EVPN)", RFC
7209, May 2014 7209, May 2014
[RFC7348] Mahalingam, M., et al, "VXLAN: A Framework for Overlaying [RFC7348] Mahalingam, M., et al, "VXLAN: A Framework for Overlaying
Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, August
2014 2014
[RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis.",
January 2006.
[NVGRE] Garg, P., et al., "NVGRE: Network Virtualization using [NVGRE] Garg, P., et al., "NVGRE: Network Virtualization using
Generic Routing Encapsulation", draft-sridharan-virtualization-nvgre- Generic Routing Encapsulation", RFC 7637, September, 2015
07.txt, November 11, 2014
[Problem-Statement] Narten et al., "Problem Statement: Overlays for [Problem-Statement] Narten et al., "Problem Statement: Overlays for
Network Virtualization", draft-ietf-nvo3-overlay-problem-statement- Network Virtualization", RFC 7364, October 2014.
01, September 2012.
[NOV3-FRWK] Lasserre et al., "Framework for DC Network [NVO3-FRWK] Lasserre et al., "Framework for DC Network
Virtualization", draft-ietf-nvo3-framework-01.txt, work in progress, Virtualization", RFC 7365, October 2014.
October 2012.
[DCI-EVPN-OVERLAY] Rabadan et al., "Interconnect Solution for EVPN [DCI-EVPN-OVERLAY] Rabadan et al., "Interconnect Solution for EVPN
Overlay networks", draft-ietf-bess-dci-evpn-overlay-02, work in Overlay networks", draft-ietf-bess-dci-evpn-overlay-04, work in
progress, February 29, 2016. progress, February 29, 2016.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-02, work in progress, May Attribute", draft-ietf-idr-tunnel-encaps-03, work in progress, May
31, 2016. 31, 2016.
[VXLAN-GPE] Maino et al., "Generic Protocol Extension for VXLAN", [VXLAN-GPE] Maino et al., "Generic Protocol Extension for VXLAN",
draft-ietf-nvo3-vxlan-gpe-03, work in progress October 25, 2016. draft-ietf-nvo3-vxlan-gpe-03, work in progress October 25, 2016.
[RFC4364] Rosen, E., et al, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006.
[RFC4023] T. Worster et al., "Encapsulating MPLS in IP or Generic
Routing Encapsulation (GRE)", RFC 4023, March 2005
[RFC6514] R. Aggarwal et al., "BGP Encodings and Procedures for
Multicast in MPLS/BGP IP VPNs", RFC 6514, February 2012
Contributors Contributors
S. Salam K. Patel D. Rao S. Thoria D. Cai Cisco S. Salam
Y. Rekhter A. Issac Wen Lin Nischal Sheth Juniper K. Patel
D. Rao
S. Thoria
D. Cai
Cisco
L. Yong Huawei Y. Rekhter
A. Issac
Wen Lin
Nischal Sheth
Juniper
L. Yong
Huawei
Authors' Addresses Authors' Addresses
Ali Sajassi Ali Sajassi
Cisco Cisco
Email: sajassi@cisco.com Email: sajassi@cisco.com
John Drake John Drake
Juniper Networks Juniper Networks
Email: jdrake@juniper.net Email: jdrake@juniper.net
 End of changes. 65 change blocks. 
148 lines changed or deleted 180 lines changed or added

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