INTERNET-DRAFT Maria Napierala
Intended Status: Informational AT&T
Expires: April 18, 2014 Luyuan Fang
Cisco
October 18, 2013
Requirements for Extending BGP/MPLS VPNs to End-Systems
draft-fang-l3vpn-end-system-requirements-02.txt
Abstract
The proven scalability and extensibility beyond the original design
purposes of the BGP/MPLS IP VPNs (IP VPN) technology [RFC4364] has
made it an attractive candidate for Data Center (DC)/Cloud
virtualization. This document provides the requirements for extending
IP VPN (in original or modified versions) into the end-systems/end-
devices, such as a server in a DCs/Cloud. Physical separation of the
control and the forwarding planes; virtualizing the network functions
of the IP VPN network elements, such as a PE, are the key differences
compared with the classic IP VPN solutions.
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) 2013 IETF Trust and the persons identified as the
Napierala and Fang Expires <April 18, 2014> [Page 1]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
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 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Application of MPLS/BGP VPNs to End-Systems . . . . . . . . . . 4
2.1. End-System CE and PE Functions . . . . . . . . . . . . . . 4
2.2. PE Control Plane Function . . . . . . . . . . . . . . . . . 5
3. VPN Communication Requirements . . . . . . . . . . . . . . . . 5
3.1. Unicast IPv4 and IPv6 . . . . . . . . . . . . . . . . . . . 5
3.2. Multicast/VPN Broadcast IPv4 and IPv6 . . . . . . . . . . . 5
3.3. IP Subnet Support . . . . . . . . . . . . . . . . . . . . . 5
4. Multi-Tenancy Requirements . . . . . . . . . . . . . . . . . . 6
5. Decoupling of Virtualized Networking from Physical . . . . . . 7
6. Decoupling of Layer 3 Virtualization from Layer 2 Topology . . 7
7. Requirements for Encapsulation of Virtual Payloads . . . . . . 8
7.1. Encapsulation Methods . . . . . . . . . . . . . . . . . . . 9
7.2. Routing of Virtual Payloads . . . . . . . . . . . . . . . . 9
8. Optimal Forwarding of Traffic . . . . . . . . . . . . . . . . . 9
9. IP Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. IP Addressing of Virtual Hosts . . . . . . . . . . . . . . 10
9.2. Network Layer-Based Mobility . . . . . . . . . . . . . . . 10
9.3. Routing Convergence Requirements . . . . . . . . . . . . . 10
10. Inter-operability with Existing MPLS/BGP VPNs . . . . . . . . 11
11. BGP Requirements in a Virtualized Environment . . . . . . . . 12
11.1. BGP Convergence and Routing Consistency . . . . . . . . . 12
11.1.1. BGP IP Mobility Requirements . . . . . . . . . . . . . 12
11.2. Optimization of Route Distribution . . . . . . . . . . . . 12
11.3. Service chaining . . . . . . . . . . . . . . . . . . . . . 13
12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
14.1. Normative References . . . . . . . . . . . . . . . . . . 13
14.2. Informative References . . . . . . . . . . . . . . . . . 14
15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Napierala and Fang Expires <April 18, 2014> [Page 2]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
1 Introduction
Enterprise networks are increasingly being consolidated and
outsourced in an effort to improve the deployment time of services as
well as reduce operational costs. This coincides with an increasing
demand for compute, storage, and network resources from applications.
Logical abstraction of these resources is needed to for improved
scalability and cost efficiency. This is referred as server, storage,
and network virtualization. It can be implemented in all layers of
the computer systems or networks. The virtualized loads are executed
or transferred over a common physical infrastructure. Compute nodes
running guest operating systems are often executed as Virtual
Machines (or VMs). Network virtualization is the next step after
compute virtualization.
This document defines requirements for a network virtualization
solution that provides BGP/MPLS IP VPN style connectivity to virtual
resources on end-systems/end-device, such as a server, operating in a
multi-tenant shared physical infrastructure. The requirements
addresses the needs of virtual resources, applications reside on VMs,
and focus on the appliances that require only IP connectivity. Non-IP
communication is addressed by other documents and is not in scope of
this document.
The technical solutions to support these requirements are work in
progress in IETF. [I-D.ietf-l3vpn-end-system],
[I-D.fang-l3vpn-virtual-pe]. The solutions may referred as End-System
solutions or virtual PE (vPE) solutions in different documents.
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].
Term Definition
----------- --------------------------------------------------
AS Autonomous System
CE Customer Edge router
End-System A device where Guest OS, Host OS/Hypervisor reside
GRE Generic Routing Encapsulation
Hypervisor Virtual Machine Manager
PE Provider Edge router
RT Route Target
RTC RT Constraint
SDN Software Defined Network
ToR Top-of-Rack switch
Napierala and Fang Expires <April 18, 2014> [Page 3]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
VM Virtual Machine
vPE virtual Provider Edge Router
VPN Virtual Private Network
2. Application of MPLS/BGP VPNs to End-Systems
MPLS/BGP VPN technology [RFC4364] have proven to be able to very
scale to a large number of VPNs (tens of thousands) and customer
routes (millions) while providing for aggregated management
capability. In traditional WAN deployments of BGP IP VPNs a Customer
Edge (CE) is a physical device, residing a customer's location,
connected to a Provider Edge (PE), residing in a Service Provider's
location. CE devices are logically part of a customer's VPN while PE
routers are logically part of the SP's network. In a traditional
MPLS/BGP VPN deployment, a CE device is a router and it is a routing
peer of a PE to which it is attached via an attachment circuit.
In addition, the forwarding function and control function of a
Provider Edge (PE) device co-exist within a single physical router.
MPLS/BGP VPN technology can be evolved and adapted to new virtualized
environments by implementing the VPN edge functionality of the PE
line-cards on the end-system hosts and thereby extending VPN service
directly to end-systems.
2.1. End-System CE and PE Functions
When end-system/end-device attaches to MPLS/BGP VPN, CE corresponds
to a non-routing host that can reside in a VM or be an application
residing on the end-system itself.
As in traditional MPLS/BGP VPN deployments, it is undesirable for the
end-system VPN forwarding knowledge to extend to the core transport
network infrastructure. Hence, optimally, with regard to forwarding,
the end-system should become both the CE and the PE simultaneously.
The network virtualization solution should also support deployments
where it is not possible or not desirable to co-locate the PE and CE
functionality. In such deployments PE may be implemented on an
external device with remote CE attachments. This external PE device
should be as close as possible to the end-system where the CE
resides. The external PE devices that attach to a particular VPN,
need to know, for each attachment circuit leading to that VPN, the
host address that is reachable over that attachment circuit. The end-
system MPLS/BGP VPN solution must specify a method to convey this
information from the end-system to the PE.
The same network virtualization solution should support deployments
Napierala and Fang Expires <April 18, 2014> [Page 4]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
with mixed, internal (co-located with CE) and external PE (i.e.,
remote CE) implementations.
2.2. PE Control Plane Function
It is a current practice to implement MPLS/BGP VPN PE forwarding and
control functions in different processors of the same device and to
use internal (proprietary) communication between those processors.
Typically, the PE control functionality is implemented in one (or
very few) components of a device and the PE forwarding functionality
is implemented in multiple components of the same device (a.k.a.,
"line cards").
In end-system environment, a single end-system, effectively,
corresponds to a line card in a traditional PE router. For scalable
and cost effective deployment of end-system MPLS/BGP VPNs the PE
forwarding function should be decoupled from PE control function such
that the former can be implemented on multiple standalone devices.
This separation of functionality will allow for implementing the end-
system PE forwarding on multiple end-system devices, for example, in
operating systems of application servers or network appliances.
Moreover, the separation of PE forwarding and control plane functions
allows for the PE control plane function to be itself virtualized and
run as an application in end-system.
3. VPN Communication Requirements
3.1. Unicast IPv4 and IPv6
A network virtualization solution should be able to provide IPv4 and
IPv6 unicast connectivity between hosts in the same and different
subnets without any assumptions regarding the underlying media layer.
3.2. Multicast/VPN Broadcast IPv4 and IPv6
Furthermore, the multicast transmission, i.e., allowing IP
applications to send packets to a group of IPv4 or IPv6 addresses
should be supported. The multicast service should also support a
delivery of traffic to all endpoints of a given VPN even if those
endpoints have not sent any control messages indicating the need to
receive that traffic. In other words, the multicast service should be
capable of delivering the IP broadcast traffic in a virtual topology.
A solution for supporting VPN multicast and VPN broadcast must not
require that the underlying transport network supports IP multicast
transmission service.
3.3. IP Subnet Support
Napierala and Fang Expires <April 18, 2014> [Page 5]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
In some deployments, Virtual Machines or applications are configured
to belong to an IP subnet. A network virtualization solution should
support grouping of virtual resources into IP subnets regardless of
whether the underlying implementation uses a multi-access network or
not. While some applications may expect to find other peers in a
particular user defined IP subnet, this does not imply the need to
provide a layer 2 service that preserves MAC addresses. End-system
network virtualization solution should be able to provide IP
(unicast, multicast, VPN broadcast) connectivity between hosts in the
same and different subnets without any assumptions regarding the
underlying media layer.
4. Multi-Tenancy Requirements
One of the main goals of network virtualization is to provide traffic
and routing isolation between different virtual components that share
a common physical infrastructure. Networks use various VPN
technologies to isolate disjoint groups of virtual resources. Some
use VLANs [IEEE.802-1Q] as a VPN technology, others use layer 3 based
solutions, often with proprietary control planes. Service Providers
are interested in interoperability and in openly documented protocols
rather than in proprietary solutions. Further more, it is more
favorable if the solution can provide Open Source codes in public
forums, this will give the most flexibility and agility for SPs to
create new services.
A collection of virtual resources might provide external or internal
services. Such collection may serve an external "customer" or
internal "tenant" to whom a Service Provider provides service(s). In
MPLS/BGP VPN terminology a collection of virtual resources dedicated
to a process or application corresponds to a VPN.
A network virtualization multi-tenancy solution should support the
following:
- Tenant or application isolation, in data plane and control plane,
while sharing the same underlying physical network. Tenants should
be able to independently select and deploy their choice of IP
address space: public or private IPv4 and/or IPv6.
- Multiple distinct VPNs per tenant. Tenant's inter-VPN traffic
should be allowed to cross VPN boundaries, subject to access
controls and/or routing policies.
- Inter-VPN communication, subject to access policies. Typically
VPNs that belong to different external tenants do not communicate
with each other directly but they should be allowed to access
shared services or shared network resources. It is often the case
Napierala and Fang Expires <April 18, 2014> [Page 6]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
that SP infrastructure services are provided to multiple tenants,
for example voice-over-IP gateway services or video-conferencing
services for branch offices.
- VM or application end-point should be able to directly access
multiple VPNs without a need to traverse a gateway.
- End-system network virtualization solution should support both,
isolated VPNs as well as overlapping VPNs (often referred to as
"extranets"). It should also support any-to-any and hub-and-spoke
topologies.
5. Decoupling of Virtualized Networking from Physical Infrastructure
One of the main goals in designing a large scale transport network is
to minimize the cost and complexity of its "fabric" by delegating the
virtual resource communication processing to the network edge. It has
been proven (in Internet and in large MPLS/BGP VPN deployments) that
moving complexity to network edge while keeping network core simple
has very good scaling properties.
The transport network infrastructure should not maintain any
information that pertains to the virtual resources in end-systems.
Decoupling of virtualized networking from the physical infrastructure
has the following advantages: 1) provides better scalability; 2)
simplifies the design and operation; 3) reduces network cost.
Decoupling of virtualized networking from underlying physical network
consists in the following:
- Separation between the virtualized segments (i.e., interface
associated with virtual resources) and the physical network (i.e.,
physical interfaces associated with network infrastructure).
- Separation of the virtual network IP address space from the
physical infrastructure network IP address space. In the case of a
transport other than IP, for example MPLS or Ethernet, the
infrastructure address refers to the Subnetwork Point of
Attachment (SNPA) address in a given multi-access network.
- The physical infrastructure addresses should be routable (or
switchable) in the underlying transport network, while the virtual
network addresses should be routable only in the virtual network.
- The virtual network control plane should be decoupled from the
underlying transport network.
6. Decoupling of Layer 3 Virtualization from Layer 2 Topology
Napierala and Fang Expires <April 18, 2014> [Page 7]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
The layer 3 approach to network virtualization dictates that the
virtualized communication should be routed, not bridged. The layer 3
virtualization solution should be decoupled from the layer 2
topology. Thus, there should be no dependency on VLANs and layer 2
broadcast.
In solutions that depend on layer 2 broadcast domains, host-to-host
communication is established based on flooding and data plane MAC
learning. Layer 2 MAC information has to be maintained on every
switch where a given VLAN is present. Even if some solutions are able
to minimize data plane MAC learning and/or unicast flooding, they
still rely on MAC learning at the network edge and on maintaining the
MAC addresses on every switch where the layer 2 VPN is present.
The MAC addresses known to guest OS in end-system are not relevant to
IP services and introduce unnecessary overhead. Hence, the MAC
addresses associated with virtual resources should not be used in the
virtual layer 3 networks. Rather, only what is significant to IP
communication, namely the IP addresses of the virtual machines and
application endpoints should be maintained by the virtual networks.
7. Requirements for Encapsulation of Virtual Payloads
In order to scale the transport networks, the virtual network
payloads must be encapsulated with headers that are routable (or
switchable) in the physical network infrastructure. The IP addresses
of the virtual resources are not to be advertized within the physical
infrastructure address space.
The encapsulation (and de-capsulation) function should be implemented
on a device as close to virtualized resources as possible. Since the
hypervisors in the end-systems are the devices at the network edge
they are the most optimal location for the encap/decap functionality.
The network virtualization solution should also support deployments
where it is not possible or not desirable to implement the virtual
payload encapsulation in the hypervisor/Host OS. In such deployments
encap/decap functionality may be implemented in an external device.
The external device implementing encap/decap functionality should be
a close as possible to the end-system itself. The same network
virtualization solution should support deployments with both,
internal (in a hypervisor) and external(outside of a hypervisor)
encap/decap devices.
Whenever the virtual forwarding functionality is implemented in an
external device, the virtual service itself must be delivered to an
end-system such that switching elements connecting the end-system to
the encap/decap device are not aware of the virtual topology.
Napierala and Fang Expires <April 18, 2014> [Page 8]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
7.1. Encapsulation Methods
MPLS/VPN technology based on [RFC4364] specifies that different
encapsulation methods could be for connecting PE routers, namely
Label Switched Paths (LSPs), IP tunneling, and GRE tunneling.
If LSPs are used in the transport network they could be signaled with
LDP, in which case host (/32) routes to all PE routers must be
propagated throughout the network, or with RSVP-TE, in which case a
full mesh of RSVP-TE tunnels is required.
If the transport network is only IP-capable then MPLS in IP or MPLS
in GRE [RFC4023] encapsulation could be used. Due to route
aggregation property of IP protocols, with IP/GRE encapsulation the
PE host routes do not have to be present in the transport network.
Multi-access technologies, especially Ethernet, may also need to be
supported as transport networks, for example, 802.1ah.
7.2. Routing of Virtual Payloads
A device implementing the encap/decap functionality acts as the
first-hop router in the virtual topology.
In a layer 3 end-system virtual network, IP packets should reach the
first-hop router in one IP-hop, regardless of whether the first-hop
router is an end-system itself (i.e., a hypervisor/Host OS) or it is
an external (to end-system) device. The first-hop router should
always perform an IP lookup on every packet it receives from a
virtual machine or an application. The first-hop router should
encapsulate the packets and route them towards the destination end-
system.
8. Optimal Forwarding of Traffic
The network virtualization solutions that optimize for the maximum
utilization of compute and storage resources require that those
resources may be located anywhere in the network. The physical and
logical spreading of appliances and workloads implies a very
significant increase in the infrastructure bandwidth consumption. In
order to be efficient in terms of traffic forwarding, the virtualized
networking solutions must assure that packets traverse the transport
network only once.
It must be also possible to send the traffic directly from one end-
system to another end-system without traversing through a midpoint
router.
Napierala and Fang Expires <April 18, 2014> [Page 9]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
9. IP Mobility
Another reason for a network virtualization is the need to support IP
mobility. IP mobility consists in IP addresses used for communication
within or between applications being located anywhere across the
virtual network. Using a virtual topology, i.e., abstracting the
externally visible network address from the underlying infrastructure
address is an effective way to solve IP mobility problem.
IP mobility consists in a device physically moving (e.g., a roaming
wireless device) or a workload being transferred from one physical
server/appliance to another. IP mobility requires preserving device's
active network connections (e.g., TCP and higher-level sessions).
Such mobility is also referred to as "live" migration with respect to
a Virtual Machine. IP mobility is highly desirable for many reasons
such as efficient and flexible resource sharing, data center
migration, disaster recovery, server redundancy, or service bursting.
9.1. IP Addressing of Virtual Hosts
To accommodate live mobility of a virtual machine (or a device), it
is desirable to assign to it a semi-permanent IP address that remains
with the VM/device as it moves. The semi-permanent IP address can be
configured through VM configuration process or by means of DHCP.
9.2. Network Layer-Based Mobility
When dealing with IP-only applications it is not only sufficient but
optimal to forward the traffic based on layer 3 (network layer)
rather than on layer 2 (data-link layer) information. The MAC
addresses of devices or applications are irrelevant to IP services
and introduce unnecessary overhead and complications when devices or
VMs move. For example, when a VM moves between physical servers, the
MAC learning tables in the switches must be updated. Moreover, it is
possible that VM's MAC address might need to change in its new
location. In IP-based network virtualization solution a device or a
workload move is handled by an IP route advertisement.
9.3. Routing Convergence Requirements
IP mobility has to be transparent to applications and any external
entity interacting with the applications. This implies that the
network connectivity restoration time is critical. The transport
sessions can typically survive over several seconds of disruption,
however, applications may have sub-second latency requirement for
their correct operation.
To minimize the disruption to established communication during
Napierala and Fang Expires <April 18, 2014> [Page 10]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
workload or device mobility, the control plane of a network
virtualization solution should be able to differentiate between the
activation of a workload in a new location from advertising its route
to the network. This will enable the remote end-points to update
their routing tables prior to workload's migration as well as
allowing the traffic to be tunneled via the workload's old location.
10. Inter-operability with Existing MPLS/BGP VPNs
Service Providers want to tie their server-based offerings to their
MPLS/BGP VPN services. MPLS/BGP VPNs provide secure and latency-
optimized remote connectivity to the virtualized resources in SP's
data center. The Service Provider-based VPN access can provide
additional capabilities compared with public internet access, such as
QoS, OAM, multicast service, VoIP service, video conferencing,
wireless connectivity.
MPLS/BGP VPN customers may require simultaneous access to resources
in both SP and their own data centers.
Service Providers want to "spin up" the L3VPN access to data center
VPNs as dynamically as the spin up of compute and other virtualized
resources.
The network virtualization solution should be fully inter-operable
with MPLS/BGP VPNs, including:
- Inter-AS MPLS/BGP VPN Options A, B, and C [RFC4364].
- BGP/MPLS VPN-capable network devices (such as routers and network
appliances) should be able to participate directly in a virtual
network that spans end-systems.
- The network devices should be able to participate in isolated
collections of end-systems, i.e., in isolated VPNs, as well as in
overlapping VPNs (called "extranets" in BGP/MPLS VPN terminology).
- The network devices should be able to participate in any-to-any
and hub-and-spoke end-systems topologies.
When connecting an end-system VPN with other services/networks, it
should not be necessary to advertize the specific host routes but
rather the aggregated routing information. A BGP/MPLS VPN-capable
router or appliance can be used to aggregate VPN's IP routing
information and advertize the aggregated prefixes. The aggregated
prefixes should be advertized with the router/appliance IP address
as BGP next-hop and with locally assigned aggregate 20-bit label.
The aggregate label should trigger a destination IP lookup in its
Napierala and Fang Expires <April 18, 2014> [Page 11]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
corresponding VRF on all the packets entering the virtual network.
The inter-connection of end-system VPNs with traditional VPNs
requires an integrated control plane and unified orchestration of
network and end-system resources.
11. BGP Requirements in a Virtualized Environment
11.1. BGP Convergence and Routing Consistency
BGP was designed to carry very large amount of routing information
but it is not a very fast converging protocol. In addition, the
routing protocols, including BGP, have traditionally favored
convergence (i.e., responsiveness to route change due to failure or
policy change) over routing consistency. Routing consistency means
that a router forwards a packet strictly along the path adopted by
the upstream routers. When responsiveness is favored, a router
applies a received update immediately to its forwarding table before
propagating the update to other routers, including those that
potentially depend upon the outcome of the update. The route change
responsiveness comes at the cost of routing blackholes and loops.
Routing consistency in virtualized environments is important because
multiple workloads can be simultaneously moved between different
physical servers due to maintenance activities, for example. If
packets sent by the applications that are being moved are dropped
(because they do not follow a live path), the active network
connections will be dropped. To minimize the disruption to the
established communications during VM migration or device mobility,
the live path continuity is required.
11.1.1. BGP IP Mobility Requirements
In IP mobility, the network connectivity restoration time is
critical. In fact, Service Provider networks already use routing and
forwarding plane techniques that support fast failure restoration by
pre-installing a backup path to a given destination. These techniques
allow to forward traffic almost continuously using an indirect
forwarding path or a tunnel to a given destination, and hence, are
referred to as "local repair". The traffic path is restored locally
at the destination's old location while the network converges to a
backup path. Eventually, the network converges to an optimal path and
bypasses the local repair. BGP assists in the local repair techniques
by advertizing multiple and not only the best path to a given
destination.
11.2. Optimization of Route Distribution
Napierala and Fang Expires <April 18, 2014> [Page 12]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
When virtual networks are triggered based on the IP communication,
the Route Target Constraint extension [RFC4684] of BGP should be used
to optimize the route distribution for sparse virtual network events.
This technique ensures that only those VPN forwarders that have local
participants in a particular data plane event receive its routing
information. This also decreases the total load on the upstream BGP
speakers.
11.3. Service chaining
It is important to provide service chaining ability without major
impact to the existing protocols deployed. One solution currently
work in progress in IETF is [I-D.rfernando-l3vpn-service-chaining].
12. Security Considerations
The document presents the requirements for end-systems MPLS/BGP VPNs.
The security considerations for traditional MPLS/BGP VPN deployments
are described in [RFC4364] in Section 13. Security issues associated
with deployments using MPLS-in-GRE or MPLS-in-IP encapsulations are
described in [RFC4023] in Section 8. And [RFC4111] provides general
IP VPN security guidelines.
The additional security requirements specific to end-system MPLS/BGP
VPNs are as follows:
- End-systems MPLS/BGP VPNs solution should guarantee that packets
originating from a specific end-system virtual interface are
accepted only if the corresponding VPN IP host is present on that
end-system.
- Virtual network must ensure that traffic arriving at the egress
end-system is being sent from the correct ingress end-system.
- One virtual host or VM should not be able to impersonate another,
during steady-state operation and during live migration.
The security considerations for specific solutions will be
documented in the relevant documents.
13. IANA Considerations
This document contains no new IANA considerations.
14. References
14.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Napierala and Fang Expires <April 18, 2014> [Page 13]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed.,
"Encapsulating MPLS in IP or Generic Routing Encapsulation
(GRE)", RFC 4023, March 2005.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, February 2006.
[RFC4684] Marques, P., Bonica, R., Fang, L., Martini, L., Raszuk,
R., Patel, K., and J. Guichard, "Constrained Route
Distribution for Border Gateway Protocol/MultiProtocol
Label Switching (BGP/MPLS) Internet Protocol (IP) Virtual
Private Networks (VPNs)", RFC 4684, November 2006.
[IEEE.802-1Q] Institute of Electrical and Electronics Engineers,
"Local and Metropolitan Area Networks: Virtual Bridged
Local Area Networks", IEEE Std 802.1Q-2005, May 2006.
14.2. Informative References
[RFC4111] Fang, L., Ed., "Security Framework for Provider-
Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
July 2005.
[I-D.ietf-l3vpn-end-system] Marques, P., Fang, L., Pan, P., Shukla,
A., Napierala, M., "BGP-signaled end-system IP/VPNs",
draft-ietf-l3vpn-end-system, work in progress.
[I-D.fang-l3vpn-virtual-pe] Fang, L., Ward, D., Fernando, R.,
Napierala, M., Bitar, N., Rao, D., Rijsman, B., So, N.,
"BGP IP VPN Virtual PE", draft-fang-l3vpn-virtual-pe, work
in progress.
[I-D.rfernando-l3vpn-service-chaining] Fernando, R., Rao, D., Fang,
L., Napierala, M., So, N., draft-rfernando-l3vpn-service-
chaining, work in progress.
15. Acknowledgements
The authors would like to thank Pedro Marques and Han Nguyen for the
comments and suggestions.
Authors' Addresses
Maria Napierala
AT&T
200 Laurel Avenue
Middletown, NJ 07748
Napierala and Fang Expires <April 18, 2014> [Page 14]
INTERNET DRAFT <BGP/MPLS IP VPN DCI> <October 18, 2013>
Email: mnapierala@att.com
Luyuan Fang
Cisco
111 Wood Avenue South
Iselin, NJ 08830, USA
Email: luyuanf@gmail.com
Napierala and Fang Expires <April 18, 2014> [Page 15]