Internet DRAFT - draft-ietf-bess-end-system-requirements

draft-ietf-bess-end-system-requirements



 



INTERNET-DRAFT                                           Maria Napierala
Intended Status: Informational                                      AT&T
Expires: May 12, 2015                                        Luyuan Fang
                                                               Microsoft
                                                                        
                                                       November 11, 2014


        Requirements for Extending BGP/MPLS VPNs to End-Systems
             draft-ietf-bess-end-system-requirements-00.txt


Abstract 

   The proven scalability and extensibility of the BGP/MPLS IP VPNs (IP
   VPN) technology has made it an attractive candidate for data
   center/cloud virtualization. Virtualized end-system environment
   imposes additional requirements to MPLS/BGP VPN technology. This
   document provides the requirements for extending IP VPN technology
   (in original or modified versions) into the end-systems/hosts, such
   as a server in a data center.

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) 2014 IETF Trust and the persons identified as the
   document authors. All rights reserved.

 


Napierala and Fang       Expires <May 12, 2015>                 [Page 1]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


   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 . . . . . . . . . . . . . . . . . . . . .  6
   4. Multi-Tenancy Requirements  . . . . . . . . . . . . . . . . . .  6
   5. Decoupling of Virtualized Networking from Physical 
      Infrastructure  . . . . . . . . . . . . . . . . . . . . . . . .  7
   6. Decoupling of Layer 3 Virtualization from Layer 2 Topology  . .  8
   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 . . . . . . . . . . . . 13
   12. Service chaining . . . . . . . . . . . . . . . . . . . . . . . 13
     12.1. Load Balancing . . . . . . . . . . . . . . . . . . . . . . 13
     12.2. Symmetric Service Chain Support  . . . . . . . . . . . . . 14
     12.3. Packet Header Transforming Services  . . . . . . . . . . . 14
   13. Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   13. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   14.  References  . . . . . . . . . . . . . . . . . . . . . . . . . 15
     14.1.  Normative References  . . . . . . . . . . . . . . . . . . 15
     14.2.  Informative References  . . . . . . . . . . . . . . . . . 16
 


Napierala and Fang       Expires <May 12, 2015>                 [Page 2]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16


Requirements Language

Although this document is not a protocol specification, 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  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). 

This document defines requirements for a network virtualization solution
that provides secure IP VPN connectivity to virtual resources on end-
systems operating in a multi-tenant shared physical infrastructure. The
requirements address the needs of virtual resources, defined as Virtual
Machines, applications, and appliances that require only IP
connectivity. Non-IP communication is addressed by other solutions 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
 


Napierala and Fang       Expires <May 12, 2015>                 [Page 3]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


CE                Customer Edge router 
End-System        A device where Guest OS, Host OS/Hypervisor reside
GRE               Generic Routing Encapsulation
Hypervisor        Virtual Machine Manager
Iaa               Infrastructure as a Service 
PE                Provider Edge router
RT                Route Target
RTC               RT Constraint        
SDN               Software Defined Network
ToR               Top-of-Rack switch
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 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 forwarding edge functionality 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 attaches to MPLS/BGP VPN, CE corresponds to a non-
routing host that can reside in a Virtual Machine 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 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
 


Napierala and Fang       Expires <May 12, 2015>                 [Page 4]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


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


Napierala and Fang       Expires <May 12, 2015>                 [Page 5]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


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

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.

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.
 


Napierala and Fang       Expires <May 12, 2015>                 [Page 6]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


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


Napierala and Fang       Expires <May 12, 2015>                 [Page 7]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


      underlying transport network.

6. Decoupling of Layer 3 Virtualization from Layer 2 Topology

   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.
 


Napierala and Fang       Expires <May 12, 2015>                 [Page 8]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


   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.

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. The label forwarding tables
   can also be constructed using SDN controllers without the need of
   distributed signaling protocols.

   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.

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. 

 


Napierala and Fang       Expires <May 12, 2015>                 [Page 9]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


   It must be also possible to send the traffic directly from one end-
   system to another end-system without traversing through a midpoint
   router.

9. IP Mobility

   Another reason for a network virtualization is the need to support IP
   mobility. IP mobility means that IP addresses used for communication
   within or between applications can be 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 or device 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
 


Napierala and Fang       Expires <May 12, 2015>                [Page 10]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


   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
   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 advertizing 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 to other 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
 


Napierala and Fang       Expires <May 12, 2015>                [Page 11]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


      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
      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 forwarding 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
 


Napierala and Fang       Expires <May 12, 2015>                [Page 12]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


   repair techniques by advertizing multiple paths and not only the best
   path to a given destination.

11.2. Optimization of Route Distribution

   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.

12. Service chaining

   A service chain is a deployment where a sequence of appliances
   intermediate traffic between networks. In fact, traffic from one
   virtual network may go through an arbitrary graph of service nodes
   before reaching another virtual network. Service chains can contain a
   mixture of virtual services (implemented as VMs on compute nodes) and
   physical services (hosted on service nodes). Network appliances tend
   to be designed to operate on an "inside/outside" interface model.
   This type of applications do not terminate traffic and are
   transparent to packets. In an SDN approach, the service chain is
   configured and managed in software that adds and removes services
   from the chain in an automated way. It is a requirement that service
   chaining is supported on devices using MPLS/BGP VPN technology for
   virtual networking. 

   Connecting appliances in a sequence has been done for many years
   using VLANs. However, "service-chaining" cannot be implemented
   without solving the problem of how to bring in traffic from a routed
   network into the set of appliances. The issue is always how to
   attract the traffic in and forward it out of the service-chain, i.e.,
   how to integrate the service-chain with routing. By using the same
   mechanism to route traffic in and out of a service chain as well as
   through its intermediate hops, the implementation of service chains
   is significantly simplified. 

   One solution currently work in progress in IETF is
   [I-D.rfernando-l3vpn-service-chaining].


12.1. Load Balancing

   One of the main requirements of service-chaining is horizontal
   scaling of a service in a service-chain to tens or hundreds of
   instances. When using MPLS/BGP VPN routing instance (or VRF)
 


Napierala and Fang       Expires <May 12, 2015>                [Page 13]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


   construct to implement service chaining, the load balancing is built-
   in. The load balancing corresponds to BGP multipath where multiple
   routes for a single prefix are installed in a routing instance. The
   multiple BGP routes in the routing table translate to Equal Cost
   Multi-Path in the forwarding plane. The hash used in the load
   balancing algorithm can be per packet, per flow or per prefix. The
   forwarding plane should support load balancing over several hundreds
   next-hops.

   Load balancing should support deployments where both, virtual and
   physical service appliances are present. It should support
   deployments where virtual service instances are spread across the
   same and different end-systems/hosts.

12.2. Symmetric Service Chain Support

   If a service function is stateful, it is required that forward flows
   and reverse flows always pass through the same service instance. ECMP
   does not provide this capability, since the hash calculation will see
   different input data for the same flow in the forward and reverse
   directions. Additionally, if the number of service instances changes,
   either to expand/decrease capacity or due to an instance failure, the
   hash table in ECMP is recalculated, and most flows will be re-
   directed to a different service instance, causing user session
   disruption.

   It is a requirement that service chaining solution satisfies the
   requirements of symmetric forward/reverse paths for flows and a
   minimal traffic disruption when service instances are added to or
   removed from a set of instances.

12.3. Packet Header Transforming Services

   A service in a service chain might perform an action that changes the
   packet header information, e.g., the packet's source address (such as
   performed by NAT service). In order to support the reverse traffic
   flow traffic in this case, the routing and forwarding information has
   to be modified such that the traffic can be directed via the
   instances of the transforming service. For example, the original
   routes with a source prefix (Network-A) are replaced with a route
   that has a prefix that includes all the possible addresses that the
   source address could be mapped to. In the case of network address
   translation, this would correspond to the NAT pool.

   It is a requirement that service chaining solution supports services
   that manipulate packet headers.

13. Security Considerations
 


Napierala and Fang       Expires <May 12, 2015>                [Page 14]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


   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. The additional security
   issues associated with deployments using MPLS-in-GRE or MPLS-in-IP
   encapsulations are described in [RFC4023] in Section 8. In addition,
   [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

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

 


Napierala and Fang       Expires <May 12, 2015>                [Page 15]

INTERNET DRAFT           <BGP/MPLS IP VPN DCI>       <November 11, 2014>


14.2.  Informative References

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

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


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
   Email: mnapierala@att.com

   Luyuan Fang
   Microsoft
   5600 148th Ave NE
   Redmond, WA 98052
   Email: lufang@microsoft.com










Napierala and Fang       Expires <May 12, 2015>                [Page 16]