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]