Internet DRAFT - draft-drao-bgp-l3vpn-virtual-network-overlays
draft-drao-bgp-l3vpn-virtual-network-overlays
L3VPN D. Rao
Internet-Draft J. Mullooly
Intended status: Standards Track R. Fernando
Expires: January 5, 2015 Cisco
July 4, 2014
Layer-3 virtual network overlays based on BGP Layer-3 VPNs
draft-drao-bgp-l3vpn-virtual-network-overlays-03
Abstract
Virtual network overlays are being designed and deployed in various
types of networks, including data centers. These network overlays
address several requirements including flexible network
virtualization and multi-tenancy, increased scale, and support for
mobility of virtual machines. Such overlay networks can be used to
provide both Layer-2 and Layer-3 network services to hosts at the
network edge. New packet encapsulations are being defined and
standardized to support these virtual networks. These
encapsulations, such as VXLAN and NVGRE, are primarily based on IP
and are currently defined to support a Layer-2 forwarding service.
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. However, RFC 4364 procedures use MPLS labels to
provide the network virtualization capability in the data plane. With
the increasing support for IP overlay encapsulations in data center
devices, there is a strong preference to utilize this support to
deploy Layer-3 virtual networks using the familiarpolicy and
operational primitives of Layer-3 VPNs.
This document describes the use of BGP Layer-3 VPNs alongwith various
IP-based virtual network overlay encapsulations to provide a Layer-3
virtualization solution for all IP traffic, and specifies mechanisms
to use the new encapsulations while continuing to leverage existing
BGP Layer-3 VPN control plane techniques, extensions and
implementations. This mechanism provides an efficient incremental
solution to support forwarding for IP traffic, irrespective of
whether it is destined within or across an IP subnet boundary.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
Rao, et al. Expires January 5, 2015 [Page 1]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on January 5, 2015.
Copyright Notice
Copyright (c) 2014 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Control plane signaling requirements . . . . . . . . . . 4
1.4. Control plane model . . . . . . . . . . . . . . . . . . . 5
1.5. Overlay Encapsulations . . . . . . . . . . . . . . . . . 5
2. Virtual Network Identifier . . . . . . . . . . . . . . . . . 5
2.1. Virtual Network Identifier Scope . . . . . . . . . . . . 6
2.1.1. Domain-scoped provisioned virtual network identifiers 6
2.1.2. Per-device scoped allocated virtual network
identifiers . . . . . . . . . . . . . . . . . . . . . 6
2.1.3. Global unicast table . . . . . . . . . . . . . . . . 7
2.1.4. Virtual Network Identifier Specification . . . . . . 7
2.2. Signaling Virtual Network Identifiers . . . . . . . . . . 7
2.2.1. Signaling Requirements . . . . . . . . . . . . . . . 8
2.2.2. Signaling Specification . . . . . . . . . . . . . . . 9
3. Overlay Encapsulation specification . . . . . . . . . . . . . 9
3.1. Encapsulation for VXLAN and NVGRE . . . . . . . . . . . . 10
3.2. Encapsulation for MPLS-in-GRE . . . . . . . . . . . . . . 11
3.3. Multiple encapsulations . . . . . . . . . . . . . . . . . 11
3.4. Gateway device encapsulation handling . . . . . . . . . . 11
Rao, et al. Expires January 5, 2015 [Page 2]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
4. Forwarding behavior . . . . . . . . . . . . . . . . . . . . . 11
5. Overlay Interconnection and Interworking Scenarios . . . . . 12
5.1. End-to-end overlay . . . . . . . . . . . . . . . . . . . 12
5.2. Virtual-network overlay VPN interworking . . . . . . . . 12
5.2.1. Normalized interworking via VRF . . . . . . . . . . . 13
5.2.2. Seamless VPN interworking . . . . . . . . . . . . . . 13
6. Virtual-Network Overlay Encapsulation Capability . . . . . . 13
6.1. Need for Capability Negotiation . . . . . . . . . . . . . 13
6.2. Capability Specification . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction
Virtual network overlays are increasingly being designed and deployed
in various types of networks, including data center networks. These
virtual network overlays can 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
transport, such as VXLAN and NVGRE. A significant characteristic of
these encapsulations is the presence of an embedded virtual network
identifier field that is part of the encapsulation header. The use
of these encapsulations is defined in [VXLAN] and [NVGRE] and is
being currently worked on as part of the NVO3 architecture [NVO3].
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. The Layer-3 VPN BGP control plane is eminently
suitable to provide a Layer-3 network virtualization solution in the
data center.
However, RFC 4364 mechanisms use MPLS labels as the mechanism to
provide the network virtualization capability in the data plane. An
MPLS label is signaled by a device advertising a VPN-IP route. This
label can identify the virtual network when the device processes
packets received with that label. RFC 4364 does allow an MPLS label
to be carried in an IP tranport encapsulation such as MPLS-in-GRE.
This document specifies procedures to use the new IP-based virtual
network overlay encapsulations such as VXLAN and NVGRE, while
continuing to leverage the BGP based Layer-3 VPN control plane
techniques and extensions. It also describes how virtual network
Rao, et al. Expires January 5, 2015 [Page 3]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
overlays based on these encapsulations can efficiently interconnect
with one another and with existing MPLS based L3VPN networks.
This document describes the protocol extensions necessary to allow
advertising a VPN-IP NLRI with an attached VN-ID as well as an
encapsulation attribute indicating the type of enapsulation, for
example, VXLAN or NVGRE.
There are aspects of the signaling of encapsulation and VN-ID that
can be leveraged across different kinds of services. Hence, the
generic overlay encapsulation signaling extensions are defined in
[remote-next-hop]. The current document provides the necessary
context of how these extensions are used with the BGP IP-VPN NLRIs.
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].
1.2. Terminology
VM: Virtual Machine
Edge device: The edge device is where end-hosts (eg. application VMs)
attach to the overlay. This is where the tunnel encapsulation
starts. It's called NVE in the NVO3 terminology. The NVE is
equivalent to a VPN PE in the context of BGP L3VPNs.
1.3. Control plane signaling requirements
While considering the leverage of the BGP L3VPN control plane with
the IP overlay technologies, the following requirements should be
supported.
1. Signal VN-ID with VPN-IP routes, that can be used with IP based
overlay encapsulations.
2. Support signaling of multiple encapsulations per edge device.
3. Have flexibility to support single and per-encapsulation VN-ID
spaces if needed.
4. Support both device-local and domain-global VN-ID/label spaces.
5. Support per-prefix granularity for VN-ID/encapsulation.
6. Support interoperability with legacy IP-VPN PEs.
Rao, et al. Expires January 5, 2015 [Page 4]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
7. Be efficient in signaling to provide good scalability.
8. Minimize protocol and deployment overhead.
1.4. Control plane model
The virtual network overlay described in this document uses regular
BGP peering on the edge devices for policy constrained route
distribution. A typical deployment would use Route Reflectors.
It is also feasible for an alternative protocol or provisioning
framework to be used to control the forwarding plane population and
forwarding behavior on the edge devices, as described in [vpe-
framework].
The extensions specified here are compatible with both approaches.
1.5. Overlay Encapsulations
Different tunnel encapsulations may be used to realize an overlay
virtual network. Based on the encapsulation type being used, the
virtual network identifier is appropriately encoded in the
encapsulation header.
An overlay network may use the IP based VN-ID encapsulations such as
VXLAN and NVGRE. It may also use an MPLS based encapsulation such as
MPLS-in-GRE.
When VXLAN encapsulation is used, the virtual network identifier is
carried as the 24-bit VNI in the VXLAN header.
When NVGRE encapsulation is used, the virtual network identifier is
carried as the 24-bit VSID in the NVGRE header.
When MPLS-in-GRE is used, the regular MPLS VPN label serves as the
data plane identifier for the virtual network or a specific
destination.
A given overlay edge device may support a single encapsulation type
or it may support multiple encapsulation types. In the latter case,
it may signal the multiple encapsulations so that a receiving device
can potentially use the one most suitable to it. An edge device may
use the same encapsulation(s) for all routes or for a subset of
routes.
2. Virtual Network Identifier
Rao, et al. Expires January 5, 2015 [Page 5]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
In RFC 4364 based Layer-3 VPNs, a 20-bit MPLS label is assigned to an
VPN-IP route by the device that advertises the route, with itself as
the BGP next-hop. This label determines the forwarding behavior in
the data plane for traffic being switched as per that route. A
device receiving this route will encode this label in the packet
header when sending traffic to the advertiser. The advertiser will
take a unique forwarding action for traffic received with this label
when compared to traffic with other labels. The label may also be
used at the granularity of a VPN table and drive an IP lookup in that
table. This MPLS VPN label is independent of the transport
encapsulation that is used to carry this traffic to this PE from
other PEs across a core network. The transport encapsulation may be
native MPLS or be IP (eg, MPLS-in-GRE).
On the other hand, the various IP overlay encapsulations support a
virtual network identifier explicitly within their encapsulation
header. A virtual network identifier is a value that at a minimum
can identify a specific virtual network table in the forwarding
plane, and may be used to perform an IP address lookup. It may also
drive a specific forwarding action for packets destined to a
particular destination address or prefix.
It is typically a 24-bit value which can support upto 16 million
individual network segments or end-hosts. For instance, VXLAN
defines a 24-bit VNI while NVGRE uses a 24-bit VSID that is carried
in the GRE key field of the GRE header.
2.1. Virtual Network Identifier Scope
The scope of these virtual network identifiers fall into two broad
categories. 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.
2.1.1. Domain-scoped provisioned virtual network identifiers
Based on the provisioning mechanism used, a virtual network
identifier typically has a domain-wide scope within the network
domain, where a unique value is assigned to a given virtual network
or a given IP destination route at one or more edge devices.
This scope is useful in environments such as data centers where
virtual networks and VMs are automatically provisioned by central
orchestration systems. The system must support a very large number
of VN-IDs given the scope.
2.1.2. Per-device scoped allocated virtual network identifiers
Rao, et al. Expires January 5, 2015 [Page 6]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
There are scenarios where it is also necessary for an identifier to
have significance local to each network edge device that advertises
the route. In this case, the same value may be used by different
edge devices to represent different forwarding classes.
When it is locally scoped, the virtual network identifier may be
dynamically allocated by the advertising device. This allocation
follows the same semantics of an MPLS VPN label, and supports similar
forwarding behaviors as specified in RFC 4364. The device may, for
example, be a DC-WAN edge device that supports L3VPN Inter-AS Option
B and use this allocation for routes received from other ASBRs.
2.1.3. 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.4. Virtual Network Identifier Specification
The above requirements can be achieved in a simple manner by
splitting the virtual network ID number space to support both domain-
wide and device-local scopes.
o Values upto 1 million (or less than 20 bits) SHOULD be treated
with the same semantics as MPLS VPN labels and have significance
local to the advertiser.
For future expansion, this draft stipulates that the 16 numerical
values in the end of the VN-ID range be reserved for future use.
These special values could be used to indicate the presence of other
types of IP payloads.
o Values greater than 1 million (greater than 20 bits) SHOULD be
treated as per their original definition, ie domain-wide scoped
values.
These limits are not mandatory, but are recommended defaults. As
long as the provisioning system can ensure conflict-free operation,
the boundary between local and domain scoped ranges can be adjusted
higher or lower by configuration.
o A virtual network identifier value of zero SHOULD be used by
default to indicate the global or routing table.
2.2. Signaling Virtual Network Identifiers
Rao, et al. Expires January 5, 2015 [Page 7]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
2.2.1. Signaling Requirements
The Introduction section listed the desirable characteristics of
signaling of VN-IDs. This section elaborates on a couple of those
requirements.
o The device may support a single VN-ID space across all its
supported encapsulations.
This is expected to be common deployed scenario. A given edge device
will be provisioned by a single network orchestrator or controller.
The device may support multiple encapsulations in order to
interoperate with remote edge devices that support a different
encapsulation. However, the single network orchestrator will manage
the VN-ID space that will be common across multiple encapsulations on
this device.
o A device may support an independent VN-ID space per-supported
encapsulation.
This is expected to be applicable mostly at network gateway devices
that interconnect two different overlay domains and support the same
virtual network across these domains. These border devices are
likely to be managed by two different orchestrators, and hence need
to support different VN-ID spaces. In this case, they typically
advertise routes of one domain into another.
o An edge device may support an independent VN-ID space per-
supported encapsulation.
This is assumed to not be a commmon scenario, where an edge device
within the domain is being shared or managed by multiple
orchestration systems. However, in case this scenario must be
supported, the edge device must be able to support multiple distinct
VN-ID spaces. An alternative scheme would be to divide the VN-ID
range among the orchestration systems.
o It is required to support prefix-level VN-ID assignment.
Supporting prefix-level granularity is useful in various scenarios,
for example, at an interworking point between DC (VXLAN) and WAN
(MPLS).
Rao, et al. Expires January 5, 2015 [Page 8]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
2.2.2. Signaling Specification
This document specifies two options for signaling VN-IDs.
1. The VN-ID is encoded within an Virtual-Network Overlay
encapsulation attribute that also contains the encapsulation type and
associated parameters.
This enables the device to signal a VN-ID per encapsulation that it
may support. For example, the device may use VN-ID1 for VXLAN and
VN-ID2 for NVGRE. The VN-ID is encoded as a 24-bit value in each
encapsulation attribute.
When multiple VN-IDs need to be signaled, one per overlay
encapsulation type, then the VN-ID MUST be included in the overlay
encapsulation attribute as defined in [remote-next-hop].
When MPLS-in-GRE is one of the encapsulations, there is no change
from current behavior. The VPN label is encoded in the label field in
the IP-VPN NLRI.
2. The VN-ID is encoded in the label field in the IP-VPN NLRI.
This option is used when a device supports a single VN-ID space
across all encapsulations. The benefit of this encoding is it's
efficiency of packing, even when used for per-prefix VN-ID
assignment. With this option, the 24-bit VN-ID for VXLAN and NVGRE
is encoded as a 3-byte label field in the IP-VPN NLRI.
When a VN-ID or VPN label is to be signaled, the value MUST be
encoded in the 3-octet label field in the IP or IP-VPN NLRI.
This offers the most efficient packing of prefixes in BGP update
messages. The device may still advertise multiple encapsulation
types with this route, but they will all use the same VN-ID value.
An advertising device will select the suitable option as per the
requirements stated above, based on configuration.
3. Overlay Encapsulation specification
Signaling the VN-ID must be coupled with signaling the appropriate
overlay encapsulation type. An overlay encapsulation attribute MUST
be carried with each route.
Rao, et al. Expires January 5, 2015 [Page 9]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
The section above specified two options of signaling VN-ID. In both
options, the accompanying encapsulation attribute indicates that a
24-bit VN-ID is specified with the NLRI and must be encoded in the
signaled encapsulation header.
The encapsulation attribute also indicates the accompanying
parameters to be used in the packet header.
RFC 5512 defines a Tunnel Encapsulation Extended Community that can
be used to signal different tunnel types. It defines an Encapsulation
Sub-TLV that can be used to specify encapsulation parameters.
[remote-next-hop] specifies a Remote-Next-Hop attribute which reuses
the Encapsulation Sub-TLV from RFC 5512, but adds the flexibility to
signal the encapsulation attribute and parameters along with each
individual route. The address specified as the remote next-hop
identifies the end-point or destination of the encapsulated packets
that use the dependent routes as well as the tunnel encapsulation
parameters.
Hence, the Remote-Next-Hop attribute is used to signal VN-ID
encapsulations. New tunnel types are defined for VXLAN, NVGRE and
MPLS-in-GRE. The format for the tunnel parameters are specified in
[remote-next-hop].
3.1. Encapsulation for VXLAN and NVGRE
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.
Alternatively, 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.
Rao, et al. Expires January 5, 2015 [Page 10]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
3.2. Encapsulation for MPLS-in-GRE
When MPLS-in-GRE is one of the encapsulations, there is no change
from current behavior. A tunnel type of [MPLS-in-GRE] as defined in
RFC 5512 is used in the Remote-Next-Hop attribute.
3.3. Multiple encapsulations
A given overlay edge device MAY advertise multiple Encapsulation Sub-
TLVs, in order to signal multiple encapsulations. It MAY encode a
different VN-ID in each Sub-TLV as per rules specified earlier.
A receiving edge device may support one or more encapsulations that
are signaled by the advertising edge device. In that case, the
receiving device can select any of these encapsulations for sending
traffic to the advertiser. If a receiving device supports no
encapsulations that were signaled by the advertiser, then it will not
send any traffic for these routes to the advertiser.
3.4. Gateway device encapsulation handling
When an intermediate gateway device changes the BGP next-hop to self
before propagating a received route, it may need to advertise a new
overlay encapsulation attribute with the local address as the
endpoint. While doing so, it MAY use an overlay encapsulation type
that is different from the received route. It MAY also signal a
different VN-ID or VPN label than what it received, as described in
the various VN-ID requirements and rules earlier.
4. Forwarding behavior
o Locally assigned virtual network identifiers
When the virtual network identifier is locally assigned, forwarding
based on the identifier at the advertising device follows the
semantics of an MPLS VPN label. The VN-ID may either drive an IP
table lookup or provide a seamless binding to an output VN-ID or
label.
o Domain-scoped provisioned virtual network identifiers
With a provisioned VN-ID, forwarding behavior at a device which is
provisioned with this value is governed by the forwarding action that
has been provisioned. As one example, the VN-ID may be set up to
represent a specific IP VRF table on all relevant edge devices,
causing incoming packets with this VN-ID to undergo an IP lookup.
Alternatively, the VN-ID may be configured on only one or two edge or
border devices to directly forward incoming packets to an attached
Rao, et al. Expires January 5, 2015 [Page 11]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
end-host, without undergoing an IP lookup.
In either case, the forwarding behavior at any ingress edge device
(physical or virtual) remains the same. The ingress edge device adds
an encapsulation as signaled by the advertising device, and includes
the VN-ID in that encapsulation header.
5. Overlay Interconnection and Interworking Scenarios
Multiple virtual network overlay domains may be inter-connected using
a couple of approaches. Both these approaches may co-exist in the
same data center, and be used for connectivity to different kinds of
external networks.
5.1. End-to-end overlay
The IP overlay encapsulation or tunnel extends end-to-end between
edge devices in different data centers.
IP routes for hosts attached to each edge device are exchanged
between the overlay domains either via route exchange between BGP
speakers in each overlay domain, or via an orchestration/controller
framework that manages the domains. The two networks may be located
within the same ASN or may extend across ASes.
The routes are propogated to various edge device via the control
plane mechanism used in the DC, along with the encapsulation and VN-
ID or label to be used for sending traffic to a given destination
edge device. All intermediate devices in the forwarding path between
the two edge devices simply transport the IP encapsulated overlay
traffic.
The tunnel endpoints, ie the edge devices need to be reachable across
the ASes. This reachability may be provided by BGP peering across
ASes.
5.2. Virtual-network overlay VPN interworking
The overlay encapsulation terminates at a border router such as the
DC-WAN gateway device. The gateway device may re-encapsulate packets
in another header when sending it onwards. This requires an
interworking function which can be of multiple types.
5.2.1. Normalized interworking via VRF
The overlay based virtual network terminates into an L3VPN VRF at the
DC-WAN gateway device. Internal routes of the DC as well as the
external routes received from the WAN router are installed in the VRF
Rao, et al. Expires January 5, 2015 [Page 12]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
forwarding table at the DC gateway router. The DC gateway will
perform an IP lookup and forward traffic after doing the appropriate
output MPLS or IP overlay/VPN encapsulation.
5.2.2. Seamless VPN interworking
In this case, the DC Gateway router performs a direct translation of
VN-IDs/labels while switching packets between the DC and WAN
interfaces without doing an IP lookup. The forwarding table at the
DC Gateway router is set up to do a VN-ID or VPN label lookup and
derive the output VN-ID or VPN label. The DC Gateway Router can act
as an Inter-AS Option-B ASBR/ABR peering with other ASBRs/ABRs.
6. Virtual-Network Overlay Encapsulation Capability
6.1. Need for Capability Negotiation
When the MP-BGP NLRIs are used along with a VN-ID based
encapsulation, the MPLS label field in the NLRI is either not used or
is used to indicate the presence of a VN-ID that must be included in
the corresponding overlay encapsulation packet header while sending
data. A device that supports vanilla RFC 4364 based IP-VPNs but does
not understand the extensions specified in this document may not
interpret the received MP-BGP NLRI as intended, potentially causing
inconsistent forwarding plane behavior. In order to avoid this
situation, such devices must not receive the modified NLRIs. The
presence of a capability protect against this issue and ensures
interoperability with vanilla IP-VPN peers.
[RFC5492] defines a mechanism to allow two peering BGP speakers to
discover if a particular capability is supported by each other and
thus whether it can be used between them. This document defines a
new BGP capability that can be advertised using [RFC5492] and is
referred to as the Virtual-Network Overlay Encapsulation capability.
A BGP speaker MUST only advertise to a BGP peer the corresponding MP-
BGP NLRIs alongwith a VN-ID if the BGP speaker has first ascertained
via BGP Capability Advertisement that the BGP peer supports the
Virtual-Network Overlay Encapsulation capability.
With the Virtual-Network Overlay Encapsulation Capability, a VN-
capable BGP speaker will detect peers that are not capable of
processing VN-ID encapsulation information received in BGP updates.
The speaker MUST not send any VPN-IP routes that contain only a VN-ID
based encapsulation to such peers. If the route contains both a VN-
ID encapsulation and an MPLS-in-GRE encapsulation, the speaker MAY
send the route to the legacy peer with only the MPLS encapsulation
information, and with the VN-ID encapsulation information removed.
Rao, et al. Expires January 5, 2015 [Page 13]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
If routes are advertised by a speaker via a Route Reflector (RR),
then the RR MUST advertise the BGP capability for it to receive
routes with VN-ID information from the speaker.
When a next-hop address needs to be passed along unchanged (e.g., by
an RR), its encoding MUST NOT be changed. If a particular RR client
cannot handle that encoding (as determined by the BGP Capability
Advertisement), then the NLRI in question cannot be distributed to
that client. The RR may, as above, send the route with only the
MPLS-in-GRE encapsulation information to such legacy peers.
6.2. Capability Specification
A BGP speaker that is capable of processing VN-ID based encapsulation
information in BGP updates as per this specification MUST use the
Capability Advertisement procedures defined in [RFC5492] with the
Virtual-Network Overlay Encapsulation Capability. The fields in the
Capabilities Optional Parameter MUST be set as follows:
o The Capability Code field MUST be set to 71, indicating the
capability.
o The Capability Length field is set to a variable value that is the
length of the Capability Value field (which follows).
o The Capability value field has the following format:
+-----------------------------------------------------+
| NLRI AFI - 1 (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - 1 (2 octets) |
+-----------------------------------------------------+
| ..... |
+-----------------------------------------------------+
| NLRI AFI - N (2 octets) |
+-----------------------------------------------------+
| NLRI SAFI - N (2 octets) |
+-----------------------------------------------------+
where:
* each NLRI AFI, NLRI SAFI pair indicates the BGP NLRI address
family for which the speaker can process the VN-ID information.
* the AFI and SAFI values are defined in the Address Family
Identifier and Subsequent Address Family Identifier
registries maintained by IANA.
Rao, et al. Expires January 5, 2015 [Page 14]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
Since this document only concerns itself with the advertisement of
IP NLRI and VPN-IP NLRIs, this specification specifies the
following values in the Capability Value field of the above
capability:
o NLRI AFI = 1 (IPv4), 2 (IPv6)
o NLRI SAFI = 1, 2, 4, or 128
It is expected that if new AFI/SAFIs can use this in the future,
then these AFI/SAFIs can be included in the Capability values.
7. Acknowledgements
The authors would like to acknowledge and thank Nabil Bitar, Dave
Smith, Maria Napierala, Robert Raszuk, Eric Rosen, Ashok Ganesan and
Luyuan Fang for their input and feedback.
8. IANA Considerations
This document defines, in Section N, a new Capability Code to
indicate the Virtual-Network Overlay Encapsulation Capability in the
[RFC5492] Capabilities Optional Parameter. The value for this new
Capability Code is 71, which is in the range set aside for allocation
using the "FCFS" policy defined in [RFC5226]. There are no
additional requirements to IANA at this time. A specific VN-ID range
may be reserved for future use as applications for carrying payloads
different than regular IP/VPN packets emerge in future.
9. 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.
There are security considerations pertaining to IP based overlay or
tunnel encapsulations which are described in the respective overlay
encapsulation specifications as well as in RFC 5512.
There are certain measures that may be taken by default to increase
the level of security provided at the overlay edge devices.
Rao, et al. Expires January 5, 2015 [Page 15]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
When an IP-based overlay encapsulation is used within a domain such
as a data center, the network edge devices can enforce a default
forwarding access rule to restrict the acceptance of such overlay
encapsulated packets on their access interfaces attached to servers
or VMs.
For example, when VXLAN is being used, an edge device may be directed
to filter any VXLAN encapsulated packets (identified by the UDP port
number) on their access interfaces. This rule can be further
augmented by checking that the destination IP address of such VXLAN
packets does not fall in the prefix range allocated to edge device
addresses. Similarly, a DC edge device may be directed to not accept
any VXLAN encapsulated packets on its interfaces connected to
external routers, depending on the interconnectivity option being
used.
10. References
10.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-09
(work in progress), April 2014.
[I-D.sridharan-virtualization-nvgre]
Sridharan, M., Greenberg, A., Venkataramaiah, N., Wang,
Y., Duda, K., Ganga, I., Lin, G., Pearson, M., Thaler, P.,
and C. Tumuluri, "NVGRE: Network Virtualization using
Generic Routing Encapsulation", draft-sridharan-
virtualization-nvgre-04 (work in progress), February
2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[min_ref] authSurName, authInitials., "Minimal Reference", 2006.
10.2. Informative References
[I-D.fang-l3vpn-virtual-pe]
Fang, L., Ward, D., Fernando, R., Napierala, M., Bitar,
N., Rao, D., Rijsman, B., and S. Ning, "BGP IP VPN Virtual
PE", draft-fang-l3vpn-virtual-pe-05 (work in progress),
July 2014.
Rao, et al. Expires January 5, 2015 [Page 16]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
[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., Rao, D., Raszuk, R., and R. Bush,
"BGP Remote-Next-Hop", draft-vandevelde-idr-remote-next-
hop-07 (work in progress), June 2014.
[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
John Mullooly
Cisco
New Jersey
USA
Email: jmullool@cisco.com
Rao, et al. Expires January 5, 2015 [Page 17]
Internet-Draft BGP Layer-3 virtual network overlay July 4, 2014
Rex Fernando
Cisco
San Jose
USA
Email: rex@cisco.com
Rao, et al. Expires January 5, 2015 [Page 18]
