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