Internet Engineering Task Force (IETF) L. Jakab Request for Comments: 7215 Cisco Systems Category: Experimental A. Cabellos-Aparicio ISSN: 2070-1721 F. Coras J. Domingo-Pascual Technical University of Catalonia D. Lewis Cisco Systems April 2014 Locator/Identifier Separation Protocol (LISP) Network Element Deployment Considerations
AbstractThis 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 LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since then. This memo represents one stable point in that evolution of understanding. Status of This Memo This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation. This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7215.
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.
1. Introduction ....................................................3 2. Tunnel Routers ..................................................5 2.1. Deployment Scenarios .......................................5 2.1.1. Customer Edge (CE) ..................................5 2.1.2. Provider Edge (PE) ..................................6 2.1.3. Tunnel Routers behind NAT ...........................8 188.8.131.52. ITR ........................................8 184.108.40.206. ETR ........................................9 220.127.116.11. Additional Notes ...........................9 2.2. Functional Models with Tunnel Routers ......................9 2.2.1. Split ITR/ETR .......................................9 2.2.2. Inter-Service-Provider Traffic Engineering .........11 2.3. Summary and Feature Matrix ................................13 3. Map-Servers and Map-Resolvers ..................................14 3.1. Map-Servers ...............................................14 3.2. Map-Resolvers .............................................16 4. Proxy Tunnel Routers ...........................................17 4.1. PITRs .....................................................17 4.2. PETRs .....................................................18 5. Migration to LISP ..............................................19 5.1. LISP+BGP ..................................................19 5.2. Mapping Service Provider (MSP) PITR Service ...............20 5.3. Proxy-ITR Route Distribution (PITR-RD) ....................20 5.4. Migration Summary .........................................23 6. Security Considerations ........................................24 7. Acknowledgements ...............................................24 8. References .....................................................24 8.1. Normative References ......................................24 8.2. Informative References ....................................24 Appendix A. Step-by-Step Example BGP-to-LISP Migration Procedure ..26 A.1. Customer Pre-Install and Pre-Turn-Up Checklist .............26 A.2. Customer Activating LISP Service ...........................28 A.3. Cut-Over Provider Preparation and Changes ..................29 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 and which new network elements are introduced, and it details the packet formats for the data and control planes.
LISP assumes that such separation is between the edge and core and uses mapping and encapsulation for forwarding. While the boundary between both is not strictly defined, one widely accepted definition places it at the border routers of stub autonomous systems, which may carry a partial or complete default-free zone (DFZ) routing table. The initial design of LISP took this location as a baseline for protocol development. However, the applications of LISP go beyond just decreasing the size of the DFZ routing table and include improved multihoming and ingress traffic engineering (TE) support for edge networks, and even individual hosts. Throughout this document, we will use the term "LISP site" to refer to these networks/hosts behind a LISP Tunnel Router. We formally define the following two terms: Network element: Facility or equipment used in the provision of a communications service over the Internet [TELCO96]. LISP site: A single host or a set of network elements in an edge network under the administrative control of a single organization, delimited from other networks by LISP Tunnel Router(s). Since LISP is a protocol that can be used for different purposes, it is important to identify possible deployment scenarios and the additional requirements they may impose on the protocol specification and other protocols. Additionally, this document is intended as a 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 and discusses the impact of deployment scenarios on the protocol specification. For definitions of terms, please refer to the appropriate documents (as cited in the respective sections). This experimental document describes deployment considerations. These considerations and the LISP specifications have areas that require additional experience and measurement. LISP is not recommended for deployment beyond experimental situations. Results of experimentation may lead to modifications and enhancements of LISP mechanisms. Additionally, at the time of this writing there is no standardized security to implement. Beware that there are no countermeasures for any of the threats identified in [LISP-THREATS]. See Section 15 of [RFC6830] for specific known issues that are in need of further work during development, implementation, and experimentation, and see [LISP-THREATS] for recommendations to ameliorate the above-mentioned security threats.
Section 8 of the main LISP specification [RFC6830] has a short discussion of where Tunnel Routers can be deployed and some of the associated advantages and disadvantages. This section adds more detail to the scenarios presented there and provides additional scenarios as well. Furthermore, this section discusses functional models, that is, network functions that can be achieved by deploying Tunnel Routers in specific ways. ISP1 ISP2 | | | | +----+ +----+ +--|xTR1|--|xTR2|--+ | +----+ +----+ | | | | LISP site | +------------------+ Figure 1: xTRs at the Customer Edge
From the LISP site's perspective, the main advantage of this type of deployment (compared to the one described in the next section) is having direct control over its ingress traffic engineering. This makes it easy to set up and maintain active/active, active/backup, or more complex TE policies, adding ISPs and additional xTRs at will, without involving third parties. Being under the same administrative control, reachability information of all ETRs is easier to synchronize, because the necessary control traffic can be allowed between the locators of the ETRs. A correct synchronous global view of the reachability status is thus available, and the Locator-Status-Bits can be set correctly in the LISP data header of outgoing packets. By placing the Tunnel Router at the edge of the site, existing internal network configuration does not need to be modified. Firewall rules, router configurations, and address assignments inside the LISP site remain unchanged. This helps with incremental deployment and allows a quick upgrade path to LISP. For larger sites distributed in geographically diverse points of presence (PoPs) and having many external connections and complex internal topology, it may, however, make more sense to both encapsulate and decapsulate as soon as possible, to benefit from the information in the IGP to choose the best path. See Section 2.2.1 for a discussion of this scenario. Another thing to consider when placing Tunnel Routers is MTU issues. Encapsulation increases the amount of overhead associated with each packet. This added overhead decreases the effective end-to-end path MTU (unless fragmentation and reassembly are used). Some transit networks are known to provide larger MTU values than the typical value of 1500 bytes for popular access technologies used at end hosts (e.g., IEEE 802.3 and 802.11). However, placing the LISP router connecting to such a network at the customer edge could possibly bring up MTU issues, depending on the link type to the provider as opposed to the following scenario. See [RFC4459] for MTU considerations of tunneling protocols and how to mitigate potential issues. Still, even with these mitigations, path MTU issues are still possible.
large ISPs with many residential/business customers asking for LISP, this can lead to important savings, since there is no need to upgrade the software (or hardware, if that's the case) at each client's location. Instead, they can upgrade the software (or hardware) on a few PE routers serving the customers. This scenario is depicted in Figure 2. +----------+ +------------------+ | ISP1 | | ISP2 | | | | | | +----+ | | +----+ +----+ | +--|xTR1|--+ +--|xTR2|--|xTR3|--+ +----+ +----+ +----+ | | | | | | +--<[LISP site]>---+-------+ Figure 2: xTRs at the Provider Edge While this approach can make transition easy for customers and may be cheaper for providers, the LISP site loses one of the main benefits of LISP: ingress traffic engineering. Since the provider controls the ETRs, additional complexity would be needed to allow customers to modify their mapping entries. 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, to either attract all the traffic or 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 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 the Locator-Status-Bits (LSBs) correctly on encapsulated packets. Because of this, and due to the security concerns about LSBs as described in [LISP-THREATS], their use is discouraged (set the L-bit to 0). Map-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. _.--. _.--. ,-'' `--. +-------+ ,-'' `--. ' EID ` (Private) | NAT | (Public) ,' RLOC `. ( )---[ITR]---| |---------( ) . space ,' (Address) | Box |(Address) . space ,' `--. _.-' +-------+ `--. _.-' `--'' `--'' Figure 3: ITR behind NAT Packets encapsulated by an ITR are just UDP packets from a NAT device's point of view, and they are handled like any UDP packet; there are no additional requirements for LISP data packets. Map-Requests sent by an ITR, which create the state in the NAT table, have a different 5-tuple in the IP header than the Map-Reply generated by the authoritative ETR. Since the source address of this packet is different from the destination address of the request packet, no state will be matched in the NAT table and the packet will be dropped. To avoid this, the NAT device has to do the following: o Send all UDP packets with source port 4342, regardless of the destination port, to the RLOC of the ITR. The simplest way to achieve this is configuring 1:1 NAT mode from the external RLOC of the NAT device to the ITR's RLOC (called "DMZ" mode in consumer broadband routers). o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in the payload. This setup supports only a single ITR behind the NAT device.
_.--. _.--. ,-'' `--. +-------+ ,-'' `--. ' EID ` (Private) | NAT | (Public) ,' RLOC `. ( )---[ETR]---| |---------( ) . space ,' (Address) | Box |(Address) . space ,' `--. _.-' +-------+ `--. _.-' `--'' `--'' Figure 4: ETR behind NAT RFC6887]. We only include this scenario due to completeness, to show that a LISP site can be deployed behind NAT should it become necessary. However, LISP deployments behind NAT should be avoided, if possible. Section 2.1.1). In this scenario, packets are routed inside the domain according to the EID. However, more complex networks may want to route packets according to the destination RLOC. This would enable them to choose the best egress point.
The LISP specification separates the ITR and ETR functionality and allows both entities to be deployed in separated network equipment. ITRs can be deployed closer to the host (i.e., access routers). This way, packets are encapsulated as soon as possible, and egress point selection is driven by operational policy. In turn, ETRs can be deployed at the border routers of the network, and packets are decapsulated as soon as possible. Once decapsulated, packets are routed based on the destination EID according to internal routing policy. We can see an example in Figure 5. The Source (S) transmits packets using its EID, and in this particular case packets are encapsulated at ITR_1. The encapsulated packets are routed inside the domain according to the destination RLOC and can egress the network through the best point (i.e., closer to the RLOC's Autonomous System (AS)). On the other hand, inbound packets are received by ETR_1, which decapsulates them. Then, packets are routed towards S according to the EID, again following the best path. +---------------------------------------+ | | | +-------+ +-------+ +-------+ | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | | +-------+ | +-------+ +-------+ | +-+ | | | | |S| | IGP | | | +-+ | | | | +-------+ | +-------+ +-------+ | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | | +-------+ +-------+ +-------+ | | +---------------------------------------+ Figure 5: Split ITR/ETR Scenario This scenario has a set of implications: 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 unicast reverse path forwarding (uRPF) filtering, this scenario may become impractical. To set the correct source RLOC in the encapsulation header, ITRs need to first determine which ETR will be used by the outgoing packet. 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. o The MTU within the site network must be large enough to accommodate encapsulated packets. o In this scenario, each ITR is serving fewer hosts than in the case when it is deployed at the border of the network. It has been shown that the cache hit rate grows logarithmically with the amount of users [CACHE]. Taking this into account, when ITRs are deployed closer to the host the effectiveness of the mapping cache may be lower (i.e., the miss rate is higher). Another consequence of this is that the site may transmit a higher amount of Map-Requests, increasing the load on the distributed mapping database. o By placing the ITRs inside the site, they will still need global RLOCs. This may add complexity to intra-site routing configurations and more intra-site issues when there is a change of providers. Figure 6. 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 with their own xTRs. In this scenario, we assume that Stub1 and Stub2 are communicating with each other; 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 6: Inter-Service-Provider TE Scenario Both ISPs deploy xTRs 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 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 three important caveats. First, it is intended to be deployed between only two ISPs. If more than two ISPs use this approach, then either the xTRs deployed at the participating ISPs must query multiple mapping systems, or the ISPs must agree on a common shared mapping system. Furthermore, keeping this deployment scenario restricted to only two ISPs maintains a scalable solution, 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 recursively encapsulated belong to said ISP. Otherwise, the participating ISPs must register prefixes they do not own in the above-mentioned private mapping system. This results in either requiring complex authentication mechanisms or enabling simple traffic redirection attacks. Failure to follow these recommendations may lead to operational security issues when deploying this scenario. And third, recursive encapsulation models are typically complex to troubleshoot and debug.
Besides these recommendations, the main disadvantages of this deployment case are: o An extra LISP header is needed. This increases the packet size and requires that the MTU between both ISPs accommodate double- encapsulated packets. o The ISP ITR must encapsulate packets and therefore must know the RLOC-to-RLOC bindings. These bindings are stored in a mapping database and may be cached in the ITR's mapping cache. Cache misses lead to an additional lookup latency, unless a push-based mapping system is used for the private mapping system. o Maintaining the shared mapping database involves operational overhead.
The following table gives a quick overview of the features supported by each of the deployment scenarios discussed above (marked with an "x" in the appropriate column): "CE" for customer edge, "PE" for provider edge, "Split" for split ITR/ETR, and "Recursive" for inter-service-provider traffic engineering. The discussed features include: Control of ingress TE: This scenario allows the LISP site to easily control LISP ingress traffic engineering policies. No modifications to existing int. network infrastructure: This scenario doesn't require the LISP site to modify internal network configurations. Locator-Status-Bits sync: This scenario allows easy synchronization of the Locator Status Bits. MTU/PMTUD issues minimized: The scenario minimizes potential MTU and Path MTU Discovery (PMTUD) issues. Feature CE PE Split Recursive NAT -------------------------------------------------------------------- Control of ingress TE x - x x x No modifications to existing int. network infrastructure x x - - x Locator-Status-Bits sync x - x x - MTU/PMTUD issues minimized - x - - - RFC6833]. They are meant to be deployed in RLOC space, and their operation behind NAT is not supported. RFC6833].
The Map-Server is provided by a Mapping Service Provider (MSP). The MSP participates in the global distributed mapping database infrastructure by setting up connections to other participants according to the specific mapping system that is employed (e.g., Alternative Logical Topology (ALT) [RFC6836], Delegated Database Tree (DDT) [LISP-DDT]). Participation in the mapping database and the storing of EID-to-RLOC mapping data are subject to the policies of the "root" operators, who should check ownership rights for the EID-Prefixes stored in the database by participants. These policies are out of scope for this document. The LISP DDT protocol is used by LISP MSPs to provide reachability between those providers' Map-Resolvers and Map-Servers. The DDT root is currently operated by a collection of organizations on an open basis. See [DDT-ROOT] for more details. Similarly to the DNS root, it has several different server instances using names of the letters of the Greek alphabet (alpha, delta, etc.), operated by independent organizations. When this document was published, there were 6 such instances, with one of them being anycasted. [DDT-ROOT] provides the list of server instances on its web site and configuration files for several Map-Server implementations. The DDT root and LISP Mapping Providers both rely on and abide by existing allocation policies as defined by Regional Internet Registries (RIRs) to determine prefix ownership for use as EIDs. It is expected that the DDT root organizations will continue to evolve in response to experimentation with LISP deployments for Internet edge multihoming and VPN use cases. In all cases, the MSP configures its Map-Server(s) to publish the prefixes of its clients in the distributed mapping database and start encapsulating and forwarding Map-Requests to the ETRs of the AS. These ETRs register their prefix(es) with the Map-Server(s) through periodic authenticated Map-Register messages. In this context, for some LISP sites, there is a need for mechanisms to: o Automatically distribute EID-Prefix(es) shared keys between the ETRs and the EID-registrar Map-Server. o Dynamically obtain the address of the Map-Server in the ETR of the AS. The Map-Server plays a key role in the reachability of the EID-Prefixes it is serving. On one hand, it is publishing these prefixes into the distributed mapping database, and on the other hand, it is encapsulating and forwarding Map-Requests to the authoritative ETRs of these prefixes. ITRs encapsulating towards EIDs for which a failed Map-Server is responsible will be unable to
look up any of their covering prefixes. The only exceptions are the ITRs that already contain the mappings in their local caches. 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 takes its inspiration 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 scope for 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. 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. However, regardless of the availability of open access resolvers, the MSP providing the Map-Server(s) for a LISP site should also make available Map-Resolver(s) for the use of that site. In medium- to large-size ASes, ITRs must be configured with the RLOC of a Map-Resolver; this type of operation can be done manually. However, in Small Office/Home Office (SOHO) scenarios, a mechanism for autoconfiguration should be provided. One solution to avoid manual configuration in LISP sites of any size is the use of anycast [RFC4786] RLOCs for Map-Resolvers, similar to the DNS root server infrastructure. Since LISP uses UDP
encapsulation, the use of anycast would not affect reliability. LISP routers are then shipped with a preconfigured list of well-known Map-Resolver RLOCs, which can be edited by the network administrator, if needed. The use of anycast also helps improve mapping lookup performance. Large MSPs can increase the number and geographical diversity of their Map-Resolver infrastructure, using a single anycasted RLOC. Once LISP deployment is advanced enough, very large content providers may also be interested in running this kind of setup, to ensure minimal connection setup latency for those connecting to their network from LISP sites. While Map-Servers and Map-Resolvers implement different functionalities within the LISP mapping system, they can coexist on the same device. For example, MSPs offering both services can deploy a single Map-Resolver/Map-Server in each PoP where they have a presence. RFC6832] for a detailed description of PITR functionality. The success of new protocols depends greatly on their ability to maintain backwards compatibility and interoperate with the protocol(s) they intend to enhance or replace, and on the incentives to deploy the necessary new software or equipment. A LISP site needs an interworking mechanism to be reachable from non-LISP sites. A PITR can fulfill this role, enabling early adopters to see the benefits of LISP, similar to tunnel brokers helping the transition from IPv4 to IPv6. A site benefits from new LISP functionality (proportionally with existing global LISP deployment) when migrating to LISP, so it has the incentives to deploy the necessary Tunnel Routers. In order to be reachable from non-LISP sites, it has two options: keep announcing its prefix(es) with BGP, or have a PITR announce prefix(es) covering them.
If the goal of reducing the DFZ routing table size is to be reached, the second option is preferred. Moreover, the second option allows LISP-based ingress traffic engineering from all sites. However, the placement of PITRs significantly influences performance and deployment incentives. Section 5 is dedicated to the migration to a LISP-enabled Internet and includes deployment scenarios for PITRs. RFC6832].
PETRs can be deployed by ISPs wishing to offer value-added services to their customers. As is the case with PITRs, PETRs too may introduce path stretch (the ratio between the cost of the selected path and that of the optimal path). Because of this, the ISP needs to consider the tradeoff of using several devices close to the customers to minimize it, or fewer devices farther away from the customers to minimize cost instead. Since the deployment incentives for PITRs and PETRs are different, it is likely that they will be deployed in separate devices, except for the Content Delivery Network (CDN) case, which may deploy both in a single device. In all cases, the existence of a PETR involves another step in the configuration of a LISP router. CPE routers, which are typically configured by DHCP, stand to benefit most from PETRs. Autoconfiguration of the PETR locator could be achieved by a DHCP option or by adding a PETR field to either Map-Notify or Map-Reply messages.
This scenario is not limited to sites that already have their prefixes announced with BGP. Newly allocated EID blocks could follow this strategy as well during the early LISP deployment phase, depending on the cost/benefit analysis of the individual networks. Since this leads to an increase in the DFZ size, the following architecture should be preferred for new allocations.
While it is possible for a PSP to manually configure each client's EID-Routes to be announced, this approach offers little flexibility and is not scalable. This section presents a scalable architecture that offers automatic distribution of EID-Routes to LISP sites and service providers. The architecture requires no modification to existing LISP network elements, but it introduces a new (conceptual) network element, the EID-Route Server, which is defined as a router that either propagates routes learned from other EID-Route Servers or originates EID-Routes. The EID-Routes that it originates are those for which it is authoritative. It propagates these routes to Proxy-ITRs within the AS of the EID-Route Server. It is worth noting that a BGP-capable router can also be considered an EID-Route Server. Further, an EID-Route is defined as a prefix originated via the Route Server of the MSP, which should be aggregated if the MSP has multiple customers inside a single large continuous prefix. This prefix is propagated to other PITRs both within the MSP and to other PITR operators with which it peers. EID-Route Servers are operated by either the LISP site, MSPs, or PSPs and may be collocated with a Map-Server or PITR, but they are functionally discrete entities. They distribute EID-Routes, using BGP, to other domains according to policies set by participants. MSP (AS64500) RS ---> PITR | / | _.--./ ,-'' /`--. LISP site ---,' | v `. ( | DFZ )----- Mapping system non-LISP site ----. | ^ ,' `--. / _.-' | `--'' v / PITR PSP (AS64501) Figure 7: PITR-RD Architecture The architecture described above decouples EID origination from route propagation, with the following benefits: o Can accurately represent business relationships between PITR operators o Is more mapping system agnostic
o Makes minor changes to PITR implementation; no changes to other components In the example in Figure 7, we have a MSP providing services to the LISP site. The LISP site does not run BGP and gets an EID allocation directly from a RIR, or from the MSP, which may be a Local Internet Registry (LIR). Existing PI allocations can be migrated as well. The MSP ensures the presence of the prefix in the mapping system and runs an EID-Route Server to distribute it to PSPs. Since the LISP site does not run BGP, the prefix will be originated with the AS number of the MSP. In the simple case depicted in Figure 7, the EID-Route of a LISP site will be originated by the Route Server and announced to the DFZ by the PSP's PITRs with AS path 64501 64500. From that point on, the usual BGP dynamics apply. This way, routes announced by the PITR are still originated by the authoritative Route Server. Note that the peering relationships between MSPs/PSPs and those in the underlying forwarding plane may not be congruent, making the AS path to a PITR shorter than it is in reality. The non-LISP site will select the best path towards the EID-Prefix according to its local BGP policies. Since AS-path length is usually an important metric for selecting paths, careful placement of PITRs could significantly reduce path stretch between LISP and non-LISP sites. The architecture allows for flexible policies between MSPs/PSPs. Consider the EID-Route Server networks as control plane overlays, facilitating the implementation of policies necessary to reflect the business relationships between participants. The results are then injected into the common underlying forwarding plane. For example, some MSPs/PSPs may agree to exchange EID-Prefixes and only announce them to each of their forwarding plane customers. Global reachability of an EID-Prefix depends on the MSP from which the LISP site buys service and is also subject to agreement between the above- mentioned parties. In terms of impact on the DFZ, this architecture results in a slower routing table increase for new allocations, since traffic engineering will be done at the LISP level. For existing allocations migrating to LISP, the DFZ may decrease, since MSPs may be able to aggregate the prefixes announced.
Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix deaggregation for traffic engineering purposes, resulting in slower routing table increase in the case of new allocations and potential 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 do not come without a cost, however: A PSP operator has to establish either transit or peering relationships to improve its connectivity. Section 5 we focused on the effects of LISP deployment on the DFZ routing table size. Other metrics may be impacted as well but to the best of our knowledge have not been measured as yet.
LISP-THREATS] gives an overview of LISP threat models, including ETR operators attracting traffic by overclaiming an EID-Prefix (Section 4.4.3 of [LISP-THREATS]). Securing mapping lookups is discussed in [LISP-SEC]. [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. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. [CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS performance and the effectiveness of caching", IEEE/ACM Transactions on Networking (TON), Volume 10, Issue 5, pages 589-603, October 2002. [DDT-ROOT] "Introduction to LISP DDT: DDT Root", March 2014, <http://ddt-root.org/>. [LISP-DDT] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", Work in Progress, March 2013.
[LISP-SEC] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", Work in Progress, October 2013. [LISP-THREATS] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Analysis", Work in Progress, April 2014. [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the-Network Tunneling", RFC 4459, April 2006. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013. [RFC6835] Farinacci, D. and D. Meyer, "The Locator/ID Separation Protocol Internet Groper (LIG)", RFC 6835, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. [TELCO96] Federal Communications Commission, "Telecommunications Act of 1996", 1996, <http://transition.fcc.gov/telecom.html>.
LISP, like any tunneling protocol, will increase the size of packets when the LISP header is appended. If increasing the MTU of the access links is not possible, care must be taken that ICMP is not being filtered in order to allow Path MTU Discovery to take place. 5. Validate member prefix allocation. This step checks to see whether the prefix used by the customer is a direct (Provider-Independent) prefix or a prefix assigned by a physical service provider (Provider Aggregatable). If the prefixes are assigned by other service providers, then a Letter of Agreement is required to announce prefixes through the Proxy Service Provider. 6. Verify the member RLOCs and their reachability. This step ensures that the RLOCs configured on the CE router are in fact reachable and working. 7. Prepare for cut-over. * If possible, have a host outside of all security and filtering policies connected to the console port of the edge router or switch. * Make sure the customer has access to the router in order to configure it.
RFC6835] to ensure that registration is successful. * To verify LISP connectivity, find and ping LISP connected sites. If possible, find ping destinations that are not covered by a prefix in the global BGP routing system, because PITRs may deliver the packets even if LISP connectivity is not working. Traceroutes may help determine if this is the case. * To verify connectivity to non-LISP sites, try accessing a landmark (e.g., a major Internet site) via a web browser.