idnits 2.17.1 draft-saucez-lisp-impact-07.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 24, 2014) is 3443 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.chiappa-lisp-architecture' is defined on line 564, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-07 ** 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-05 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-introduction-06 == Outdated reference: A later version (-22) exists of draft-ietf-lisp-lcaf-06 == Outdated reference: A later version (-15) exists of draft-ietf-lisp-threats-10 == Outdated reference: A later version (-16) exists of draft-meyer-lisp-mn-11 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 27, 2015 Telecom ParisTech 6 A. Cabellos 7 F. Coras 8 Technical University of Catalonia 9 October 24, 2014 11 LISP Impact 12 draft-saucez-lisp-impact-07.txt 14 Abstract 16 The Locator/Identifier Separation Protocol (LISP) aims at improving 17 the Internet scalability properties leveraging on three simple 18 principles: address role separation, encapsulation, and mapping. In 19 this document, based on implementation, deployment, and theoretical 20 studies, we discuss the impact that deployment of LISP can have on 21 both the Internet in general and for the end-users in particular. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on April 27, 2015. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. LISP in a nutshell . . . . . . . . . . . . . . . . . . . . . 3 59 3. LISP for scaling the Internet . . . . . . . . . . . . . . . . 4 60 4. Beyond scaling the Internet . . . . . . . . . . . . . . . . . 5 61 4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 6 62 4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 7 63 4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . 8 64 5. Impact of LISP on operations and business model . . . . . . . 8 65 5.1. Impact on non-LISP traffic and sites . . . . . . . . . . 8 66 5.2. Impact on LISP traffic and sites . . . . . . . . . . . . 9 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 70 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 9.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 9.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 75 1. Introduction 77 The Locator/Identifier Separation Protocol (LISP) relies on three 78 simple principles to scale the Internet: address role separation, 79 encapsulation, and mapping. The main goal of LISP is to make the 80 Internet more scalable by reducing the number of prefixes announced 81 in the Default Free Zone (DFZ) as well as its related churn. As LISP 82 relies on mapping and encapsulation, it turns out that it provides 83 more benefits than just scalability. For example, LISP provides a 84 mean for a LISP site to precisely control its inter-domain outgoing 85 and incoming traffic, with the possibility to apply different 86 policies to the different domains exchanging traffic with it. LISP 87 can also be used to ease the transition from IPv4 to IPv6 as it 88 allows to transport IPv4 over IPv6 or IPv6 over IPv4. Furthermore, 89 LISP also provides a solution to perform inter-domain multicast. 91 This document discusses the impact of LISP's deployment on the 92 Internet and on end-users and shows the consequences of the 93 interworking infrastructure in path stretch. There still are many, 94 economical rather than technical, open questions related to the 95 deployment of such infrastructure. Moreover, encapsulation may raise 96 some issues (that do not have a real impact in practice) because it 97 reduces the Maximum Transmission Unit (MTU) size. An important 98 impact of LISP on network operations is related to resiliency and 99 troubleshooting. Indeed, as LISP relies on cached mappings and on 100 encapsulation, troubleshooting is harder than in the traditional 101 Internet. Also, end-to-end encapsulation stresses resiliency as it 102 makes failure detection and recovery slower than with hop-by-hop 103 routing. 105 2. LISP in a nutshell 107 The Locator/Identifier Separation Protocol (LISP) relies on three 108 simple principles: address role separation, encapsulation, and 109 mapping. 111 Semantics of address are separated in two: the Routing Locators 112 (RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are assigned from 113 the address space of the Internet service providers (PA). The EIDs 114 are attributed, to the nodes in the edge network, by block of 115 contiguous addresses extracted from the EID Space. To limit the 116 scalability problem of today's Internet, only the routes towards the 117 RLOCs are announced in the Internet while EIDs are also propagated 118 today. 120 LISP routers are used at the boundary between the EID and the RLOC 121 spaces. Routers used to exit the EID space are called Ingress Tunnel 122 Router (ITRs) and those used to enter the EID space the Egress Tunnel 123 Routers (ETRs). When a host sends a packet to a remote destination, 124 it sends it as in today's Internet. The packet eventually arrives at 125 the border of its site at an ITR. Because EIDs are not routable on 126 the Internet, the packet is encapsulated with the source address set 127 to the ITR RLOC and the destination address set to the ETR RLOC. The 128 encapsulated packet is then forwarded in the Internet until it 129 reaches the selected ETR. The ETR decapsulates the packet and 130 forwards it to its final destination. The acronym xTR for Ingress/ 131 Egress tunnel router is used for a router playing these two roles. 133 The correspondence between EIDs and RLOCs is given by the mappings. 134 When an ITR needs to find ETR RLOCs that serve an EID it queries the 135 mapping system. It is worth noticing that with the LISP Canonical 136 Address Format (LCAF) [I-D.ietf-lisp-lcaf], LISP is not restricted to 137 the Internet Protocol for the EID addresses. With LCAF, any address 138 type can be used as EID (the address is the key for the mapping 139 lookup) and LISP can then transport, for example, Ethernet frames 140 over the Internet. 142 A more thorough introduction to LISP can be found in 143 [I-D.ietf-lisp-introduction]. The complete specifications are given 144 in [RFC6830], [RFC6833], [I-D.fuller-lisp-ddt], [RFC6836], [RFC6832], 145 [RFC6834], and [I-D.ietf-lisp-sec]. 147 3. LISP for scaling the Internet 149 The first goal of LISP is to scale the Internet. LISP improves the 150 Internet's scalability because traffic engineering and stub AS 151 prefixes are not propagated in the DFZ, so routing tables are smaller 152 and more stable (i.e., less affected by churn). Also, at the edge 153 network, information necessary to forward packets (i.e., the 154 mappings) is usually obtained on demand using a pull model. 155 Therefore, for each edge network they scale with the traffic matrix 156 of the edge network and are independent of the Internet's size. This 157 scaling improvement is proven by several works. 159 Quoitin et al. show in [QIdLB07] that the separation between locator 160 and identifier roles at the network level improves the routing 161 scalability by reducing the RIB size (up to one order of magnitude) 162 and increases the path diversity and thus the traffic engineering 163 capabilities. In addition, Iannone and Bonaventure show in [IB07] 164 that the number of mapping entries that must be supported at an ITR 165 of a 10,000 users campus network is limited and does not represent 166 more that 3 to 4 Megabytes of memory. Furthermore, they show that 167 signaling traffic (i.e., Map-Request/Map-Reply packets) is in the 168 same order of magnitude like DNS requests traffic and that 169 encapsulation overhead, while not negligible, is very limited (in the 170 order of few percentage points of the total traffic volume). 171 Similarly, Kim et al. show that the EID-to-RLOC cache size should not 172 exceed 14 MB for an ITR responsible of more than 20,000 residential 173 ADSL users at a large ISP [KIF11]. [IB07], [KIF11] rely on BGP and 174 traffic traces to determine the number of entries to keep in the EID- 175 to-RLOC cache. In both papers, the size of the cache is inferred 176 from the number of entries by considering that every EID is 177 associated with two or three locators. [S11] confirms these results 178 by looking at the distribution of the number of locators per EID if 179 LISP were deployed in the 2010's Internet. The assumptions in these 180 studies are: 182 o contiguous addresses tend to be used similarly, EID prefixes 183 follow the current BGP prefixes decomposition; 185 o EIDs are used only at the stub ASes, not in the transit ASes; 187 o the RLOCs of an EID prefix are deployed at the edge between the 188 stubs owning the EID prefix and the providers and locator 189 addresses are allocated in a Provider Aggregetable (PA) mode. 191 While all previous studies consider the case of a timer-based cache 192 eviction policy (i.e., mappings are deleted from the cache upon 193 timeout), [CCD12] generalizes the caching discussion for the Least 194 Recently Used (LRU) eviction policy and proposes an analytic model 195 for the EID-to-RLOC cache size when prefix-level traffic has a 196 stationary generating process. The model shows that miss rate can be 197 accurately predicted from the EID-to-RLOC cache size and a small set 198 of easily measurable traffic parameters. The model was validated 199 using four one-day-long packet traces collected at egress points of a 200 campus network and an academic exchange point considering EID- 201 prefixes as being of BGP-prefix granularity. Consequently, operators 202 can provision the EID-to-RLOC cache of their ITRs according to the 203 miss rate they want to achieve for their given traffic. 205 The results indicate that for a given miss ratio, cache size only 206 depends on the parameters of the popularity distribution and is in 207 fact independent of the number of users (the size of the LISP site) 208 and the number of destinations (the size of the EID-prefix space). 209 Assuming that the popularity distribution remains constant, this 210 means that as the number of users and the number of destinations 211 grow, the cache size needed to obtain a given miss rate remains 212 constant O(1). 214 Under normal user traffic, miss-ratio decreases at an accelerated 215 pace with cache size and finally settles to a power-law decrease. 216 However, [CDLC] extends the model to account for scanning attacks, 217 whereby attackers generate a constant flux of packets according to 218 random scans of the destination prefix space and shows that miss- 219 ratios are be very high and independent of cache size. In fact, if 220 the attack is merely 1% of the legitimate traffic, the miss rate does 221 not drop under 1% as long as the cache cannot accommodate the whole 222 prefix space. Locality measurements also suggested that LRU eviction 223 policy should be close to optimal. 225 TBD: add a paragraph to explain thhe operational difference while 226 dealing with a pull model instead of a push. 228 4. Beyond scaling the Internet 230 Even though it is its main goal, LISP is more than just a scalability 231 solution, it is also a tool to provide both incoming and outgoing 232 traffic engineering [S11], can be used as an IPv6 transition at the 233 routing level, and for inter-domain multicast [RFC6831], 234 [I-D.coras-lisp-re]. LISP has also proven to be a good protocol for 235 mobility of devices in the Internet [I-D.meyer-lisp-mn] or even 236 virtual machine mobility in data centers and multi-tenant VPN, 237 however, we don't further discuss in details the two last points as 238 they are out of the scope of the charter. 240 Lisp architecture facilitates routing in environments where there is 241 little to no correlation between network endpoints and topological 242 location. In service provider environment this use is evident in a 243 range of consumer use cases which require an inline anchor in-order 244 to deliver a service to a subscribers. Inline anchors provide one of 245 three types of capabilities: 247 o enable mobility of subscriber end points 249 o enable chaining of middle-box functions 251 o enable seamless scale-out of functions 253 Without LISP operators are forced to centralize service anchors in 254 custom built special boxes. This means that end-points can move as 255 long as their traffic ends up on the same mobile gateway, functions 256 can be chained as long as all traffic traverses the same wire or the 257 same DPI box, and capacity can scale out as long as traffic fans out 258 to and form a specific load balancer. 260 With LISP service providers are able to distribute, virtualize, and 261 insatiate subscriber-service anchors anywhere in the network. 262 Typical use cases that Virtualize inline anchors and network 263 functions include: Distributed Mobility and Virtualized Evolved 264 Packet Core (vEPC), where centralization makes way to distributed and 265 virtualized inline anchoring of mobility, Virtualized Customer 266 Premise Equipment or vCPE, where functionality previously anchored at 267 customer prem is now dynamically allocated in-network, Virtualized 268 SGi LAN, where value added mobile services previously anchored inside 269 full-stack boxes or anchored to physical wires with permutation 270 setups aka "Rails", Virtual IMS and Virtual SBC, etc. 272 Current deployments by ConteXtream, using a pre standards (designed 273 2006) based architecture, support a total of 100 millions subscribers 274 with such an architecture. A deployment at a tier-1 US Mobile 275 operator over 50 millions subscribers provides a 39% download rate 276 improvement over LTE. 278 4.1. Traffic engineering 280 In today's Internet, stub networks are globally routable and the 281 routing system distributes the routes to reach these stubs. On the 282 contrary, the EID prefixes of a LISP site are not routable on the 283 Internet and mappings are needed to determine the list of LISP 284 routers to contact to send them packets. The difference is 285 significant for two reasons. First, packets are not sent to a site 286 but to a specific ingress router. Second, a site can control the 287 entry points for its traffic by controlling its mappings. 289 For traffic engineering purpose, a mapping associates an EID prefix 290 to a list of RLOCs. Each RLOC is annotated with a priority and a 291 weight. When there are several RLOCs, the ITR selects the one with 292 the lowest priority value and sends the encapsulated packet to this 293 RLOC. If several such RLOCs exist, then the traffic is balanced 294 proportionally to their weight among the RLOCs with the lowest 295 priority value. Traffic engineering in LISP thus allows the mapping 296 owner to have a fine-grained control on the primary and backup path 297 its incoming and outgoing packets use. In addition, it can share the 298 load among its links. An example of the use of such a feature is 299 described in [SDIB08], where Saucez et al. show how to use LISP to 300 direct different types of traffic on different links having different 301 capacity. 303 Traffic engineering in LISP goes one step further. As every Map- 304 Request contains the Source EID Address of the packet that caused a 305 cache miss and triggered the Map-Request. It is thus possible for a 306 mapping owner to differentiate the answer (Map-Reply) it gives to 307 Map-Requests based on the requester. This functionality is not 308 available today with BGP because a domain cannot control exactly the 309 routes that will be received by domains that are not in the direct 310 neighborhood. 312 4.2. LISP for IPv6 Co-existence 314 The LISP encapsulation mechanism is designed to support any 315 combination of locators and identifiers address family. It is then 316 possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa. This 317 allows transporting IPv6 packets over an IPv4 network (or IPv4 318 packets over an IPv6 network), making LISP a valuable mechanism to 319 ease the transition to IPv6. 321 A not so uncommon example is the case of the network infrastructure 322 of a datacenter being IPv4-only while dual-stack front-end load 323 balancers are used. In this scenario, LISP can be used to provide 324 IPv6 access to servers even though the network and the servers only 325 support IPv4. Assuming that the datacenter's ISP offers IPv6 326 connectivity, the datacenter only needs to deploy one (or more) 327 xTR(s) at its border with the ISP and one (or more) xTR(s) directly 328 connected to the load balancers. The xTR(s) at the ISP's border 329 tunnels IPv6 packets over IPv4 to the xTR(s) directly attached to the 330 load balancer. The load balancer's xTR decapsulates the packets and 331 forward them to the load balancer, which act as proxies, translating 332 each IPv6 packet into an IPv4. IPv4 packets are then sent to the 333 appropriate servers. Similarly, when the server's response arrives 334 at the load balancer, the packet is translated back into an IPv6 335 packet and forwarded to its xTR(s), which in turn will tunnel it 336 back, over the IPv4-only infrastructure, to an xTR connected to the 337 ISP. The packet is then decapsulated and forwarded to the ISP 338 natively in IPv6. 340 4.3. Inter-domain multicast 342 LISP has native support for multicast [RFC6831]. From the data-plane 343 perspective, at a multicast enabled xTR, an EID sourced multicast 344 packet is encapsulated in another multicast packet and subsequently 345 forwarded in a RLOC-level distribution tree. Therefore, xTRs must 346 participate in both EID and RLOC level distribution trees. Control- 347 plane wise, since group addresses have no topological significance 348 they need not be mapped. It is worth noting that, to properly 349 function inter-domain, LISP-Multicast requires that inter-domain 350 multicast be prior deployed. 352 [I-D.coras-lisp-re] and [CDM12] propose a technique to construct xTR 353 based inter-domain multicast distribution trees. Simulations of 354 three different management strategies for low latency content 355 delivery show that such overlays can support thousands of member 356 xTRs, hundreds of thousands of end-hosts and deliver content at 357 latencies close to unicast ones [CDM12]. It was also observed that 358 high client churn has a limited impact on performance and management 359 overhead. 361 5. Impact of LISP on operations and business model 363 Important implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], 364 [LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the 365 specifications and interoperability tests [Was09] have been a 366 success. World-wide large deployment in the international lisp4.net 367 testbed, which is currently composed of nodes running at least three 368 different implementations, allows to learn operational matters 369 related to LISP. 371 We have to distinguish the impact of LISP on LISP sites from the 372 impact on non-LISP sites. 374 5.1. Impact on non-LISP traffic and sites 376 LISP has no impact on traffic which has neither LISP origin nor LISP 377 destination. However, LISP can have a significant impact on traffic 378 between a LISP site and a non-LISP site. Traffic between a non-LISP 379 site and a LISP site are subject to the same issues than those 380 observed for LISP-to-LISP traffic (cf infra) but also have issues 381 specific to the transition mechanism that allow LISP site to exchange 382 packets with non-LISP site ([RFC6832], [I-D.ietf-lisp-deployment]). 384 Indeed, the transition requires to setup proxy tunnel routers 385 (PxTRs). PxTRs do not cause particular technical issue. However, by 386 definition proxies cause path stretch and make troubleshooting 387 harder. There are still big questions related to PxTRs that have to 388 be answered: 390 o Where to deploy PxTRs? The placement in the topology has an 391 important impact on the path stretch. 393 o How many PxTRs? The number of PxTR has a direct impact on the 394 load and the impact of the failure of a PxTR on the traffic. 396 o What part of the EID space? Will all the PxTRs be proxies for the 397 whole EID space or will it be segmented between different PxTRs? 399 o Who to operate PxTRs? The IETF does not aim at providing business 400 model hints, however, an important question to answer is related 401 to the entities that will deploy PxTRs, how they will manage their 402 CAPEX/OPEX and how the traffic will be carried with respect for 403 the security and privacy. 405 PxTR also normally have to advertise in BGP the EID prefix they are 406 proxy for. However, if proxies are managed by different entities, 407 they will belong to different ASes. In this case, we have to be sure 408 that it will not cause MOA issues that could negatively influence 409 routing. Moreover, we have to be sure that the way EID prefixes will 410 be deaggregated by the proxies will remain reasonable to not take 411 part in the BGP scalability issues. 413 5.2. Impact on LISP traffic and sites 415 LISP is a protocol based on the map-and-encap paradigm which has the 416 positive effects that we have given in the sections above. However, 417 by design, LISP also has side impact on operations: 419 MTU issue: as LISP uses encapsulation, the MTU is reduced, this has 420 implication on potentially all the traffic. However, in 421 practice, on the lisp4.net network, no major issue due to the 422 MTU has been observed. This is probably due to the fact that 423 current end-host stacks are well designed to deal with the 424 problem of MTU. 426 Resiliency issue: the advantage of flexibility and control offered 427 by the Locator/ID separation comes at the cost of increasing 428 the complexity of the reachability detection. Indeed, 429 identifiers are not directly routable and have to be mapped to 430 locators but a locator may be unreachable while others are 431 still reachable. This is an important problem for any tunnel- 432 based solution. In the current Internet, packets are forwarded 433 independently of the border router of the network meaning that 434 in case of the failure of a border router, another one can be 435 used. With LISP, the destination RLOC specifically designate 436 one particular ETR, hence if this ETR fails, the traffic is 437 dropped even though other ETRs are available for the 438 destination site. Another resiliency issue is linked to the 439 fact that mappings are learned on demand. When an ITR fails, 440 all its traffic is redirected to other ITRs that might not have 441 yet the mappings for the redirected traffic. The study in 442 [SKI12] and [SD12] show, based on measurements and traffic 443 traces, that failure of ITRs and RLOC are infrequent but that 444 when such failure happens, an important number of packet can be 445 dropped. Unfortunately, the current techniques for LISP 446 resiliency, based on monitoring or probing are not rapid enough 447 (failure recovery of the order of a few seconds). To tackle 448 this issue [I-D.bonaventure-lisp-preserve] and 449 [I-D.saucez-lisp-itr-graceful] propose techniques based on 450 local failure detection and recovery. 452 Middle boxes/filters: because of encapsulation, the middle boxes 453 might not understand the traffic which can cause firewall to 454 drop legitimate packets. In addition, LISP allows triangular 455 or even rectangular routing, so it is hard to maintain a 456 correct state even if the middle box perfectly understands 457 LISP. Finally, filtering might also have problems because they 458 might think only one host is generating the traffic (the ITR), 459 as long as it is not decapsulated. To deal with LISP 460 encapsulation, LISP aware firewalls that inspect inner LISP 461 packets are proposed [lispfirewall]. 463 Troubleshooting/debugging: the major issue years of LISP 464 experimentation have shown is the difficulty of 465 troubleshooting. When there is a problem in the network, it is 466 hard to pin-point the reason as the operator only has a partial 467 view of the network. The operator can see what is in its EID- 468 to-RLOC cache/database, and can try to obtain what is 469 potentially elsewhere by querying the Map Resolvers but the 470 knowledge remains partial. On top of that, ICMP is too small, 471 which means that when an ICMP arrives at the ITR, it might not 472 contain enough information to make correct troubleshooting. 473 Interestingly, deployment in the beta network has shown that 474 LISP+ALT was not easy to maintain and control, which explains 475 the migration to LISP-DDT [I-D.fuller-lisp-ddt]. 477 Business: the IETF is not aiming at providing business models. 478 However, even though [IL10] shown that there is economical 479 incentives to migrate to LISP, some questions are on hold. For 480 example, how will the EIDs be allocated to allow aggregation 481 and hence scalability of the mapping system? Who will operate 482 the mapping system infrastructure and for what benefit? 484 6. IANA Considerations 486 This document makes no request to the IANA. 488 7. Security Considerations 490 Security and threats analysis of the LISP protocol is out of the 491 scope of the present document. A thorough analysis of LISP security 492 threats is detailed in [I-D.ietf-lisp-threats]. 494 8. Acknowledgments 496 The people that contributed to this document are Sharon Barkai, Vince 497 Fuller, Joel Halpern, Terry Manderson, and Gregg Schudel. 499 9. References 501 9.1. Normative References 503 [I-D.fuller-lisp-ddt] 504 Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP 505 Delegated Database Tree", draft-fuller-lisp-ddt-04 (work 506 in progress), September 2012. 508 [I-D.ietf-lisp-deployment] 509 Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 510 Pascual, J., and D. Lewis, "LISP Network Element 511 Deployment Considerations", draft-ietf-lisp-deployment-12 512 (work in progress), January 2014. 514 [I-D.ietf-lisp-sec] 515 Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D. 516 Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07 517 (work in progress), October 2014. 519 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 520 Locator/ID Separation Protocol (LISP)", RFC 6830, January 521 2013. 523 [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The 524 Locator/ID Separation Protocol (LISP) for Multicast 525 Environments", RFC 6831, January 2013. 527 [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 528 "Interworking between Locator/ID Separation Protocol 529 (LISP) and Non-LISP Sites", RFC 6832, January 2013. 531 [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation 532 Protocol (LISP) Map-Server Interface", RFC 6833, January 533 2013. 535 [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID 536 Separation Protocol (LISP) Map-Versioning", RFC 6834, 537 January 2013. 539 [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, 540 "Locator/ID Separation Protocol Alternative Logical 541 Topology (LISP+ALT)", RFC 6836, January 2013. 543 9.2. Informative References 545 [CCD12] Coras, F., Cabellos-Aparicio, A., and J. Domingo-Pascual, 546 "An Analytical Model for the LISP Cache Size", In Proc. 547 IFIP Networking 2012, May 2012. 549 [CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An 550 Analytical Model for Loc/ID Mappings Caches", Technical 551 Report http://arxiv.org/pdf/1312.1378v2.pdf, 2013. 553 [CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., 554 and A. Cabellos-Aparicio, "Lcast: Software-defined Inter- 555 Domain Multicast", Technical Report, Universitat 556 Politecnica de Catalunya, 2012, July 2012. 558 [I-D.bonaventure-lisp-preserve] 559 Bonaventure, O., Francois, P., and D. Saucez, "Preserving 560 the reachability of LISP ETRs in case of failures", draft- 561 bonaventure-lisp-preserve-00 (work in progress), July 562 2009. 564 [I-D.chiappa-lisp-architecture] 565 Art, Y., "An Architectural Perspective on the LISP 566 Location-Identity Separation System", draft-chiappa-lisp- 567 architecture-01 (work in progress), July 2012. 569 [I-D.coras-lisp-re] 570 Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., 571 Maino, F., and D. Farinacci, "LISP Replication 572 Engineering", draft-coras-lisp-re-05 (work in progress), 573 April 2014. 575 [I-D.ietf-lisp-introduction] 576 Cabellos-Aparicio, A. and D. Saucez, "An Architectural 577 Introduction to the Locator/ID Separation Protocol 578 (LISP)", draft-ietf-lisp-introduction-06 (work in 579 progress), October 2014. 581 [I-D.ietf-lisp-lcaf] 582 Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical 583 Address Format (LCAF)", draft-ietf-lisp-lcaf-06 (work in 584 progress), October 2014. 586 [I-D.ietf-lisp-threats] 587 Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats 588 Analysis", draft-ietf-lisp-threats-10 (work in progress), 589 July 2014. 591 [I-D.meyer-lisp-mn] 592 Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP 593 Mobile Node", draft-meyer-lisp-mn-11 (work in progress), 594 July 2014. 596 [I-D.saucez-lisp-itr-graceful] 597 Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, 598 "LISP ITR Graceful Restart", draft-saucez-lisp-itr- 599 graceful-03 (work in progress), December 2013. 601 [IB07] Iannone, L. and O. Bonaventure, "On the cost of caching 602 locator/id mappings", In Proc. ACM CoNEXT 2007, December 603 2007. 605 [IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID 606 Separation for the Future Internet", Book Chapter, Towards 607 the Future Internet - Emerging Trends from the European 608 Research, IOS Press, May 2010. 610 [IOSNXOS] Cisco Systems Inc., , "Locator/ID Separation Protocol 611 (LISP)", http://lisp4.cisco.com, 2013. 613 [KIF11] Kim, J., Iannone, L., and A. Feldmann, "Deep dive into the 614 lisp cache and what isps should know about it", In Proc. 615 IFIP Networking 2011, May 2011. 617 [LISPClick] 618 Saucez, D. and V. Nguyen, "LISP-Click: A Click 619 implementation of the Locator/ID Separation Protocol", 1st 620 Symposium on Click Modular Router, 2009, November 2009. 622 [LISPcp] "The lip6-lisp Project", https://github.com/lip6-lisp/, 623 2014. 625 [LISPfritz] 626 "Unsere FRITZ!Box-Produkte", 627 http://avm.de/produkte/fritzbox/, 2014. 629 [LISPmob] "LISP Mobile Node for Linux", http://lispmob.org, 2013. 631 [OpenLISP] 632 "The OpenLISP Project", http://www.openlisp.org, 2013. 634 [QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. 635 Bonaventure, "Evaluating the benefits of the locator/ 636 identifier separation", In Proc. ACM MobiArch 2007, May 637 2007. 639 [S11] Saucez, D., "Mechanisms for Interdomain Traffic 640 Engineering with LISP", PhD Thesis, Universite catholique 641 de Louvain, 2011, October 2011. 643 [SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in 644 LISP", In Proc. IFIP Networking 2012, May 2012. 646 [SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, 647 "Interdomain Traffic Engineering in a Locator/Identifier 648 Separation Context", In Proc. of Internet Network 649 Management Workshop, 2008, October 2008. 651 [SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. 652 Filsfils, "A Local Approach to Fast Failure Recovery of 653 LISP Ingress Tunnel Routers", In Proc. IFIP Networking 654 2012, May 2012. 656 [Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, 657 LISP WG presentation, 2009., November 2009. 659 [lispfirewall] 660 "LISP and Zone-Based Firewalls Integration and 661 Interoperability", http://www.cisco.com/c/en/us/td/docs/ 662 ios-xml/ios/sec_data_zbf/configuration/xe-3s/ 663 sec-data-zbf-xe-book/sec-zbf-lisp-inner-pac-insp.html, 664 2014. 666 Authors' Addresses 668 Damien Saucez 669 INRIA 670 2004 route des Lucioles BP 93 671 06902 Sophia Antipolis Cedex 672 France 674 Email: damien.saucez@inria.fr 676 Luigi Iannone 677 Telecom ParisTech 678 23, Avenue d'Italie, CS 51327 679 75214 PARIS Cedex 13 680 France 682 Email: luigi.iannone@telecom-paristech.fr 684 Albert Cabellos 685 Technical University of Catalonia 686 C/Jordi Girona, s/n 687 08034 Barcelona 688 Spain 690 Email: fcoras@ac.upc.edu 692 Florin Coras 693 Technical University of Catalonia 694 C/Jordi Girona, s/n 695 08034 Barcelona 696 Spain 698 Email: fcoras@ac.upc.edu