draft-ietf-bess-evpn-overlay-03.txt   draft-ietf-bess-evpn-overlay-04.txt 
L2VPN Workgroup A. Sajassi (Editor) L2VPN 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
A. Isaac R. Shekhar
Juniper Juniper
J. Uttaro J. Uttaro
AT&T AT&T
W. Henderickx W. Henderickx
Nokia Nokia
Expires: November 24, 2016 May 24, 2016 Expires: December 10, 2016 June 10, 2016
A Network Virtualization Overlay Solution using EVPN A Network Virtualization Overlay Solution using EVPN
draft-ietf-bess-evpn-overlay-03 draft-ietf-bess-evpn-overlay-04
Abstract Abstract
This document describes how Ethernet VPN (EVPN) [RFC7432] can be used This document describes how Ethernet VPN (EVPN) [RFC7432] can be used
as an Network Virtualization Overlay (NVO) solution and explores the as an 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
skipping to change at page 3, line 17 skipping to change at page 3, line 17
10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 21 10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 21
10.2 DCI using ASBRs . . . . . . . . . . . . . . . . . . . . . . 21 10.2 DCI using ASBRs . . . . . . . . . . . . . . . . . . . . . . 21
10.2.1 ASBR Functionality with NVEs in Hypervisors . . . . . . 22 10.2.1 ASBR Functionality with NVEs in Hypervisors . . . . . . 22
10.2.2 ASBR Functionality with NVEs in TORs . . . . . . . . . 22 10.2.2 ASBR Functionality with NVEs in TORs . . . . . . . . . 22
11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24 11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 24
12 Security Considerations . . . . . . . . . . . . . . . . . . . 24 12 Security Considerations . . . . . . . . . . . . . . . . . . . 24
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
14.1 Normative References . . . . . . . . . . . . . . . . . . . 25 14.1 Normative References . . . . . . . . . . . . . . . . . . . 25
14.2 Informative References . . . . . . . . . . . . . . . . . . 26 14.2 Informative References . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
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). The key requirements of such a solution, as described Machines (VMs). The key requirements of such a solution, as described
in [Problem-Statement], are: in [Problem-Statement], are:
skipping to change at page 12, line 38 skipping to change at page 12, line 38
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 that which type of data plane encapsulation
(i.e., VXLAN, NVGRE, MPLS, or MPLS in GRE) is to be used, the BGP (i.e., VXLAN, NVGRE, MPLS, or MPLS in GRE) is to be used, the BGP
Encapsulation extended community defined in [RFC5512] is included Encapsulation extended community defined in [TUNNEL-ENCAP]and
with all EVPN routes (i.e. MAC Advertisement, Ethernet AD per EVI, [RFC5512] is included with all EVPN routes (i.e. MAC Advertisement,
Ethernet AD per ESI, Inclusive Multicast Ethernet Tag, and Ethernet Ethernet AD per EVI, Ethernet AD per ESI, Inclusive Multicast
Segment) advertised by an egress PE. Five new values have been Ethernet Tag, and Ethernet Segment) advertised by an egress PE. Five
assigned by IANA to extend the list of encapsulation types defined in new values have been assigned by IANA to extend the list of
[RFC5512]: encapsulation types defined in [TUNNEL-ENCAP] and they are listed in
section 13.
+ 8 - VXLAN Encapsulation
+ 9 - NVGRE Encapsulation
+ 10 - MPLS Encapsulation
+ 11 - MPLS in GRE Encapsulation
+ 12 - VXLAN GPE Encapsulation
Note that the MPLS encapsulation tunnel type is needed in order to The MPLS encapsulation tunnel type, listed in section 13, is needed
distinguish between an advertising node that only supports non-MPLS in order to distinguish between an advertising node that only
encapsulations and one that supports MPLS and non-MPLS supports non-MPLS encapsulations and one that supports MPLS and non-
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 - e.g., the mix of VXLAN and NVGRE
encapsulation types is a valid one but not the mix of VXLAN and MPLS encapsulation types is a valid one but not the mix of VXLAN and MPLS
encapsulation types. encapsulation types.
skipping to change at page 13, line 39 skipping to change at page 13, line 33
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 field. The Checksum and Sequence
Number fields are not needed and their corresponding C and S bits Number fields are not needed and their corresponding C and S bits
MUST be set to zero. MUST be set to zero. A PE capable of supporting this encapsulation,
should advertise its EVPN routes along with the Tunnel Encapsulation
extended community indicating MPLS over 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 [RFC5512] The use of the BGP Encapsulation extended community per [TUNNEL-
allows each NVE in a given EVI to know each of the encapsulations ENCAP] and [RFC5512] allows each NVE in a given EVI to know each of
supported by each of the other NVEs in that EVI. i.e., each of the the encapsulations supported by each of the other NVEs in that EVI.
NVEs in a given EVI may support multiple data plane encapsulations. i.e., each of the NVEs in a given EVI may support multiple data plane
An ingress NVE can send a frame to an egress NVE only if the set of encapsulations. An ingress NVE can send a frame to an egress NVE
encapsulations advertised by the egress NVE in the subject MAC/IP only if the set of encapsulations advertised by the egress NVE in the
Advertisement or per EVI Ethernet AD route, forms a non-empty subject MAC/IP Advertisement or per EVI Ethernet AD route, forms a
intersection with the set of encapsulations supported by the ingress non-empty intersection with the set of encapsulations supported by
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 statically present, then the default MPLS encapsulation or a statically
configured encapsulation is assumed.) configured encapsulation is assumed.)
An ingress node that uses shared multicast trees for sending An ingress node that uses shared multicast trees for sending
broadcast or multicast frames MUST maintain distinct trees for each broadcast or multicast frames MUST 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
skipping to change at page 24, line 41 skipping to change at page 24, line 41
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 use Ether A-D per ES route; whereas, PEs receiving from the same AS use Ether A-D per ES route; whereas, PEs receiving
mass-withdraw route from different AS use Ether A-D per EVI route. mass-withdraw route from different AS use Ether A-D per EVI route.
11 Acknowledgement 11 Acknowledgement
The authors would like to thank David Smith, John Mullooly, Thomas The authors would like to thank Aldrin Isaac, David Smith, John
Nadeau for their valuable comments and feedback. The authors would Mullooly, Thomas Nadeau for their valuable comments and feedback. The
also like to thank Jakob Heitz for his contribution on section 10. authors would also like to thank 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 and NVGRE encapsulations. The security considerations from those
documents as well as [RFC4301] apply to the data plane aspects of documents as well as [RFC4301] apply to the data plane aspects of
this document. this document.
skipping to change at page 26, line 46 skipping to change at page 26, line 47
draft-ietf-l3vpn-end-system, work in progress, October 2012. draft-ietf-l3vpn-end-system, work in progress, October 2012.
[NOV3-FRWK] Lasserre et al., "Framework for DC Network [NOV3-FRWK] Lasserre et al., "Framework for DC Network
Virtualization", draft-ietf-nvo3-framework-01.txt, work in progress, Virtualization", draft-ietf-nvo3-framework-01.txt, work in progress,
October 2012. 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-02, work in
progress, February 29, 2016. progress, February 29, 2016.
[TUNNEL-ENCAP] Rosen et al., "The BGP Tunnel Encapsulation
Attribute", draft-ietf-idr-tunnel-encaps-02, work in progress, May
31, 2016.
Contributors Contributors
S. Salam K. Patel D. Rao S. Thoria D. Cai Cisco S. Salam K. Patel D. Rao S. Thoria D. Cai Cisco
Y. Rekhter R. Shekhar Wen Lin Nischal Sheth Juniper Y. Rekhter R. Shekhar Wen Lin Nischal Sheth Juniper
L. Yong Huawei 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
skipping to change at page 27, line 20 skipping to change at page 27, line 27
Email: sajassi@cisco.com Email: sajassi@cisco.com
John Drake John Drake
Juniper Networks Juniper Networks
Email: jdrake@juniper.net Email: jdrake@juniper.net
Nabil Bitar Nabil Bitar
Nokia Nokia
Email : nabil.bitar@nokia.com Email : nabil.bitar@nokia.com
Aldrin Isaac R. Shekhar
Juniper Juniper
Email: aisaac@juniper.net Email: rshekhar@juniper.net
James Uttaro James Uttaro
AT&T AT&T
Email: uttaro@att.com Email: uttaro@att.com
Wim Henderickx Wim Henderickx
Alcatel-Lucent Alcatel-Lucent
e-mail: wim.henderickx@nokia.com e-mail: wim.henderickx@nokia.com
 End of changes. 13 change blocks. 
35 lines changed or deleted 39 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/