LISP S. Freitas Internet-Draft P. Bellagamba Intended status: Informational Y. Hertoghs Expires: August 16, 2014 Cisco Systems February 12, 2014 Using LISP for Secure Hybrid Cloud Extension draft-freitas-bellagamba-lisp-hybrid-cloud-usecase-00 Abstract The purpose of this draft is to document how the Locator/Identifier Separation Protocol (LISP) can be used to enable a secure layer 3-based Hybrid Cloud, which is a composition of two or more distinct cloud infrastructures that remain unique entities, but are bound together to enable data and application portability. It describes how LISP, in combination with IPsec, can be implemented on a virtualized router that is deployed on a public cloud and on the enterprise Data Center to enable cloud bursting, workload migration, rapid provision of new applications in the cloud and disaster recovery use cases. This draft covers how LISP allows virtual machines (VMs) to be moved to the cloud without requiring changes to the VMs IP and/or MAC-address. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 16, 2014. Freitas, et al. Expires August 16, 2014 [Page 1] Internet-Draft LISP Hybrid Cloud Use Case February 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. LISP-Enabled Secure Hybrid Cloud Diagram . . . . . . . . . . 4 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Deploying LISP for Secure Hybrid Cloud Extension . . . . . . 6 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 7 5.1. Requirements on the underlying network . . . . . . . . . 7 5.2. Routing Considerations . . . . . . . . . . . . . . . . . 8 5.2.1. RLOC Advertisement . . . . . . . . . . . . . . . . . 8 5.2.2. LISP Stretched Subnets Advertisement . . . . . . . . 8 5.2.3. Traffic symmetry . . . . . . . . . . . . . . . . . . 8 5.3. No changes to Virtual or Physical Servers . . . . . . . . 8 5.4. Integration with other network services . . . . . . . . . 9 5.4.1. WAN acceleration . . . . . . . . . . . . . . . . . . 9 5.4.2. Firewalls . . . . . . . . . . . . . . . . . . . . . . 9 6. Communication (flow) examples . . . . . . . . . . . . . . . . 9 6.1. LISP-enabled Intra subnet communication between the Enterprise and the Cloud . . . . . . . . . . . . . . . . 10 6.2. Communication from non-LISP Enabled Remote Sites to the Enterprise and to the Cloud . . . . . . . . . . . . . . . 10 6.3. Communication from enterprise local LISP enabled subnet to the Cloud LISP enabled subnet . . . . . . . . . . . . 11 6.4. Communication from enterprise local non-LISP enabled subnet to the cloud LISP enabled subnet . . . . . . . . . 11 6.5. Communication from LISP Enabled Subnets to non-LISP Enabled Subnets . . . . . . . . . . . . . . . . . . . . . 11 6.6. Communication between non-LISP enabled subnets . . . . . 11 6.7. Inter-Subnet communication between servers in the Cloud . 11 6.8. Communication from LISP Enabled Remote Sites to the Enterprise and to the Cloud . . . . . . . . . . . . . . . 11 7. Performance and Scalability Considerations . . . . . . . . . 12 8. Management and Automation Considerations . . . . . . . . . . 12 Freitas, et al. Expires August 16, 2014 [Page 2] Internet-Draft LISP Hybrid Cloud Use Case February 2014 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.2. Informative References . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 1. Introduction Many enterprises are pursuing an hybrid cloud computing strategy within the next three years. Some of the use cases for Hybrid Cloud are automated on-demand compute capacity (cloud bursting), split application architectures, workload migration, rapid provision of new applications in the cloud, and disaster recovery. One common requirement from enterprises that wish to move to a Hybrid Cloud is the ability to migrate the servers to the Cloud without making any changes to them. In particular, server administrators would like to avoid changing the server's IP address, subnet mask and default gateway configurations. Also, enterprises would like to adopt their own IP addressing scheme in the cloud and not been limited by the addressing scheme of the cloud provider infrastructure. Locator/Identifier Separation Protocol (LISP) [RFC6830] can be used to address those requirements. LISP separates location and identity, thus allowing the enterprise to migrate or create new servers on the cloud with the same IP address (server's identity), subnet mask, and default gateway configurations then the one used inside their own private data centers. LISP will update the EID-to-RLOC mapping of the server to reflect the new location that, in this this example, is moved to the cloud. No changes are required to the end systems, users or servers, as the mapping between identity (server's IP address) and location (enterprise DC or public cloud) is handled by LISP, transparently to the users trying to reach the server. LISP operates as an overlay, encapsulating the original packet from the server into an UDP packet along with an additional outer IPvN header, which holds the source and destination RLOCs. This allows the server administrators to address the server in the cloud according to their own IP addressing scheme, independent of the cloud provider's addressing structure. Another important property of LISP that is relevant to enable a Secure Hybrid Cloud extension is that it enables IP portability to the cloud by routing (layer 3) to the right location where the server Freitas, et al. Expires August 16, 2014 [Page 3] Internet-Draft LISP Hybrid Cloud Use Case February 2014 is. This provides total isolation of broadcast (Layer 2) domains between the Enterprise and the Public Cloud. Non-LISP enabled sites communicates to the servers moved to the cloud via the enterprise data center (DC), where LISP is also deployed. The solution proposed in this draft does not require LISP to be enabled globally, but can be deployed by enabling LISP on just the enterprise DC and the public cloud, with minimal impact on the operations of both the DC and the cloud. The optional deployment of LISP at individual user's site, provides data path optimization, as the LISP-encapsulated traffic is routed directly to the public cloud or the DC, depending on the server location. The LISP service is provided in the network, to any virtual machine, independently of the hypervisor type used in the enterprise or the public cloud provider. In fact, the hypervisor type used on the enterprise and on the cloud infrastructure can be different. LISP works with any VM in the public cloud without the need to modify the VM configuration before migration. LISP is deployed in virtualized routers in the cloud, and can be deployed in either physical or virtual router in the enterprise DC. The LISP-enabled router deployed within the enterprise DC does not need to be the default gateway for the local servers (physical and VMs). The communication between the LISP-enabled router deployed within the enterprise DC and within the public cloud SHOULD be secured by an IPsec (Internet Protocol Security (IPsec)) tunnel. LISP encapsulated traffic is protected with an IPsec tunnel, that can provide data origin authentication, integrity protection, anti-reply protection and confidentiality between the cloud and the enterprise. The LISP-enabled Hybrid Cloud solution allows Intra-Subnet communication regardless of the location of the server. This means that communication between two servers located on the same subnet can happen even when one server is located at the enterprise DC and another server is located at the cloud. Inter-subnet communication is also supported. 2. LISP-Enabled Secure Hybrid Cloud Diagram This diagram illustrates the use case described in this draft. Freitas, et al. Expires August 16, 2014 [Page 4] Internet-Draft LISP Hybrid Cloud Use Case February 2014 Users' end-devices, typically located at non-LISP sites, are connected to the enterprise WAN to access servers located either at the enterprise DC or at the public cloud. The enterprise DC hosts some of the servers, and has a PxTR deployed attached to the subnets which host mobile servers. The PxTR (PxTR-1) deployed within the enterprise DC is configured with an IPsec tunnel towards the cloud's xTR (xTR-2). Some servers have been moved to the cloud and an xTR is deployed within the cloud to allow IP mobility between the enterprise DC and the public cloud. Enterprise DC Public Cloud |---------------------| |--------------------| | | .--..--. .--. .. | | | | ( ' '.--. | | | | .-.' Internet ' | | | Server -------PxTR-1|===(=====IPsec Tunnel=====)===|== ====xTR-2 --VM 1 | | A | | ( '-' | | | | | (._.'--'._.'.-._.'.-._) |--------------------| | Server -- Router 2 | | B |\ .--..--. .--. .. |---------------------| \ ( ' '.--. .-.' L3 ' ( Underlay ) ( (WAN) '-' ._.'--'._.'.-._.'.-._) // +---+---+ .--.-.|Router1|'.-. ( +---+---+ ) ( __. ..' Non-LISP Site ) ( .'-' '--'._.'. )\ / '--' \ '--------' '--------' : End : : End : : Device : : Device : : 1 : : 2 : '--------' '--------' Figure 1 Freitas, et al. Expires August 16, 2014 [Page 5] Internet-Draft LISP Hybrid Cloud Use Case February 2014 3. Terminology Hybrid Cloud = A composition of two or more clouds (private, community or public) that remain unique entities but are bound together, offering the benefits of multiple deployment models. LISP-enabled virtualized router = A virtual machine / appliance that supports Routing and LISP functions, including Host Mobility. The terms Ingress Tunnel Router (ITR) and Egress Tunnel Router (ETR) are defined in [RFC6830] The terms Proxy-ITR (PITR) and Proxy-ETR (PETR) are defined in [RFC6832] 4. Deploying LISP for Secure Hybrid Cloud Extension As represented in Figure 1, LISP routers are deployed at both the enterprise DC (PxTR-1) and the public cloud (xTR-2). At the enterprise DC, PxTR-1 does not need to be the default gateway for the local servers (physical and VMs), but it MUST be directly connected to the subnet where IP mobility will be provided. PxTR-1 MUST have an interface (physical or virtual sub-interface) connected to the same subnet of the servers that are eligible for moving. This allows the LISP router to detect the servers and to provide IP mobility for this subnet. PxTR-1 can detect server's EIDs by various way, including listening to ARPs that may be sent by the servers, for example during boot up time, or by initiating traffic (ICMP requests) to the servers. PxTR-1 MUST perform both proxy-itr and proxy-etr functions, so that non- LISP enabled sites can reach the servers moved to the cloud via the enterprise data center. Since PxTR-1 is not the default gateway and is not on the regular data path (i.e. the data path before there is any migration to the cloud), we refer to the deployment of LISP in the enterprise DC as non-intrusive. To redirect traffic from the enterprise data center to the cloud, the PxTR utilizes Proxy-ARP for both Intra-Subnet and Inter-Subnet communication. The map-resolver (MR) and map-server (MS) functions can be enabled on either PxTR-1 in the enterprise DC, or xTR-2 running within the cloud. By enabling the MS/MR functions on one of the LISP routers used to provide the hybrid cloud extension, the solution can be deployed without adding other infrastructure at the cloud provider or at the enterprise. Within the cloud, the LISP-enabled virtualized router (xTR-2) MUST be the default gateway for the Virtual Machines on those subnets that Freitas, et al. Expires August 16, 2014 [Page 6] Internet-Draft LISP Hybrid Cloud Use Case February 2014 require IP mobility. xTR-2 MUST be configured as a LISP ITR and ETR node so that it can perform LISP encapsulation and de-encapsulation of the packets coming from or going to the VMs located within the cloud. Whenever a route to the destination is not found on xTR-2 routing table, xTR-2 must route that traffic via PxTR-1 (at the enterprise DC). This function is useful to ensure that the traffic flow is symmetric between non-LISP enabled sites and the cloud, and MUST be used when there are firewalls or other stateful devices located at the enterprise data center. xTR-2, being the default gateway on the cloud, can detect servers' EIDs (Endpoint IDentifiers) by listening to ARPs that may be sent by the server themselves. For example during boot up time, or whenever the host needs to communicate outside its subnet, because the host will ARP or send the packet towards its default gateway xTR-2. To support Intra-subnet communication between the cloud and the enterprise, xTR-2 attracts traffic local to the cloud using proxy-arp. Whenever a VM on the cloud ARPs for another IP located on the same subnet, the xTR will respond to this ARP request (proxy-arp) unless it has detected that the EID is local to the cloud . 5. Deployment Considerations This section will cover what needs to be considered for a successful deployment of a LISP-Enabled Secure Hybrid Cloud. 5.1. Requirements on the underlying network The network at the enterprise DC and the network within the cloud MUST allow the flooding of ARP packets within the subnets (i.e. VLAN, or similar Layer 2 technologies) where IP mobility is required. The reason for this requirement is that the xTR deployed within the cloud or the PxTR deployed within the enterprise DC uses Proxy-ARP to attract traffic to themselves to enable intra-subnet communication. For example, when a server within the enterprise DC wants to communicate with a server that is located within the cloud within the same subnet, the server within the enterprise DC will ARP for the IP address of the server that has moved to the cloud, in this case this ARP request MUST be flooded on the broadcast domain (i.e. VLAN) such that the LISP enabled router within the enterprise DC can respond to this request with its own MAC (proxy-ARP) so that traffic to a server moved to the cloud is then sent to the router located within the enterprise DC which then performs LISP encapsulation and send the traffic to the RLOC of the xTR located on the cloud. The same process happens on the reverse direction when traffic is returned from the cloud to the enterprise DC. Freitas, et al. Expires August 16, 2014 [Page 7] Internet-Draft LISP Hybrid Cloud Use Case February 2014 5.2. Routing Considerations Deploying LISP for Secure Hybrid Cloud extension requires routing considerations related with: (1) RLOC advertisement, (2) advertisement of LISP enabled subnets to enable communication from non-LISP sites, and (3) traffic symmetry. 5.2.1. RLOC Advertisement The RLOCs used on the LISP enabled routers at the enterprise DC and at the cloud MUST be reciprocally reachable via the IPsec tunnel that connects the enterprise DC to the cloud. Those RLOCs SHOULD belong to the private IP address space controlled by the enterprise. This keeps the LISP deployment independent from both the cloud and the enterprise infrastructures. Reachability information for those RLOCs SHOULD be announced via the dynamic routing protocol of choice (IGP or EGP) used on top of the IPsec tunnel connecting the enterprise to the cloud. In alternative, if preferred, static routing COULD be used as well. 5.2.2. LISP Stretched Subnets Advertisement The subnets that are going to be stretched from the enterprise to the cloud already exist within the enterprise data center. Those subnets SHOULD already be advertised towards the enterprise WAN by the existing routing protocol. This ensures that non-LISP remote sites have a route to the LISP-enabled subnets via the enterprise data center, where PxTR-1 attracts all the traffic directed to the subnets that have been "stretched" to the cloud. 5.2.3. Traffic symmetry For the cases where there are stateful devices (i.e. Firewalls, Load balancers) located within the enterprise data center, traffic symmetry is mandatory. To achieve that, as described in the LISP Stretched Subnets Advertisement section, traffic is first attracted to the enterprise and then tunneled to the cloud. On the return from the cloud, the iTR MUST ensures that the traffic towards non-LISP sites is first returned to the PeTR at the enterprise DC. 5.3. No changes to Virtual or Physical Servers The network-based solution described in this draft, deployed with LISP routers at the enterprise DC and at the cloud, does not require changes to the servers (physical or virtual). Neither to those that are eligible for mobility, nor to those that are not eligible for mobility. Freitas, et al. Expires August 16, 2014 [Page 8] Internet-Draft LISP Hybrid Cloud Use Case February 2014 5.4. Integration with other network services Although not the focus of this draft, it's important to consider that enterprises may have some network services, like firewalls or WAN acceleration devices that SHOULD be integrated as part of a holistic Hybrid Cloud solution. LISP SHOULD not prevent the integration of such services. 5.4.1. WAN acceleration It may be desirable by an enterprise to accelerate traffic from the enterprise DC to the cloud. WAN acceleration SHOULD happen before the traffic is LISP and IPsec encapsulated. Defining all the options for how the WAN acceleration device is inserted within the traffic flow is outside the scope of this draft. However, one approach that may be supported by the routers used on the enterprise and on the cloud, is to have the LISP-enabled router redirect the traffic to the WAN acceleration device(s) before the traffic is LISP and IPsec encapsulated. 5.4.2. Firewalls Within enterprise data centers, firewalls can be implemented at several points of the network. The section "Traffic Symmetry" covers how this solution works when there are firewalls located within the enterprise data center. At the cloud, the LISP-enabled virtualized router (xTR-2 in Figure 1) is the default gateway for the servers VMs. In order to simplify the deployment xTR-2 SHOULD also function as a firewall for the servers located at the cloud. xTR-2 SHOULD secure communication between subnets located at the cloud, and communication from the cloud to the enterprise or the Internet. 6. Communication (flow) examples This section will explain the detailed communication flows referring to the diagram shown in Figure 1 PxTR-1, at the enterprise LISP site, is placed "on a stick", meaning that it does not need to be the default gateway, and its interaction with the local infrastructure is based on Proxy-ARP. PxTR-1 proxy- replies on behalf of all non-local servers, inserting its own MAC address for any EID that is not locally detected. PxTR-1 can be either a physical router, or a virtual appliance. To be able to manage not only locally sourced traffic, but also traffic coming from the WAN, PxTR -1 is enabled as a PiTR. To be able to receive back traffic from the cloud and deliver it to the WAN, PxTR-1 is also set- Freitas, et al. Expires August 16, 2014 [Page 9] Internet-Draft LISP Hybrid Cloud Use Case February 2014 up as a PeTR. In summary this node is a PxTR regarding its role for handling LISP traffic. At the Cloud LISP site, xTR-2 is a standard xTR for the locally attached subnets. xTR-2 is the default gateway for the extended subnets. xTR-2 is playing the role of eTR for the flow coming from the enterprise site, and acts as an iTR for the flow going back to the enterprise site. For any destination that is not known by the xTR, the iTR encapsulates the traffic to the RLOC of the PeTR specified, in this case the PeTR specified is PxTR-1 deployed at the enterprise site. 6.1. LISP-enabled Intra subnet communication between the Enterprise and the Cloud Server A at the enterprise site sends an ARP request for the IP address of VM-1 that it wants to communicate with, in order to find the MAC address. PxTR-1, which is on a stick, replies with its own MAC address (proxy-arp) as VM-1 is not detected locally. Traffic is then sent to PxTR-1, after which it will issue a Map-Request to the MS to find the location of VM-1. Finally it will encapsulate the traffic towards xTR-2 at the Cloud site as VM-1 is identified in the Map-server as belonging to that site. Traffic is then delivered towards the cloud-attached subnet. On the return path, the flow is handled in a symmetrical reverse way compared to the inbound one just described above. 6.2. Communication from non-LISP Enabled Remote Sites to the Enterprise and to the Cloud Traffic from End Device 1 or 2, which are located at a remote site that is not LISP enabled, is naturally attracted toward the enterprise DC by IP routing. Whenever reaching the Enterprise site, it is crossing the site's security and other services to reach the local subnet that is supposed to host the destination server VM-1. When the local default gateway sends an ARP to find VM-1, PxTR-1 responds to this ARP using the Proxy-ARP function as described above. Traffic is sent LISP-encapsulated to the Cloud site where it is delivered to VM-1. xTR-2, which is the default gateway for VM-1, handles the return traffic that is sent by VM-1. As this traffic is not intended to a LISP site, (i.e.it is targeted to End Device 1 or 2), xTR-2 sends the traffic to the PeTR configured on it (PxTR-1). Freitas, et al. Expires August 16, 2014 [Page 10] Internet-Draft LISP Hybrid Cloud Use Case February 2014 6.3. Communication from enterprise local LISP enabled subnet to the Cloud LISP enabled subnet Traffic originated from a LISP enabled subnet (from Server B), intended to another LISP enabled subnet extended to the cloud (to VM-1) will first reach the local gateway (Router 2) and then will be routed locally to the extended subnet where PxTR-1 will respond to the ARP issued by Router 2. On the return path, the traffic will hit xTR-2, which is the default gateway, and then be routed by LISP towards the Enterprise site. 6.4. Communication from enterprise local non-LISP enabled subnet to the cloud LISP enabled subnet In this case, traffic will first reach the default gateway (Router 2), from which it will follow the same path than the traffic originated from a remote site. The PxTR function will be used in both directions. 6.5. Communication from LISP Enabled Subnets to non-LISP Enabled Subnets When traffic is sourced from a LISP enabled subnet at the enterprise site (Server A or B) towards a non-LISP enabled subnet at the cloud site, standard routing will take effect. For the return traffic, xTR-2 will send it back to PxTR-1 as LISP encapsulated traffic. 6.6. Communication between non-LISP enabled subnets In this case, the traffic will be routed using plain IP routing and LISP is not involved. The return traffic also uses plain IP routing, and LISP is not involved. 6.7. Inter-Subnet communication between servers in the Cloud In the cloud itself, xTR-2 can locally route traffic between local subnets as it is the cloud site default gateway. 6.8. Communication from LISP Enabled Remote Sites to the Enterprise and to the Cloud All above considerations of traffic flows are assuming that the only LISP enabled devices are PxTR-1 and xTR-2. Freitas, et al. Expires August 16, 2014 [Page 11] Internet-Draft LISP Hybrid Cloud Use Case February 2014 If one remote site need to access directly a non-LISP enabled resource in the cloud, meaning a subnet that is strictly local to the cloud, then pure routing can be used. If a remote site needs path optimization to directly reach the servers that are part of a LISP stretched subnet at the cloud site, LISP can be enabled on this remote site. An xTR deployed on this remote site would consult the map-server to receive the correct location of the server. 7. Performance and Scalability Considerations TBD. 8. Management and Automation Considerations TBD. 9. Acknowledgements The authors would like to thanks Michael Nolan and Fabio Maino for their review, and Fabio Maino for his encouragement to develop this draft. 10. IANA Considerations This memo includes no request to IANA. 11. Security Considerations The connection from the enterprise to the public cloud provider is usually done over the internet, although it may happen via a dedicated private circuit on some cases. This draft strongly suggests that an IPsec tunnel SHOULD be established between the enterprise and the cloud provider and that the data sent within this tunnel SHOULD be encrypted. The IPsec tunnel SHOULD be established between the LISP-enabled routers located on the enterprise and on the cloud. By establishing the IPsec tunnels and ensuring that the RLOC from the routers are reachable via those IPsec tunnels then the LISP encapsulated traffic between the enterprise and the cloud will also be encrypted as it will flow over the IPsec tunnels. Also see [I-D.ietf-lisp-sec] for a list of security considerations for LISP. Freitas, et al. Expires August 16, 2014 [Page 12] Internet-Draft LISP Hybrid Cloud Use Case February 2014 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 12.2. Informative References [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft- ietf-lisp-sec-05 (work in progress), October 2013. [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013. Authors' Addresses Santiago Freitas Cisco Systems New Square Park, Bedfont Lakes Feltham TW14 8HA UK Phone: +44 20 8824 8429 Email: safreita@cisco.com Patrice Bellagamba Cisco Systems L'Atlantis, 11, Rue Camille Desmoulins Issy Les Moulineaux 92782 France Phone: +33 15 804 6235 Email: pbellaga@cisco.com Freitas, et al. Expires August 16, 2014 [Page 13] Internet-Draft LISP Hybrid Cloud Use Case February 2014 Yves Hertoghs Cisco Systems De Kleetlaan 6a Diegem 1831 BE Email: yhertogh@cisco.com Freitas, et al. Expires August 16, 2014 [Page 14]