idnits 2.17.1 draft-ietf-lisp-impact-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 5, 2015) is 3125 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 6830 (Obsoleted by RFC 9300, RFC 9301) ** Obsolete normative reference: RFC 6833 (Obsoleted by RFC 9301) ** Obsolete normative reference: RFC 6834 (Obsoleted by RFC 9302) == Outdated reference: A later version (-08) exists of draft-coras-lisp-re-07 == Outdated reference: A later version (-04) exists of draft-farinacci-lisp-signal-free-multicast-03 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-09 == Outdated reference: A later version (-09) exists of draft-ietf-lisp-ddt-03 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-11 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-threats-13 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-13 Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Saucez 3 Internet-Draft INRIA 4 Intended status: Informational L. Iannone 5 Expires: April 7, 2016 Telecom ParisTech 6 A. Cabellos 7 F. Coras 8 Technical University of 9 Catalonia 10 October 5, 2015 12 LISP Impact 13 draft-ietf-lisp-impact-04.txt 15 Abstract 17 The Locator/Identifier Separation Protocol (LISP) aims at improving 18 the Internet routing scalability properties by leveraging on three 19 principles: address role separation, encapsulation, and mapping. In 20 this document, based on implementation work, deployment experiences, 21 and theoretical studies, we discuss the impact that the deployment of 22 LISP can have on both the routing infrastructure and the end-user. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 7, 2016. 41 Copyright Notice 43 Copyright (c) 2015 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. LISP in a nutshell . . . . . . . . . . . . . . . . . . . . . . 3 60 3. LISP for scaling the Internet Routing Architecture . . . . . . 4 61 4. Beyond scaling the Internet Routing Architecture . . . . . . . 6 62 4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 7 63 4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . . 8 64 4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . . 8 65 5. Impact of LISP on operations and business models . . . . . . . 9 66 5.1. Impact on non-LISP traffic and sites . . . . . . . . . . . 9 67 5.2. Impact on LISP traffic and sites . . . . . . . . . . . . . 10 68 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 69 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 70 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 76 1. Introduction 78 The Locator/Identifier Separation Protocol (LISP) relies on three 79 principles to improve the scalability properties of Internet routing: 80 address role separation, encapsulation, and mapping. The main goal 81 of LISP is to make the routing infrastructure more scalable by 82 reducing the number of prefixes announced in the Default Free Zone 83 (DFZ). As LISP utilizes mapping and encapsulation technologies, it 84 provides additional benefits beyond routing scalability. For 85 example, LISP provides a mean for a LISP site to precisely control 86 its inter-domain outgoing and incoming traffic, with the possibility 87 to apply different policies to different domains exchanging traffic 88 with it. LISP can also be used to ease the transition from IPv4 to 89 IPv6 as it allows the transport of IPv4 over IPv6 or IPv6 over IPv4. 90 Furthermore, LISP also supports inter-domain multicast. 92 This document discusses the impact of LISP's deployment on the 93 Internet routing infrastructure and on end-users. LISP utilizes a 94 tunnel-based data plane and a distributed control plane. LISP 95 requires some new functionalities, such as RLOC reachability 96 mechanisms. Being more than a simple encapsulation technology and as 97 a new technology, until more deployment experience is gained, there 98 will remain open questions related to LISP deployment and operations. 99 As an encapsulation technology, there may be concerns on reduced 100 Maximum Transmission Unit (MTU) size in some deployments. An 101 important impact of LISP is on network operations related to 102 resiliency and troubleshooting. As LISP relies on cached mappings 103 and on encapsulation, resiliency during failures and troubleshooting 104 may be more difficult. Also, the use of encapsulation may make 105 failure detection and recovery slower and it will require more 106 coordination than with a single, non-encapsulated, routing domain 107 solution. 109 2. LISP in a nutshell 111 The Locator/Identifier Separation Protocol (LISP) relies on three 112 principles: address role separation, encapsulation, and mapping. 114 Addresses are semantically separated in two: the Routing Locators 115 (RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are addresses 116 typically assigned from the Provider (interdomain) Aggregatable (PA) 117 address space. The EIDs are attributed to the nodes in the edge 118 networks, by a block of contiguous addresses, which are typically 119 Provider Independent (PI). To limit the scalability problem, LISP 120 only requires the PA routes towards the RLOCs to be announced in the 121 Provider infrastructure. Whereas, for non-LISP deployments the EIDs 122 need as well to be propagated. 124 LISP routers are used at the boundary between the EID and the RLOC 125 spaces. Routers used to exit the EID space (towards the Provider 126 domain) are called Ingress Tunnel Router (ITRs) and those used to 127 enter the EID space (from the Provider domain) are called the Egress 128 Tunnel Routers (ETRs). When a host sends a packet to a remote 129 destination, it sends it as in the non-LISP Internet. The packet 130 arrives at the border of its site at an ITR. Because EIDs are not 131 routable on the Internet, the packet is encapsulated with the source 132 address set to the ITR RLOC and the destination address set to the 133 ETR RLOC. The encapsulated packet is then forwarded in the Provider 134 domain until it reaches the selected ETR. The ETR de-encapsulates 135 the packet and forwards it to its final destination. The acronym xTR 136 for Ingress/Egress tunnel router is used for a router playing these 137 two roles. 139 The correspondence between EIDs and RLOCs is given by the mappings. 140 When an ITR needs to find ETR RLOCs that serve an EID, it queries a 141 mapping system. With the LISP Canonical Address Format (LCAF) 142 [I-D.ietf-lisp-lcaf], LISP is not restricted to the Internet Protocol 143 for the EID addresses. With LCAF, any address type can be used as 144 EID (the address is only the key for the mapping lookup). LISP can 145 transport, for example, Ethernet frames over the Internet. 147 An introduction to LISP can be found in [RFC7215]. The LISP 148 specifications are given in [RFC6830], [RFC6833], 149 [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834]. 151 3. LISP for scaling the Internet Routing Architecture 153 The original goal of LISP was to improve the scalability properties 154 of the Internet routing architecture. LISP utilizes traffic 155 engineering and stub AS prefixes (not announced anymore in the DFZ), 156 so that routing tables are smaller and more stable (i.e., they 157 experience less churn). Furthermore, at the edge of the network, 158 information necessary to forward packets (i.e., the mappings) is 159 obtained on demand using a pull model (whereas the current Internet 160 BGP model uses a push model). Therefore, the scalability of edge 161 networks is less dependent on the Internet's size and more related to 162 its traffic matrix. This scaling improvement has been proven by 163 several studies. The research studies cited hereafter are based on 164 the following assumptions: 166 o EID-to-RLOC mappings follow the same prefix size as the current 167 BGP routing infrastructure (current PI addresses only); 169 o EIDs are used only at the stub ASes, not in the transit ASes; 170 o the RLOCs of an EID prefix are deployed at the edge between the 171 stubs owning the EID prefix and the providers, allocating the 172 RLOCs in a Provider Aggregetable (PA) mode. 174 The above assumptions are inline with [RFC7215] and current LISP 175 deployments. It is recognized these assumptions may change in the 176 longer term. [KIF13] and [CDLC] explore different EDI prefix space 177 sizes, and still show results that are consistent and equivalent to 178 the above assumptions. 180 Quoitin et al. [QIdLB07] show that the separation between locator 181 and identifier roles at the network level improves the routing 182 scalability by reducing the Routing Information Base (RIB) size (up 183 to one order of magnitude) and increases path diversity and thus the 184 traffic engineering capabilities. [IB07] and [KIF13] show, based on 185 real Internet traffic traces, that the number of mapping entries that 186 must be handled by an ITR of a network with up to 20,000 users is 187 limited to few tens of thousands; that the signaling traffic (i.e., 188 Map-Request/Map-Reply packets) is in the same order of magnitude 189 similar to DNS requests/reply traffic; and that the encapsulation 190 overhead, while not negligible, is very limited (in the order of few 191 percentage points of the total traffic volume). 193 Previous studies consider the case of a timer-based cache eviction 194 policy (i.e., mappings are deleted from the cache upon timeout), 195 while [CDLC] has a more general approach based on the Least Recently 196 Used (LRU) eviction policy, proposing an analytic model for the EID- 197 to-RLOC cache size when prefix-level traffic has a stationary 198 generating process. The model shows that miss rate can be accurately 199 predicted from the EID-to-RLOC cache size and a small set of easily 200 measurable traffic parameters. The model was validated using four 201 one-day-long packet traces collected at egress points of a campus 202 network and an academic exchange point considering EID-prefixes as 203 being of the same size as BGP prefixes. Consequently, operators can 204 provision the EID-to-RLOC cache of their ITRs according to the miss 205 rate they want to achieve for their given traffic. 207 Results indicate that for a given target miss-ratio, the size of the 208 cache depends only on the parameters of the popularity distribution, 209 being independent of the number of users (the size of the LISP site) 210 and the number of destinations (the size of the EID-prefix space). 211 Assuming that the popularity distribution remains constant, this 212 means that as the number of users and the number of destinations 213 grow, the cache size needed to obtain a given miss rate remains 214 constant O(1). 216 LISP usually populates its EID-to-RLOC cache in a pull mode which 217 means that mappings are retrieved on demand by the ITR. The main 218 advantage of this mode is that the EID-to-RLOC cache size only 219 depends on the traffic characteristics at the ITR and is independent 220 of the size of the Provider domain. This benefit comes at the cost 221 of some delay to transmit the packets that do not hit an entry in the 222 cache (for which a mapping has to be learned). This delay is bound 223 by the time necessary to retrieve the mapping from the mapping 224 system. Moreover, similarly to a push model (e.g., BGP), the pull 225 model induces signaling messages that correspond to the retrieval of 226 mappings upon cache miss. The difference being that the signaling 227 load only depends on the traffic at the ITR and is not triggered by 228 external events such as in BGP. [CDLC] shows that the miss rate is a 229 function of the EID-to-RLOC cache size and traffic generation process 230 and [CDLC], [SDIB08], and [SDIB08] show from traffic traces that, in 231 practice, the cache miss rate, and thus the signaling rate, remain 232 low. 234 4. Beyond scaling the Internet Routing Architecture 236 LISP is more than just a scalability solution, it is also a tool to 237 provide both incoming and outgoing traffic engineering ([S11], 238 [I-D.farinacci-lisp-te]), it can be used as an IPv6 transition at the 239 routing level, and it can be used for inter-domain multicast 240 ([RFC6831], [I-D.coras-lisp-re]). Also, LISP has been identified for 241 use to support devices' Internet mobility ([I-D.meyer-lisp-mn]) and 242 to support virtual machines' mobility in data centers and multi- 243 tenant VPNs. These last two uses are not discussed further as they 244 are out of the scope of the current LISP Working Group charter. 246 A key advantage of the LISP architecture is that it facilitates 247 routing in environments where there is little to no correlation 248 between network endpoints and topological location. In service 249 provider environments, this application is needed in a range of 250 consumer use cases which require an inline anchor to deliver a 251 service to a subscribers. Inline anchors provide one of three types 252 of capabilities: 254 o enable mobility of subscriber end points 256 o enable chaining of middle-box functions and services 258 o enable seamless scale-out of functions 260 Without LISP, operators are forced to centralize service anchors in 261 custom built boxes. This limits deployments as end-points only can 262 move on the same mobile gateway, functions can be chained only if 263 traffic traverses the same wire or the same DPI box, and capacity can 264 scale out only if traffic fans out to/from a specific load balancer. 266 With LISP, service providers are able to distribute, virtualize, and 267 instantiate subscriber-service anchors anywhere in the network. 268 Typical use cases for virtualized inline anchors and network 269 functions include: Distributed Mobility and Virtualized Evolved 270 Packet Core (vEPC), Virtualized Customer Premise Equipment or vCPE, 271 where functionality previously anchored at a customer premises is now 272 dynamically allocated in-network, Virtualized SGi LAN, Virtual IMS 273 and Virtual SBC, etc. 275 Current deployments by ConteXtream, using a pre-standards (designed 276 2006) LISP-based architecture, support a total of 100 million 277 subscribers. And, a deployment at a tier-1 US Mobile operator with 278 over 50 million subscribers provides a 39% download rate improvement 279 over LTE. 281 4.1. Traffic engineering 283 In the current (non-LISP)routing infrastructure, addresses used by 284 stub networks are globally routable and the routing system 285 distributes the routes to reach these stubs. With LISP, the EID 286 prefixes of a LISP site are not routable in the DFZ, mappings are 287 needed in order to determine the list of LISP routers to contact to 288 forward packets. This difference is significant for two reasons. 289 First, packets are not forwarded to a site but to a specific router. 290 Second, a site can control the entry points for its traffic by 291 controlling its mappings. 293 For traffic engineering purposes, a mapping associates an EID prefix 294 to a list of RLOCs. Each RLOC is annotated with a priority and a 295 weight. When there are several RLOCs, the ITR selects the one with 296 the highest priority and sends the encapsulated packet to this RLOC. 297 If several such RLOCs exist, then the traffic is balanced 298 proportionally to their weight among the RLOCs with the lowest 299 priority value. Traffic engineering in LISP thus allows the mapping 300 owner to have a fine-grained control on the primary and backup path 301 for its incoming and outgoing packets use. In addition, it can share 302 the load among its links. An example of the use of such a feature is 303 described by Saucez et al. [SDIB08], showing how to use LISP to 304 direct different types of traffic on different links having different 305 capacity. 307 Traffic engineering in LISP goes one step further. As every Map- 308 Request contains the Source EID Address of the packet that caused a 309 cache miss and triggered the Map-Request. It is thus possible for a 310 mapping owner to differentiate the answer (Map-Reply) it gives to 311 Map-Requests based on the requester. This functionality is not 312 available today with BGP because a domain cannot control exactly the 313 routes that will be received by domains that are not in the direct 314 neighborhood. 316 4.2. LISP for IPv6 Co-existence 318 The LISP encapsulation mechanism is designed to support any 319 combination of locators and identifiers address family. It is then 320 possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa. This 321 allows transporting IPv6 packets over an IPv4 network (or IPv4 322 packets over an IPv6 network), making LISP a valuable mechanism to 323 ease the transition to IPv6. 325 An example is the case of the network infrastructure of a datacenter 326 being IPv4-only while dual-stack front-end load balancers are used. 327 In this scenario, LISP can be used to provide IPv6 access to servers 328 even though the network and the servers only support IPv4. Assuming 329 that the datacenter's ISP offers IPv6 connectivity, the datacenter 330 only needs to deploy one (or more) xTR(s) at its border with the ISP 331 and one (or more) xTR(s) directly connected to the load balancers. 332 The xTR(s) at the ISP's border tunnels IPv6 packets over IPv4 to the 333 xTR(s) directly attached to the load balancer. The load balancer's 334 xTR de-encapsulates the packets and forwards them to the load 335 balancer, which act as proxies, translating each IPv6 packet into an 336 IPv4. IPv4 packets are then sent to the appropriate servers. 337 Similarly, when the server's response arrives at the load balancer, 338 the packet is translated back into an IPv6 packet and forwarded to 339 its xTR(s), which in turn will tunnel it back, over the IPv4-only 340 infrastructure, to an xTR connected to the ISP. The packet is then 341 de-encapsulated and forwarded to the ISP natively in IPv6. 343 4.3. Inter-domain multicast 345 LISP has native support for multicast [RFC6831]. From the data-plane 346 perspective, at a multicast enabled xTR, an EID sourced multicast 347 packet is encapsulated in another multicast packet and subsequently 348 forwarded in a RLOC-level distribution tree. Therefore, xTRs must 349 participate in both EID and RLOC level distribution trees. Control- 350 plane wise, since group addresses have no topological significance 351 they need not to be mapped. It is worth noting that, to properly 352 function, LISP-Multicast requires that inter-domain multicast be 353 available. 355 LISP Replication Engineering (RE) ([I-D.coras-lisp-re], [CDM12]) 356 leverage LISP messages ([I-D.farinacci-lisp-mr-signaling]) for 357 multicast state distribution to construct xTR based inter-domain 358 multicast distribution trees when inter-domain multicast support is 359 not available. Simulations of three different management strategies 360 for low latency content delivery show that such overlays can support 361 thousands of member xTRs, hundreds of thousands of end-hosts and 362 deliver content at latencies close to unicast ones ([CDM12]). It was 363 also observed that high client churn has a limited impact on 364 performance and management overhead. 366 Similarly to LISP-RE, Signal-Free LISP Multicast 367 ([I-D.farinacci-lisp-signal-free-multicast]) can be used when the 368 core network does not provide multicast support. But instead of 369 using signaling to build inter-domain multicast trees, signal-free 370 exclusively leverages the map-server for multicast state storage and 371 distribution. As a result, the source ITR generally performs head- 372 end replication but it might be also used to emulate LISP-RE 373 distribution trees. 375 5. Impact of LISP on operations and business models 377 Numerous implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], 378 [LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the 379 specifications and, additionally, interoperability tests ([Was09]) 380 have been successful. A world-wide large deployment in the 381 international lisp4.net testbed, which is currently composed of nodes 382 running at least three different implementations, will allow us to 383 learn further operational aspects related to LISP. 385 The following sections distinguish the impact of LISP on LISP sites 386 from the impact on non-LISP sites. 388 5.1. Impact on non-LISP traffic and sites 390 LISP has no impact on traffic which has neither LISP origin nor LISP 391 destination. However, LISP can have a significant impact on traffic 392 between a LISP site and a non-LISP site. Traffic between a non-LISP 393 site and a LISP site are subject to the same issues as those observed 394 for LISP-to-LISP traffic but also have issues specific to the 395 transition mechanism that allows the LISP site to exchange packets 396 with a non-LISP site ([RFC6832], [RFC7215]). 398 The transition requires setup of proxy tunnel routers (PxTRs). 399 Proxies cause what is referred to as path stretch and make 400 troubleshooting harder. There are still questions related to PxTRs 401 that need to be answered: 403 o Where to deploy PxTRs? The placement in the topology has an 404 important impact on the path stretch. 406 o How many PxTRs? The number of PxTR has a direct impact on the 407 load and the impact of the failure of a PxTR on the traffic. 409 o What part of the EID space? Will all the PxTRs be proxies for the 410 whole EID space or will it be segmented between different PxTRs? 412 o Who operates PxTRs? An important question to answer is related to 413 the entities that will deploy PxTRs, how will they manage their 414 additional CAPEX/OPEX costs associated with PxTRs? How will the 415 traffic be carried with respect to security and privacy? 417 A PxTR will also normally advertise in BGP the EID prefix for which 418 they are proxy. However, if proxies are managed by different 419 entities, they will belong to different ASes. In this case, we need 420 to be sure that this will not cause MOAS (Multi-Origin AS) issues 421 that could negatively influence routing. Moreover, it is important 422 to ensure that the way EID prefixes will be de-aggregated by the 423 proxies will remain reasonable so as not to contribute to BGP 424 scalability issues. 426 5.2. Impact on LISP traffic and sites 428 LISP is a protocol based on the map-and-encap paradigm which has the 429 positive impacts that we have summarized in the above sections. 430 However, LISP also has impacts on operations: 432 MTU issue: as LISP uses encapsulation, the MTU is reduced, this has 433 implications on potentially all of the traffic. However, in 434 practice, on the lisp4.net network, no major issue due to the 435 MTU has been observed. This is probably due to the fact that 436 current end-host stacks are well designed to deal with the 437 problem of MTU. 439 Resiliency issue: the advantage of flexibility and control offered 440 by the Locator/ID separation comes at the cost of increasing 441 the complexity of the reachability detection. Indeed, 442 identifiers are not directly routable and have to be mapped to 443 locators but a locator may be unreachable while others are 444 still reachable. This is an important problem for any tunnel- 445 based solution. In the current Internet, packets are forwarded 446 independently of the border router of the network meaning that, 447 in case of the failure of a border router, another one can be 448 used. With LISP, the destination RLOC specifically designates 449 one particular ETR, hence if this ETR fails, the traffic is 450 dropped, even though other ETRs are available for the 451 destination site. Another resiliency issue is linked to the 452 fact that mappings are learned on demand. When an ITR fails, 453 all its traffic is redirected to other ITRs that might not have 454 the mappings requested by the redirected traffic. Existing 455 studies ([SKI12], [SD12]) show, based on measurements and 456 traffic traces, that failure of ITRs and RLOC are infrequent 457 but that when such failure happens, a critical number of 458 packets can be dropped. Unfortunately, the current techniques 459 for LISP resiliency, based on monitoring or probing are not 460 rapid enough (failure recovery on the order of a few seconds). 461 To tackle this issue [I-D.bonaventure-lisp-preserve] and 462 [I-D.saucez-lisp-itr-graceful] propose techniques based on 463 local failure detection and recovery. 465 Middle boxes/filters: because of encapsulation, the middle boxes may 466 not understand the traffic, which can cause a firewall to drop 467 legitimate packets. In addition, LISP allows triangular or 468 even rectangular routing, so it is difficult to maintain a 469 correct state even if the middle box understands LISP. 470 Finally, filtering may also have problems because they may 471 think only one host is generating the traffic (the ITR), as 472 long as it is not de-encapsulated. To deal with LISP 473 encapsulation, LISP aware firewalls that inspect inner LISP 474 packets are proposed [lispfirewall]. 476 Troubleshooting/debugging: the major issue which LISP 477 experimentation has shown is the difficulty of troubleshooting. 478 When there is a problem in the network, it is hard to pin-point 479 the reason as the operator only has a partial view of the 480 network. The operator can see what is in its EID-to-RLOC 481 cache/database, and can try to obtain what is potentially 482 elsewhere by querying the Map Resolvers, but the knowledge 483 remains partial. On top of that, ICMP packets only carry the 484 first few tens of bytes of the original packet, which means 485 that when an ICMP arrives at the ITR, it might not contain 486 enough information to allow correct troubleshooting. 487 Deployment in the beta network has shown that LISP+ALT 488 ([RFC6836], [CCR13]) was not easy to maintain and control, 489 which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]. 491 Business/Operational-related: Iannone et al. [IL10] have shown that 492 there are economical incentives to migrate to LISP, however, 493 some questions remain. For example, how will the EIDs be 494 allocated to allow aggregation and hence scalability of the 495 mapping system? Who will operate the mapping system 496 infrastructure and for what benefits? 498 Reachability: The overhead related to RLOC reachability mechanisms 499 is not known. 501 6. IANA Considerations 503 This document makes no request to the IANA. 505 7. Security Considerations 507 Security and threats analysis of the LISP protocol is out of the 508 scope of the present document. A thorough analysis of LISP security 509 threats is detailed in [I-D.ietf-lisp-threats]. 511 8. Acknowledgments 513 Thanks to Deborah Brungard and Wassim Haddad for their thorough 514 reviews, comments, and suggestions. 516 The people that contributed to this document are Sharon Barkai, Vince 517 Fuller, Joel Halpern, Terry Manderson, Gregg Schudel, Ron Bonica, 518 Ross Callon. 520 The work of Luigi Iannone has been partially supported by the ANR-13- 521 INFR-0009 LISP-Lab Project (www.lisp-lab.org). 523 9. References 525 9.1. Normative References 527 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 528 Locator/ID Separation Protocol (LISP)", RFC 6830, 529 DOI 10.17487/RFC6830, January 2013, 530 . 532 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 533 Locator/ID Separation Protocol (LISP) for Multicast 534 Environments", RFC 6831, DOI 10.17487/RFC6831, 535 January 2013, . 537 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 538 "Interworking between Locator/ID Separation Protocol 539 (LISP) and Non-LISP Sites", RFC 6832, DOI 10.17487/ 540 RFC6832, January 2013, 541 . 543 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 544 Protocol (LISP) Map-Server Interface", RFC 6833, 545 DOI 10.17487/RFC6833, January 2013, 546 . 548 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 549 Separation Protocol (LISP) Map-Versioning", RFC 6834, 550 DOI 10.17487/RFC6834, January 2013, 551 . 553 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 554 "Locator/ID Separation Protocol Alternative Logical 555 Topology (LISP+ALT)", RFC 6836, DOI 10.17487/RFC6836, 556 January 2013, . 558 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 559 Pascual, J., and D. Lewis, "Locator/Identifier Separation 560 Protocol (LISP) Network Element Deployment 561 Considerations", RFC 7215, DOI 10.17487/RFC7215, 562 April 2014, . 564 9.2. Informative References 566 [CCR13] Saucez, D., Iannone, L., and B. Donnet, "A First 567 Measurement Look at the Deployment and Evolution of the 568 Locator/ID Separation Protocol", ACM SIGCOMM Computer 569 Communication Review. Vol. 43, N. 2., April 2013. 571 [CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An 572 Analytical Model for Loc/ID Mappings Caches", IEEE 573 Transactions on Networking, 2014. 575 [CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., 576 and A. Cabellos-Aparicio, "Lcast: Software-defined Inter- 577 Domain Multicast", Elsevier Computer Networks, July 2014. 579 [I-D.bonaventure-lisp-preserve] 580 Bonaventure, O., Francois, P., and D. Saucez, "Preserving 581 the reachability of LISP ETRs in case of failures", 582 draft-bonaventure-lisp-preserve-00 (work in progress), 583 July 2009. 585 [I-D.coras-lisp-re] 586 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 587 Maino, F., and D. Farinacci, "LISP Replication 588 Engineering", draft-coras-lisp-re-07 (work in progress), 589 April 2015. 591 [I-D.farinacci-lisp-mr-signaling] 592 Farinacci, D. and M. Napierala, "LISP Control-Plane 593 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 594 (work in progress), February 2015. 596 [I-D.farinacci-lisp-signal-free-multicast] 597 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 598 draft-farinacci-lisp-signal-free-multicast-03 (work in 599 progress), June 2015. 601 [I-D.farinacci-lisp-te] 602 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 603 Engineering Use-Cases", draft-farinacci-lisp-te-09 (work 604 in progress), September 2015. 606 [I-D.ietf-lisp-ddt] 607 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 608 Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in 609 progress), April 2015. 611 [I-D.ietf-lisp-lcaf] 612 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 613 Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in 614 progress), September 2015. 616 [I-D.ietf-lisp-threats] 617 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 618 Analysis", draft-ietf-lisp-threats-13 (work in progress), 619 August 2015. 621 [I-D.meyer-lisp-mn] 622 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 623 Mobile Node", draft-meyer-lisp-mn-13 (work in progress), 624 July 2015. 626 [I-D.saucez-lisp-itr-graceful] 627 Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, 628 "LISP ITR Graceful Restart", 629 draft-saucez-lisp-itr-graceful-03 (work in progress), 630 December 2013. 632 [IB07] Iannone, L. and O. Bonaventure, "On the cost of caching 633 locator/id mappings", In Proc. ACM CoNEXT 2007, 634 December 2007. 636 [IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID 637 Separation for the Future Internet", Book Chapter, 638 Towards the Future Internet - Emerging Trends from the 639 European Research, IOS Press, May 2010. 641 [IOSNXOS] Cisco Systems Inc., "Locator/ID Separation Protocol 642 (LISP)", http://lisp4.cisco.com, 2013. 644 [KIF13] Kim, J., Iannone, L., and A. Feldmann, "Caching Locator/ID 645 Mappings: Scalability Analysis and Implications", 646 Elsevier Computer Networks Journal, March 2013. 648 [LISPClick] 649 Saucez, D. and V. Nguyen, "LISP-Click: A Click 650 implementation of the Locator/ID Separation Protocol", 651 1st Symposium on Click Modular Router, 2009, 652 November 2009. 654 [LISPcp] "The lip6-lisp Project", https://github.com/lip6-lisp/, 655 2014. 657 [LISPfritz] 658 "Unsere FRITZ!Box-Produkte", 659 http://avm.de/produkte/fritzbox/, 2014. 661 [LISPmob] "An open-source LISP implementation for Linux, Android and 662 OpenWRT", http://lispmob.org, 2015. 664 [OpenLISP] 665 "The OpenLISP Project", http://www.openlisp.org, 2013. 667 [QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. 668 Bonaventure, "Evaluating the benefits of the locator/ 669 identifier separation", In Proc. ACM MobiArch 2007, 670 May 2007. 672 [S11] Saucez, D., "Mechanisms for Interdomain Traffic 673 Engineering with LISP", PhD Thesis, Universite catholique 674 de Louvain, 2011, October 2011. 676 [SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in 677 LISP", In Proc. IFIP Networking 2012, May 2012. 679 [SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, 680 "Interdomain Traffic Engineering in a Locator/Identifier 681 Separation Context", In Proc. of Internet Network 682 Management Workshop, 2008, October 2008. 684 [SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. 685 Filsfils, "A Local Approach to Fast Failure Recovery of 686 LISP Ingress Tunnel Routers", In Proc. IFIP Networking 687 2012, May 2012. 689 [Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, 690 LISP WG presentation, 2009., November 2009. 692 [lispfirewall] 693 "LISP and Zone-Based Firewalls Integration and 694 Interoperability", http://www.cisco.com/c/en/us/td/docs/ 695 ios-xml/ios/sec_data_zbf/configuration/xe-3s/ 696 sec-data-zbf-xe-book/sec-zbf-lisp-inner-pac-insp.html, 697 2014. 699 Authors' Addresses 701 Damien Saucez 702 INRIA 703 2004 route des Lucioles BP 93 704 06902 Sophia Antipolis Cedex 705 France 707 Email: damien.saucez@inria.fr 709 Luigi Iannone 710 Telecom ParisTech 711 23, Avenue d'Italie, CS 51327 712 75214 PARIS Cedex 13 713 France 715 Email: ggx@gigix.net 717 Albert Cabellos 718 Technical University of Catalonia 719 C/Jordi Girona, s/n 720 08034 Barcelona 721 Spain 723 Email: acabello@ac.upc.edu 725 Florin Coras 726 Technical University of Catalonia 727 C/Jordi Girona, s/n 728 08034 Barcelona 729 Spain 731 Email: fcoras@ac.upc.edu