draft-ietf-bess-evpn-overlay-05.txt   draft-ietf-bess-evpn-overlay-06.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: April 18, 2017 October 18, 2016 Expires: May 18, 2017 November 18, 2016
A Network Virtualization Overlay Solution using EVPN A Network Virtualization Overlay Solution using EVPN
draft-ietf-bess-evpn-overlay-05 draft-ietf-bess-evpn-overlay-06
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 2, line 41 skipping to change at page 2, line 41
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 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 NVE Residing in ToR Switch . . . . . . . . . . . . . . . . . . 15
8.1 EVPN Multi-Homing Features . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . . . . . . . . . . 16
8.1.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 16 8.1.4 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 16
8.1.5 DF Election . . . . . . . . . . . . . . . . . . . . . . 17 8.1.5 DF Election . . . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . . . . 18
8.3.2 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 19 8.3.2 Aliasing and Backup-Path . . . . . . . . . . . . . . . . 19
9 Support for Multicast . . . . . . . . . . . . . . . . . . . . . 19 9 Support for Multicast . . . . . . . . . . . . . . . . . . . . . 19
10 Data Center Interconnections - DCI . . . . . . . . . . . . . . 20 10 Data Center Interconnections - DCI . . . . . . . . . . . . . . 20
10.1 DCI using GWs . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . . . . . . 25 11 Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 25
12 Security Considerations . . . . . . . . . . . . . . . . . . . 25 12 Security Considerations . . . . . . . . . . . . . . . . . . . 25
13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 13 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 14 References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
14.1 Normative References . . . . . . . . . . . . . . . . . . . 26 14.1 Normative References . . . . . . . . . . . . . . . . . . . 26
14.2 Informative References . . . . . . . . . . . . . . . . . . 26 14.2 Informative References . . . . . . . . . . . . . . . . . . 26
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
skipping to change at page 11, line 33 skipping to change at page 11, line 33
- 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
In EVPN, an MPLS label identifying forwarding table is distributed by In EVPN, an MPLS label for instance identifying forwarding table is
the egress PE via the EVPN control plane and is placed in the MPLS distributed by the egress PE via the EVPN control plane and is placed
header of a given packet by the ingress PE. This label is used upon in the MPLS header of a given packet by the ingress PE. This label is
receipt of that packet by the egress PE for disposition of that used upon receipt of that packet by the egress PE for disposition of
packet. This is very similar to the use of the VNI by the egress NVE, that packet. This is very similar to the use of the VNI by the egress
with the difference being that an MPLS label has local significance NVE, with the difference being that an MPLS label has local
while a VNI typically has global significance. Accordingly, and significance while a VNI typically has global significance.
specifically to support the option of locally-assigned VNIs, the MPLS Accordingly, and specifically to support the option of locally-
Label1 field in the MAC/IP Advertisement route, the MPLS label field assigned VNIs, the MPLS Label1 field in the MAC/IP Advertisement
in the Ethernet AD per EVI route, and the MPLS label field in the route, the MPLS label field in the Ethernet AD per EVI route, and the
PMSI Tunnel Attribute of the Inclusive Multicast Ethernet Tag (IMET) MPLS label field in the PMSI Tunnel Attribute of the Inclusive
route are used to carry the VNI. For the balance of this memo, the Multicast Ethernet Tag (IMET) route are used to carry the VNI. For
MPLS label field will be referred to as the VNI field. The VNI field the balance of this memo, the MPLS label field will be referred to as
is used for both local and global VNIs, and for either case the the VNI field. The VNI field is used for both local and global VNIs,
entire 24-bit field is used to encode the VNI value. and for either case the entire 24-bit field is used 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
Tags for that EVI needs to be configured consistently on all PEs Tags for that EVI needs to be configured consistently on all PEs
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
skipping to change at page 17, line 45 skipping to change at page 17, line 49
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 is performed on host VLAN IDs (VIDs). It is assumed that for election SHOULD BE performed based on host VLAN IDs (VIDs) per
a given Ethernet Segment, VIDs are unique and consistent (e.g., no section 8.5 of [RFC 7432]. Furthermore, multi-homing PEs of a given
duplicate VIDs exist). In NVEs where QinQ tagged frames are received Ethernet Segment MAY perform DF election using configured IDs such as
from hosts, then if NVEs are configured to identify an EVI/BD based VNI, EVI, normalized VIDs, and etc. as along the IDs are configured
on both tags, then DF election is performed on both tags; however, if consistently across the multi-homing PEs.
NVEs are configured to identify an EVI/BD based on a single tag, then
DF election is performed based on the outer tag.
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
Since multi-homing is supported in this scenario, then the entire set Since multi-homing is supported in this scenario, then the entire set
of BGP routes and attributes defined in [RFC7432] are used. The of BGP routes and attributes defined in [RFC7432] are used. The
skipping to change at page 19, line 51 skipping to change at page 20, line 5
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 is set as described in section 5.1.3.
9 Support for Multicast 9 Support for Multicast
The E-VPN Inclusive Multicast BGP route is used to discover the The E-VPN Inclusive Multicast BGP route is used to discover the
multicast tunnels among the endpoints associated with a given EVI multicast tunnels among the endpoints associated with a given EVI
(e.g., given VNI) for VLAN-based service and a given <EVI,VLAN> for (e.g., given VNI) for VLAN-based service and a given <EVI,VLAN> for
VLAN-aware bundle service. The Ethernet Tag field 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.
 End of changes. 8 change blocks. 
39 lines changed or deleted 37 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/