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 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]