Network Working Group
   Internet Draft
   Intended status: Informational                    Maria Napierala
   Expires: May 2013                                            AT&T
                                                         Luyuan Fang
                                                       Cisco Systems

                                                       November 2012


          Requirements for Extending BGP/MPLS VPNs to End-Systems
              draft-fang-l3vpn-end-system-requirements-01.txt

Abstract

   Service Providers commonly use BGP/MPLS VPNs [RFC 4364] as the
   technology for providing wide-area virtual private network
   services. This technology has proven to scale to a very large
   number of VPNs and attachment points, and it is well suited for
   extending VPN connectivity to end-systems operating in a multi-
   tenant environments. Virtualized end-system environment imposes
   additional requirements to MPLS/BGP VPN technology when applied to
   end-system networking, which are defined in this document.


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


Napierala, Fang            Expire May 2012                   [Page 1]


Internet Draft                                         November 2012

   Copyright (c) 2012 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the Simplified BSD License.


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                                10
   9.   IP Mobility                                                  10
   9.1.  IP Addressing of Virtual Hosts                             10
   9.2.  Network Layer-Based Mobility                               11
   9.3.  Routing Convergence Requirements                           11
   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.2. Optimization of Route Distribution                         13
   12.  Security Considerations                                      13
   13.  IANA Considerations                                          14
   14.  Normative References                                         14
   15.  Informative References                                       14
   16.  Authors' Addresses                                           15
                                                              [Page 2]


Internet Draft                                         November 2012

   17.  Acknowledgements                                             15


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 [RFC
   2119].


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.

   In order to scale compute, storage, and network service functions,
   physical resources are being abstracted from their logical
   representation. This is referred as server, storage, and network
   virtualization. Virtualization can be implemented in various layers
   of computer systems or networks. The virtualized loads are executed
   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.


  1.1.  Terminology

   AS           Autonomous Systems
   End-System   A device where Guest OS and Host OS/Hypervisor reside
   IaaS         Infrastructure as a Service
   RT           Route Target
   ToR          Top-of-Rack switch
   VM           Virtual Machine
   Hypervisor   Virtual Machine Manager
   SDN          Software Defined Network
   VPN          Virtual Private Network
                                                              [Page 3]


Internet Draft                                         November 2012




2. Application of MPLS/BGP VPNs to End-Systems

   MPLS/BGP VPN technology [RFC 4364] 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 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 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.



                                                              [Page 4]


Internet Draft                                         November 2012

   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 sent any control messages indicating the need to
   receive that traffic. In other words, the multicast service should
                                                              [Page 5]


Internet Draft                                         November 2012

   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.


                                                              [Page 6]


Internet Draft                                         November 2012

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

                                                              [Page 7]


Internet Draft                                         November 2012

      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

   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
                                                              [Page 8]


Internet Draft                                         November 2012

   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.


  7.1.  Encapsulation Methods

   MPLS/VPN technology based on [RFC 4364] 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
                                                              [Page 9]


Internet Draft                                         November 2012

   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.


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

                                                             [Page 10]


Internet Draft                                         November 2012

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



                                                             [Page 11]


Internet Draft                                         November 2012

   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 [RFC 4364].

   - 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
   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
                                                             [Page 12]


Internet Draft                                         November 2012

   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

   When virtual networks are triggered based on the IP communication,
   the Route Target Constraint extension [RFC 4684] 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.     Security Considerations


                                                             [Page 13]


Internet Draft                                         November 2012

   The document presents the requirements for end-systems MPLS/BGP
   VPNs. The security considerations for traditional MPLS/BGP VPN
   deployments are described in [RFC 4364] 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.

   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.     Normative References

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

   [RFC 4023]  Worster, T., Rekhter, Y. and E. Rosen, "Encapsulating
   in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March
   2005.

   [RFC 4684]  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.


15.     Informative References



                                                             [Page 14]


Internet Draft                                         November 2012

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

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


16.     Authors' Addresses


   Maria Napierala
   AT&T
   200 Laurel Avenue
   Middletown, NJ 07748
   Email: mnapierala@att.com

   Luyuan Fang
   Cisco Systems
   111 Wood Avenue South
   Iselin, NJ 08830, USA
   Email: lufang@cisco.com


17.     Acknowledgements


   The authors would like to thank Pedro Marques and Han Nguyen for
   the comments and suggestions.





















                                                             [Page 15]