Network Working Group L. Yong Internet Draft S. Hares Intended status: Informational Huawei Expires: April 2013 October 21, 2012 VPN Protocol Gap Analysis for DC Network Virtualization Overlays draft-hy-nvo3-vpn-protocol-gap-analysis-02 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/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April, 2013. Copyright Notice Copyright (c) 2009 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. Yong & Hares Expires April 21, 2013 [Page 1] Internet-Draft NVO3 and VPN Gap October 2012 Abstract This document is to describe the applicability of traditional IP/MPLS L2VPN and L3VPN for NVO3 and identify the protocol gaps. It also addresses the use of the VPNs for inter DC connectivity when NVO3 is used. Table of Contents 1. Introduction...................................................2 2. Terminology....................................................3 3. IP/MPLS Virtual Private Networks (VPNs)........................3 4. VPN for Network Virtualization Overlays........................4 4.1. NVE Location..............................................4 4.2. VM Mobility...............................................6 4.3. VNI on NVE................................................6 4.4. Tunneling.................................................6 4.5. Auto Discovery............................................7 4.6. Load Balancing............................................7 4.7. Broadcast and Multicast Traffic...........................7 4.8. Gateway...................................................7 4.9. Underlay Network Design...................................8 5. VPN for Inter DC Connectivity..................................8 5.1. Interconnecting DC Underlying Networks....................8 5.2. Interconnecting DC Overlay Networks.......................9 5.3. Interconnecting a DC VN and Enterprise Networks..........10 6. Operator Aspects..............................................12 7. Security Considerations.......................................13 8. IANA Considerations...........................................13 9. Acknowledgments...............................................13 10. References...................................................13 10.1. Normative References....................................13 10.2. Informative Reference...................................14 1. Introduction DC Network Virtualization Overlay is driven by a desire of building a tenant application in a true virtual and secure environment [NVO3PRBM]. The NVO3 aims on a solution to group virtual hosts together in a true virtual environment that is decoupled from the physical network configuration. This decoupling not only speeds up the construction of a tenant applications and virtual Data Centers but also enables a new cloud application. For example, allow the hot VM move from a server to another. Yong & Hares Expires April 21, 2013 [Page 2] Internet-Draft NVO3 and VPN Gap October 2012 Virtual and overlay network technology is not new. [RFC4364] [RFC4761] [RFC6325] The main differences between other overlay network technologies and NVO3 are 1) the client edge of the NVO3 network may be individual virtualized hosts, not network sites or LANs; 2) the hosts and the network edge may be on the same server and the server is a host, not a network edge device; 3) the capability to support dynamic host placement and mobility. VPLS [RFC4761] [RFC4762] based L2VPN and BGP/MPLS L3VPN [RFC4364] have been widely deployed in Service Provider IP/MPLS networks to provide Layer 2 or Layer 3 virtual private networking for a customer. In fact, these VPN technologies have a lot of common characteristics that the NVO3 requires. These characteristics are: 1) the capability to build many L2VPN and/or L3VPN instances on a common IP/MPLS backbone infrastructure; 2) to segregate the VPN traffic from other VPN's; 3) each VPN uses its own address space and the address is isolated from the infrastructure address space. Further both L2VPN and L3VPN solutions use the virtualization and encapsulation approach at the edge device, i.e. PE, to hide customer frames or packets and use a LSP tunnel transporting the frames/packets. This is very similar to the targeted NVO3 solution. Thus, it is useful to evaluate the L2VPN and L3VPN applicability for NVO3 and identify the protocol gaps between them. In addition, an NVO3 application may need to communicate with external users in a secured manner. The use of a traditional VPN to interconnect between a DC virtual network and enterprise networks [NVO3UCASE] remains the minimum changes in the enterprise networks and service provider networks. As a result the VPNs in a WAN may be necessary to support NVO3 features as well. This draft is to analyze NV03 requirements and L2VPN/L3VPN solutions/protocols and point out the gaps in between. The draft intends to stay in neutral on whether a new solution or the extension/simplification of the VPN solutions is right approach for NVO3. 2. Terminology This document uses the terminologies defined in [NVO3FRWK], [RFC4364]. 3. IP/MPLS Virtual Private Networks (VPNs) IP/MPLS based VPLS and E-VPN [RFC4761][RFC4762][EVPN] and L3VPN [RFC4364] are developed for Wide-Area Networks. Both VPLS and L3VPN Yong & Hares Expires April 21, 2013 [Page 3] Internet-Draft NVO3 and VPN Gap October 2012 have been widely deployed in Service Provider WANs, MANs, and some access networks. The E-VPN is still under development. These VPN solutions allow a Service Provider IP/MPLS backbone network provides a virtual private network in a WAN for a customer who has more than one network sites, i.e. the connectivity among customer network sites. The architecture of L2VPN [RFC4664] and L3VPN are very similar. The three entities in the VPN architecture are CE, PE, and P. CE is the customer edge, representing a customer site. PE is the backbone network edge that connects to a customer CE via a physical interface. P is the backbone core node that does not connect to the customer site directly. The distinction between L2VPN and L3VPN is that an L2VPN routes and forwards on Ethernet MAC addresses while an L3VPN routes and forward on IP addresses. The VPLS solution uses the PW [RFC4448] for the transport between any pair of PEs; the L3VPN [RFC4364] and EVPN [EVPN] uses a MPLS LSP tunnel for the transport between any pair of PEs. Note that the PW in turn relies on a LSP tunnel for the transport as well. The VPLS uses data plane MAC learning at each PE to resolve the endpoint location. The L3VPN and EVPN uses iBGP protocol to disseminate customer IP and MAC address to the remote PEs. The L3VPN may use eBGP, OSPF [RFC4577], or others for the route population between CE-PE; EVPN uses data plane MAC learning at a PE customer facing interface. Both L2VPN and L3VPN solutions make the core node unaware of the VPN existence at PEs. Regarding auto discovery and configuration, the L3VPN and EVPN use the BGP protocols; the VPLS uses either LDP [RFC4762] or iBGP [RFC4761] protocol. Note that PW [RFC4448], L2TP [RFC5641], etc are often known as a L2VPN solution because they can transport Ethernet MAC frames between two points. This draft focuses on the analysis of VPLS, EVPN and L3VPN for the NVO3 and refers these two as L2VPN. 4. VPN for Network Virtualization Overlays 4.1. NVE Location One characteristics of NVO3 is the NVE location [NVO3FRWK]. There are two distinct cases. First an NVE resides on a server, i.e. TESs and NVE are on the same hardware. In this case, a server manager system is responsible to create NVE/VNs and VMs, and also responsible to assign a VM to a VN that has unique identification, then server software just makes it works properly and securely. A server itself may connect to the ToR as a host and DC physical network uses L3 network. This configuration is similar to Option B in RFC4363 [RFC4364]. Second an NVE resides on an external switch Yong & Hares Expires April 21, 2013 [Page 4] Internet-Draft NVO3 and VPN Gap October 2012 such as ToR. When a server manager creates a VM and adds the VM to a VN on a local NVE, the server will send a notification of VM participation in the VN to the local NVE. In both cases, when a local NVE notices the new attached TES in a VN, it will announce the TES to remote NVEs [RFC4364] [EVPN] or to a mapping server via a control plane protocol [LISP]. Traditional VPN architecture has PE and CE roles on different devices and two devices are connected via a wire (or more). In addition, PE and CE may be managed by different administration systems and serve as the service demarcation point. A CE is typical a network site (in L3VPN) or LANs (in L2VPN). PE is a Service Provider edge device. Although the VPN PE function is some similar to NVE, CE function is very different from NVO3 TES's from several aspects: o PE and CE are on different hardware not on one. The provision process on CE and PE is done by different systems. TES/NVE in NV03 may be managed by one system. o When CE is at a network site, a new end system is added into the site first, then this route is populated or learned by the PE. Thus the supporting of the dynamic changes of end-points is not critical to a VPN solution today due to the CE site network limitation to support that. However, in NVO3, a TES directly attaches to an NVE, the NVO3 solution has to support the dynamic change of TES. o In L3VPN, the route population between PE and CE can be done by some control plane protocol such as eBGP, OSPF, etc. If an NVE is on a server, no need a control plane protocol between a TES and NVE; if an NVE is on an external switch, it may not be practical or efficient to run these protocols on every server as CE's. Thus NV03 may use a different protocol between an NVE and a server when the NVE is on an external switch.[ESYS] From the data plane perspective, L2VPN and L3VPN both can support virtual sub- interface on a wire.[RFC4761][EVPN][VRF-LITE] o When an NVE is on a server, the server connects to one or more ToRs as a host, i.e. the server does not run any routing protocol but is configured with a default gateway. DC physical network does not have any visibility of NVO3. See section 5.2. NVO3 makes TES and NVE more coupled together while VPN solution has VPN function and underlay network more coupled. Yong & Hares Expires April 21, 2013 [Page 5] Internet-Draft NVO3 and VPN Gap October 2012 4.2. VM Mobility Compute virtualization drives the need for network virtualization overlays, which lets closed user groups (CUG) to communication in a true virtual environment without considering physical network configuration. One BIG application for this is to enable dynamic VM placement and move without the change of VM IP and MAC address. Further the VM move has to be quickly enough so that the application does not get disrupted. This requires the NVO3 solution to differentiate a VM placement from a VM move. Both L2VPN and L3VPN solutions do not distinguish two actions and are not able to support a hot move. Further VM mobility adds the challenges for IP routing optimization [ISSUES]. If the VM move is necessary across Data Centers [ISSUES], a traditional VPN solution also needs to support that. The BGP protocol supports sending a MAC withdraw message to allow a local PE to inform the remote PEs about its end-system removal. However, if a local PE can't detect the end-system removal quickly, this message may not be sufficient to insure the frame forwarding properly. For example, if a TES does not directly connect to a PE by a wire, the PE hardly syncs the state of TES when it moves. Another issue is when a VM moves, if its default gateway has no change, the traffic to/from the VM will still be routed through the same gateway entity, which is not optimized router. [ISSUES] 4.3. VNI on NVE NVO3 may apply to a large data center that may have hundred thousand servers and several millions of VMs. One NVO3 requirement is to be able to support a large number of virtual networks on a common data center infrastructure where each virtual network may be highly distributed in term of NVEs and spares TES per a NVE. To let each NVE maintain all the routes may lead a scalability issue for a server or a ToR switch. Considering a TES in a closed user group may rarely communicate with all other TESs at the same time, it is not necessary for an NVE to maintain all the routes at all the time. Some advanced control plane protocol and mechanism may fit better than traditional VPN control plane protocol for the route population between NVEs. [LISP] 4.4. Tunneling Traditional L2VPN and L3VPN are mainly implemented with the MPLS tunnels for transporting over the backbone network. Although the GRE tunnel [RFC4797] is technically feasible, the majority L2VPN and L3VPN deployments if not all use MPLS/LSP tunnel approach, i.e. one Yong & Hares Expires April 21, 2013 [Page 6] Internet-Draft NVO3 and VPN Gap October 2012 MPLS label (inner label) as the VPN identifier (or PW for VPLS) and one label (outer label) for MPLS/LSP tunnel. Thus core nodes, i.e. P nodes, are unaware of individual VPN instances. This implementation integrates the VPN solutions and the underlying MPLS network technology in one or another way. For example, the use of one label stack for the packet processing at PE and P, the traffic engineering capability, and MPLS trace [RFC4379] tools are able to track both inner and outer labels. NVO3 clearly requires the decoupling the overlay and underlying networking configuration. Further it has a high desirable to use IP tunnel instead of MPLS tunnel in a Data Center. Although the IP/GRE tunnel can apply to L2/L3 VPN solutions, the lack of the deployment in a real network may leave some unknown holes in the packet processing and management. For example, the IP/GRE tunnel approach aggregates the tunneled traffic in the underlying network, which may impacts the recovery and traffic optimization in the network. Thus a diligent study is necessary. 4.5. Auto Discovery Both L2VPN and L3VPN have auto discovery capability and use BGP protocol. The protocol can apply to the NVO3 if the same control plane protocol is used. However, if other route population protocol is used, NVO3 also needs the similar auto discovery capability. 4.6. Load Balancing Address in next version. 4.7. Broadcast and Multicast Traffic Address in next version. 4.8. Gateway A logical gateway places an important role in NVO3 use case [NVO3UCASE]. A gateway may interconnect NVO3 instances together, connect a NVO and a virtual network in a DC, or connect a NVO to external users via Internet, WAN VPN, or direct line. Furthermore a logical gateway may perform encapsulation translation, NAT, firewall, IPSEC, etc. Although an L3VPN is able to provide some gateway and policy functions, it does not have the role to perform encapsulation translation, NAT functions. Yong & Hares Expires April 21, 2013 [Page 7] Internet-Draft NVO3 and VPN Gap October 2012 4.9. Underlay Network Design DC underlay network design may be different from carrier WAN network design. DC physical networks have a common three tier architecture, ToR, aggregation switch and core switch plus DC gateway for the external connection. DC operator may not deploy any IGP in DC and just configure many ASes and use BGP protocol for the reachbility in DC physical networks [DCBGP] or use Open Flow design [ONF] instead of distributed control plane. This makes some challenges or new aspects for underlay network configuration and management, optimization, resiliency, and convergence. Although MPLS/BGP solution supports multi-ASes and allows a transit AS carrying a VPN seamlessly, the configuration is more complex than the VPN in single IGP. See section 5.2. 5. VPN for Inter DC Connectivity Today Service Provider VPN services are mainly used for interconnecting Enterprise DCs that are at different locations including DC providers. In this case, DC provider sites as the CE site and connect to Service Provider edge routers, i.e. PEs, via a physical wire. Typically an Ethernet Interface is used. Service provider may offer either a L2VPN [RFC4761][RFC4762] or L3VPN [RFC4364] service over the WANs to a customer. The service provides the connectivity among customer physical networks (port based) or virtual networks (sub-interface) at the locations. When using NVO3, one difference is that NVO3 uses the overlay for each VN instead of VLANs. In other words, on a DC provider infrastructure, there is one underlying network (physical) and many overlay networks (virtual). Following sections describe the VPN applicability for interconnecting such DC locations and potential enhancements to interwork with NVO3. Note that the description applies to both L2VPN and L3VPN unless it is stated explicitly. 5.1. Interconnecting DC Underlying Networks In this case, a Service Provider constructs a traditional VPN to interconnect multiple DC physical networks over the WANs for a DC customer. Then the DC customer may configure a NVO3 virtual network in multiple DCs in the same way as if configuring it in one DC without considering the VPN configuration at all. The DC physical networks and the VPN in the WANs together provide the underlying networking for an NVO3 virtual network. Two NVEs in the different DC locations can build one tunnel for NVO3 transport over DC networks and the VPN. The VPN transports the tunneled Yong & Hares Expires April 21, 2013 [Page 8] Internet-Draft NVO3 and VPN Gap October 2012 packets seamlessly across WANs and does not have the visibility of the end systems in each virtual network. The routes populated between a CE and PE are the DC underlying network routes only. The NVO3 functions such as auto discovery and VM mobility seamlessly work over the VPN. No change on the existing VPN solutions is necessary for this option. From the NVO3 perspective, it is completely decoupled from the VPN and is not aware of the VPN existence at all. When using BGP/MPLS VPNs, the eBGP interworks with DC control plane protocols such as OSPF or ISIS, which makes each DC network as individual islands from the control plane perspective. In the case that different DCs use different NVO3 solutions and require a gateway entity between two virtual networks, this option still works seamlessly. However the NVO3 control plane needs to address disseminating the end system locations across DCs [NVO3PRBM], which is discussed in next section. This is the interface protocol between oracle systems Note that for an L3VPN configuration, the control plane in each DC site just peers with the local PE not a remote CE; For an L2VPN configuration, a Service Provider can configure the policy for L2CP BDUs at a PE based on the customer request. They can be either passed or discarded. It is worth to mention that there are other network solutions that support an overlay networking beside IP IGP technology. PBB [PBB] is L2 network solution; SPB [RFC6329] and TRILL [RFC6325] are L2 network solution with IS-IS control plane. Some DC operators may choose one of them for their data centers. The EVPN extensions such as [PBB-EVPN],[SPB-EVPN],[TRILL-EVPN] allow to interconnect DCs that use these solutions. 5.2. Interconnecting DC Overlay Networks In this case, a Service Provider constructs a VPN in the WANs to interconnect a particular NVO3 virtual network (i.e. a tenant virtual network that spans across multiple DCs). A sub-interface such as a VLAN between CE and PE can be used to identify the VN between the CE, e.g. DC Gateway Router, and the PE. Each DC builds a tunnel between a NVE and the DC Gateway Router for the transport within the DC. The VPN may use a MPLS/LSP tunnel between any pair of PEs in WANs. This option creates one NVO3 virtual network in each DC and one VPN over the WANs and stitches them together by a local VLAN between a CE and PE to form one tenant virtual network. The VPN in the WANs in this case only has the visibility of the VN in a DC. The VPN does not have the visibility of the DC physical network and other VNs in the DCs. The end systems in other DCs will appear as if associating with the DC Gateway Router in a DC. The VPN Yong & Hares Expires April 21, 2013 [Page 9] Internet-Draft NVO3 and VPN Gap October 2012 protocol extension may be necessary for the route population between CE and PE as well as among PEs. This is because 1) NVO3 may use a new control plane protocol that current VPN does not support. 2) The capability to support VM mobility. [ISSUES] Note that this option allows individual DCs to use the same or different NVO3 encapsulation schema. In fact, this option is very similar to Option A [RFC4364] except NVO3 implementation may differ. If DC operators want to construct an L2 VN within a data center but buy an L3VPN interconnect them, the NVE on the DC GW will perform the ARP function to resolve the IP/MAC mapping. If DC operators use eBGP and RR to disseminate the TES locations across DCs, it is possible to implement Option B and C [RFC4364]. In option B, the IP address of remote NVE in another DC is used in outer header, i.e. as the tunnel address. In option C, two tunnels are necessary. The inter tunnel is to the remote NVE; the outer tunnel is to the ASBR, which enables IGP routers to forward packets in IGP. In both cases, a WAN VPN (or Internet) has to connect DC physical networks first as mentioned in section 5.1. There is not a WAN VPN directly connecting to an overlay network in DC. It is interesting to note that two BGP separated control planes are used: one works with DC underlying network control plane and another is used for overlay network control plane. Note that no matter a VPN in a WAN connects to a DC underlying network or overlay network, a DC network never have the visibility to the WAN network, i.e. the VPN networking is decoupled from the IP/MPLS transport. 5.3. Interconnecting a DC VN and Enterprise Networks [NVO3UCASE] describes the needs and the different ways for a virtual network in a Data Center to communicate with external users. For a private cloud application, the use of a traditional VPN in a WAN to interconnect with a VN in DC provider site is desirable. The benefit of the traditional VPN is to leverage existing VPN usage or minimize the change on the VPN when the enterprise customer uses it to access a cloud service provided by a DC provider. Figure 1 below illustrates this scenario. Both enterprise A and B uses a Service Provider L3VPN services to interconnect its branch locations respectively. Note that the two VPN topologies may differ. Now each buys a virtual DC from a DC provider and wants the vDC to connect to their VPN supported by the Service Provider. In this case, the VPN service provider configures a VPN for each customer at the PE near to DC provider location, i.e. PE3 in Figure 1. The PE Yong & Hares Expires April 21, 2013 [Page 10] Internet-Draft NVO3 and VPN Gap October 2012 has a physical interface connecting DC Gateway Router (DCGR). The DC provider constructs an NVO3 based vDC for each enterprise customer. .----------------------. | IP/MPLS Network | *-------* | | *-------* | +--+ AC +----+ iBGP +----+ AC +--+ | | |CE+----| PE1|............| PE2|----+CE| | |E-A.+--+ +----+ LSP Tunnel +----+ +--+ E-A| |Site 1 | /| . . |\ |Site 2 | *-------* / | . . | \ *-------* / | +---+ | \ AC/ | |PE3| | \AC / .--------+-+-+---------. \ / eBGP |AC(s) \ / | \ *-+--+--* *-------+-+--+-------* *-+--+--* | |CE| | | |DCGR| | | |CE| | | +--+ | | +/--\+ | | +--+ | |E-B | | .../. .\... | | E-B | |Site 1 | | . V . . V . | |Site 2 | +-------+ | . D . . D . | *-------* | . C . . C . | | . a . . b . | Date Center | ..... ..... | Provider Site *--------------------* Figure 1 L3VPN for Enterprise and Provider DC Interconnection This configuration can be seen as the combination of section 5.1 and section 5.2. The VPN at PE1 and PE2 connects to the enterprise customer physical networks; while the VPN at PE3 connects to a DC provider NVO3 virtual network. Using option A [RFC4364], the VPN does not have the visibility of DC Provider physical network. The overlay tunnel terminates at the DCGR. Note that Option B and C may apply to this case with additional inter-tenant configuration. In addition, the VPN policy may be used for controlling routes and traffic in inter-tenant connectivity. This configuration provides the connectivity among the enterprise networks and its vDC in the DC provider location and isolates the VPN from the DC provider infrastructure, WAN infrastructure, as well as other virtual networks in the DC provider location. Note that it Yong & Hares Expires April 21, 2013 [Page 11] Internet-Draft NVO3 and VPN Gap October 2012 is possible that vDC span across multiple DC provider locations. One VPN can be used to interconnect them all. For this configuration, the VPN Service Provider has to work with both an enterprise customer and a DC provider to provision the VPN properly at each PE. The VPN protocol extension for this is the same as in section 5.2. 6. Operator Aspects The L2VPN and L3VPN were developed for a Metro or Wide Area Networks (MAN and WAN). The architecture model fits the Service Provider business model well and both are well-known services and have been deployed widely in Service Provider networks. The NVO3 is driven by DC operators for a quicker and easier constructing a tenant IT application in a Data Center. A tenant IT application requires the capability to form a virtual communication domain for a highly distributed closed user groups. The NVO3 has some common characteristics as VPN's such as virtualization and encapsulation but also has some unique characteristics such as 1) the same hardware for both switching and end-systems; 2) end-system mobility. In addition, DC operator aims on NVO3 potentials for supporting a new IT application. From the operation perspective, the NVO3 aims that the virtual hosts and NVE are managed by the same orchestration system and the underlying network is decoupled from the overlay network and may be managed by a different orchestration system. However, in the VPN operation model, PE and P, i.e. the VPNs and underlying networks, are managed by the same operators; CEs at the customer sites are managed by different operators and two have the provider-customer relationship. Furthermore, the creation and remove NVE and VM placement and move in NVO3 could be very dynamic compared to the creation of a VPN on a PE. Thus, NVO3 needs a better auto provisioning software than the command-line interface for the provisioning. These distinct areas are significant enough for people to further study if we should develop a brand new technology for NVO3 or may evolve the VPN technologies for it and trade-offs in each. Note that any new IT application may also require WAN VPN technology enhancement at the same time anyway. For example, the VM mobility across DCs also requires the VPN on a WAN network to support that properly. Yong & Hares Expires April 21, 2013 [Page 12] Internet-Draft NVO3 and VPN Gap October 2012 It is important for DC operators and SP operators as well as the people from vendors to work together on the NVO3 solution. It would be ideal to make the future virtual and overlay networking technology seamlessly work in DC, WANs, and wireless networks. 7. Security Considerations The VPN protocol solutions provide the security capability for a customer and allow many VPN running on one common network infrastructure. However, the VPN does not have much way to protect the infrastructure network attacked by the VPN traffic except the rate limit at the PE. This approach may not apply to NVO3 due to the VM dynamical placement and move. If the underlying network uses IP network and NVO3 uses GRE or IP Tunnel, it makes the security more challenge because of heavy filtering process [RFC4365]. 8. IANA Considerations The document does not require any IANA action. 9. Acknowledgments Authors like to thanks Aldrin Isaac, Ivan Pepeinjak, Yakov Rekhter, John Drake, Joe Halpern, and others on mailing list for their valuable input. 10. References 10.1. Normative References [RFC4364] Rosen, E. and Rekhter, Y., "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC4364, February 2006. [RFC4365] Rosen, E. "Applicability Statement for BGP/MPLS IP Virtual Private Network (VPNs)", RFC4365, February 2006. [RFC4379] Kompella, K. and Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC4379, February 2006 [RFC4448] Martini, L., etc, "Encapsulation Methods for Transport Ethernet over MPLS networks", RFC4448, April 2006 Yong & Hares Expires April 21, 2013 [Page 13] Internet-Draft NVO3 and VPN Gap October 2012 [RFC4577] Rosen, E., Psenak, P., and Pillay-Esnault, P., "OSPF as the Provider/Customer Edge Protocol for BGP/MPLS IP Virtual Private Network (VPNs)", RFC4577, Jun 2006 [RFC4664] Andersson, L., "Framework for Layer 2 Virtual Private Networks (L2VPNs)", RFC4664, September 2006 [RFC4761] Kompella, K. and Rekhter, Y., "virtual Private LAN Services (VPLS) Using BGP for Auto-Discovery and Signaling", RFC4761, January 2007 [RFC4762] Lasserre, M. and Kompella, V., "Virtual Private LAN Service (VPLS) Using Label Distribution Protocol (LDP) Signaling", RFC4762, January 2007 [RFC4797] Rekhter, Y., etc, "Use of Provider Edge to Provider Edge (PE-PE) Generic Routing Encapsulation (GRE) or IP in BGP/MPLS IP Virtual Private Networks", RFC4797, January 2007 [RFC5641] McGill, N., "Layer 2 Tunneling Protocol Version 3 (L2TPv3) Extended Circuit Status Values", rfc5641, April 2009. [RFC6325] Perlman, R., Eastlake, D., and etc, "Routing Bridges (RBridges): Base Protocol Specification", RFC6325, July 2011 [RFC6329] Fedyk, D., etc, "IS-IS Extension Supporting IEEE 802.1aq Shorest Path Bridging", RFC6329, April 2012 [PBB] "Standard for Local and Metropolitan Area Networks / Virtual Bridged Local Area Networks / Amendment 7: Provider Backbone Bridges, IEEE STD 802.1ah", 2008. 10.2. Informative Reference [DCBGP] Lapukhov, P., and Premji, A.,, "Using BGP for Routing in Large-Scale Data Centers", draft-lapukhov-bgp-routing- large-dc-02, August 2012 [ESYS] Marques,P., "End-System support for BGP-signaled IP/VPNs", draft-marques-l3vpn-end-system-07, August 2012 [EVPN] Sajassi, A.,"BGP MPLS Based Ethernet VPN", draft-ietf-l2vpn- evpn-01, July 2012 Yong & Hares Expires April 21, 2013 [Page 14] Internet-Draft NVO3 and VPN Gap October 2012 [ISSUES] Rekhter, Y., "Network-related VM Mobility Issues", draft- rekhter-nvo3-vm-mobility-issues-03, October 2012 [LISP] Maino, F., etc "LISP Control Plane for Network Virtualization Overlays", draft-maino-nvo3-lisp-cp-01, September 2012 [NVO3PRBM] Narten, T., etc "Problem Statement: Overlays for Network Virtualization", draft-narten-nvo3-overlay-problem- statement-04, August 2012 [NVO3FRWK] Lasserre, M., Motin, T., and etc, "Framework for DC Network Virtualization", draft-lasserre-nvo3-framework-03, July 2012 [NVO3UCASE] Yong, L., and etc, "Use Case for DC Network Virtualization Overlays", draft-mity-nvo3-use-case-03, August 2012 [ONF] Open Network Forum, "Open Flow 1.2", https://www.opennetworking.org/images/stories/downloads/sp ecification/openflow-spec-v1.2.pdf, Dec. 2011 [PBB-EVPN] Sajassi, A. et al. "PBB-EVPN", draft-sajassi-l2vpn-pbb- evpn-03., June 2012. [SPB-EVPN] Allan, D., etc, "802.1aq and 802.1Qbp Support over EVPN", draft-allan-l2vpn-spbm-evpn-01, July 2012 [TRILL-EVPN] Sajassi, A., etc, "TRILL-EVPN", draft-ietf-l2vpn-trill- evpn-00, June 20, 2012 [VRF-LITE] Cisco, "Configuring VRF-lite", http://www.cisco.com Yong & Hares Expires April 21, 2013 [Page 15] Internet-Draft NVO3 and VPN Gap October 2012 Authors' Addresses Lucy Yong Huawei Technologies (USA) 5340 Legacy Drive Plano, TX75025 Phone: +1-469-277-5873 Email: lucy.yong@huawei.com Susan Hares Huawei Technologies (USA) 2330 Central Expressway Santa Clara, CA 95050 Phone: +408-330-4581 Email: susan.hares@huawei.com Yong & Hares Expires April 21, 2013 [Page 16]