--- 1/draft-ietf-lisp-deployment-09.txt 2013-08-06 10:14:09.695988728 -0700 +++ 2/draft-ietf-lisp-deployment-10.txt 2013-08-06 10:14:09.747990045 -0700 @@ -1,98 +1,101 @@ Network Working Group L. Jakab Internet-Draft Cisco Systems -Intended status: Informational A. Cabellos-Aparicio -Expires: January 10, 2014 F. Coras +Intended status: Experimental A. Cabellos-Aparicio +Expires: February 7, 2014 F. Coras J. Domingo-Pascual Technical University of Catalonia D. Lewis Cisco Systems - July 9, 2013 + August 6, 2013 LISP Network Element Deployment Considerations - draft-ietf-lisp-deployment-09.txt + draft-ietf-lisp-deployment-10.txt Abstract - This document discusses the different scenarios for the deployment of - the new network elements introduced by the Locator/Identifier - Separation Protocol (LISP). + This document is a snapshot of different Locator/Identifier + Separation Protocol (LISP) deployment scenarios. It discusses the + placement of new network elements introduced by the protocol, + representing the thinking of the authors as of Summer 2013. LISP + deployment scenarios may have evolved since. This memo represents + one stable point in that evolution of understanding. 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 January 10, 2014. + This Internet-Draft will expire on February 7, 2014. Copyright Notice Copyright (c) 2013 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. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10 2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.3. Additional Notes . . . . . . . . . . . . . . . . . . . 11 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 3. Map Resolvers and Map Servers . . . . . . . . . . . . . . . . 12 3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 13 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 14 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 17 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 20 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 - 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 - 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 21 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Step-by-Step Example BGP to LISP Migration Procedure . . . . . . . . . . . . . . . . . . . . . . 22 A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22 - A.2. Customer Activating LISP Service . . . . . . . . . . . . . 23 - A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 24 + A.2. Customer Activating LISP Service . . . . . . . . . . . . . 24 + A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction The Locator/Identifier Separation Protocol (LISP) is designed to address the scaling issues of the global Internet routing system identified in [RFC4984] by separating the current addressing scheme into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The main protocol specification [RFC6830] describes how the separation is achieved, which new network elements are introduced, and details the @@ -125,20 +128,28 @@ guide for the operational community for LISP deployments in their networks. It is expected to evolve as LISP deployment progresses, and the described scenarios are better understood or new scenarios are discovered. Each subsection considers an element type, discussing the impact of deployment scenarios on the protocol specification. For definition of terms, please refer to the appropriate documents (as cited in the respective sections). + This experimental specification has areas that require additional + experience and measurement. It is NOT RECOMMENDED for deployment + beyond experimental situations. Results of experimentation may lead + to modifications and enhancements of protocol mechanisms defined in + this document. See Section 15 [of RFC 6830] for specific, known + issues that are in need of further work during development, + implementation, and experimentation. + 2. Tunnel Routers The device that is the gateway between the edge and the core is called a Tunnel Router (xTR), performing one or both of two separate functions: 1. Encapsulating packets originating from an end host to be transported over intermediary (transit) networks towards the other end-point of the communication @@ -247,33 +258,31 @@ The problem is aggravated when the LISP site is multihomed. Consider the scenario in Figure 2: whenever a change to TE policies is required, the customer contacts both ISP1 and ISP2 to make the necessary changes on the routers (if they provide this possibility). It is however unlikely, that both ISPs will apply changes simultaneously, which may lead to inconsistent state for the mappings of the LISP site. Since the different upstream ISPs are usually competing business entities, the ETRs may even be configured to compete, either to attract all the traffic or to get no traffic. The former will happen if the customer pays per volume, the latter if the - connectivity has a fixed price. A solution could be to have the - mappings in the Map Server(s), and have their operator give control - over the entries to customer, much like in the Domain Name System at - the time of this writing. + connectivity has a fixed price. A solution could be to configure the + Map Server(s) to do proxy-replying and have the Mapping Service + Provider (MSP) apply policies. Additionally, since xTR1, xTR2, and xTR3 are in different administrative domains, locator reachability information is unlikely to be exchanged among them, making it difficult to set Loc-Status- Bits (LSB) correctly on encapsulated packets. Because of this, and due to the security concerns about LSB described in - [I-D.ietf-lisp-threats] their use is discouraged without verifying - ETR reachability through the mapping system or other means. Mapping - versioning is another alternative [RFC6834]. + [I-D.ietf-lisp-threats] their use is discouraged (set the L-bit to + 0). Mapping versioning is another alternative [RFC6834]. Compared to the customer edge scenario, deploying LISP at the provider edge might have the advantage of diminishing potential MTU issues, because the tunnel router is closer to the core, where links typically have higher MTUs than edge network links. 2.3. Split ITR/ETR In a simple LISP deployment, xTRs are located at the border of the LISP site (see Section 2.1). In this scenario packets are routed @@ -311,24 +320,24 @@ | +-------+ | +-------+ +-------+ | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | | +-------+ +-------+ +-------+ | | +---------------------------------------+ Figure 3: Split ITR/ETR Scenario This scenario has a set of implications: - o The site must carry at least partial BGP routes in order to choose - the best egress point, increasing the complexity of the network. - However, this is usually already the case for LISP sites that - would benefit from this scenario. + o The site must carry more specific routes in order to choose the + best egress point, and typically BGP is used for this, increasing + the complexity of the network. However, this is usually already + the case for LISP sites that would benefit from this scenario. o If the site is multihomed to different ISPs and any of the upstream ISPs are doing uRPF filtering, this scenario may become impractical. ITRs need to determine the exit ETR, for setting the correct source RLOC in the encapsulation header. This adds complexity and reliability concerns. o In LISP, ITRs set the reachability bits when encapsulating data packets. Hence, ITRs need a mechanism to be aware of the liveness of all ETRs serving their site. @@ -362,26 +371,27 @@ increases DFZ table size. Typically, LISP is seen applicable only to stub networks, however the LISP protocol can be also applied in a recursive manner, providing service provider ingress/egress TE capabilities without impacting the DFZ table size. In order to implement this functionality with LISP consider the scenario depicted in Figure 4. The two ISPs willing to achieve ingress/egress TE are labeled as ISP_A and ISP_B, they are servicing - Stub1 and Stub2 respectively, both are required to be LISP sites. In - this scenario we assume that Stub1 and Stub2 are communicating and - thus, ISP_A and ISP_B offer transit for such communications. ISP_A - has RLOC_A1 and RLOC_A2 as upstream IP addresses while ISP_B has - RLOC_B1 and RLOC_B2. The shared goal among ISP_A and ISP_B is to - control the transit traffic flow between RLOC_A1/A2 and RLOC_B1/B2. + Stub1 and Stub2 respectively, both are required to be LISP sites with + their own xTRs. In this scenario we assume that Stub1 and Stub2 are + communicating with each other and thus, ISP_A and ISP_B offer transit + for such communications. ISP_A has RLOC_A1 and RLOC_A2 as upstream + IP addresses while ISP_B has RLOC_B1 and RLOC_B2. The shared goal + among ISP_A and ISP_B is to control the transit traffic flow between + RLOC_A1/A2 and RLOC_B1/B2. _.--. Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2 \ | R_A1|----,' `. ---|R_B1 | / --| | ( Transit ) | |-- ... .../ | R_A2|-----. ,' ---|R_B2 | \... ... +-------+ `--. _.-' +-------+ ... ... ISP_A `--'' ISP_B ... ... Figure 4: Inter-Service provider TE scenario @@ -389,43 +399,44 @@ Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively and reach a bilateral agreement to deploy their own private mapping system. This mapping system contains bindings between the RLOCs of Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and RLOC_A1/A2 and RLOC_B1/B2. Such bindings are in fact the TE policies between both ISPs and the convergence time is expected to be fast, since ISPs only have to update/query a mapping to/from the database. The packet flow is as follows. First, a packet originated at Stub1 towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A - reencapsulates it and, according to the TE policies stored in the - private mapping system, the ISP_A xTR chooses RLOC_B1 or RLOC_B2 as - the reencapsulation destination. Note that the packet transits - between ISP_A and ISP_B double-encapsulated. Upon reception at the - xTR of ISP_B the packet is decapsulated and sent towards Stub2 which - performs the last decapsulation. + recursively encapsulates it and, according to the TE policies stored + in the private mapping system, the ISP_A xTR chooses RLOC_B1 or + RLOC_B2 as the outer encapsulation destination. Note that the packet + transits between ISP_A and ISP_B double-encapsulated. Upon reception + at the xTR of ISP_B the packet is decapsulated and sent towards Stub2 + which performs the last decapsulation. This deployment scenario, which uses recursive LISP, includes two important caveats. First, it is intended to be deployed between only two ISPs. If more than two ISPs use this approach, then the xTRs deployed at the participating ISPs must either query multiple mapping systems, or the ISPs must agree on a common shared mapping system. Furthemore, keeping this deployment scenario restricted to only two ISPs maintains the solution scalable, given that only two entities need to agree on using recursive LISP, and only one private mapping system is involved. Second, the scenario is only recommended for ISPs providing connectivity to LISP sites, such that source RLOCs of packets to be - reencapsulated belong to said ISP. Otherwise the participating ISPs - must register prefixes they do not own in the above mentioned private - mapping system. Failure to follow these recommendations may lead to - operational and security issues when deploying this scenario. + recursively encapsulated belong to said ISP. Otherwise the + participating ISPs must register prefixes they do not own in the + above mentioned private mapping system. Failure to follow these + recommendations may lead to operational and security issues when + deploying this scenario. Besides these recommendations, the main disadvantages of this deployment case are: o Extra LISP header is needed. This increases the packet size and requires that the MTU between both ISPs accommodates double- encapsulated packets. o The ISP ITR must encapsulate packets and therefore must know the RLOC-to-RLOC binding. These bindings are stored in a mapping @@ -564,35 +575,35 @@ of their covering prefixes. The only exception are the ITRs that already contain the mappings in their local cache. In this case ITRs can reach ETRs until the entry expires (typically 24 hours). For this reason, redundant Map Server deployments are desirable. A set of Map Servers providing high-availability service to the same set of prefixes is called a redundancy group. ETRs are configured to send Map-Register messages to all Map Servers in the redundancy group. The configuration for fail-over (or load-balancing, if desired) among the members of the group depends on the technology behind the mapping system being deployed. Since ALT is based on BGP and DDT was - inspired from DNS, deployments can leverage current industry best - practices for redundancy in BGP and DNS. These best practices are - out of the scope of this document. + inspired from the Domain Name System (DNS), deployments can leverage + current industry best practices for redundancy in BGP and DNS. These + best practices are out of the scope of this document. Additionally, if a Map Server has no reachability for any ETR serving a given EID block, it should not originate that block into the mapping system. 3.2. Map Resolvers A Map Resolver is a network infrastructure component which accepts LISP encapsulated Map-Requests, typically from an ITR, and finds the - appropriate EID-to-RLOC mapping by either consulting its local cache - or by consulting the distributed mapping database. Map Resolver - functionality is described in detail in [RFC6833]. + appropriate EID-to-RLOC mapping by consulting the distributed mapping + database. Map Resolver functionality is described in detail in + [RFC6833]. Anyone with access to the distributed mapping database can set up a Map Resolver and provide EID-to-RLOC mapping lookup service. Database access setup is mapping system specific. For performance reasons, it is recommended that LISP sites use Map Resolvers that are topologically close to their ITRs. ISPs supporting LISP will provide this service to their customers, possibly restricting access to their user base. LISP sites not in this position can use open access Map Resolvers, if available. @@ -890,20 +901,35 @@ decrease for existing ones. Moreover, MSPs serving different clients with adjacent aggregatable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study. The flexibility and scalability of this architecture does not come without a cost however: A PSP operator has to establish either transit or peering relationships to improve their connectivity. 5.4. Migration Summary + Registering a domain name typically entails an annual fee that should + cover the operating expenses for publishing the domain in the global + DNS. The situation is similar with several other registration + services. A LISP mapping service provider (MSR) client publishing an + EID prefix in the LISP mapping system has the option of signing up + for PITR services as well, for an extra fee. These services may be + offered by the MSP itself, but it is expected that specialized P-ITR + service providers (PSPs) will do it. Clients not signing up become + responsible for getting non-LISP traffic to their EIDs (using the + LISP+BGP scenario). + + Additionally, Tier 1 ISPs have incentives to offer P-ITR services to + non-subscribers in strategic places just to attract more traffic from + competitors, thus more revenue. + The following table presents the expected effects of the different transition scenarios during a certain phase on the DFZ routing table size: Phase | LISP+BGP | MSP P-ITR | PITR-RD -----------------+--------------+-----------------+---------------- Early transition | no change | slower increase | slower increase Late transition | may decrease | slower increase | slower increase LISP Internet | considerable decrease