idnits 2.17.1 draft-jakab-lisp-deployment-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 == Line 471 has weird spacing: '...ructure x ...' -- The document date (April 8, 2011) is 4767 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-10 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-06 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-01 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-07 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Jakab 3 Internet-Draft A. Cabellos-Aparicio 4 Intended status: Informational F. Coras 5 Expires: October 10, 2011 J. Domingo-Pascual 6 Technical University of Catalonia 7 D. Lewis 8 Cisco Systems 9 April 8, 2011 11 LISP Network Element Deployment Considerations 12 draft-jakab-lisp-deployment-03.txt 14 Abstract 16 This document discusses the different scenarios for the deployment of 17 the new network elements introduced by the Locator/Identifier 18 Separation Protocol (LISP). 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on October 10, 2011. 37 Copyright Notice 39 Copyright (c) 2011 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 6 59 2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 60 2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10 61 2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 64 3. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 11 65 3.1. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 11 66 3.2. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 12 67 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13 68 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.1.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.1.2. Mapping Service Provider P-ITR Service . . . . . . . . 15 71 4.1.3. Tier 1 P-ITR Service . . . . . . . . . . . . . . . . . 15 72 4.1.4. Migration Summary . . . . . . . . . . . . . . . . . . 17 73 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 17 74 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 75 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 77 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 8.1. Normative References . . . . . . . . . . . . . . . . . . . 19 79 8.2. Informative References . . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 82 1. Introduction 84 The Locator/Identifier Separation Protocol (LISP) addresses the 85 scaling issues of the global Internet routing system by separating 86 the current addressing scheme into Endpoint IDentifiers (EIDs) and 87 Routing LOCators (RLOCs). The main protocol specification 88 [I-D.ietf-lisp] describes how the separation is achieved, which new 89 network elements are introduced, and details the packet formats for 90 the data and control planes. 92 While the boundary between the core and edge is not strictly defined, 93 one widely accepted definition places it at the border routers of 94 stub autonomous systems, which may carry a partial or complete 95 default-free zone (DFZ) routing table. The initial design of LISP 96 took this location as a baseline for protocol development. However, 97 the applications of LISP go beyond of just decreasing the size of the 98 DFZ routing table, and include improved multihoming and ingress 99 traffic engineering (TE) support for edge networks, and even 100 individual hosts. Throughout the draft we will use the term LISP 101 site to refer to these networks/hosts behind a LISP Tunnel Router. 102 We formally define it as: 104 LISP site: A single host or a set of network elements in an edge 105 network under the administrative control of a single organization, 106 delimited from other networks by LISP Tunnel Router(s). 108 Since LISP is a protocol which can be used for different purposes, it 109 is important to identify possible deployment scenarios and the 110 additional requirements they may impose on the protocol specification 111 and other protocols. The main specification [I-D.ietf-lisp] mentions 112 positioning of tunnel routers, but without an in-depth discussion. 113 This document fills that gap, by exploring the most common cases. 114 While the theoretical combinations of device placements are quite 115 numerous, the more practical scenarios are given preference in the 116 following. 118 Additionally, this documents is intended as a guide for the 119 operational community for LISP deployments in their networks. It is 120 expected to evolve as LISP deployment progresses, and the described 121 scenarios are better understood or new scenarios are discovered. 123 Each subsection considers an element type, discussing the impact of 124 deployment scenarios on the protocol specification. For definition 125 of terms, please refer to the appropriate documents (as cited in the 126 respective sections). 128 Comments and discussions about this memo should be directed to the 129 LISP working group mailing list: lisp@ietf.org. 131 2. Tunnel Routers 133 LISP is a map-and-encap protocol, with the main goal of improving 134 global routing scalability. To achieve its goal, it introduces 135 several new network elements, each performing specific functions 136 necessary to separate the edge from the core. The device that is the 137 gateway between the edge and the core is called Tunnel Router (xTR), 138 performing one or both of two separate functions: 140 1. Encapsulating packets originating from an end host to be 141 transported over intermediary (transit) networks towards the 142 other end-point of the communication 144 2. Decapsulating packets entering from intermediary (transit) 145 networks, originated at a remote end host. 147 The first function is performed by an Ingress Tunnel Router (ITR), 148 the second by an Egress Tunnel Router (ETR). 150 Section 8 of the main LISP specification [I-D.ietf-lisp] has a short 151 discussion of where Tunnel Routers can be deployed and some of the 152 associated advantages and disadvantages. This section adds more 153 detail to the scenarios presented there, and provides additional 154 scenarios as well. 156 2.1. Customer Edge 158 LISP was designed with deployment at the core-edge boundary in mind, 159 which can be approximated as the set of DFZ routers belonging to non- 160 transit ASes. For the purposes of this document, we will consider 161 this boundary to be consisting of the routers connecting LISP sites 162 to their upstreams. As such, this is the most common expected 163 scenario for xTRs, and this document considers it the reference 164 location, comparing the other scenarios to this one. 166 ISP1 ISP2 167 | | 168 | | 169 +----+ +----+ 170 +--|xTR1|--|xTR2|--+ 171 | +----+ +----+ | 172 | | 173 | LISP site | 174 +------------------+ 176 Figure 1: xTRs at the customer edge 178 From the LISP site perspective the main advantage of this type of 179 deployment (compared to the one described in the next section) is 180 having direct control over its ingress traffic engineering. This 181 makes it is easy to set up and maintain active/active, active/backup, 182 or more complex TE policies, without involving third parties. 184 Being under the same administrative control, reachability information 185 of all ETRs is easier to synchronize, because the necessary control 186 traffic can be allowed between the locators of the ETRs. A correct 187 synchronous global view of the reachability status is thus available, 188 and the Loc-Status-Bits can be set correctly in the LISP data header 189 of outgoing packets. 191 By placing the tunnel router at the edge of the site, existing 192 internal network configuration does not need to be modified. 193 Firewall rules, router configurations and address assignments inside 194 the LISP site remain unchanged. This helps with incremental 195 deployment and allows a quick upgrade path to LISP. For larger sites 196 with many external connections, distributed in geographically diverse 197 PoPs, and complex internal topology, it may however make more sense 198 to both encapsulate and decapsulate as soon as possible, to benefit 199 from the information in the IGP to choose the best path (see 200 Section 2.3 for a discussion of this scenario). 202 Another thing to consider when placing tunnel routers are MTU issues. 203 Since encapsulating packets increases overhead, the MTU of the end- 204 to-end path may decrease, when encapsulated packets need to travel 205 over segments having close to minimum MTU. Some transit networks are 206 known to provide larger MTU than the typical value of 1500 bytes of 207 popular access technologies used at end hosts (e.g., IEEE 802.3 and 208 802.11). However, placing the LISP router connecting to such a 209 network at the customer edge could possibly bring up MTU issues, 210 depending on the link type to the provider as opposed to the 211 following scenario. 213 2.2. Provider Edge 215 The other location at the core-edge boundary for deploying LISP 216 routers is at the Internet service provider edge. The main incentive 217 for this case is that the customer does not have to upgrade the CE 218 router(s), or change the configuration of any equipment. 219 Encapsulation/decapsulation happens in the provider's network, which 220 may be able to serve several customers with a single device. For 221 large ISPs with many residential/business customers asking for LISP 222 this can lead to important savings, since there is no need to upgrade 223 the software (or hardware, if it's the case) at each client's 224 location. Instead, they can upgrade the software (or hardware) on a 225 few PE routers serving the customers. This scenario is depicted in 226 Figure 2. 228 +----------+ +------------------+ 229 | ISP1 | | ISP2 | 230 | | | | 231 | +----+ | | +----+ +----+ | 232 +--|xTR1|--+ +--|xTR2|--|xTR3|--+ 233 +----+ +----+ +----+ 234 | | | 235 | | | 236 +--<[LISP site]>---+-------+ 238 Figure 2: xTR at the PE 240 While this approach can make transition easy for customers and may be 241 cheaper for providers, the LISP site looses one of the main benefits 242 of LISP: ingress traffic engineering. Since the provider controls 243 the ETRs, additional complexity would be needed to allow customers to 244 modify their mapping entries. 246 The problem is aggravated when the LISP site is multihomed. Consider 247 the scenario in Figure 2: whenever a change to TE policies is 248 required, the customer contacts both ISP1 and ISP2 to make the 249 necessary changes on the routers (if they provide this possibility). 250 It is however unlikely, that both ISPs will apply changes 251 simultaneously, which may lead to inconsistent state for the mappings 252 of the LISP site (e.g., weights for the same priority don't sum 100). 253 Since the different upstream ISPs are usually competing business 254 entities, the ETRs may even be configured to compete, either to 255 attract all the traffic or to get no traffic. The former will happen 256 if the customer pays per volume, the latter if the connectivity has a 257 fixed price. A solution could be to have the mappings in the Map- 258 Server(s), and have their operator give control over the entries to 259 customer, much like in today's DNS. 261 Additionally, since xTR1, xTR2, and xTR3 are in different 262 administrative domains, locator reachability information is unlikely 263 to be exchanged among them, making it difficult to set Loc-Status- 264 Bits correctly on encapsulated packets. 266 Compared to the customer edge scenario, deploying LISP at the 267 provider edge might have the advantage of diminishing potential MTU 268 issues, because the tunnel router is closer to the core, where links 269 typically have higher MTUs than edge network links. 271 2.3. Split ITR/ETR 273 In a simple LISP deployment, xTRs are located at the border of the 274 LISP site (see Section 2.1). In this scenario packets are routed 275 inside the domain according to the EID. However, more complex 276 networks may want to route packets according to the destination RLOC. 277 This would enable them to choose the best egress point. 279 The LISP specification separates the ITR and ETR functionality and 280 considers that both entities can be deployed in separated network 281 equipment. ITRs can be deployed closer to the host (i.e., access 282 routers). This way packets are encapsulated as soon as possible, and 283 packets exit the network through the best egress point in terms of 284 BGP policy. In turn, ETRs can be deployed at the border routers of 285 the network, and packets are decapsulated as soon as possible. 286 Again, once decapsulated packets are routed according to the EID, and 287 can follow the best path according to internal routing policy. 289 In the following figure we can see an example. The Source (S) 290 transmits packets using its EID and in this particular case packets 291 are encapsulated at ITR_1. The encapsulated packets are routed 292 inside the domain according to the destination RLOC, and can egress 293 the network through the best point (i.e., closer to the RLOC's AS). 294 On the other hand, inbound packets are received by ETR_1 which 295 decapsulates them. Then packets are routed towards S according to 296 the EID, again following the best path. 298 +---------------------------------------+ 299 | | 300 | +-------+ +-------+ +-------+ 301 | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | 302 | +-------+ | +-------+ +-------+ 303 | +-+ | | | 304 | |S| | IGP | | 305 | +-+ | | | 306 | +-------+ | +-------+ +-------+ 307 | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | 308 | +-------+ +-------+ +-------+ 309 | | 310 +---------------------------------------+ 312 Figure 3: Split ITR/ETR Scenario 314 This scenario has a set of implications: 316 o The site must carry at least partial BGP routes in order to choose 317 the best egress point, increasing the complexity of the network. 318 However, this is usually already the case for LISP sites that 319 would benefit from this scenario. 321 o If the site is multihomed to different ISPs and any of the 322 upstream ISPs is doing uRPF filtering, this scenario may become 323 impractical. ITRs need to determine the exit ETR, for setting the 324 correct source RLOC in the encapsulation header. This adds 325 complexity and reliability concerns. 327 o In LISP, ITRs set the reachability bits when encapsulating data 328 packets. Hence, ITRs need a mechanism to be aware of the liveness 329 of ETRs. 331 o ITRs encapsulate packets and in order to achieve efficient 332 communications, the MTU of the site must be large enough to 333 accommodate this extra header. 335 o In this scenario, each ITR is serving fewer hosts than in the case 336 when it is deployed at the border of the network. It has been 337 shown that cache hit ratio grows logarithmically with the amount 338 of users [cache]. Taking this into account, when ITRs are 339 deployed closer to the host the effectiveness of the mapping cache 340 may be lower (i.e., the miss ratio is higher). Another 341 consequence of this is that the site will transmit a higher amount 342 of Map-Requests, increasing the load on the distributed mapping 343 database. 345 2.4. Inter-Service Provider Traffic Engineering 347 With LISP, two LISP sites can route packets among them and control 348 their ingress TE policies. Typically, LISP is seen as applicable to 349 stub networks, however the LISP protocol can also be applied to 350 transit networks recursively. 352 Consider the scenario depicted in Figure 4. Packets originating from 353 the LISP site Stub1, client of ISP_A, with destination Stub4, client 354 of ISP_B, are LISP encapsulated at their entry point into the ISP_A's 355 network. The external IP header now has as the source RLOC an IP 356 from ISP_A's address space (R_A1, R_A2, or R_A3) and destination RLOC 357 from ISP_B's address space (R_B1 or R_B2). One or more ASes separate 358 ISP_A from ISP_B. With a single level of LISP encapsulation, Stub4 359 has control over its ingress traffic. However, ISP_B only has the 360 current tools (such as BGP prefix deaggregation) to control on which 361 of his own upstream or peering links should packets enter. This is 362 either not feasible (if fine-grained per-customer control is 363 required, the very specific prefixes may not be propagated) or 364 increases DFZ table size. 366 _.--. 367 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 368 \ | R_A1|----,' `. ---|R_B1 | / 369 --| R_A2|---( Transit ) | |-- 370 Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 371 +-------+ `--. _.-' +-------+ 372 ... ISP_A `--'' ISP_B ... 374 Figure 4: Inter-Service provider TE scenario 376 A solution for this is to apply LISP recursively. ISP_A and ISP_B 377 may reach a bilateral agreement to deploy their own private mapping 378 system. ISP_A then encapsulates packets destined for the prefixes of 379 ISP_B, which are listed in the shared mapping system. Note that in 380 this case the packet is double-encapsulated. ISP_B's ETR removes the 381 outer, second layer of LISP encapsulation from the incoming packet, 382 and routes it towards the original RLOC, the ETR of Stub4, which does 383 the final decapsulation. 385 If ISP_A and ISP_B agree to share a private distributed mapping 386 database, both can control their ingress TE without the need of 387 disaggregating prefixes. In this scenario the private database 388 contains RLOC-to-RLOC bindings. The convergence time on the TE 389 policies updates is expected to be fast, since ISPs only have to 390 update/query a mapping to/from the database. 392 This deployment scenario includes two important recommendations. 393 First, it is intended to be deployed only between two ISPs (ISP_A and 394 ISP_B in Figure 4). If more than two ISPs use this approach, then 395 the xTRs deployed at the participating ISPs must either query 396 multiple mapping systems, or the ISPs must agree on a common shared 397 mapping system. Second, the scenario is only recommended for ISPs 398 providing connectivity to LISP sites, such that source RLOCs of 399 packets to be reencapsulated belong to said ISP. Otherwise the 400 participating ISPs must register prefixes they do not own in the 401 above mentioned private mapping system. Failure to follow these 402 recommendations may lead to operational and security issues when 403 deploying this scenario. 405 Besides these recommendations, the main disadvantages of this 406 deployment case are: 408 o Extra LISP header is needed. This increases the packet size and, 409 for efficient communications, it requires that the MTU between 410 both ISPs can accommodate double-encapsulated packets. 412 o The ISP ITR must encapsulate packets and therefore must know the 413 RLOC-to-RLOC binding. These bindings are stored in a mapping 414 database and may be cached in the ITR's mapping cache. Cache 415 misses lead to an extra lookup latency, unless NERD 416 [I-D.lear-lisp-nerd] is used for the lookups. 418 o The operational overhead of maintaining the shared mapping 419 database. 421 2.5. Tunnel Routers Behind NAT 423 NAT in this section refers to IPv4 network address and port 424 translation. 426 2.5.1. ITR 428 Packets encapsulated by an ITR are just UDP packets from a NAT 429 device's point of view, and they are handled like any UDP packet, 430 there are no additional requirements for LISP data packets. 432 Map-Requests sent by an ITR, which create the state in the NAT table 433 have a different 5-tuple in the IP header than the Map-Reply 434 generated by the authoritative ETR. Since the source address of this 435 packet is different from the destination address of the request 436 packet, no state will be matched in the NAT table and the packet will 437 be dropped. To avoid this, the NAT device has to do the following: 439 o Send all UDP packets with source port 4342, regardless of the 440 destination port, to the RLOC of the ITR. The most simple way to 441 achieve this is configuring 1:1 NAT mode from the external RLOC of 442 the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer 443 broadband routers). 445 o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in 446 the payload. 448 This setup supports a single ITR behind the NAT device. 450 2.5.2. ETR 452 An ETR placed behind NAT is reachable from the outside by the 453 Internet-facing locator of the NAT device. It needs to know this 454 locator (and configure a loopback interface with it), so that it can 455 use it in Map-Reply and Map-Register messages. Thus support for 456 dynamic locators for the mapping database is needed in LISP 457 equipment. 459 Again, only one ETR behind the NAT device is supported. 461 An implication of the issues described above is that LISP sites with 462 xTRs can not be behind carrier based NATs, since two different sites 463 would collide on the port forwarding. 465 2.6. Summary and Feature Matrix 467 Feature CE PE Split Rec. 468 -------------------------------------------------------- 469 Control of ingress TE x - x x 470 No modifications to existing 471 int. network infrastructure x x - - 472 Loc-Status-Bits sync x - x x 473 MTU/PMTUD issues minimized - x - x 475 3. Map-Resolvers and Map-Servers 477 3.1. Map-Servers 479 The Map-Server learns EID-to-RLOC mapping entries from an 480 authoritative source and publishes them in the distributed mapping 481 database. These entries are learned through authenticated Map- 482 Register messages sent by authoritative ETRs. Also, upon reception 483 of a Map-Request, the Map-Server verifies that the destination EID 484 matches an EID-prefix for which it is responsible for, and then re- 485 encapsulates and forwards it to a matching ETR. Map-Server 486 functionality is described in detail in [I-D.ietf-lisp-ms]. 488 The Map-Server is provided by a Mapping Service Provider (MSP). A 489 MSP can be any of the following: 491 o EID registrar. Since the IPv4 address space is nearing 492 exhaustion, IPv4 EIDs will come from already allocated Provider 493 Independent (PI) space. The registrars in this case remain the 494 current five Regional Internet Registries (RIRs). In the case of 495 IPv6, the possibility of reserving a /16 block as EID space is 496 currently under consideration [I-D.meyer-lisp-eid-block]. If 497 granted by IANA, the community will have to determine the body 498 responsible for allocations from this block, and the associated 499 policies. For already allocated IPv6 prefixes the principles from 500 IPv4 should be applied. 502 o Third parties. Participating in the LISP mapping system is 503 similar to participating in global routing or DNS: as long as 504 there is at least another already participating entity willing to 505 forward the newcomer's traffic, there is no barrier to entry. 506 Still, just like routing and DNS, LISP mappings have the issue of 507 trust, with efforts underway to make the published information 508 verifiable. When these mechanisms will be deployed in the LISP 509 mapping system, the burden of providing and verifying trust should 510 be kept away from MSPs, which will simply host the secured 511 mappings. This will keep the low barrier of entry to become an 512 MSP for third parties. 514 In all cases, the MSP configures its Map-Server(s) to publish the 515 prefixes of its clients in the distributed mapping database and start 516 encapsulating and forwarding Map-Requests to the ETRs of the AS. 517 These ETRs register their prefix(es) with the Map-Server(s) through 518 periodic authenticated Map-Register messages. In this context, for 519 some LISP end sites, there is a need for mechanisms to: 521 o Automatically distribute EID prefix(es) shared keys between the 522 ETRs and the EID-registrar Map-Server. 524 o Dynamically obtain the address of the Map-Server in the ETR of the 525 AS. 527 The Map-Server plays a key role in the reachability of the EID- 528 prefixes it is serving. On the one hand it is publishing these 529 prefixes into the distributed mapping database and on the other hand 530 it is encapsulating and forwarding Map-Requests to the authoritative 531 ETRs of these prefixes. ITRs encapsulating towards EIDs under the 532 responsibility of a failed Map-Server will be unable to look up any 533 of their covering prefixes. The only exception are the ITRs that 534 already contain the mappings in their local cache. In this case ITRs 535 can reach ETRs until the entry expires (typically 24 hours). For 536 this reason, redundant Map-Server deployments are desirable. A set 537 of Map-Servers providing high-availability service to the same set of 538 prefixes is called a redundancy group. ETRs are configured to send 539 Map-Register messages to all Map-Servers in the redundancy group. To 540 achieve fail-over (or load-balancing, if desired), current known BGP 541 practices can be used on the LISP+ALT BGP overlay network. 543 Additionally, if a Map-Server has no reachability for any ETR serving 544 a given EID block, it should not originate that block into the 545 mapping system. 547 3.2. Map-Resolvers 549 A Map-Resolver a is a network infrastructure component which accepts 550 LISP encapsulated Map-Requests, typically from an ITR, and finds the 551 appropriate EID-to-RLOC mapping by either consulting its local cache 552 or by consulting the distributed mapping database. Map-Resolver 553 functionality is described in detail in [I-D.ietf-lisp-ms]. 555 Anyone with access to the distributed mapping database can set up a 556 Map-Resolver and provide EID-to-RLOC mapping lookup service. In the 557 case of the LISP+ALT mapping system, the Map-Resolver needs to become 558 part of the ALT overlay so that it can forward packets to the 559 appropriate Map-Servers. For more detail on how the ALT overlay 560 works, see [I-D.ietf-lisp-alt] 562 For performance reasons, it is recommended that LISP sites use Map- 563 Resolvers that are topologically close to their ITRs. ISPs 564 supporting LISP will provide this service to their customers, 565 possibly restricting access to their user base. LISP sites not in 566 this position can use open access Map-Resolvers, if available. 567 However, regardless of the availability of open access resolvers, the 568 MSP providing the Map-Server(s) for a LISP site should also make 569 available Map-Resolver(s) for the use of that site. 571 In medium to large-size ASes, ITRs must be configured with the RLOC 572 of a Map-Resolver, operation which can be done manually. However, in 573 Small Office Home Office (SOHO) scenarios a mechanism for 574 autoconfiguration should be provided. 576 One solution to avoid manual configuration in LISP sites of any size 577 is the use of anycast RLOCs for Map-Resolvers similar to the DNS root 578 server infrastructure. Since LISP uses UDP encapsulation, the use of 579 anycast would not affect reliability. LISP routers are then shipped 580 with a preconfigured list of well know Map-Resolver RLOCs, which can 581 be edited by the network administrator, if needed. 583 The use of anycast also helps improving mapping lookup performance. 584 Large MSPs can increase the number and geographical diversity of 585 their Map-Resolver infrastructure, using a single anycasted RLOC. 586 Once LISP deployment is advanced enough, very large content providers 587 may also be interested running this kind of setup, to ensure minimal 588 connection setup latency for those connecting to their network from 589 LISP sites. 591 While Map-Servers and Map-Resolvers implement different 592 functionalities within the LISP mapping system, they can coexist on 593 the same device. For example, MSPs offering both services, can 594 deploy a single Map-Resolver/Map-Server in each PoP where they have a 595 presence. 597 4. Proxy Tunnel Routers 599 4.1. P-ITR 601 Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP 602 transition mechanism, allowing non-LISP sites to reach LISP sites. 603 They announce via BGP certain EID prefixes (aggregated, whenever 604 possible) to attract traffic from non-LISP sites towards EIDs in the 605 covered range. They do the mapping system lookup, and encapsulate 606 received packets towards the appropriate ETR. Note that for the 607 reverse path LISP sites can reach non-LISP sites simply by not 608 encapsulating traffic. See [I-D.ietf-lisp-interworking] for a 609 detailed description of P-ITR functionality. 611 The success of new protocols depends greatly on their ability to 612 maintain backwards compatibility and inter-operate with the 613 protocol(s) they intend to enhance or replace, and on the incentives 614 to deploy the necessary new software or equipment. A LISP site needs 615 an interworking mechanism to be reachable from non-LISP sites. A 616 P-ITR can fulfill this role, enabling early adopters to see the 617 benefits of LISP, similar to tunnel brokers helping the transition 618 from IPv4 to IPv6. A site benefits from new LISP functionality 619 (proportionally with existing global LISP deployment) when going 620 LISP, so it has the incentives to deploy the necessary tunnel 621 routers. In order to be reachable from non-LISP sites it has two 622 options: keep announcing its prefix(es) with BGP (see next 623 subsection), or have a P-ITR announce prefix(es) covering them. 625 If the goal of reducing the DFZ routing table size is to be reached, 626 the second option is preferred. Moreover, the second option allows 627 LISP-based ingress traffic engineering from all sites. However, the 628 placement of P-ITRs greatly influences performance and deployment 629 incentives. The following subsections present the LISP+BGP 630 transition strategy and then possible P-ITR deployment scenarios. 631 They use the loosely defined terms of "early transition phase", "late 632 transition phase", and "LISP Internet phase", which refer to time 633 periods when LISP sites are a minority, a majority, or represent all 634 edge networks respectively. 636 4.1.1. LISP+BGP 638 For sites wishing to go LISP with their PI prefix the least 639 disruptive way is to upgrade their border routers to support LISP, 640 register the prefix into the LISP mapping system, but keep announcing 641 it with BGP as well. This way LISP sites will reach them over LISP, 642 while legacy sites will be unaffected by the change. The main 643 disadvantage of this approach is that no decrease in the DFZ routing 644 table size is achieved. Still, just increasing the number of LISP 645 sites is an important gain, as an increasing LISP/non-LISP site ratio 646 will slowly decrease the need for BGP-based traffic engineering that 647 leads to prefix deaggregation. That, in turn, may lead to a decrease 648 in the DFZ size in the late transition phase. 650 This scenario is not limited to sites that already have their 651 prefixes announced with BGP. Newly allocated EID blocks could follow 652 this strategy as well during the early LISP deployment phase, 653 depending on the cost/benefit analysis of the individual networks. 654 Since this leads to an increase in the DFZ size, one of the following 655 scenarios should be preferred for new allocations. 657 4.1.2. Mapping Service Provider P-ITR Service 659 In addition to publishing their clients' registered prefixes in the 660 mapping system, MSPs with enough transit capacity can offer them 661 P-ITR service as a separate service. This service is especially 662 useful for new PI allocations, to sites without existing BGP 663 infrastructure, that wish to avoid BGP altogether. The MSP announces 664 the prefix into the DFZ, and the client benefits from ingress traffic 665 engineering without prefix deaggregation. The downside of this 666 scenario is path stretch, which may be greater than 1. 668 Routing all non-LISP ingress traffic through a third party which is 669 not one of its ISPs is only feasible for sites with modest amounts of 670 traffic (like those using the IPv6 tunnel broker services today), 671 especially in the first stage of the transition to LISP, with a 672 significant number of legacy sites. When the LISP/non-LISP site 673 ratio becomes high enough, this approach can prove increasingly 674 attractive. 676 Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix 677 deaggregation for traffic engineering purposes, resulting in slower 678 routing table increase in the case of new allocations and potential 679 decrease for existing ones. Moreover, MSPs serving different clients 680 with adjacent aggregable prefixes may lead to additional decrease, 681 but quantifying this decrease is subject to future research study. 683 4.1.3. Tier 1 P-ITR Service 685 The ideal location for a P-ITR is on the traffic path, as close to 686 non-LISP site as possible, to minimize or completely eliminate path 687 stretch. However, this location is far away from the networks that 688 most benefit from the P-ITR services (i.e., LISP sites, destinations 689 of encapsulated traffic) and have the most incentives to deploy them. 690 But the biggest challenge having P-ITRs close to the traffic source 691 is the large number of devices and their wide geographical diversity 692 required to have a good coverage, in addition to considerable transit 693 capacity. Tier 1 service providers fulfill these requirements and 694 have clear incentives to deploy P-ITRs: to attract more traffic from 695 their customers. Since a large fraction is multihomed to different 696 providers with more than one active link, they compete with the other 697 providers for traffic. 699 To operate the P-ITR service, the ISP announces an aggregate of all 700 known EID prefixes (a mechanism will be needed to obtain this list) 701 downstream to their customers with BGP. First, the performance 702 concerns of the MSP P-ITR service described in the previous section 703 are now addressed, as P-ITRs are on-path, eliminating path stretch 704 (except when combined with LISP+BGP, see below). Second, thanks to 705 the direction of the announcements, the DFZ routing table size is not 706 affected. 708 The main downside of this approach is non-global coverage for the 709 announced prefixes, caused by the downstream direction of the 710 announcements. As a result, a LISP site will be only reachable from 711 customers of service providers running P-ITRs, unless one of the 712 previous approaches is used as well. Due to this issue, it is 713 unlikely that existing BGP speakers migrating to LISP will withdraw 714 their announcements to the DFZ, resulting in a combination of this 715 approach with LISP+BGP. At the same time, smaller new LISP sites 716 still depend on MSP for global reachability. The early transition 717 phase thus will keep the status quo in the DFZ routing table size, 718 but offers the benefits of increasingly better ingress traffic 719 engineering to early adopters. 721 As the number of LISP destinations increases, traffic levels from 722 those non-LISP, large multihomed clients who rely on BGP path length 723 for provider selection (such as national/regional ISPs), start to 724 shift towards the Tier 1 providing P-ITRs. The competition is then 725 incentivised to deploy their own service, thus improving global P-ITR 726 coverage. If all Tier 1 providers have P-ITR service, the LISP+BGP 727 and MSP alternatives are not required for global reachability of LISP 728 sites. Still, LISP+BGP users may still want to keep announcing their 729 prefixes for security reasons (i.e., preventing hijacking). DFZ size 730 evolution in this phase depends on that choice, and the aggregability 731 of all LISP prefixes. As a result, it may decrease or stay at the 732 same level. 734 For performance reasons, and to simplify P-ITR implementations, it is 735 desirable to minimize the number of non-aggregable EID prefixes. In 736 IPv6 this can be easily achieved if a large prefix block is reserved 737 as LISP EID space [I-D.meyer-lisp-eid-block]. If the EID space is 738 not fragmented, new LISP sites will not cause increase in the DFZ 739 size, unless they do LISP+BGP. 741 To summarize, the main benefits of this scenario are stopping the 742 increase and potentially decreasing the size of the DFZ routing 743 tables, while keeping path stretch close to 1, with the cost of not 744 having global coverage of one's prefixes. 746 4.1.4. Migration Summary 748 The following table presents the expected effects of the different 749 transition scenarios during a certain phase on the DFZ routing table 750 size: 752 Phase | LISP+BGP | MSP | Tier 1 753 -----------------+--------------+-------------------+------------- 754 Early transition | no change | slowdown increase | no change 755 Late transition | may decrease | slowdown increase | may decrease 756 LISP Internet | considerable decrease 758 It is expected that a combination of these scenarios will exist 759 during the migration period, in particular existing sites choosing 760 LISP+BGP, new small sites choosing MSP, and competition between Tier 761 1 providers bringing optimized service. If all Tier 1 ISPs have 762 P-ITR service in place, the other scenarios can be deprecated, 763 greatly reducing DFZ size. 765 4.2. P-ETR 767 In contrast to P-ITRs, P-ETRs are not required for the correct 768 functioning of all LISP sites. There are two cases, where they can 769 be of great help: 771 o LISP sites with unicast reverse path forwarding (uRPF) 772 restrictions, and 774 o LISP sites without native IPv6 communicating with LISP nodes with 775 IPv6-only locators. 777 In the first case, uRPF filtering is applied at their upstream PE 778 router. When forwarding traffic to non-LISP sites, an ITR does not 779 encapsulate packets, leaving the original IP headers intact. As a 780 result, packets will have EIDs in their source address. Since we are 781 discussing the transition period, we can assume that a prefix 782 covering the EIDs belonging to the LISP site is advertised to the 783 global routing tables by a P-ITR, and the PE router has a route 784 towards it. However, the next hop will not be on the interface 785 towards the CE router, so non-encapsulated packets will fail uRPF 786 checks. 788 To avoid this filtering, the affected ITR encapsulates packets 789 towards the locator of the P-ETR for non-LISP destinations. Now the 790 source address of the packets, as seen by the PE router is the ITR's 791 locator, which will not fail the uRPF check. The P-ETR then 792 decapsulates and forwards the packets. 794 The second use case is IPv4-to-IPv6 transition. Service providers 795 using older access network hardware, which only supports IPv4 can 796 still offer IPv6 to their clients, by providing a CPE device running 797 LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP 798 sites, with IPv6-only locators. Packets originating from the client 799 LISP site for these destinations would be encapsulated towards the 800 P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, 801 decapsulating and forwarding packets. For non-LISP destination, the 802 packet travels natively from the P-ETR. For LISP destinations with 803 IPv6-only locators, the packet will go through a P-ITR, in order to 804 reach its destination. 806 For more details on P-ETRs see the [I-D.ietf-lisp-interworking] 807 draft. 809 P-ETRs can be deployed by ISPs wishing to offer value-added services 810 to their customers. As is the case with P-ITRs, P-ETRs too may 811 introduce path stretch. Because of this the ISP needs to consider 812 the tradeoff of using several devices, close to the customers, to 813 minimize it, or few devices, farther away from the customers, 814 minimizing cost instead. 816 Since the deployment incentives for P-ITRs and P-ETRs are different, 817 it is likely they will be deployed in separate devices, except for 818 the CDN case, which may deploy both in a single device. 820 In all cases, the existence of a P-ETR involves another step in the 821 configuration of a LISP router. CPE routers, which are typically 822 configured by DHCP, stand to benefit most from P-ETRs. To enable 823 autoconfiguration of the P-ETR locator, a DHCP option would be 824 required. 826 As a security measure, access to P-ETRs should be limited to 827 legitimate users by enforcing ACLs. 829 5. Security Considerations 831 Security implications of LISP deployments are to be discussed in 832 separate documents. [I-D.saucez-lisp-security] gives an overview of 833 LISP threat models, while securing mapping lookups is discussed in 834 [I-D.maino-lisp-sec]. 836 6. IANA Considerations 838 This memo includes no request to IANA. 840 7. Acknowledgements 842 Many thanks to Margaret Wasserman for her contribution to the IETF76 843 presentation that kickstarted this work. The authors would also like 844 to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, 845 Dino Farinacci, Terry Manderson, Noel Chiappa, and everyone else who 846 provided input. 848 8. References 850 8.1. Normative References 852 [I-D.ietf-lisp] 853 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 854 "Locator/ID Separation Protocol (LISP)", 855 draft-ietf-lisp-10 (work in progress), March 2011. 857 [I-D.ietf-lisp-alt] 858 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 859 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-06 860 (work in progress), March 2011. 862 [I-D.ietf-lisp-interworking] 863 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 864 "Interworking LISP with IPv4 and IPv6", 865 draft-ietf-lisp-interworking-01 (work in progress), 866 August 2010. 868 [I-D.ietf-lisp-ms] 869 Fuller, V. and D. Farinacci, "LISP Map Server", 870 draft-ietf-lisp-ms-07 (work in progress), March 2011. 872 [I-D.maino-lisp-sec] 873 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 874 and O. Bonaventure, "LISP-Security (LISP-SEC)", 875 draft-maino-lisp-sec-00 (work in progress), March 2011. 877 [I-D.saucez-lisp-security] 878 Saucez, D., Iannone, L., and O. Bonaventure, "LISP 879 Security Threats", draft-saucez-lisp-security-03 (work in 880 progress), March 2011. 882 8.2. Informative References 884 [I-D.lear-lisp-nerd] 885 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 886 draft-lear-lisp-nerd-08 (work in progress), March 2010. 888 [I-D.meyer-lisp-eid-block] 889 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 890 EID Block", draft-meyer-lisp-eid-block-02 (work in 891 progress), March 2011. 893 [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS 894 performance and the effectiveness of caching", 2002. 896 Authors' Addresses 898 Lorand Jakab 899 Technical University of Catalonia 900 C/Jordi Girona, s/n 901 BARCELONA 08034 902 Spain 904 Email: ljakab@ac.upc.edu 906 Albert Cabellos-Aparicio 907 Technical University of Catalonia 908 C/Jordi Girona, s/n 909 BARCELONA 08034 910 Spain 912 Email: acabello@ac.upc.edu 914 Florin Coras 915 Technical University of Catalonia 916 C/Jordi Girona, s/n 917 BARCELONA 08034 918 Spain 920 Email: fcoras@ac.upc.edu 922 Jordi Domingo-Pascual 923 Technical University of Catalonia 924 C/Jordi Girona, s/n 925 BARCELONA 08034 926 Spain 928 Email: jordi.domingo@ac.upc.edu 929 Darrel Lewis 930 Cisco Systems 931 170 Tasman Drive 932 San Jose, CA 95134 933 USA 935 Email: darlewis@cisco.com