draft-ietf-bess-evpn-overlay-08.txt   draft-ietf-bess-evpn-overlay-09.txt 
skipping to change at page 1, line 16 skipping to change at page 1, line 16
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: September 27, 2017 March 27, 2017 Expires: May 7, 2018 December 7, 2017
A Network Virtualization Overlay Solution using EVPN A Network Virtualization Overlay Solution using EVPN
draft-ietf-bess-evpn-overlay-08 draft-ietf-bess-evpn-overlay-09
Abstract Abstract
This document describes how Ethernet VPN (EVPN) can be used as an This document specifies how Ethernet VPN (EVPN) can be used as a
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.
This document also specifies new multi-homing procedures for split-
horizon filtering and mass-withdraw. It also specifies EVPN route
constructions for VxLAN/NvGRE encapsulations and ASBR procedures for
multi-homing NV Edge devices.
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
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 other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at page 2, line 23 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . 5 2 Requirements Notation and Conventions . . . . . . . . . . . . . 5
3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 EVPN Features . . . . . . . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . 9 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 . . . . . . . . . . . . . 12
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 . . . . . . . . . 14
7 Single-Homing NVEs - NVE Residing in Hypervisor . . . . . . . . 14 7 Single-Homing NVEs - NVE Residing in Hypervisor . . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . . . . 15
7.2 Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation . . 15 7.2 Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation . . 16
8 Multi-Homing NVEs - NVE Residing in ToR Switch . . . . . . . . 16 8 Multi-Homing NVEs - NVE Residing in ToR Switch . . . . . . . . 16
8.1 EVPN Multi-Homing Features . . . . . . . . . . . . . . . . 16 8.1 EVPN Multi-Homing Features . . . . . . . . . . . . . . . . 17
8.1.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . 16 8.1.1 Multi-homed Ethernet Segment Auto-Discovery . . . . . . 17
8.1.2 Fast Convergence and Mass Withdraw . . . . . . . . . . . 16 8.1.2 Fast Convergence and Mass Withdraw . . . . . . . . . . . 17
8.1.3 Split-Horizon . . . . . . . . . . . . . . . . . . . . . 17 8.1.3 Split-Horizon . . . . . . . . . . . . . . . . . . . . . 17
8.1.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 17 8.1.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 17
8.1.5 DF Election . . . . . . . . . . . . . . . . . . . . . . 18 8.1.5 DF Election . . . . . . . . . . . . . . . . . . . . . . 18
8.2 Impact on EVPN BGP Routes & Attributes . . . . . . . . . . . 18 8.2 Impact on EVPN BGP Routes & Attributes . . . . . . . . . . . 19
8.3 Impact on EVPN Procedures . . . . . . . . . . . . . . . . . 18 8.3 Impact on EVPN Procedures . . . . . . . . . . . . . . . . . 19
8.3.1 Split Horizon . . . . . . . . . . . . . . . . . . . . . 19 8.3.1 Split Horizon . . . . . . . . . . . . . . . . . . . . . 19
8.3.2 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 20 8.3.2 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 20
8.3.3 Unknown Unicast Traffic Designation . . . . . . . . . . 20 8.3.3 Unknown Unicast Traffic Designation . . . . . . . . . . 20
9 Support for Multicast . . . . . . . . . . . . . . . . . . . . . 20 9 Support for Multicast . . . . . . . . . . . . . . . . . . . . . 21
10 Data Center Interconnections - DCI . . . . . . . . . . . . . . 21 10 Data Center Interconnections - DCI . . . . . . . . . . . . . . 22
10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 22 10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 22
10.2 DCI using ASBRs . . . . . . . . . . . . . . . . . . . . . . 22 10.2 DCI using ASBRs . . . . . . . . . . . . . . . . . . . . . . 23
10.2.1 ASBR Functionality with Single-Homing NVEs . . . . . . 23 10.2.1 ASBR Functionality with Single-Homing NVEs . . . . . . 24
10.2.2 ASBR Functionality with Multi-Homing NVEs . . . . . . . 23 10.2.2 ASBR Functionality with Multi-Homing NVEs . . . . . . . 24
11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26 11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 26
12 Security Considerations . . . . . . . . . . . . . . . . . . . 26 12 Security Considerations . . . . . . . . . . . . . . . . . . . 26
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
14.1 Normative References . . . . . . . . . . . . . . . . . . . 27 14.1 Normative References . . . . . . . . . . . . . . . . . . . 27
14.2 Informative References . . . . . . . . . . . . . . . . . . 27 14.2 Informative References . . . . . . . . . . . . . . . . . . 27
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 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 [RFC7364], are:
- Isolation of network traffic per tenant - Isolation of network traffic per tenant
- Support for a large number of tenants (tens or hundreds of - Support for a large number of tenants (tens or hundreds of
thousands) thousands)
- Extending L2 connectivity among different VMs belonging to a given - Extending L2 connectivity among different VMs belonging to a given
tenant segment (subnet) across different PODs within a data center or tenant segment (subnet) across different PODs within a data center or
between different data centers between different data centers
skipping to change at page 5, line 5 skipping to change at page 5, line 5
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 Requirements Notation and Conventions
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 [KEYWORDS]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
3 Terminology 3 Terminology
Most of the terminology used in this documents comes from [RFC7432] Most of the terminology used in this documents comes from [RFC7432]
and [NVO3-FRWK]. and [RFC7365].
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 8, line 4 skipping to change at page 8, line 6
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 encapsulation and it mandates [RFC7637] encapsulation is based on GRE encapsulation and it mandates
the inclusion of the optional GRE Key field which carries the VSID. the inclusion of the optional GRE Key field which carries the VSID.
There is a one-to-one mapping between the VSID and the tenant VLAN There is a one-to-one mapping between the VSID and the tenant VLAN
ID, as described in [NVGRE] and the inclusion of an inner VLAN tag is ID, as described in [RFC7637] and the inclusion of an inner VLAN tag
prohibited. This mode of operation in [NVGRE] maps to VLAN Based is prohibited. This mode of operation in [RFC7637] maps to VLAN Based
Service in [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 the 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.
skipping to change at page 11, line 9 skipping to change at page 11, line 9
auto generated as described in [RFC7432] and RT can be auto-derived auto generated as described in [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 from 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 avoid conflict in RT spaces arises,
spaces arises, RT values for DCNs are auto-derived as follow: the 6-byte RT values with 2-octet AS number for DCNs can be auto-
derived as follow:
0 1 2 3 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 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 ID | | Global Administrator | Local Administrator |
+-----------------------------------------------+---------------+
| Local Administrator (Cont.) |
+-------------------------------+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Administrator |A| TYPE| D-ID | Service ID |
+-----------------------------------------------+---------------+ +-----------------------------------------------+---------------+
| Service ID (Cont.) | | Service ID (Cont.) |
+-------------------------------+ +-------------------------------+
- 2 bytes of global admin field of the RT is set to the AS number. The 6-octet RT field consists of two sub-field:
- Three least significant bytes of the local admin field of the RT is - Global Administrator sub-field: 2 octets. This sub-field contains
set to the VNI, VSID, I-SID, or VID. an Autonomous System number assigned by IANA.
- The most significant bit of the local admin field of the RT is set - Local Administrator sub-field: 4 octets
as follow:
0: auto-derived
1: manually-derived
- The next 3 bits of the most significant byte of the local admin * A: A single-bit field indicating if this RT is auto-derived
field of the RT identifies the space in which the other 3 bytes are
defined. The following spaces are defined:
0 : VID (802.1Q VLAN ID)
1 : VXLAN
2 : NVGRE
3 : I-SID
4 : EVI
5 : dual-VID (QinQ VLAN ID)
- The remaining 4 bits of the most significant byte of the local 0: auto-derived
admin field of the RT identifies the domain-id. The default value of 1: manually-derived
domain-id is zero indicating that only a single numbering space exist
for a given technology. However, if there are more than one number * Type: A 3-bit field that identifies the space in which
space exist for a given technology (e.g., overlapping VXLAN spaces), the other 3 bytes are defined. The following spaces are
then each of the number spaces need to be identify by their defined:
corresponding domain-id starting from 1.
0 : VID (802.1Q VLAN ID)
1 : VXLAN
2 : NVGRE
3 : I-SID
4 : EVI
5 : dual-VID (QinQ VLAN ID)
* D-ID: A 4-bit field that identifies domain-id. The default
value of domain-id is zero indicating that only a single
numbering space exist for a given technology. However, if
there are more than one number space exist for a given
technology (e.g., overlapping VXLAN spaces), then each of
the number spaces need to be identify by their
corresponding domain-id starting from 1.
* Service ID: This 3-octet field is set to VNI, VSID, I-SID,
or VID.
It should be noted that RT auto-derivation is applicable for 2-octet
AS numbers. For 4-octet AS numbers, RT needs to be manually
configured since 3-octet VNI fields cannot be fit within 2-octet
local administrator field.
5.1.3 Constructing EVPN BGP Routes 5.1.3 Constructing EVPN BGP Routes
In EVPN, an MPLS label for instance identifying forwarding table is In EVPN, an MPLS label for instance identifying forwarding table is
distributed by the egress PE via the EVPN control plane and is placed distributed by the egress PE via the EVPN control plane and is placed
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
skipping to change at page 13, line 12 skipping to change at page 13, line 32
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
with multiple encapsulation types as long as they use the same EVPN
multi-homing procedures (section 8.3.1, Split Horizon) - e.g., the
mix of VXLAN and NVGRE encapsulation types is a valid one but not the
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").
5.2 MPLS over GRE 5.2 MPLS over GRE
The EVPN data-plane is modeled as an EVPN MPLS client layer sitting The EVPN data-plane is modeled as an EVPN MPLS client layer sitting
over an MPLS PSN-tunnel server layer. Some of the EVPN functions over an MPLS PSN-tunnel server layer. Some of the EVPN functions
(split-horizon, aliasing, and backup-path) are tied to the MPLS (split-horizon, aliasing, and backup-path) are tied to the MPLS
client layer. If MPLS over GRE encapsulation is used, then the EVPN client layer. If MPLS over GRE encapsulation is used, then the EVPN
MPLS client layer can be carried over an IP PSN tunnel transparently. MPLS client layer can be carried over an IP PSN tunnel transparently.
Therefore, there is no impact to the EVPN procedures and associated Therefore, there is no impact to the EVPN procedures and associated
data-plane operation. data-plane operation.
The existing standards for MPLS over GRE encapsulation as defined by The existing standards for MPLS over GRE encapsulation as defined by
[RFC4023] can be used for this purpose; however, when it is used in [RFC4023] can be used for this purpose; however, when it is used in
conjunction with EVPN the GRE key field SHOULD be present, and SHOULD conjunction with EVPN the GRE key field SHOULD be present, and SHOULD
be used to provide a 32-bit entropy field. The Checksum and Sequence be used to provide a 32-bit entropy value. The Checksum and Sequence
Number fields are not needed and their corresponding C and S bits Number fields MUST NOT be included and the corresponding C and S bits
MUST be set to zero. A PE capable of supporting this encapsulation, in the GRE Packet Header MUST be set to zero. A PE capable of
should advertise its EVPN routes along with the Tunnel Encapsulation supporting this encapsulation, should advertise its EVPN routes along
extended community indicating MPLS over GRE encapsulation, as with the Tunnel Encapsulation extended community indicating MPLS over
described in previous section. GRE encapsulation, as described in previous section.
6 EVPN with Multiple Data Plane Encapsulations 6 EVPN with Multiple Data Plane Encapsulations
The use of the BGP Encapsulation extended community per [TUNNEL- The use of the BGP Encapsulation extended community per [TUNNEL-
ENCAP] and [RFC5512] allows each NVE in a given EVI to know each of ENCAP] and [RFC5512] allows each NVE in a given EVI to know each of
the encapsulations supported by each of the other NVEs in that EVI. the encapsulations supported by each of the other NVEs in that EVI.
i.e., each of the NVEs in a given EVI may support multiple data plane i.e., each of the NVEs in a given EVI may support multiple data plane
encapsulations. An ingress NVE can send a frame to an egress NVE encapsulations. An ingress NVE can send a frame to an egress NVE
only if the set of encapsulations advertised by the egress NVE forms only if the set of encapsulations advertised by the egress NVE forms
a non-empty intersection with the set of encapsulations supported by a non-empty intersection with the set of encapsulations supported by
the ingress NVE, and it is at the discretion of the ingress NVE which the ingress NVE, and it is at the discretion of the ingress NVE which
encapsulation to choose from this intersection. (As noted in encapsulation to choose from this intersection. (As noted in
section 5.1.3, if the BGP Encapsulation extended community is not section 5.1.3, if the BGP Encapsulation extended community is not
present, then the default MPLS encapsulation or a locally configured present, then the default MPLS encapsulation or a locally configured
encapsulation is assumed.) encapsulation is assumed.)
When a PE advertises multiple supported encapsulations, it MUST
advertise encapsulations that use the same EVPN procedures including
procedures associated with split-horizon filtering described in
section 8.3.1. For example, VxLAN and NvGRE (or MPLS and MPLS over
GRE) encapsulations use the same EVPN procedures and thus a PE can
advertise both of them and can support either of them or both of them
simultaneously. However, a PE MUST NOT advertise VxLAN and MPLS
encapsulations together because a) MPLS field of EVPN routes is set
to either a MPLS label for a VNI but not both and b) some of EVPN
procedures (such as split-horizon filtering) are different for
VxLAN/NvGRE and MPLS encapsulations.
An ingress node that uses shared multicast trees for sending An ingress node that uses shared multicast trees for sending
broadcast or multicast frames MAY maintain distinct trees for each broadcast or multicast frames MAY maintain distinct trees for each
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
skipping to change at page 14, line 49 skipping to change at page 15, line 27
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
[NVO3-FRWK], the RD must be a unique value per EVI or per NVE as [RFC7365], 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 has local significance, then a unique
unique RD MUST be used. Therefore, it is recommend to use a unique RD RD must be used. Therefore, it is recommended to use a unique RD as
as described in [RFC7432] at all time. 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 the total of eight listed in section 7 of [RFC7432]:
- MAC/IP Advertisement Route - MAC/IP Advertisement Route
- Inclusive Multicast Ethernet Tag Route - Inclusive Multicast Ethernet Tag Route
- MAC Mobility Extended Community - MAC Mobility Extended Community
- Default Gateway Extended Community - Default Gateway Extended Community
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 backup-path when interacting with multi-homed egress aliasing, and backup-path when interacting with multi-homed egress
NVEs attached to a given Ethernet segment, the single-homing ingress NVEs attached to a given Ethernet segment, the single-homing ingress
NVE SHOULD be able to receive and process Ethernet AD per ES and NVE should be able to receive and process Ethernet AD per ES and
Ethernet AD per EVI routes. Ethernet AD per EVI routes.
7.2 Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation 7.2 Impact on EVPN Procedures for VXLAN/NVGRE Encapsulation
When the NVEs reside on the hypervisors, the EVPN procedures When the NVEs reside on the hypervisors, the EVPN procedures
associated with multi-homing are no longer required. This limits the associated with multi-homing are no longer required. This limits the
procedures on the NVE to the following subset of the EVPN procedures: procedures on the NVE to the following subset of the EVPN procedures:
1. Local learning of MAC addresses received from the VMs per section 1. Local learning of MAC addresses received from the VMs per section
10.1 of [RFC7432]. 10.1 of [RFC7432].
skipping to change at page 15, line 50 skipping to change at page 16, line 30
4. Discovering other NVEs and constructing the multicast tunnels 4. Discovering other NVEs and constructing the multicast tunnels
using the Inclusive Multicast Ethernet Tag routes. using the Inclusive Multicast Ethernet Tag routes.
5. Handling MAC address mobility events per the procedures of Section 5. Handling MAC address mobility events per the procedures of Section
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 Multi-Homing NVEs - 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 NVE 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
skipping to change at page 17, line 40 skipping to change at page 18, line 18
from a given source MAC address to a single NVE. Another scenario from a given source MAC address to a single NVE. Another scenario
where this occurs is when the NVEs rely on control plane learning on where this occurs is when the NVEs rely on control plane learning on
the access (e.g. using ARP), since ARP traffic will be hashed to a the access (e.g. using ARP), since ARP traffic will be hashed to a
single link in the LAG. single link in the LAG.
To alleviate this issue, EVPN introduces the concept of Aliasing. To alleviate this issue, EVPN introduces the concept of Aliasing.
This refers to the ability of an NVE to signal that it has This refers to the ability of an NVE to signal that it has
reachability to a given locally attached Ethernet segment, even when reachability to a given locally attached Ethernet segment, even when
it has learnt no MAC addresses from that segment. The Ethernet A-D it has learnt no MAC addresses from that segment. The Ethernet A-D
route per EVI is used to that end. Remote NVEs which receive MAC route per EVI is used to that end. Remote NVEs which receive MAC
advertisement routes with non-zero ESI SHOULD consider the MAC advertisement routes with non-zero ESI should consider the MAC
address as reachable via all NVEs that advertise reachability to the address as reachable via all NVEs that advertise reachability to the
relevant Segment using Ethernet A-D routes with the same ESI and with relevant Segment using Ethernet A-D routes with the same ESI and with
the Single-Active flag reset. the Single-Active flag reset.
Backup-Path is a closely related function, albeit it applies to the Backup-Path is a closely related function, albeit it applies to the
case where the redundancy mode is Single-Active. In this case, the case where the redundancy mode is Single-Active. In this case, the
NVE signals that it has reachability to a given locally attached NVE signals that it has reachability to a given locally attached
Ethernet Segment using the Ethernet A-D route as well. Remote NVEs Ethernet Segment using the Ethernet A-D route as well. Remote NVEs
which receive the MAC advertisement routes, with non-zero ESI, SHOULD which receive the MAC advertisement routes, with non-zero ESI, should
consider the MAC address as reachable via the advertising NVE. consider the MAC address as reachable via the advertising NVE.
Furthermore, the remote NVEs should install a Backup-Path, for said
Furthermore, the remote NVEs SHOULD install a Backup-Path, for said
MAC, to the NVE which had advertised reachability to the relevant MAC, to the NVE which had advertised reachability to the relevant
Segment using an Ethernet A-D route with the same ESI and with the Segment using an Ethernet A-D route with the same ESI and with the
Single-Active flag set. Single-Active flag set.
8.1.5 DF Election 8.1.5 DF Election
If a host is multi-homed to two or more NVEs on an Ethernet segment If a host is multi-homed to two or more NVEs on an Ethernet segment
operating in all-active redundancy mode, then for a given EVI only operating in all-active redundancy mode, then for a given EVI only
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 [RFC7432]. 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).
skipping to change at page 19, line 31 skipping to change at page 20, line 8
In EVPN, an MPLS label is used for split-horizon filtering to support In EVPN, an MPLS label is used for split-horizon filtering to support
All-Active multi-homing where an ingress NVE adds a label All-Active multi-homing where an ingress NVE adds a label
corresponding to the site of origin (aka ESI Label) when corresponding to the site of origin (aka ESI Label) when
encapsulating the packet. The egress NVE checks the ESI label when encapsulating the packet. The egress NVE checks the ESI label when
attempting to forward a multi-destination frame out an interface, and attempting to forward a multi-destination frame out an interface, and
if the label corresponds to the same site identifier (ESI) associated if the label corresponds to the same site identifier (ESI) associated
with that interface, the packet gets dropped. This prevents the with that interface, the packet gets dropped. This prevents the
occurrence of forwarding loops. occurrence of forwarding loops.
Since the VXLAN or NVGRE encapsulation does not include this ESI Since VXLAN and NVGRE encapsulations do not include the ESI label,
label, other means of performing the split-horizon filtering function other means of performing the split-horizon filtering function must
MUST be devised. The following approach is recommended for split- be devised for these encapsulations. The following approach is
horizon filtering when VXLAN (or NVGRE) encapsulation is used. recommended for split-horizon filtering when VXLAN (or NVGRE)
encapsulation is used.
Every NVE track the IP address(es) associated with the other NVE(s) Every NVE track the IP address(es) associated with the other NVE(s)
with which it has shared multi-homed Ethernet Segments. When the NVE with which it has shared multi-homed Ethernet Segments. When the NVE
receives a multi-destination frame from the overlay network, it receives a multi-destination frame from the overlay network, it
examines the source IP address in the tunnel header (which examines the source IP address in the tunnel header (which
corresponds to the ingress NVE) and filters out the frame on all corresponds to the ingress NVE) and filters out the frame on all
local interfaces connected to Ethernet Segments that are shared with local interfaces connected to Ethernet Segments that are shared with
the ingress NVE. With this approach, it is required that the ingress the ingress NVE. With this approach, it is required that the ingress
NVE performs replication locally to all directly attached Ethernet NVE performs replication locally to all directly attached Ethernet
Segments (regardless of the DF Election state) for all flooded Segments (regardless of the DF Election state) for all flooded
traffic ingress from the access interfaces (i.e. from the hosts). traffic ingress from the access interfaces (i.e. from the hosts).
This approach is referred to as "Local Bias", and has the advantage This approach is referred to as "Local Bias", and has the advantage
that only a single IP address needs to be used per NVE for split- that only a single IP address needs to be used per NVE for split-
horizon filtering, as opposed to requiring an IP address per Ethernet horizon filtering, as opposed to requiring an IP address per Ethernet
Segment per NVE. Segment per NVE.
In order to prevent unhealthy interactions between the split horizon In order to allow proper operation of split-horizon filtering among
procedures defined in [RFC7432] and the local bias procedures the same group of multi-homing PE devices, a mix of PE devices with
described in this document, a mix of MPLS over GRE encapsulations on MPLS over GRE encapsulations running [RFC7432] procedures for split-
the one hand and VXLAN/NVGRE encapsulations on the other on a given horizon filtering on the one hand and VXLAN/NVGRE encapsulations
Ethernet Segment is prohibited. running local-bias procedures on the other on a given Ethernet
Segment MUST NOT be configured.
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 are 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-
skipping to change at page 20, line 46 skipping to change at page 21, line 25
address arrives on the ingress PE, it floods it via ingress address arrives on the ingress PE, it floods it via ingress
replication to all the egress PE(s) and since they are known to the replication to all the egress PE(s) and since they are known to the
egress PE(s), multiple copies is sent to the All-Active multi-homed egress PE(s), multiple copies is sent to the All-Active multi-homed
site. It should be noted that such transient packet duplication only site. It should be noted that such transient packet duplication only
happens when a) the destination host is multi-homed via All-Active happens when a) the destination host is multi-homed via All-Active
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 set the BUM Traffic Bit (B bit) [VXLAN-GPE]
indicate BUM traffic type. Bit 6 of flag field in the VxLAN header is to indicate BUM traffic.
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 Ethernet Tag (IMET) route is used to
discover the multicast tunnels among the endpoints associated with a discover the multicast tunnels among the endpoints associated with a
given EVI (e.g., given VNI) for VLAN-based service and a given given EVI (e.g., given VNI) for VLAN-based service and a given
<EVI,VLAN> for VLAN-aware bundle service. All fields of this route is <EVI,VLAN> for VLAN-aware bundle service. All fields of this route is
set as described in section 5.1.3. The Originating router's IP set as described in section 5.1.3. The Originating router's IP
address field is set to the NVE's IP address. This route is tagged address field is set to the NVE's IP address. This route is tagged
with the PMSI Tunnel attribute, which is used to encode the type of with the PMSI Tunnel attribute, which is used to encode the type of
multicast tunnel to be used as well as the multicast tunnel multicast tunnel to be used as well as the multicast tunnel
identifier. The tunnel encapsulation is encoded by adding the BGP identifier. The tunnel encapsulation is encoded by adding the BGP
Encapsulation extended community as per section 5.1.1. For example, Encapsulation extended community as per section 5.1.1. For example,
skipping to change at page 23, line 41 skipping to change at page 24, line 20
NVEs reside in a Hypervisors or in TORs. NVEs reside in a Hypervisors or in TORs.
10.2.1 ASBR Functionality with Single-Homing NVEs 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 Multi-Homing NVEs 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
multi-homing NVE to send Ethernet A-D per ES route(s) (used for mass multi-homing NVE to send Ethernet A-D per ES route(s) (used for mass
withdraw) and Ethernet A-D per EVI routes (used for aliasing). As withdraw) and Ethernet A-D per EVI routes (used for aliasing). As
described above, the re-write of BGP next-hop by ASBRs creates described above, the re-write of BGP next-hop by ASBRs creates
skipping to change at page 26, line 17 skipping to change at page 26, line 44
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
A-D per EVI route. A-D per EVI route.
11 Acknowledgement 11 Acknowledgement
The authors would like to thank Aldrin Isaac, David Smith, John The authors would like to thank Aldrin Isaac, David Smith, John
Mullooly, Thomas Nadeau for their valuable comments and feedback. The Mullooly, Thomas Nadeau, Samir Thoria, and Jorge Rabadan for their
authors would also like to thank Jakob Heitz for his contribution on valuable comments and feedback. The authors would also like to thank
section 10.2. Jakob Heitz for his contribution on section 10.2.
12 Security Considerations 12 Security Considerations
This document uses IP-based tunnel technologies to support data This document uses IP-based tunnel technologies to support data
plane transport. Consequently, the security considerations of those plane transport. Consequently, the security considerations of those
tunnel technologies apply. This document defines support for VXLAN tunnel technologies apply. This document defines support for VXLAN
and NVGRE encapsulations. The security considerations from those [RFC7348] and NVGRE [RFC7637] encapsulations. The security
documents as well as [RFC4301] apply to the data plane aspects of considerations from those RFCs apply to the data plane aspects of
this document. this document.
As with [RFC5512], any modification of the information that is used As with [RFC5512], any modification of the information that is used
to form encapsulation headers, to choose a tunnel type, or to choose to form encapsulation headers, to choose a tunnel type, or to choose
a particular tunnel for a particular payload type may lead to user a particular tunnel for a particular payload type may lead to user
data packets getting misrouted, misdelivered, and/or dropped. data packets getting misrouted, misdelivered, and/or dropped.
More broadly, the security considerations for the transport of IP More broadly, the security considerations for the transport of IP
reachability information using BGP are discussed in [RFC4271] and reachability information using BGP are discussed in [RFC4271] and
[RFC4272], and are equally applicable for the extensions described [RFC4272], and are equally applicable for the extensions described
in this document. in this document.
If the integrity of the BGP session is not itself protected, then an
imposter could mount a denial-of-service attack by establishing
numerous BGP sessions and forcing an IPsec SA to be created for each
one. However, as such an imposter could wreak havoc on the entire
routing system, this particular sort of attack is probably not of
any special importance.
It should be noted that a BGP session may itself be transported over
an IPsec tunnel. Such IPsec tunnels can provide additional security
to a BGP session. The management of such IPsec tunnels is outside
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 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
Requirement Levels", BCP 14, RFC 2119, March 1997. 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border
Gateway Protocol 4 (BGP-4)", January 2006.
[RFC4301] S. Kent, K. Seo., "Security Architecture for the
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.", [RFC4272] S. Murphy, "BGP Security Vulnerabilities Analysis.",
January 2006. January 2006.
[NVGRE] Garg, P., et al., "NVGRE: Network Virtualization using [RFC7637] Garg, P., et al., "NVGRE: Network Virtualization using
Generic Routing Encapsulation", RFC 7637, September, 2015 Generic Routing Encapsulation", RFC 7637, September, 2015
[Problem-Statement] Narten et al., "Problem Statement: Overlays for [RFC7364] Narten et al., "Problem Statement: Overlays for Network
Network Virtualization", RFC 7364, October 2014. Virtualization", RFC 7364, October 2014.
[NVO3-FRWK] Lasserre et al., "Framework for DC Network [RFC7365] Lasserre et al., "Framework for DC Network Virtualization",
Virtualization", RFC 7365, October 2014. RFC 7365, October 2014.
[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-04, work in Overlay networks", draft-ietf-bess-dci-evpn-overlay-04, work in
progress, February 29, 2016. progress, February 29, 2016.
[RFC4271] Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed., "A Border
Gateway Protocol 4 (BGP-4)", January 2006.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation [TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-03, 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 [RFC4364] Rosen, E., et al, "BGP/MPLS IP Virtual Private Networks
(VPNs)", RFC 4364, February 2006. (VPNs)", RFC 4364, February 2006.
 End of changes. 53 change blocks. 
123 lines changed or deleted 142 lines changed or added

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