Internet DRAFT - draft-hao-l2vpn-evpn-nvo3-active-active
draft-hao-l2vpn-evpn-nvo3-active-active
L2VPN Weiguo Hao
Yizhou Li
Internet Draft Huawei
Intended status: Standards Track July 11, 2013
Expires: January 2014
Active-active access in NVO3 network
draft-hao-l2vpn-evpn-nvo3-active-active-00.txt
Status of this Memo
This Internet-Draft is submitted in full conformance with the provisions of BCP 78
and BCP 79.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78
and BCP 79. This document may not be modified, and derivative works of it may not
be created, and it may not be published except as an Internet-Draft.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78
and BCP 79. This document may not be modified, and derivative works of it may not
be created, except to publish it as an RFC and to translate it into languages
other than English.
This document may contain material from IETF Documents or IETF Contributions
published or made publicly available before November 10, 2008. The person(s)
controlling the copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the IETF Standards
Process. Without obtaining an adequate license from the person(s) controlling the
copyright in such materials, this document may not be modified outside the IETF
Standards Process, and derivative works of it may not be created outside the IETF
Standards Process, except to format it for publication as an RFC or to translate
it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet-Drafts as reference material or to cite them other
than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
Hao & Li Expires January 11, 2014 [Page 1]
Internet-Draft Active-active access in NVO3 network July 2013
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on January 11, 2014.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors.
All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating
to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully, as they
describe your rights and restrictions with respect to this document. Code
Components extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating
to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents carefully, as they
describe your rights and restrictions with respect to this document.
Abstract
E-VPN can be used as a control plane protocol for NVO3 network. In All-Active
access scenario, loop & echo forwarding prevention among multi-homed NVEs relies
on "Split horizon" filtering mechanism. ESI MPLS label is leveraged to perform
split horizon filtering in MPLS based EVPN network. In VXLAN or NVGRE
encapsulation based overlay network, no MPLS is used. Therefore a new method is
introduced in this document to achieve split horizon filtering in non-MPLS overlay
network. Data plane of the overlay network is extended with a LAGID field. The
function of LAGID is similar to ESI MPLS Label in [EVPN]. It is used to identify
each Ethernet segment(ES) on each NVE.
Table of Contents
1. Introduction................................................... 3
1.1. Terminology............................................... 4
2. Source IP based solution......................................... 4
3. LAGID extension solution......................................... 4
3.1. Ingress Replication......................................... 6
3.2. Point-to-multipoint......................................... 6
4. VXLAN data plane extension ....................................... 6
5. NVGRE data plane extension ....................................... 7
6. Security Considerations.......................................... 8
7. IANA Considerations ............................................. 8
Hao&Li Expires January 11, 2014 [Page 2]
Internet-Draft Active-active access in NVO3 network July 2013
8. References .................................................... 8
8.1. Normative References........................................ 8
8.2. Informative References ...................................... 8
9. Acknowledgments ................................................ 8
1. Introduction
Network Virtualization Overlays (NVO3) is a solution to satisfy a core requirement
of multi-tenancy in data center networks through an overlay-based network
virtualization approach. VXLAN and NVGRE are two typical mechanisms to implement
network virtualization overlays. E-VPN was originally designed for MPLS-based
network. E-VPN supports the flexible multi-homing with all-active Attachment
Circuits (ACs). In E-VPN, MAC learning between PEs occurs in the control plane.
In All-Active case, the following two problems for multicast packet forwarding
should be solved:
1. Duplicate delivery of flooded traffic. As described in [EVPN], Designated
Forwarder(DF) election mechanism can be used to prevent duplicate copies of
flooded traffic from remote PE. Only one link is elected as DF per <ESI, EVI> or
per ESI. DF is responsible for forwarding flooded multi-destination frames to the
multi-homed Segment. If a CE is multi-homed to two or more PEs, an Ethernet
segment is the set of Ethernet links and may appear to the CE as a Link
Aggregation Group (LAG). EVI is E-VPN instance.
2. Loop & Echo Forwarding among multi-homed PEs. As described in [EVPN], if a CE
sends a broadcast, unknown unicast or multicast (BUM) packet to one of the non-DF
PEs, say PE1, PE1 will forward that packet to all or subset of the other PEs in
the EVI including the DF PE for that Ethernet segment. In this case the DF PE MUST
drop the packet instead of forwarding to CE. "Split horizon" filtering mechanism
relying on MPLS ESI label can be used to avoid loop & echo forwarding.
In NVO3 network, NVE is equivalent to PE in [EVPN], VXLAN and NVGRE are two
typical data plane encapsulations between NVEs. [NV-EVPN] analyzes the feasibility
of E-VPN to be used as an control plane protocol for NVO3 network, especially the
impact of various tunnel encapsulation options such as VXLAN and NVGRE on the E-
VPN protocol. With some modifications on E-VPN procedures, EVPN framework can be
used for NVO3 solution.
In the scenario of NVE residing in TOR switch, the servers (where VMs are residing)
are normally multi-homed to ToR switches to enhance the reliability. Multi-homing
may operate in All-Active redundancy mode. In All-Active access scenario, DF
election can be used to solve the duplicated delivery of flooded traffic issue in
NVO3 network. Each EVI corresponds to single VNI or multiple VNIs. As for the
issue of loop & echo forwarding among multi-homed NVEs, as VXLAN or NVGRE
encapsulation does not include any MPLS label, method other than ESI MPLS label
Hao&Li Expires January 11, 2014 [Page 3]
Internet-Draft Active-active access in NVO3 network July 2013
should be proposed. This draft introduces such mechanism to address the issue of
loop & echo forwarding among multi-homed NVEs.
1.1. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC-2119 [RFC2119].
DC: Data Center.
NVE: Network Virtualization Endpoint.
VN: Virtual Network. This is a virtual L2 or L3 domain that belongs a tenant.
TES: Tenant End System. It defines an end system of a particular tenant, which can
be for instance a virtual machine (VM), a non-virtualized server, or a physical
appliance.
2. Source IP based solution
There is a known solution to address split-horizon filtering problem in the NVO3-
based EVPN scenario as following.
Each NVE allocates a unique IP address for each Ethernet segment which is called
ESI IP address here. When an NVE receives a BUM frame from a local ESI interface,
it uses the ESI IP address as source IP address for NVO3 tunnel encapsulation and
sends the frame to other NVE(s).
When an egress NVE receives the multicast frame from NVO3 network, it checks the
source IP address of NVO3 tunnel and filters out the frame on all local interfaces
connected to Ethernet segments that are shared with the ingress NVE. Each NVE
should track the IP address(es) associated with the other NVE(s) with which it has
shared multi-homed Ethernet segments. The solution has IP address allocation
scalability issue, as each NVE needs to allocate an IP address per Ethernet
Segment.
To address the issue above, a new solution with NVO3 data plane extension is
introduced in this draft. The details of the solution will be illustrated in
section 4. VXLAN and NVGRE data plane extensions will be given in section 5.
3. LAGID extension solution
Link Aggregation Group Identifier(LAGID) is introduced in this solution to perform
loop & echo forwarding prevention among multi-homed NVEs. LAGID is used to
identify each Ethernet segment on an NVE. All NVEs operating in All-Active multi-
homing mode should announce the local assigned LAGID to other NVEs for each
Hao&Li Expires January 11, 2014 [Page 4]
Internet-Draft Active-active access in NVO3 network July 2013
Ethernet segment, the LAGID is assigned on each NVE independently and different
LAGID can be assigned on different NVE for same Ethernet segment.
------------------
/ \
| NVO3 Network |
\ /
------------------
| |
| |
+------+ +------+
| NVE1 | | NVE2 |
+------+ +------+
non-DF-->| DF->| |
|------------| |
| |
| +------+
| | TES2 |
| +------+
ES1--->|
+------+
| TES1 |
+------+
Figure 1 Active-Active access in NVO3 network
The reserved bits in VXLAN/NVGRE header can be used to carry the LAGID for each
Ethernet segment, and the new header with LAGID is called LAGID extended NVO3
header. Each BUM packet originating from a non-DF NVE is encapsulated with the
LAGID extended NVO3 header that identifies the Ethernet segment from which the
frame entered the NVO3 network. Egress DF NVE relies on the value of the LAGID to
determine whether or not a BUM frame is allowed to egress a specific Ethernet
segment. If the BUM frame is originated from the DF NVE operating in All-Active
multi-homing mode, then the DF NVE MAY use normal NVO3 encapsulation without the
LAGID.
In NVO3 network, ingress replication or point-to-multipoint tunnels can be used to
send BUM traffic destined to multiple NVEs on a per-VNI basis. LAGID extension
solution can be used for both.
For ingress replication, ingress NVE sends BUM packet to each destination NVE
through a unicast NVO3 tunnel, the LAGID in the extended NVO3 encapsulation is
assigned by egress NVE. While for point-to-multipoint, ingress NVE sends BUM
packet to all destination NVEs through a multicast NVO3 tunnel, the LAGID in the
encapsulation is assigned by ingress NVE. The LAGID and ingress NVE IP address
uniquely identifies the Ethernet segment sending the BUM frame in point-to-point
scenario.
Hao&Li Expires January 11, 2014 [Page 5]
Internet-Draft Active-active access in NVO3 network July 2013
The following sub-sections will illustrate in more details.
LAGID information can be distributed via "Ethernet A-D route per Ethernet Segment"
TLV.
As showing in figure1, TES1 is multi-homed to NVE1 and NVE2 on Ethernet
segment(ES)1 and operating in All-Active multi-homing mode. TES2 is single homed
to NVE2. Both TES1 and TES2 belong to VNI1. NVE1 is the non-DF for VNI1 and NVE2
is the DF for VNI1. Forwarding procedures for ingress replication and point-to-
multipoint is described in the following sub-sections respectively.
3.1. Ingress Replication
1. NVE1 receives a BUM packet from TES1 on VNI1 on ES1.
2. NVE1 sends the BUM packet to egress NVE2 using unicast tunnel with LAGID
extension. The LAGID is assigned by egress NVE2 in advance. The destination IP
address of the unicast tunnel is NVE2 IP address.
3. Egress NVE2 receives this packet from NVO3 network. As LAGID in unicast NVO3
encapsulation is equal to the local assigned LAGID for ES1, NVE2 does not
forward the packet to TES1. Because the link connects to TES2 doesn't belong to
ES1, so NVE2 forwards the packet to TES2.
3.2. Point-to-multipoint
1. NVE1 receives a BUM packet from TES1 on VNI1 on ES1.
2. NVE1 sends the BUM packet to egress NVE2 using multicast with LAGID extended
NVO3 encapsulation. The LAGID in the NVO3 encapsulation is assigned by ingress
NVE1. the destination IP address of the multicast tunnel is the multicast IP
address corresponding to VNI1.
3. Egress NVE2 receives this packet from NVO3 network. AS the source IP of the
multicast NVO3 encapsulation is NVE1 and the LAGID in the encapsulation is the
LAGID that announced by NVE1 for ES1, so NVE2 drops the packet to TES1. Because
the link connects to TES2 doesn't belong to ES1, so PE2 forwards the packet to
TES2.
4. VXLAN data plane extension
The VXLAN header can be extended to support the mechanism illustrated in this
document. ''L'' flag is introduced to indicate that the LAGID field is present in
the VXLAN header. ''LAGID'' is a 12 bit value to identify local Ethernet segment on
ingress or egress NVE. For unicast VXLAN tunnel, the LAGID is assigned by egress
NVE and is the identification of Ethernet segment on egress NVE. For multicast
VXLAN tunnel, the LAGID is assigned by ingress NVE and is the identification of
Hao&Li Expires January 11, 2014 [Page 6]
Internet-Draft Active-active access in NVO3 network July 2013
Ethernet segment on ingress NVE. Each BUM packet originating from a non-DF NVE to
VXLAN network must carry the LAGID.
Egress DF NVE relies on the value of the LAGID to determine a BUM frame should be
dropped or forwarded to a specific local Ethernet segment.
VXLAN header format is shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|L|R|R|R|I|R|R|R| LAGID(optional) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VXLAN Network Identifier (VNI) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: If the bit is set to 1, then it indicates that the LAGID field is present in
the VXLAN header. Otherwise, the LAGID field is not present in the VXLAN header.
LAGID: LAGID field is a 12 bit field and is used to identify an Ethernet segment
on an NVE operating in All-Active multi-homing mode. LAGID is significant only
when "L"bit is set to 1.
5. NVGRE data plane extension
Similar to VXLAN data plane extension, the NVGRE header can be extended to support
the mechanism illustrated in this document too. ''L'' flag is introduced to
indicate that the LAGID field is present in the GRE header. Each BUM packet
originating from a non-DF NVE to NVGRE network must carry the LAGID. Egress DF NVE
relies on the value of the LAGID to determine a BUM frame should be dropped or
forwarded to a specific local Ethernet segment.
NVGRE header format is shown below:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|C| |K|S|L| Reserved0 | Ver | Protocol Type 0x6558 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum (optional) | LAGID(optional) | Resv |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Virtual Subnet ID (VSID) | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L: If the bit is set to 1, then it indicates that the LAGID field is present in
the NVGRE header. Otherwise, the LAGID field is not present in the NVGRE header.
LAGID: The LAGID field is a 12 bit field and is inserted by ingress NVE when L Bit
is set.The LAGID is used to identify a ESI that is assigned on each NVE operating
in an All-Active multi-homing mode. For unicast NVGRE tunnel, the LAGID is
Hao&Li Expires January 11, 2014 [Page 7]
Internet-Draft Active-active access in NVO3 network July 2013
assigned by egress NVE. For multicast NVGRE tunnel, the LAGID is assigned by
ingress NVE.
6. Security Considerations
NA
7. IANA Considerations
NA
8. References
8.1. Normative References
8.2. Informative References
[1] [NV-EVPN] Sajassi, A., Drake J, D., Bitar, N., , " A Network Virtualization
Overlay Solution using E-VPN", draft-sd-l2vpn-evpn-overlay-01, February
2013.
[2] [RFC2890] G. Dommety, "Key and Sequence Number Extensions to GRE",RFC 2890,
September 2000
[3] [NVGRE] Sridhavan, M., et al., "NVGRE: Network Virtualization using Generic
Routing Encapsulation", draft-sridharan-virtualization-nvgre-01.txt, July 8,
2012.
[4] [VXLAN] Dutt, D., et al, "VXLAN: A Framework for Overlaying Virtualized
Layer 2 Networks over Layer 3 Networks", draftmahalingam- dutt-dcops-vxlan-
02.txt, August 22, 2012.
[5] [E-VPN] Sajassi et al., "BGP MPLS Based Ethernet VPN", draft-ietfl2vpn-
evpn-02.txt, work in progress, February, 2012..
9. Acknowledgments
The authors wish to acknowledge the important contributions of Junlin Zhang.
Hao&Li Expires January 11, 2014 [Page 8]
Internet-Draft Active-active access in NVO3 network July 2013
Authors' Addresses
Weiguo Hao
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56623144
Email: haoweiguo@huawei.com
Yizhou Li
Huawei Technologies
101 Software Avenue,
Nanjing 210012
China
Phone: +86-25-56625375
Email: liyizhou@huawei.com
Hao&Li Expires January 11, 2014 [Page 9]
