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]