idnits 2.17.1 draft-ietf-lisp-impact-02.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 (May 7, 2015) is 3276 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-02 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-te-08 == 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-08 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-threats-12 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-12 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: November 8, 2015 Telecom ParisTech 6 A. Cabellos 7 F. Coras 8 Technical University of 9 Catalonia 10 May 7, 2015 12 LISP Impact 13 draft-ietf-lisp-impact-02.txt 15 Abstract 17 The Locator/Identifier Separation Protocol (LISP) aims at improving 18 the Internet scalability properties leveraging on three simple 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 Internet in general and the end-user in 23 particular. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 8, 2015. 42 Copyright Notice 44 Copyright (c) 2015 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. LISP in a nutshell . . . . . . . . . . . . . . . . . . . . . . 3 61 3. LISP for scaling the Internet . . . . . . . . . . . . . . . . 4 62 4. Beyond scaling the Internet . . . . . . . . . . . . . . . . . 6 63 4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 7 64 4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . . 8 65 4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . . 8 66 5. Impact of LISP on operations and business model . . . . . . . 9 67 5.1. Impact on non-LISP traffic and sites . . . . . . . . . . . 9 68 5.2. Impact on LISP traffic and sites . . . . . . . . . . . . . 10 69 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 71 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 72 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 74 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 77 1. Introduction 79 The Locator/Identifier Separation Protocol (LISP) relies on three 80 simple principles to improve the scalability properties of the 81 Internet: address role separation, encapsulation, and mapping. The 82 main goal of LISP is to make the Internet more scalable by reducing 83 the number of prefixes announced in the Default Free Zone (DFZ). As 84 LISP relies on mapping and encapsulation, it turns out that it 85 provides more benefits than just increased scalability. For 86 instance, LISP provides a mean for a LISP site to precisely control 87 its inter-domain outgoing and incoming traffic, with the possibility 88 to apply different policies to different domains exchanging traffic 89 with it. LISP can also be used to ease the transition from IPv4 to 90 IPv6 as it allows to transport IPv4 over IPv6 or IPv6 over IPv4. 91 Furthermore, LISP also provides a solution to perform inter-domain 92 multicast. 94 This document discusses the impact of LISP's deployment on the 95 Internet and on end-users and shows the consequences of the 96 interworking infrastructure in terms of path-stretch. There still 97 are many, economical rather than technical, open questions related to 98 the deployment of such infrastructure. Moreover, encapsulation may 99 raise some issues (which have a limited impact in practice) because 100 it reduces the Maximum Transmission Unit (MTU) size. An important 101 impact of LISP on network operations is related to resiliency and 102 troubleshooting. Indeed, as LISP relies on cached mappings and on 103 encapsulation, troubleshooting is harder than in the traditional 104 Internet. Also, encapsulation stresses resiliency as it makes 105 failure detection and recovery slower than with hop-by-hop routing. 107 2. LISP in a nutshell 109 The Locator/Identifier Separation Protocol (LISP) relies on three 110 simple principles: address role separation, encapsulation, and 111 mapping. 113 Addresses are semantically separated in two: the Routing Locators 114 (RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are addresses 115 typically assigned from the Provider Aggregatable (PA) address space. 116 The EIDs are attributed to the nodes in the edge networks, by block 117 of contiguous addresses, which are typically Provider Independent 118 (PI). To limit the scalability problem, only the routes towards the 119 RLOCs are announced in the Internet routing infrastructure, whereas 120 currently EIDs are also propagated. 122 LISP routers are used at the boundary between the EID and the RLOC 123 spaces. Routers used to exit the EID space are called Ingress Tunnel 124 Router (ITRs) and those used to enter the EID space the Egress Tunnel 125 Routers (ETRs). When a host sends a packet to a remote destination, 126 it sends it as in the current Internet (without LISP). The packet 127 eventually arrives at the border of its site at an ITR. Because EIDs 128 are not routable on the Internet, the packet is encapsulated with the 129 source address set to the ITR RLOC and the destination address set to 130 the ETR RLOC. The encapsulated packet is then forwarded in the 131 Internet until it reaches the selected ETR. The ETR decapsulates the 132 packet and forwards it to its final destination. The acronym xTR for 133 Ingress/Egress tunnel router is used for a router playing these two 134 roles. 136 The correspondence between EIDs and RLOCs is given by the mappings. 137 When an ITR needs to find ETR RLOCs that serve an EID it queries a 138 mapping system. It is worth noticing that with the LISP Canonical 139 Address Format (LCAF) [I-D.ietf-lisp-lcaf], LISP is not restricted to 140 the Internet Protocol for the EID addresses. With LCAF, any address 141 type can be used as EID (the address is the key for the mapping 142 lookup) and LISP can then transport, for example, Ethernet frames 143 over the Internet. 145 A more thorough introduction to LISP can be found in [RFC7215]. The 146 complete specifications are given in [RFC6830], [RFC6833], 147 [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834]. 149 3. LISP for scaling the Internet 151 The original goal of LISP is to improve the scalability properties of 152 the Internet architecture. LISP achieves such a target thanks to 153 traffic engineering and stub AS prefixes not announced anymore in the 154 DFZ, so that routing tables are smaller and more stable (i.e., they 155 experience less churn). Furthermore, at the edge network, 156 information necessary to forward packets (i.e., the mappings) is 157 obtained on demand using a pull model (whereas the current Internet 158 uses a push model, instantiated by BGP). Therefore, scalability of 159 edge networks is now independent of the Internet's size and is now 160 related its traffic matrix. This scaling improvement is proven by 161 several works. The research work cited hereafter is based on the 162 following assumptions: 164 o EID-to-RLOC mappings follow the same prefix size as the current 165 BGP routing infrastructure; 167 o EIDs are used only at the stub ASes, not in the transit ASes; 169 o the RLOCs of an EID prefix are deployed at the edge between the 170 stubs owning the EID prefix and the providers, allocating the 171 RLOCs in a Provider Aggregetable (PA) mode. 173 The above assumptions are inline with [RFC7215] and current LISP 174 deployments, however, such situation may change in the long term. 175 Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space 176 sizes, still showing results that are consitent and equivalent to the 177 above assumptions. 179 Quoitin et al. [QIdLB07] show that the separation between locator 180 and identifier roles at the network level improves the routing 181 scalability by reducing the Routing Information Base (RIB) size (up 182 to one order of magnitude) and increases path diversity and thus the 183 traffic engineering capabilities. [IB07] and [KIF13] show, based on 184 real Internet traffic traces that the number of mapping entries that 185 must be handled by an ITR of a network with up to 20,000 users is 186 limited to few tens of thousands; that the signaling traffic (i.e., 187 Map-Request/Map-Reply packets) is in the same order of magnitude like 188 DNS requests/reply traffic; that the encapsulation overhead, while 189 not negligible, is very limited (in the order of few percentage 190 points of the total traffic volume). 192 Previous studies consider the case of a timer-based cache eviction 193 policy (i.e., mappings are deleted from the cache upon timeout), 194 while [CDLC] has a more general approach based on the Least Recently 195 Used (LRU) eviction policy, proposing an analytic model for the EID- 196 to-RLOC cache size when prefix-level traffic has a stationary 197 generating process. The model shows that miss rate can be accurately 198 predicted from the EID-to-RLOC cache size and a small set of easily 199 measurable traffic parameters. The model was validated using four 200 one-day-long packet traces collected at egress points of a campus 201 network and an academic exchange point considering EID-prefixes as 202 being of the same size as BGP prefixes. Consequently, operators can 203 provision the EID-to-RLOC cache of their ITRs according to the miss 204 rate they want to achieve for their given traffic. 206 Results indicate that for a given target miss-ratio, the size of the 207 cache depends only on the parameters of the popularity distribution, 208 being independent of the number of users (the size of the LISP site) 209 and the number of destinations (the size of the EID-prefix space). 210 Assuming that the popularity distribution remains constant, this 211 means that as the number of users and the number of destinations 212 grow, the cache size needed to obtain a given miss rate remains 213 constant O(1). 215 LISP usually populates its EID-to-RLOC cache in a pull mode which 216 means that mappings are retrieved on demand by the ITR. The main 217 advantage is that the EID-to-RLOC cache size only depens on the 218 traffic characteristics at the ITR and is independent of the size of 219 the Internet. This benefit comes at the cost of some delay to 220 transmit the packets that do not hit an entry in the cache, for which 221 a mapping has to be learned. This delay is bound by the time 222 necessary to retrieve the mapping from the mapping system. Moreover, 223 similarly to a push model (e.g., BGP), the pull model induces 224 signaling messages that correspond to the retrieval of mappings upon 225 cache miss. The difference being that the signaling load only 226 depends on the traffic at the ITR and is not triggered by external 227 events such as in BGP. [CDLC] shows that the miss rate is a function 228 of the EID-to-RLOC cache size and traffic generation process and 229 [CDLC], [SDIB08], and [SDIB08] show from traffic traces that in 230 practice the cache miss rate, and thus the signaling rate, remain 231 low. 233 4. Beyond scaling the Internet 235 Even though it is its main goal, LISP is more than just a scalability 236 solution, it is also a tool to provide both incoming and outgoing 237 traffic engineering ([S11], [I-D.farinacci-lisp-te]) can be used as 238 an IPv6 transition at the routing level, and for inter-domain 239 multicast ([RFC6831], [I-D.coras-lisp-re]). LISP has also proven to 240 be a good protocol for devices' Internet mobility 241 ([I-D.meyer-lisp-mn]) or even virtual machines' mobility in data 242 centers and multi-tenant VPNs. Details of the last two points are 243 not discussed further because out of the scope of the current LISP 244 Working Group charter. 246 LISP architecture facilitates routing in environments where there is 247 little to no correlation between network endpoints and topological 248 location. In service provider environment this use is evident in a 249 range of consumer use cases which require an inline anchor in-order 250 to deliver a service to a subscribers. Inline anchors provide one of 251 three types of capabilities: 253 o enable mobility of subscriber end points 255 o enable chaining of middle-box functions and services 257 o enable seamless scale-out of functions 259 Without LISP operators are forced to centralize service anchors in 260 custom built special boxes. This means that end-points can move as 261 long as their traffic ends up on the same mobile gateway, functions 262 can be chained as long as all traffic traverses the same wire or the 263 same DPI box, and capacity can scale out as long as traffic fans out 264 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 that virtualized inline anchors and network 269 functions include: Distributed Mobility and Virtualized Evolved 270 Packet Core (vEPC), where centralization makes way to distributed and 271 virtualized inline anchoring of mobility, Virtualized Customer 272 Premise Equipment or vCPE, where functionality previously anchored at 273 customer premises is now dynamically allocated in-network, 274 Virtualized SGi LAN, where value added mobile services previously 275 anchored inside full-stack boxes or anchored to physical wires with 276 permutation setups aka "Rails", Virtual IMS and Virtual SBC, etc. 278 Current deployments by ConteXtream, using a pre standards (designed 279 2006) based architecture, support a total of 100 millions subscribers 280 with such an architecture. A deployment at a tier-1 US Mobile 281 operator over 50 millions subscribers provides a 39% download rate 282 improvement over LTE. 284 4.1. Traffic engineering 286 In the current (non-LISP) Internet, addresses used by stub networks 287 are globally routable and the routing system distributes the routes 288 to reach these stubs. On the contrary, the EID prefixes of a LISP 289 site are not routable in the DFZ, meaning that mappings are needed in 290 order to determine the list of LISP routers to contact to send them 291 packets. The difference is significant for two reasons. First, 292 packets are not sent to a site but to a specific router. Second, a 293 site can control the entry points for its traffic by controlling its 294 mappings. 296 For traffic engineering purpose, a mapping associates an EID prefix 297 to a list of RLOCs. Each RLOC is annotated with a priority and a 298 weight. When there are several RLOCs, the ITR selects the one with 299 the highest priority and sends the encapsulated packet to this RLOC. 300 If several such RLOCs exist, then the traffic is balanced 301 proportionally to their weight among the RLOCs with the lowest 302 priority value. Traffic engineering in LISP thus allows the mapping 303 owner to have a fine-grained control on the primary and backup path 304 its incoming and outgoing packets use. In addition, it can share the 305 load among its links. An example of the use of such a feature is 306 described by Saucez et al. [SDIB08], showing how to use LISP to 307 direct different types of traffic on different links having different 308 capacity. 310 Traffic engineering in LISP goes one step further. As every Map- 311 Request contains the Source EID Address of the packet that caused a 312 cache miss and triggered the Map-Request. It is thus possible for a 313 mapping owner to differentiate the answer (Map-Reply) it gives to 314 Map-Requests based on the requester. This functionality is not 315 available today with BGP because a domain cannot control exactly the 316 routes that will be received by domains that are not in the direct 317 neighborhood. 319 4.2. LISP for IPv6 Co-existence 321 The LISP encapsulation mechanism is designed to support any 322 combination of locators and identifiers address family. It is then 323 possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa. This 324 allows transporting IPv6 packets over an IPv4 network (or IPv4 325 packets over an IPv6 network), making LISP a valuable mechanism to 326 ease the transition to IPv6. 328 A not so uncommon example is the case of the network infrastructure 329 of a datacenter being IPv4-only while dual-stack front-end load 330 balancers are used. In this scenario, LISP can be used to provide 331 IPv6 access to servers even though the network and the servers only 332 support IPv4. Assuming that the datacenter's ISP offers IPv6 333 connectivity, the datacenter only needs to deploy one (or more) 334 xTR(s) at its border with the ISP and one (or more) xTR(s) directly 335 connected to the load balancers. The xTR(s) at the ISP's border 336 tunnels IPv6 packets over IPv4 to the xTR(s) directly attached to the 337 load balancer. The load balancer's xTR decapsulates the packets and 338 forward them to the load balancer, which act as proxies, translating 339 each IPv6 packet into an IPv4. IPv4 packets are then sent to the 340 appropriate servers. Similarly, when the server's response arrives 341 at the load balancer, the packet is translated back into an IPv6 342 packet and forwarded to its xTR(s), which in turn will tunnel it 343 back, over the IPv4-only infrastructure, to an xTR connected to the 344 ISP. The packet is then decapsulated and forwarded to the ISP 345 natively in IPv6. 347 4.3. Inter-domain multicast 349 LISP has native support for multicast [RFC6831]. From the data-plane 350 perspective, at a multicast enabled xTR, an EID sourced multicast 351 packet is encapsulated in another multicast packet and subsequently 352 forwarded in a RLOC-level distribution tree. Therefore, xTRs must 353 participate in both EID and RLOC level distribution trees. Control- 354 plane wise, since group addresses have no topological significance 355 they need not to be mapped. It is worth noting that, to properly 356 function, LISP-Multicast requires that inter-domain multicast be 357 available. 359 LISP Replication Engineering (RE) ([I-D.coras-lisp-re], [CDM12]) 360 leverage LISP messages ([I-D.farinacci-lisp-mr-signaling]) for 361 multicast state distribution to construct xTR based inter-domain 362 multicast distribution trees when inter-domain multicast support is 363 not available. Simulations of three different management strategies 364 for low latency content delivery show that such overlays can support 365 thousands of member xTRs, hundreds of thousands of end-hosts and 366 deliver content at latencies close to unicast ones ([CDM12]). It was 367 also observed that high client churn has a limited impact on 368 performance and management overhead. 370 Similarly to LISP-RE, Signal-Free LISP Multicast 371 ([I-D.farinacci-lisp-signal-free-multicast]) can be used when the 372 core network does not provide multicast support. But instead of 373 using signaling to build inter-domain multicast trees, signal-free 374 exclusively leverages the map-server for multicast state storage and 375 distribution. As a result, the source ITR generally performs head- 376 end replication but it might be also used to emulate LISP-RE 377 distribution trees. 379 5. Impact of LISP on operations and business model 381 Important implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], 382 [LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the 383 specifications and interoperability tests ([Was09]) have been a 384 success. World-wide large deployment in the international lisp4.net 385 testbed, which is currently composed of nodes running at least three 386 different implementations, allows to learn operational matters 387 related to LISP. 389 We have to distinguish the impact of LISP on LISP sites from the 390 impact on non-LISP sites. 392 5.1. Impact on non-LISP traffic and sites 394 LISP has no impact on traffic which has neither LISP origin nor LISP 395 destination. However, LISP can have a significant impact on traffic 396 between a LISP site and a non-LISP site. Traffic between a non-LISP 397 site and a LISP site are subject to the same issues than those 398 observed for LISP-to-LISP traffic but also have issues specific to 399 the transition mechanism that allow LISP site to exchange packets 400 with non-LISP site ([RFC6832], [RFC7215]). 402 Indeed, the transition requires to setup proxy tunnel routers 403 (PxTRs). PxTRs do not cause particular technical issue. However, by 404 definition proxies cause path stretch and make troubleshooting 405 harder. There are still big questions related to PxTRs that have to 406 be answered: 408 o Where to deploy PxTRs? The placement in the topology has an 409 important impact on the path stretch. 411 o How many PxTRs? The number of PxTR has a direct impact on the 412 load and the impact of the failure of a PxTR on the traffic. 414 o What part of the EID space? Will all the PxTRs be proxies for the 415 whole EID space or will it be segmented between different PxTRs? 417 o Who operates PxTRs? The IETF does not aim at providing business 418 model hints, however, an important question to answer is related 419 to the entities that will deploy PxTRs, how they will manage their 420 CAPEX/OPEX and how the traffic will be carried with respect for 421 the security and privacy. 423 PxTR also normally have to advertise in BGP the EID prefix they are 424 proxy for. However, if proxies are managed by different entities, 425 they will belong to different ASes. In this case, we have to be sure 426 that it will not cause MOAS (Multi-Origina AS) issues that could 427 negatively influence routing. Moreover, it is important to ensure 428 that the way EID prefixes will be deaggregated by the proxies will 429 remain reasonable to not take part in the BGP scalability issues. 431 5.2. Impact on LISP traffic and sites 433 LISP is a protocol based on the map-and-encap paradigm which has the 434 positive effects that we have given in the sections above. However, 435 by design, LISP also has side impact on operations: 437 MTU issue: as LISP uses encapsulation, the MTU is reduced, this has 438 implication on potentially all the traffic. However, in 439 practice, on the lisp4.net network, no major issue due to the 440 MTU has been observed. This is probably due to the fact that 441 current end-host stacks are well designed to deal with the 442 problem of MTU. 444 Resiliency issue: the advantage of flexibility and control offered 445 by the Locator/ID separation comes at the cost of increasing 446 the complexity of the reachability detection. Indeed, 447 identifiers are not directly routable and have to be mapped to 448 locators but a locator may be unreachable while others are 449 still reachable. This is an important problem for any tunnel- 450 based solution. In the current Internet, packets are forwarded 451 independently of the border router of the network meaning that 452 in case of the failure of a border router, another one can be 453 used. With LISP, the destination RLOC specifically designate 454 one particular ETR, hence if this ETR fails, the traffic is 455 dropped even though other ETRs are available for the 456 destination site. Another resiliency issue is linked to the 457 fact that mappings are learned on demand. When an ITR fails, 458 all its traffic is redirected to other ITRs that might not have 459 the mappings requested by the redirected traffic. Existing 460 studies ([SKI12], [SD12]) show, based on measurements and 461 traffic traces, that failure of ITRs and RLOC are infrequent 462 but that when such failure happens, an important number of 463 packet can be dropped. Unfortunately, the current techniques 464 for LISP resiliency, based on monitoring or probing are not 465 rapid enough (failure recovery of the order of a few seconds). 466 To tackle this issue [I-D.bonaventure-lisp-preserve] and 467 [I-D.saucez-lisp-itr-graceful] propose techniques based on 468 local failure detection and recovery. 470 Middle boxes/filters: because of encapsulation, the middle boxes 471 might not understand the traffic which can cause firewall to 472 drop legitimate packets. In addition, LISP allows triangular 473 or even rectangular routing, so it is hard to maintain a 474 correct state even if the middle box perfectly understands 475 LISP. Finally, filtering might also have problems because they 476 might think only one host is generating the traffic (the ITR), 477 as long as it is not decapsulated. To deal with LISP 478 encapsulation, LISP aware firewalls that inspect inner LISP 479 packets are proposed [lispfirewall]. 481 Troubleshooting/debugging: the major issue that years of LISP 482 experimentation have shown is the difficulty of 483 troubleshooting. When there is a problem in the network, it is 484 hard to pin-point the reason as the operator only has a partial 485 view of the network. The operator can see what is in its EID- 486 to-RLOC cache/database, and can try to obtain what is 487 potentially elsewhere by querying the Map Resolvers but the 488 knowledge remains partial. On top of that, ICMP packets only 489 carry the first few tens of bytes of the original packet, which 490 means that when an ICMP arrives at the ITR, it might not 491 contain enough information to make correct troubleshooting. 492 Interestingly, deployment in the beta network has shown that 493 LISP+ALT was not easy to maintain and control, which explains 494 the migration to LISP-DDT [I-D.ietf-lisp-ddt]. 496 Business: the IETF is not aiming at providing business models. 497 However, even though Iannone et al. [IL10] shown that there is 498 economical incentives to migrate to LISP, some questions are on 499 hold. For example, how will the EIDs be allocated to allow 500 aggregation and hence scalability of the mapping system? Who 501 will operate the mapping system infrastructure and for what 502 benefit? 504 6. IANA Considerations 506 This document makes no request to the IANA. 508 7. Security Considerations 510 Security and threats analysis of the LISP protocol is out of the 511 scope of the present document. A thorough analysis of LISP security 512 threats is detailed in [I-D.ietf-lisp-threats]. 514 8. Acknowledgments 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 January 2013. 531 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 532 Locator/ID Separation Protocol (LISP) for Multicast 533 Environments", RFC 6831, January 2013. 535 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 536 "Interworking between Locator/ID Separation Protocol 537 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 539 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 540 Protocol (LISP) Map-Server Interface", RFC 6833, 541 January 2013. 543 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 544 Separation Protocol (LISP) Map-Versioning", RFC 6834, 545 January 2013. 547 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 548 "Locator/ID Separation Protocol Alternative Logical 549 Topology (LISP+ALT)", RFC 6836, January 2013. 551 [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 552 Pascual, J., and D. Lewis, "Locator/Identifier Separation 553 Protocol (LISP) Network Element Deployment 554 Considerations", RFC 7215, April 2014. 556 9.2. Informative References 558 [CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An 559 Analytical Model for Loc/ID Mappings Caches", IEEE 560 Transactions on Networking, 2014. 562 [CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., 563 and A. Cabellos-Aparicio, "Lcast: Software-defined Inter- 564 Domain Multicast", Elsevier Computer Networks, July 2014. 566 [I-D.bonaventure-lisp-preserve] 567 Bonaventure, O., Francois, P., and D. Saucez, "Preserving 568 the reachability of LISP ETRs in case of failures", 569 draft-bonaventure-lisp-preserve-00 (work in progress), 570 July 2009. 572 [I-D.coras-lisp-re] 573 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 574 Maino, F., and D. Farinacci, "LISP Replication 575 Engineering", draft-coras-lisp-re-07 (work in progress), 576 April 2015. 578 [I-D.farinacci-lisp-mr-signaling] 579 Farinacci, D. and M. Napierala, "LISP Control-Plane 580 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 581 (work in progress), February 2015. 583 [I-D.farinacci-lisp-signal-free-multicast] 584 Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", 585 draft-farinacci-lisp-signal-free-multicast-02 (work in 586 progress), December 2014. 588 [I-D.farinacci-lisp-te] 589 Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic 590 Engineering Use-Cases", draft-farinacci-lisp-te-08 (work 591 in progress), March 2015. 593 [I-D.ietf-lisp-ddt] 594 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 595 Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in 596 progress), April 2015. 598 [I-D.ietf-lisp-lcaf] 599 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 600 Address Format (LCAF)", draft-ietf-lisp-lcaf-08 (work in 601 progress), April 2015. 603 [I-D.ietf-lisp-threats] 604 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 605 Analysis", draft-ietf-lisp-threats-12 (work in progress), 606 March 2015. 608 [I-D.meyer-lisp-mn] 609 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 610 Mobile Node", draft-meyer-lisp-mn-12 (work in progress), 611 January 2015. 613 [I-D.saucez-lisp-itr-graceful] 614 Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, 615 "LISP ITR Graceful Restart", 616 draft-saucez-lisp-itr-graceful-03 (work in progress), 617 December 2013. 619 [IB07] Iannone, L. and O. Bonaventure, "On the cost of caching 620 locator/id mappings", In Proc. ACM CoNEXT 2007, 621 December 2007. 623 [IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID 624 Separation for the Future Internet", Book Chapter, 625 Towards the Future Internet - Emerging Trends from the 626 European Research, IOS Press, May 2010. 628 [IOSNXOS] Cisco Systems Inc., "Locator/ID Separation Protocol 629 (LISP)", http://lisp4.cisco.com, 2013. 631 [KIF13] Kim, J., Iannone, L., and A. Feldmann, "Caching Locator/ID 632 Mappings: Scalability Analysis and Implications", 633 Elsevier Computer Networks Journal, March 2013. 635 [LISPClick] 636 Saucez, D. and V. Nguyen, "LISP-Click: A Click 637 implementation of the Locator/ID Separation Protocol", 638 1st Symposium on Click Modular Router, 2009, 639 November 2009. 641 [LISPcp] "The lip6-lisp Project", https://github.com/lip6-lisp/, 642 2014. 644 [LISPfritz] 645 "Unsere FRITZ!Box-Produkte", 646 http://avm.de/produkte/fritzbox/, 2014. 648 [LISPmob] "An open-source LISP implementation for Linux, Android and 649 OpenWRT", http://lispmob.org, 2015. 651 [OpenLISP] 652 "The OpenLISP Project", http://www.openlisp.org, 2013. 654 [QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. 655 Bonaventure, "Evaluating the benefits of the locator/ 656 identifier separation", In Proc. ACM MobiArch 2007, 657 May 2007. 659 [S11] Saucez, D., "Mechanisms for Interdomain Traffic 660 Engineering with LISP", PhD Thesis, Universite catholique 661 de Louvain, 2011, October 2011. 663 [SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in 664 LISP", In Proc. IFIP Networking 2012, May 2012. 666 [SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, 667 "Interdomain Traffic Engineering in a Locator/Identifier 668 Separation Context", In Proc. of Internet Network 669 Management Workshop, 2008, October 2008. 671 [SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. 672 Filsfils, "A Local Approach to Fast Failure Recovery of 673 LISP Ingress Tunnel Routers", In Proc. IFIP Networking 674 2012, May 2012. 676 [Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, 677 LISP WG presentation, 2009., November 2009. 679 [lispfirewall] 680 "LISP and Zone-Based Firewalls Integration and 681 Interoperability", http://www.cisco.com/c/en/us/td/docs/ 682 ios-xml/ios/sec_data_zbf/configuration/xe-3s/ 683 sec-data-zbf-xe-book/sec-zbf-lisp-inner-pac-insp.html, 684 2014. 686 Authors' Addresses 688 Damien Saucez 689 INRIA 690 2004 route des Lucioles BP 93 691 06902 Sophia Antipolis Cedex 692 France 694 Email: damien.saucez@inria.fr 696 Luigi Iannone 697 Telecom ParisTech 698 23, Avenue d'Italie, CS 51327 699 75214 PARIS Cedex 13 700 France 702 Email: ggx@gigix.net 704 Albert Cabellos 705 Technical University of Catalonia 706 C/Jordi Girona, s/n 707 08034 Barcelona 708 Spain 710 Email: fcoras@ac.upc.edu 712 Florin Coras 713 Technical University of Catalonia 714 C/Jordi Girona, s/n 715 08034 Barcelona 716 Spain 718 Email: fcoras@ac.upc.edu