Internet Engineering Task Force                                   D. Rao
Internet-Draft                                               J. Mullooly
Intended status: Standards Track                             R. Fernando
Expires: April 19, 2013                                            Cisco
                                                        October 16, 2012


       Layer-3 virtual network overlays based on BGP Layer-3 VPNs
             draft-drao-bgp-l3vpn-virtual-network-overlays-00

Abstract

   Virtual network overlays are being designed and deployed in various
   types of networks, including data center networks.  These network
   overlays serve several purposes including flexible network
   virtualization, increased scale, multi-tenancy, and mobility.  Such
   overlay networks may be used to provide both Layer-2 and Layer-3
   network services to hosts at the network edge.  New encapsulations
   are being defined and standardized to support these virtual networks.
   These encapsulations are primarily based on IP, such as VxLAN and
   NvGRE.

   BGP based Layer-3 VPNs, as specified in RFC 4364, provide an industry
   proven and well-defined solution for supporting Layer-3 virtual
   network services.  RFC 4364 mechanisms use MPLS labels to provide the
   network virtualization capability in the data plane.  This document
   specifies a simple mechanism to use the new IP-based virtual network
   overlay encapsulations, while continuing to leverage the BGP based
   Layer-3 VPN control plane techniques and extensions.

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/1id-abstracts.html

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


Copyright and License Notice

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


Rao, et al.              Expires April 19, 2013                 [Page 1]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Virtual Network Identifier . . . . . . . . . . . . . . . . . .  3
     2.1.  Virtual Network Identifier Specification . . . . . . . . .  4
     2.2.  Identifier Scope and propagation . . . . . . . . . . . . .  5
     2.3.  Forwarding behavior  . . . . . . . . . . . . . . . . . . .  6
   3.  Overlay Encapsulation  . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Encapsulation specification  . . . . . . . . . . . . . . .  7
   4.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  8
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  8
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  8
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .  9
   Intellectual Property and Copyright Statements . . . . . . . . . . 11

































Rao, et al.              Expires April 19, 2013                 [Page 2]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


1.  Introduction

   Virtual network overlays are being designed and deployed in various
   types of networks, including data center networks.  These network
   overlays serve several purposes including flexible network
   virtualization, increased scale, multi-tenancy, and mobility.  Such
   overlay networks may be used to provide both Layer-2 and Layer-3
   network services to hosts at the network edge.  New encapsulations
   are being defined and standardized to support these virtual networks.
   These encapsulations are primarily based on IP, such as VxLAN and
   NvGRE.

   BGP based Layer-3 VPNs, as specified in RFC 4364, provide an industry
   proven and well-defined solution for supporting Layer-3 virtual
   network services.  RFC 4364 mechanisms use MPLS labels to provide the
   network virtualization capability in the data plane.  This document
   specifies a simple mechanism to use the new IP-based virtual network
   overlay encapsulations, while continuing to leverage the BGP based
   Layer-3 VPN control plane techniques and extensions.

1.1.  Requirements Language

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


2.  Virtual Network Identifier

   In RFC 4364 L3VPNs, a 20-bit MPLS label that is assigned to a VPN
   route determines the forwarding behavior in the data plane for
   traffic following that route.  These labels also serve to distinguish
   the packets of one VPN from another.

   On the other hand, the various IP overlay encapsulations support a
   virtual network identifier as part of their encapsulation format.  A
   virtual network identifier is a value that at a minimum can identify
   a specific virtual network in the data plane.  It is typically a 24-
   bit value which can support upto 16 million individual network
   segments.

   There are two useful requirements regarding the scope of these
   virtual network identifiers.

   o  Network-wide scoped virtual network identifiers

   Depending on the provisioning mechanism used within a network domain
   such as a data center, the virtual network identifier may have a



Rao, et al.              Expires April 19, 2013                 [Page 3]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


   network scope, where the same value is used to identify the specific
   Layer-3 virtual network across all network edge devices where this
   virtual network is instantiated.  This network scope is useful in
   environments such as within the data center where networks can be
   automatically provisioned by central orchestration systems.  Having a
   uniform virtual network identifier per VPN is a simple approach,
   while also easing network operations (i.e. troubleshooting).  It also
   means simplifies requirements on network edge devices, both physical
   and virtual devices.  A critical requirement for this type of
   approach is to have a very large amount of network identifier values
   given the network-wide scope.

   o  Locally assigned virtual network identifiers

   In an alternative approach supported as per RFC 4364, the identifier
   has local significance to the network edge device that advertises the
   route.  In this case, the virtual network scale impact is determined
   on a per node basis, versus a network basis.

   When it is locally scoped, and uses the same existing semantics of a
   MPLS VPN label, the same forwarding behaviors as specified in RFC
   4364 can be employed.  It thus allows a seamless stitching together
   of a VPN that spans both an IP based network overlay and a MPLS VPN.
   This situation can occur for instance at the data center edge where
   the overlay network feeds into an MPLS VPN.  In this case, the
   identifier may be dynamically allocated by the advertising device.

   It is important to support both cases, and in doing so, ensure that
   the scope of the identifier be clear and the values not conflict with
   each other.

   It should be noted that deployment scenarios for these virtual
   network overlays are not constrained to the examples used above to
   categorize the options.  For example, a virtual network overlay may
   extend across multiple data centers.

   o  Global unicast table

   The overlay encapsulation can also be used to support forwarding for
   routes in the global or default routing table.  A virtual network
   identifier value can be allocated for the purpose as per the above
   options.

2.1.  Virtual Network Identifier Specification

   The above requirements can be achieved in a simple manner by
   splitting the virtual network ID number space.




Rao, et al.              Expires April 19, 2013                 [Page 4]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


   o  Values upto 1 million (or less than 20 bits) are treated exactly
      as MPLS labels and have significance local to the advertiser.

   For future expansion, this draft stipulates that the 16 numerical
   values in the end of the label range, i.e. values 0xffff0 to 0xfffff,
   be reserved for future use.  These special labels could be used to
   indicate the presence of other types of IP payloads.

   o  Values greater than 1 million (greater than 20 bits) are treated
      as per their original definition.

   o  A virtual network identifier value of zero is used by default to
      indicate the global or routing table.

   It should be noted that within an administrative domain, the entire
   range can be used such that the values have network-wide
   significance.  This is inline with the use of statically assigned
   labels today.

2.2.  Identifier Scope and propagation

   The virtual network identifier may be indicated by attaching to the
   route a new attribute.  However, it is also possible to use the MPLS
   label field in the BGP VPN NLRIs to specify this value.  The benefit
   of doing the latter is the reuse of existing NLRIs and label
   processing as is, especially keeping in mind the semantics to be
   supported.  The specification of the identifier value in the label
   field is described further below.

   The use of the virtual network identifier is coupled with the
   encapsulation used for sending traffic.

   The encapsulation used may be MPLS.  In this case, the identifier
   value should be less than 0xffff0, and will be set in the MPLS label
   field exactly as defined in RFC 3107.  There is no change to current
   RFC 4364 behavior in this case.

   When the encapsulation is one of the overlay encapsulation types as
   listed below, the virtual network identifier will be set in the
   3-byte label field described in RFC 3107 as a 24-bit value,
   irrespective of the actual value being specified.

   The value itself may fall into two ranges.

   1.  Less than 0xffff0 - In this case, the identifier has local
   significance to the network device that advertised the route.

   2.  Greater than 0xfffff - In this case, the identifier will have a



Rao, et al.              Expires April 19, 2013                 [Page 5]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


   significance as per the original definitions, typically within a
   network domain that is under a common provisioning system.

   From a routing perspective, if an intermediate network device changes
   the BGP next-hop to self before propagating the route, it will assign
   a new virtual network identifier and advertise it.  If not, the
   virtual network identifier attached by the originator of the route
   will be carried as is.

   When an intermediate network device assigns a virtual network
   identifier, the assigned value may be a new locally assigned value or
   it could still be the same network scoped value, if the route is
   being propagated within the domain.

2.3.  Forwarding behavior

   o  Locally assigned virtual network identifiers

   When the virtual network identifier is locally assigned, forwarding
   based on the identifier follows the semantics of an MPLS label.  This
   label can serve as either an aggregate label or a per-prefix label.
   This allows a seamless transition out of the overlay network at an
   MPLS VPN edge, for example, via support of Inter-AS option B.

   o  Network-scoped virtual network identifiers

   With the network-scoped virtual network identifier, any egress device
   treats the identifier as an aggregate label to lookup the appropriate
   forwarding table.

   In both cases, the forwarding behavior at an ingress edge device,
   physical or virtual, does not change.


3.  Overlay Encapsulation

   As mentioned above, different overlay encapsulations may be used to
   provide an overlay virtual network.

   The overlay may use proposed encapsulations such as:

   1.  VxLAN

   2.  NvGRE

   Based on the encapsulation type being used, the virtual network
   identifier is appropriately encoded.




Rao, et al.              Expires April 19, 2013                 [Page 6]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


   When VxLAN encapsulation is used, the virtual network identifier is
   carried as the 24-bit segment-ID in the VxLAN header.

   When NvGRE encapsulation is used, the virtual network identifier is
   carried as the 24-bit tenant network ID in the NvGRE header.

   The fact that a virtual network identifier is carried in the label
   field in the BGP NLRI is determined by virtue of the accompanying
   encapsulation attribute, that indicates an overlay encapsulation
   should be used.

   For a given overlay edge device, the same encapsulation may be used
   for all routes or for selected routes.

3.1.  Encapsulation specification

   The overlay encapsulation attribute may be carried with each route,
   or it may be indirectly inferred from the route to the BGP next-hop.

   The Tunnel Encapsulation Extended community defined in RFC 5512 can
   be used to convey this information. [remote-next-hop] specifies an
   alternative mechanism to carry this information along with each
   route.  The address specified as the remote next-hop identifies the
   end-point or destination of the encapsulated packets that use the
   dependent routes.

   A single encapsulation may be used on a given device.  In this case,
   the encapsulation may be specified for a given next-hop and inherited
   by all routes sent with that next-hop (RFC 5512).

   When VxLAN and NvGRE encapsulations are used, the header by
   definition contains an Ethernet MAC address within the overlay
   header.  When these encapsulations are used for Layer-3 as specified
   in this document, the MAC addresses are not relevant.  A single well-
   known MAC address may be specified for the purpose of
   deterministically driving a Layer-3 lookup based on the inner IP or
   IPv6 address.

   However, an overlay egress edge device device may choose to specify a
   MAC address as part of the encapsulation header in its route
   advertisement.  In this case, any ingress edge device sending traffic
   as per this route must use the above specified MAC address as the
   destination MAC address in the header.  The egress device may use
   this address to drive the Layer-3 table lookup or for other purposes.

   When an intermediate device changes the BGP next-hop to self before
   propagating a received route, it will also need to advertise a new
   overlay encapsulation attribute with the local address as the



Rao, et al.              Expires April 19, 2013                 [Page 7]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


   endpoint.  While doing so, it may use an overlay encapsulation type
   that is different from the received route.


4.  Acknowledgements

   The authors would like to acknowledge and thank Dave Smith, Maria
   Napierala, Ashok Ganesan and Luyuan Fang for their input and
   feedback.


5.  IANA Considerations

   The virtual network identifier values 0xffff0 to 0xfffff should be
   allocated by IANA as applications for carrying payloads different
   than regular IP/VPN packets emerge in future.


6.  Security Considerations

   This draft does not add any additional security implications to the
   BGP/L3VPN control plane.  All existing authentication and security
   mechanisms for BGP apply here.

   The security considerations pertaining to the various IP overlay
   encapsulations referenced here are described in the respective
   overlay encapsulation specifications.


7.  References

7.1.  Normative References

   [I-D.mahalingam-dutt-dcops-vxlan]
              Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger,
              L., Sridhar, T., Bursell, M., and C. Wright, "VXLAN: A
              Framework for Overlaying Virtualized Layer 2 Networks over
              Layer 3 Networks", draft-mahalingam-dutt-dcops-vxlan-00
              (work in progress), August 2011.

   [I-D.sridharan-virtualization-nvgre]
              Sridhavan, M., Duda, K., Ganga, I., Greenberg, A., Lin,
              G., Pearson, M., Thaler, P., Tumuluri, C., and Y. Wang,
              "NVGRE: Network Virtualization using Generic Routing
              Encapsulation", draft-sridharan-virtualization-nvgre-00
              (work in progress), September 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate



Rao, et al.              Expires April 19, 2013                 [Page 8]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [min_ref]  authSurName, authInitials., "Minimal Reference", 2006.

7.2.  Informative References

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.

   [I-D.vandevelde-idr-remote-next-hop]
              Velde, G., Patel, K., Raszuk, R., and R. Bush, "BGP
              Remote-Next-Hop", draft-vandevelde-idr-remote-next-hop-01
              (work in progress), July 2012.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3107]  Rekhter, Y. and E. Rosen, "Carrying Label Information in
              BGP-4", RFC 3107, May 2001.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.

   [RFC4271]  Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
              Protocol 4 (BGP-4)", RFC 4271, January 2006.

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

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


Authors' Addresses

   Dhananjaya Rao
   Cisco
   San Jose,
   USA

   Email: dhrao@cisco.com





Rao, et al.              Expires April 19, 2013                 [Page 9]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012


   John Mullooly
   Cisco
   New Jersey,
   USA

   Email: jmullool@cisco.com


   Rex Fernando
   Cisco
   San Jose,
   USA

   Email: rex@cisco.com





































Rao, et al.              Expires April 19, 2013                [Page 10]


Internet-Draft     BGP Layer-3 virtual network overlay      October 2012













Rao, et al.              Expires April 19, 2013                [Page 11]