[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

Network working group                                           L. Yong
Internet Draft                                                    X. Xu
Category: Standard Track                                         Huawei


Expires: November 2013                                     May 21, 2013


             NVGRE and VXLAN Encapsulation for L3VPN Extension
                  draft-yong-l3vpn-nvgre-vxlan-encap-01

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   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.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on November 21, 2013.

Copyright Notice

   Copyright (c) 2009 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.






Yong & Xu, et al.                                              [Page 1]


Internet-Draft          NVGRE/VXLAN for L3VPN Extension        May 2013

Abstract

   This document specifies NVGRE and VXLAN encapsulation for L3VPN
   Extension. Both NVGRE and VXLAN are originally designed for L2
   overlay. The draft proposes the enhancement on both to allow L3
   overlay completely decoupled from the L2 overlay in terms of
   encoding schema and data processing.

Conventions used in this document

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

Table of Contents


   1. Introduction...................................................3
   2. NVGRE and VXLAN Encapsulation for L3VPN Extension..............3
      2.1. NVGRE Enhancement for L3VPN Extension.....................3
      2.2. VXLAN Enhancement for L3VPN Extension.....................4
      2.3. BGP Tunnel Encapsulation Attribute Announcement...........5
      2.4. Benefits..................................................5
   3. Security Considerations........................................6
   4. IANA Considerations............................................6
   5. References.....................................................6
      5.1. Normative References......................................6
      5.2. Informative References....................................6






















Yong & Xu                                                      [Page 2]


Internet-Draft          NVGRE/VXLAN for L3VPN Extension        May 2013


1. Introduction

   DC Network Virtualization requires that a network virtual overlay
   may run at L2 or L3 [NVO3FRWK]. It is desirable to extend BGP/MPLS
   L3VPN [RFC4364] as one DC Network Virtualization solution. This
   implies that the PE component in the L3VPN architecture may be
   deployed in DC and reside on a same server. To complement current
   practical server implementations, the L3VPN extension [DRAO] [VAN]
   further proposes utilizing NVGRE [NVGRE] and/or VXLAN [VXLAN] data
   encapsulation formats for an L3VPN. This approach brings the
   advantage to use a unified solution for both L2 overlay [EVPN] and
   L3 overlay services. However, both NVGRE and VXLAN are originally
   designed as an L2 overlay data encapsulation in which the inner
   header MUST be an Ethernet header.

   This document proposes an enhancement to NVGRE and VXLAN
   encapsulation formats that allow the same data encapsulation
   semantics for both L2 overlay and L3 overlay services. The benefits
   of this usage include maintaining L3VPN natively and decoupling it
   from the L2 overlay completely.

2. NVGRE and VXLAN Encapsulation for L3VPN Extension

   A BGP/MPLS L3VPN [RFC4364] requires that the inner header is IP
   header, either IPv4 or IPv6. Both NVGRE [NVGRE] and VXLAN [VXLAN]
   encapsulation schema require that the inner header MUST be an
   Ethernet header. The solution of [DRAO] suggests several options to
   fill the MAC address fields when using NVGER and/or VXLAN in a BGP
   based L3VPN, although inner Ethernet address is not relevant to the
   L3VPN mechanism. These options make L3 overlay still coupled with L2
   overlay one way or another [DRAO].

  2.1. NVGRE Enhancement for L3VPN Extension

   NVGER [NVGRE] leverages the GRE protocol [RFC2890] and specifies
   that the protocol type field in the GRE header MUST be filled with
   the value of 0x6558, which means for Transparent Ethernet.

   This draft proposes to allow the protocol type field to be either
   the value of 0x6558 or 0x0800. The value 0x0800 means IP payload
   [RFC3232]. The value 0x6558 MUST be used if the inner header is
   Ethernet header. The value 0x0800 MUST be used if the inner header
   is IP header. Furthermore, the version field in IP header indicates
   if the IP header is IPv4 or IPv6. When L3VPN Extension uses NVGRE
   encapsulation, it MUST use the value of 0x0800 in the protocol type




Yong & Xu                                                      [Page 3]


Internet-Draft          NVGRE/VXLAN for L3VPN Extension        May 2013

   field and encode IP header as the inner header. Other fields in the
   outer header of the NVGRE remain the same.

  2.2. VXLAN Enhancement for L3VPN Extension

   This document proposes adding a protocol type field in the VXLAN
   header as indicated below. It takes 16 bits from the reserved 24
   bits as the protocol type field. For L2 overlay encapsulation, the
   protocol type field MUST be filled with the value of 0x6558. For L3
   overlay encapsulation, the protocol type field MUST be filled with
   the value of 0x0800, which means IP header [RFC3232]; inner header
   MUST be IP header as shown below. The remained 8 reserved bit MUST
   be filled with zero.

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     Outer Ethernet Header:
            As described in VXLAN [VXLAN]
     Outer IP Header:
            As described in VXLAN [VXLAN]
     Outer UDP Header:
            As described in VXLAN [VXLAN]
     VXLAN Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |R|R|R|R|I|R|R|R|    Reserved   | Protocol Type = 0x6558/0x0800 |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                VXLAN Network Identifier (VNI) |   Reserved    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Inner Header:
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Ethernet header or IP Header                    ~
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   When L3VPN Extension uses VXLAN encapsulation, it MUST use the value
   of 0x0800 in the protocol type field and encode IP header as the
   inner header. Other fields in the outer header and the VXLAN header
   remain the same.

   For an L2 overlay, the protocol type value MUST be 0x6558, and inner
   header MUST be Ethernet header and use the same format as in [VXLAN].
   For the backward compatibility, the value 0x0000 MUST be treated as
   Ethernet payload too.

   Other options to achieve this are either to specify another UDP port
   for L3 Overlay or to use one or more of reserved bits to indicate
   inner header type. For example, use the bit 6 in the VXLAN header.



Yong & Xu                                                      [Page 4]


Internet-Draft          NVGRE/VXLAN for L3VPN Extension        May 2013

   However, UDP based option makes the overlay tied into underlay, i.e.
   rely on the underlay header to carry the overlay header type, and
   the bit option has limited space for future expansion and makes
   NVGRE and VXLAN use of different semantics to indicate inner header.

   Memo: to be consistent with ETHER Type, the Protocol Type MAY use
   different codes for IPv4 (0x800) and IPv6 (0x86dd) payload
   respectively.

  2.3. BGP Tunnel Encapsulation Attribute Announcement

   RFC5512 [RFC5512] defines BGP tunnel encapsulation sub-TLVs and
   specifies a method for a BGP speaker to signal the tunnel
   encapsulation attributes to a peer. The BGP Remote-Next-Hop [VAN]
   uses the same sub-TLV to specify the remote next-hop tunnel
   encapsulation type. Both NVGRE and VXLAN are tunnel encapsulation
   options.

   This document suggests when specifying the tunnel encapsulation in
   the encapsulation sub-TLV, the egress router also specifies the
   proper protocol type in the protocol type sub-TLV [RFC5512]. The
   protocol type sub-TLV for IP or Ethernet overlay will be IPv4
   (protocol type = 0x0800), IPv6 (0x86dd), and Ethernet (0x6558),
   respectively. The ingress router MUST encapsulate the packets with
   the encapsulation type that egress BGP speaker signals.

  2.4. Benefits

   The enhancement on NVGRE and VXLAN encapsulation formats brings some
   beneficial for L3VPN Extension to use NVGRE and/or VXLAN as a data
   encapsulation format:

   o  Maintain L3VPN implementation natively and decouple it completely
      from L2 overlay implementation.

   o  Interwork with existing L3VPN customer

   o  Seamlessly support L2 and L3 overlay interworking [E-IP-VPN]

   o  BGP control plane works consistently with the data plane in term
      of multiple protocol support, i.e. the inner header on a data
      packet matches the address family being advertised by BGP route
      UPDATE message.

   o  Save 14 bytes in each packet in a native L3 overlay and lower the
      probability of the packet fragmentation, and eliminate the
      unnecessary packet process



Yong & Xu                                                      [Page 5]


Internet-Draft          NVGRE/VXLAN for L3VPN Extension        May 2013

   It is worth mention that the protocol extension in this document
   does not impact any mechanism that is specified in NVGRE [NVGRE] and
   VXLAN [VXLAN].

3. Security Considerations

   The mechanism proposed in this document does not add any additional
   security concern beside what has been described in the NVGRE [NVGRE]
   and VXLAN [VXLAN].

4. IANA Considerations

   The document does not require any IANA action.

5. References

  5.1. Normative References

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC2119, March 1997.

   [RFC2890] Dommety, G., "key and sequence Number Extentions to GRE",
             RFC2890, September 2000

   [RFC4364] Rosen, E and Y. Rekhter, "BGP/MPLS IP Virtual Private
             Networks (VPNs)", RFC4364, February 2006.

   [RFC5512] Mohapatra, P., Rosen, E., "BGP Encapsulation Subsequent
             Address Family Identifiers (SAFI) and the BGP Tunnel
             Encapsulation Attribute", RFC5512, April 2009

  5.2. Informative References

   [EVPN]   Sajassi, A., EVPN, J., etc, "A Network Virtualization
             Overlay Solution using E-VPN", draft-sd-l2vpn-evpn-
             overlay-01, work in progress

   [DRAO]    Rao, D., etc, "Layer-3 virtual network overlays based on
             BGP Layer-3 VPNs", draft-drao-bgp-l3vpn-virtual-network-
             overlays-01, work in progress

   [E-IP-VPN] Sajassi, A., etc, "E-VPN seamless Interoperability with
             Ip-VPN", draft-sajassi-l2vpn-evpn-ipvpn-interop-01, work
             in progress






Yong & Xu                                                      [Page 6]


Internet-Draft          NVGRE/VXLAN for L3VPN Extension        May 2013

   [NVO3FRWK] Lasserre, M., etc, "Framework for DC Network
             Virtualization", draft-ietf-nv03-framework-02.txt, work in
             progress.

   [NVGRE]  Sridharan, M., etc, "NVGRE: Network Virtualization using
             Generic Routing Encapsulation", draft-sridharan-
             virtualization-nvgre-02, work in progress

   [RFC3232] Raynolds, J., "ASSIGNED NUMBERS", RFC3232, January 2002

   [VAN]    VAN de Velde, G., etc, "BGP Remote-Next-Hop", draft-
             vandevelde-idr-remote-next-hop-03, work in progress.

   [VXLAN]  Mahalingam, M., Dutt, D., etc, "VXLAN: A Framework for
             Overlaying Virtualized Layer 2 Networks over Layer 3
             Networks", draft-mahalingam-dutt-dcops-vxlan-04.txt, work
             in progress



   Authors' Addresses

   Lucy Yong
   Huawei USA
   5340 Legacy Drive
   Plano, TX  75025
   U.S.A

   Phone:  469-277-5837
   Email: lucy.yong@huawei.com


   Xiaohu Xu
   Huawei Technologies,
   Beijing, China

   Phone: +86-10-60610041
   Email: xuxiaohu@huawei.com












Yong & Xu                                                      [Page 7]


Html markup produced by rfcmarkup 1.121, available from https://tools.ietf.org/tools/rfcmarkup/