idnits 2.17.1 draft-ietf-lisp-deployment-01.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 472 has weird spacing: '...ructure x ...' -- The document date (July 11, 2011) is 4645 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-15 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-07 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-02 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-10 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-00 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-block-00 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 Summary: 0 errors (**), 0 flaws (~~), 9 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: January 12, 2012 J. Domingo-Pascual 6 Technical University of Catalonia 7 D. Lewis 8 Cisco Systems 9 July 11, 2011 11 LISP Network Element Deployment Considerations 12 draft-ietf-lisp-deployment-01.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 January 12, 2012. 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.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16 71 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 72 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16 73 5.3. Proxy-ITR Route Distribution . . . . . . . . . . . . . . . 17 74 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 79 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 80 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 83 1. Introduction 85 The Locator/Identifier Separation Protocol (LISP) addresses the 86 scaling issues of the global Internet routing system by separating 87 the current addressing scheme into Endpoint IDentifiers (EIDs) and 88 Routing LOCators (RLOCs). The main protocol specification 89 [I-D.ietf-lisp] describes how the separation is achieved, which new 90 network elements are introduced, and details the packet formats for 91 the data and control planes. 93 While the boundary between the core and edge is not strictly defined, 94 one widely accepted definition places it at the border routers of 95 stub autonomous systems, which may carry a partial or complete 96 default-free zone (DFZ) routing table. The initial design of LISP 97 took this location as a baseline for protocol development. However, 98 the applications of LISP go beyond of just decreasing the size of the 99 DFZ routing table, and include improved multihoming and ingress 100 traffic engineering (TE) support for edge networks, and even 101 individual hosts. Throughout the draft we will use the term LISP 102 site to refer to these networks/hosts behind a LISP Tunnel Router. 103 We formally define it as: 105 LISP site: A single host or a set of network elements in an edge 106 network under the administrative control of a single organization, 107 delimited from other networks by LISP Tunnel Router(s). 109 Since LISP is a protocol which can be used for different purposes, it 110 is important to identify possible deployment scenarios and the 111 additional requirements they may impose on the protocol specification 112 and other protocols. The main specification [I-D.ietf-lisp] mentions 113 positioning of tunnel routers, but without an in-depth discussion. 114 This document fills that gap, by exploring the most common cases. 115 While the theoretical combinations of device placements are quite 116 numerous, the more practical scenarios are given preference in the 117 following. 119 Additionally, this documents is intended as a guide for the 120 operational community for LISP deployments in their networks. It is 121 expected to evolve as LISP deployment progresses, and the described 122 scenarios are better understood or new scenarios are discovered. 124 Each subsection considers an element type, discussing the impact of 125 deployment scenarios on the protocol specification. For definition 126 of terms, please refer to the appropriate documents (as cited in the 127 respective sections). 129 Comments and discussions about this memo should be directed to the 130 LISP working group mailing list: lisp@ietf.org. 132 2. Tunnel Routers 134 LISP is a map-and-encap protocol, with the main goal of improving 135 global routing scalability. To achieve its goal, it introduces 136 several new network elements, each performing specific functions 137 necessary to separate the edge from the core. The device that is the 138 gateway between the edge and the core is called Tunnel Router (xTR), 139 performing one or both of two separate functions: 141 1. Encapsulating packets originating from an end host to be 142 transported over intermediary (transit) networks towards the 143 other end-point of the communication 145 2. Decapsulating packets entering from intermediary (transit) 146 networks, originated at a remote end host. 148 The first function is performed by an Ingress Tunnel Router (ITR), 149 the second by an Egress Tunnel Router (ETR). 151 Section 8 of the main LISP specification [I-D.ietf-lisp] has a short 152 discussion of where Tunnel Routers can be deployed and some of the 153 associated advantages and disadvantages. This section adds more 154 detail to the scenarios presented there, and provides additional 155 scenarios as well. 157 2.1. Customer Edge 159 LISP was designed with deployment at the core-edge boundary in mind, 160 which can be approximated as the set of DFZ routers belonging to non- 161 transit ASes. For the purposes of this document, we will consider 162 this boundary to be consisting of the routers connecting LISP sites 163 to their upstreams. As such, this is the most common expected 164 scenario for xTRs, and this document considers it the reference 165 location, comparing the other scenarios to this one. 167 ISP1 ISP2 168 | | 169 | | 170 +----+ +----+ 171 +--|xTR1|--|xTR2|--+ 172 | +----+ +----+ | 173 | | 174 | LISP site | 175 +------------------+ 177 Figure 1: xTRs at the customer edge 179 From the LISP site perspective the main advantage of this type of 180 deployment (compared to the one described in the next section) is 181 having direct control over its ingress traffic engineering. This 182 makes it is easy to set up and maintain active/active, active/backup, 183 or more complex TE policies, without involving third parties. 185 Being under the same administrative control, reachability information 186 of all ETRs is easier to synchronize, because the necessary control 187 traffic can be allowed between the locators of the ETRs. A correct 188 synchronous global view of the reachability status is thus available, 189 and the Loc-Status-Bits can be set correctly in the LISP data header 190 of outgoing packets. 192 By placing the tunnel router at the edge of the site, existing 193 internal network configuration does not need to be modified. 194 Firewall rules, router configurations and address assignments inside 195 the LISP site remain unchanged. This helps with incremental 196 deployment and allows a quick upgrade path to LISP. For larger sites 197 with many external connections, distributed in geographically diverse 198 PoPs, and complex internal topology, it may however make more sense 199 to both encapsulate and decapsulate as soon as possible, to benefit 200 from the information in the IGP to choose the best path (see 201 Section 2.3 for a discussion of this scenario). 203 Another thing to consider when placing tunnel routers are MTU issues. 204 Since encapsulating packets increases overhead, the MTU of the end- 205 to-end path may decrease, when encapsulated packets need to travel 206 over segments having close to minimum MTU. Some transit networks are 207 known to provide larger MTU than the typical value of 1500 bytes of 208 popular access technologies used at end hosts (e.g., IEEE 802.3 and 209 802.11). However, placing the LISP router connecting to such a 210 network at the customer edge could possibly bring up MTU issues, 211 depending on the link type to the provider as opposed to the 212 following scenario. 214 2.2. Provider Edge 216 The other location at the core-edge boundary for deploying LISP 217 routers is at the Internet service provider edge. The main incentive 218 for this case is that the customer does not have to upgrade the CE 219 router(s), or change the configuration of any equipment. 220 Encapsulation/decapsulation happens in the provider's network, which 221 may be able to serve several customers with a single device. For 222 large ISPs with many residential/business customers asking for LISP 223 this can lead to important savings, since there is no need to upgrade 224 the software (or hardware, if it's the case) at each client's 225 location. Instead, they can upgrade the software (or hardware) on a 226 few PE routers serving the customers. This scenario is depicted in 227 Figure 2. 229 +----------+ +------------------+ 230 | ISP1 | | ISP2 | 231 | | | | 232 | +----+ | | +----+ +----+ | 233 +--|xTR1|--+ +--|xTR2|--|xTR3|--+ 234 +----+ +----+ +----+ 235 | | | 236 | | | 237 +--<[LISP site]>---+-------+ 239 Figure 2: xTR at the PE 241 While this approach can make transition easy for customers and may be 242 cheaper for providers, the LISP site looses one of the main benefits 243 of LISP: ingress traffic engineering. Since the provider controls 244 the ETRs, additional complexity would be needed to allow customers to 245 modify their mapping entries. 247 The problem is aggravated when the LISP site is multihomed. Consider 248 the scenario in Figure 2: whenever a change to TE policies is 249 required, the customer contacts both ISP1 and ISP2 to make the 250 necessary changes on the routers (if they provide this possibility). 251 It is however unlikely, that both ISPs will apply changes 252 simultaneously, which may lead to inconsistent state for the mappings 253 of the LISP site. Since the different upstream ISPs are usually 254 competing business entities, the ETRs may even be configured to 255 compete, either to attract all the traffic or to get no traffic. The 256 former will happen if the customer pays per volume, the latter if the 257 connectivity has a fixed price. A solution could be to have the 258 mappings in the Map-Server(s), and have their operator give control 259 over the entries to 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. 278 This would enable them to choose the best egress point. 280 The LISP specification separates the ITR and ETR functionality and 281 considers that both entities can be deployed in separated network 282 equipment. ITRs can be deployed closer to the host (i.e., access 283 routers). This way packets are encapsulated as soon as possible, and 284 packets exit the network through the best egress point in terms of 285 BGP policy. In turn, ETRs can be deployed at the border routers of 286 the network, and packets are decapsulated as soon as possible. 287 Again, once decapsulated packets are routed according to the EID, and 288 can follow the best path according to internal routing policy. 290 In the following figure we can see an example. The Source (S) 291 transmits packets using its EID and in this particular case packets 292 are encapsulated at ITR_1. The encapsulated packets are routed 293 inside the domain according to the destination RLOC, and can egress 294 the network through the best point (i.e., closer to the RLOC's AS). 295 On the other hand, inbound packets are received by ETR_1 which 296 decapsulates them. Then packets are routed towards S according to 297 the EID, again following the best path. 299 +---------------------------------------+ 300 | | 301 | +-------+ +-------+ +-------+ 302 | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | 303 | +-------+ | +-------+ +-------+ 304 | +-+ | | | 305 | |S| | IGP | | 306 | +-+ | | | 307 | +-------+ | +-------+ +-------+ 308 | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | 309 | +-------+ +-------+ +-------+ 310 | | 311 +---------------------------------------+ 313 Figure 3: Split ITR/ETR Scenario 315 This scenario has a set of implications: 317 o The site must carry at least partial BGP routes in order to choose 318 the best egress point, increasing the complexity of the network. 319 However, this is usually already the case for LISP sites that 320 would benefit from this scenario. 322 o If the site is multihomed to different ISPs and any of the 323 upstream ISPs is doing uRPF filtering, this scenario may become 324 impractical. ITRs need to determine the exit ETR, for setting the 325 correct source RLOC in the encapsulation header. This adds 326 complexity and reliability concerns. 328 o In LISP, ITRs set the reachability bits when encapsulating data 329 packets. Hence, ITRs need a mechanism to be aware of the liveness 330 of ETRs. 332 o ITRs encapsulate packets and in order to achieve efficient 333 communications, the MTU of the site must be large enough to 334 accommodate this extra header. 336 o In this scenario, each ITR is serving fewer hosts than in the case 337 when it is deployed at the border of the network. It has been 338 shown that cache hit ratio grows logarithmically with the amount 339 of users [cache]. Taking this into account, when ITRs are 340 deployed closer to the host the effectiveness of the mapping cache 341 may be lower (i.e., the miss ratio is higher). Another 342 consequence of this is that the site will transmit a higher amount 343 of Map-Requests, increasing the load on the distributed mapping 344 database. 346 2.4. Inter-Service Provider Traffic Engineering 348 With LISP, two LISP sites can route packets among them and control 349 their ingress TE policies. Typically, LISP is seen as applicable to 350 stub networks, however the LISP protocol can also be applied to 351 transit networks recursively. 353 Consider the scenario depicted in Figure 4. Packets originating from 354 the LISP site Stub1, client of ISP_A, with destination Stub4, client 355 of ISP_B, are LISP encapsulated at their entry point into the ISP_A's 356 network. The external IP header now has as the source RLOC an IP 357 from ISP_A's address space (R_A1, R_A2, or R_A3) and destination RLOC 358 from ISP_B's address space (R_B1 or R_B2). One or more ASes separate 359 ISP_A from ISP_B. With a single level of LISP encapsulation, Stub4 360 has control over its ingress traffic. However, ISP_B only has the 361 current tools (such as BGP prefix deaggregation) to control on which 362 of his own upstream or peering links should packets enter. This is 363 either not feasible (if fine-grained per-customer control is 364 required, the very specific prefixes may not be propagated) or 365 increases DFZ table size. 367 _.--. 368 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 369 \ | R_A1|----,' `. ---|R_B1 | / 370 --| R_A2|---( Transit ) | |-- 371 Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 372 +-------+ `--. _.-' +-------+ 373 ... ISP_A `--'' ISP_B ... 375 Figure 4: Inter-Service provider TE scenario 377 A solution for this is to apply LISP recursively. ISP_A and ISP_B 378 may reach a bilateral agreement to deploy their own private mapping 379 system. ISP_A then encapsulates packets destined for the prefixes of 380 ISP_B, which are listed in the shared mapping system. Note that in 381 this case the packet is double-encapsulated. ISP_B's ETR removes the 382 outer, second layer of LISP encapsulation from the incoming packet, 383 and routes it towards the original RLOC, the ETR of Stub4, which does 384 the final decapsulation. 386 If ISP_A and ISP_B agree to share a private distributed mapping 387 database, both can control their ingress TE without the need of 388 disaggregating prefixes. In this scenario the private database 389 contains RLOC-to-RLOC bindings. The convergence time on the TE 390 policies updates is expected to be fast, since ISPs only have to 391 update/query a mapping to/from the database. 393 This deployment scenario includes two important recommendations. 394 First, it is intended to be deployed only between two ISPs (ISP_A and 395 ISP_B in Figure 4). If more than two ISPs use this approach, then 396 the xTRs deployed at the participating ISPs must either query 397 multiple mapping systems, or the ISPs must agree on a common shared 398 mapping system. Second, the scenario is only recommended for ISPs 399 providing connectivity to LISP sites, such that source RLOCs of 400 packets to be reencapsulated belong to said ISP. Otherwise the 401 participating ISPs must register prefixes they do not own in the 402 above mentioned private mapping system. Failure to follow these 403 recommendations may lead to operational and security issues when 404 deploying this scenario. 406 Besides these recommendations, the main disadvantages of this 407 deployment case are: 409 o Extra LISP header is needed. This increases the packet size and, 410 for efficient communications, it requires that the MTU between 411 both ISPs can accommodate double-encapsulated packets. 413 o The ISP ITR must encapsulate packets and therefore must know the 414 RLOC-to-RLOC binding. These bindings are stored in a mapping 415 database and may be cached in the ITR's mapping cache. Cache 416 misses lead to an extra lookup latency, unless NERD 417 [I-D.lear-lisp-nerd] is used for the lookups. 419 o The operational overhead of maintaining the shared mapping 420 database. 422 2.5. Tunnel Routers Behind NAT 424 NAT in this section refers to IPv4 network address and port 425 translation. 427 2.5.1. ITR 429 Packets encapsulated by an ITR are just UDP packets from a NAT 430 device's point of view, and they are handled like any UDP packet, 431 there are no additional requirements for LISP data packets. 433 Map-Requests sent by an ITR, which create the state in the NAT table 434 have a different 5-tuple in the IP header than the Map-Reply 435 generated by the authoritative ETR. Since the source address of this 436 packet is different from the destination address of the request 437 packet, no state will be matched in the NAT table and the packet will 438 be dropped. To avoid this, the NAT device has to do the following: 440 o Send all UDP packets with source port 4342, regardless of the 441 destination port, to the RLOC of the ITR. The most simple way to 442 achieve this is configuring 1:1 NAT mode from the external RLOC of 443 the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer 444 broadband routers). 446 o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in 447 the payload. 449 This setup supports a single ITR behind the NAT device. 451 2.5.2. ETR 453 An ETR placed behind NAT is reachable from the outside by the 454 Internet-facing locator of the NAT device. It needs to know this 455 locator (and configure a loopback interface with it), so that it can 456 use it in Map-Reply and Map-Register messages. Thus support for 457 dynamic locators for the mapping database is needed in LISP 458 equipment. 460 Again, only one ETR behind the NAT device is supported. 462 An implication of the issues described above is that LISP sites with 463 xTRs can not be behind carrier based NATs, since two different sites 464 would collide on the port forwarding. 466 2.6. Summary and Feature Matrix 468 Feature CE PE Split Rec. 469 -------------------------------------------------------- 470 Control of ingress TE x - x x 471 No modifications to existing 472 int. network infrastructure x x - - 473 Loc-Status-Bits sync x - x x 474 MTU/PMTUD issues minimized - x - x 476 3. Map-Resolvers and Map-Servers 478 3.1. Map-Servers 480 The Map-Server learns EID-to-RLOC mapping entries from an 481 authoritative source and publishes them in the distributed mapping 482 database. These entries are learned through authenticated Map- 483 Register messages sent by authoritative ETRs. Also, upon reception 484 of a Map-Request, the Map-Server verifies that the destination EID 485 matches an EID-prefix for which it is authoritative for, and then re- 486 encapsulates and forwards it to a matching ETR. Map-Server 487 functionality is described in detail in [I-D.ietf-lisp-ms]. 489 The Map-Server is provided by a Mapping Service Provider (MSP). A 490 MSP can be any of the following: 492 o EID registrar. Since the IPv4 address space is nearing 493 exhaustion, IPv4 EIDs will come from already allocated Provider 494 Independent (PI) space. The registrars in this case remain the 495 current five Regional Internet Registries (RIRs). In the case of 496 IPv6, the possibility of reserving a /16 block as EID space is 497 currently under consideration [I-D.ietf-lisp-eid-block]. If 498 granted by IANA, the community will have to determine the body 499 responsible for allocations from this block, and the associated 500 policies. For already allocated IPv6 prefixes the principles from 501 IPv4 should be applied. 503 o Third parties. Participating in the LISP mapping system is 504 similar to participating in global routing or DNS: as long as 505 there is at least another already participating entity willing to 506 forward the newcomer's traffic, there is no barrier to entry. 507 Still, just like routing and DNS, LISP mappings have the issue of 508 trust, with efforts underway to make the published information 509 verifiable. When these mechanisms will be deployed in the LISP 510 mapping system, the burden of providing and verifying trust should 511 be kept away from MSPs, which will simply host the secured 512 mappings. This will keep the low barrier of entry to become an 513 MSP for third parties. 515 In all cases, the MSP configures its Map-Server(s) to publish the 516 prefixes of its clients in the distributed mapping database and start 517 encapsulating and forwarding Map-Requests to the ETRs of the AS. 518 These ETRs register their prefix(es) with the Map-Server(s) through 519 periodic authenticated Map-Register messages. In this context, for 520 some LISP end sites, there is a need for mechanisms to: 522 o Automatically distribute EID prefix(es) shared keys between the 523 ETRs and the EID-registrar Map-Server. 525 o Dynamically obtain the address of the Map-Server in the ETR of the 526 AS. 528 The Map-Server plays a key role in the reachability of the EID- 529 prefixes it is serving. On the one hand it is publishing these 530 prefixes into the distributed mapping database and on the other hand 531 it is encapsulating and forwarding Map-Requests to the authoritative 532 ETRs of these prefixes. ITRs encapsulating towards EIDs under the 533 responsibility of a failed Map-Server will be unable to look up any 534 of their covering prefixes. The only exception are the ITRs that 535 already contain the mappings in their local cache. In this case ITRs 536 can reach ETRs until the entry expires (typically 24 hours). For 537 this reason, redundant Map-Server deployments are desirable. A set 538 of Map-Servers providing high-availability service to the same set of 539 prefixes is called a redundancy group. ETRs are configured to send 540 Map-Register messages to all Map-Servers in the redundancy group. To 541 achieve fail-over (or load-balancing, if desired), current known BGP 542 practices can be used on the LISP+ALT BGP overlay network. 544 Additionally, if a Map-Server has no reachability for any ETR serving 545 a given EID block, it should not originate that block into the 546 mapping system. 548 3.2. Map-Resolvers 550 A Map-Resolver a is a network infrastructure component which accepts 551 LISP encapsulated Map-Requests, typically from an ITR, and finds the 552 appropriate EID-to-RLOC mapping by either consulting its local cache 553 or by consulting the distributed mapping database. Map-Resolver 554 functionality is described in detail in [I-D.ietf-lisp-ms]. 556 Anyone with access to the distributed mapping database can set up a 557 Map-Resolver and provide EID-to-RLOC mapping lookup service. In the 558 case of the LISP+ALT mapping system, the Map-Resolver needs to become 559 part of the ALT overlay so that it can forward packets to the 560 appropriate Map-Servers. For more detail on how the ALT overlay 561 works, see [I-D.ietf-lisp-alt] 563 For performance reasons, it is recommended that LISP sites use Map- 564 Resolvers that are topologically close to their ITRs. ISPs 565 supporting LISP will provide this service to their customers, 566 possibly restricting access to their user base. LISP sites not in 567 this position can use open access Map-Resolvers, if available. 568 However, regardless of the availability of open access resolvers, the 569 MSP providing the Map-Server(s) for a LISP site should also make 570 available Map-Resolver(s) for the use of that site. 572 In medium to large-size ASes, ITRs must be configured with the RLOC 573 of a Map-Resolver, operation which can be done manually. However, in 574 Small Office Home Office (SOHO) scenarios a mechanism for 575 autoconfiguration should be provided. 577 One solution to avoid manual configuration in LISP sites of any size 578 is the use of anycast RLOCs for Map-Resolvers similar to the DNS root 579 server infrastructure. Since LISP uses UDP encapsulation, the use of 580 anycast would not affect reliability. LISP routers are then shipped 581 with a preconfigured list of well know Map-Resolver RLOCs, which can 582 be edited by the network administrator, if needed. 584 The use of anycast also helps improving mapping lookup performance. 585 Large MSPs can increase the number and geographical diversity of 586 their Map-Resolver infrastructure, using a single anycasted RLOC. 587 Once LISP deployment is advanced enough, very large content providers 588 may also be interested running this kind of setup, to ensure minimal 589 connection setup latency for those connecting to their network from 590 LISP sites. 592 While Map-Servers and Map-Resolvers implement different 593 functionalities within the LISP mapping system, they can coexist on 594 the same device. For example, MSPs offering both services, can 595 deploy a single Map-Resolver/Map-Server in each PoP where they have a 596 presence. 598 4. Proxy Tunnel Routers 600 4.1. P-ITR 602 Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP 603 transition mechanism, allowing non-LISP sites to reach LISP sites. 604 They announce via BGP certain EID prefixes (aggregated, whenever 605 possible) to attract traffic from non-LISP sites towards EIDs in the 606 covered range. They do the mapping system lookup, and encapsulate 607 received packets towards the appropriate ETR. Note that for the 608 reverse path LISP sites can reach non-LISP sites simply by not 609 encapsulating traffic. See [I-D.ietf-lisp-interworking] for a 610 detailed description of P-ITR functionality. 612 The success of new protocols depends greatly on their ability to 613 maintain backwards compatibility and inter-operate with the 614 protocol(s) they intend to enhance or replace, and on the incentives 615 to deploy the necessary new software or equipment. A LISP site needs 616 an interworking mechanism to be reachable from non-LISP sites. A 617 P-ITR can fulfill this role, enabling early adopters to see the 618 benefits of LISP, similar to tunnel brokers helping the transition 619 from IPv4 to IPv6. A site benefits from new LISP functionality 620 (proportionally with existing global LISP deployment) when going 621 LISP, so it has the incentives to deploy the necessary tunnel 622 routers. In order to be reachable from non-LISP sites it has two 623 options: keep announcing its prefix(es) with BGP, or have a P-ITR 624 announce prefix(es) covering them. 626 If the goal of reducing the DFZ routing table size is to be reached, 627 the second option is preferred. Moreover, the second option allows 628 LISP-based ingress traffic engineering from all sites. However, the 629 placement of P-ITRs significantly influences performance and 630 deployment incentives. Section Section 5 is dedicated to the 631 migration to a LISP-enabled Internet, and includes deployment 632 scenarios for P-ITRs. 634 4.2. P-ETR 636 In contrast to P-ITRs, P-ETRs are not required for the correct 637 functioning of all LISP sites. There are two cases, where they can 638 be of great help: 640 o LISP sites with unicast reverse path forwarding (uRPF) 641 restrictions, and 643 o LISP sites without native IPv6 communicating with LISP nodes with 644 IPv6-only locators. 646 In the first case, uRPF filtering is applied at their upstream PE 647 router. When forwarding traffic to non-LISP sites, an ITR does not 648 encapsulate packets, leaving the original IP headers intact. As a 649 result, packets will have EIDs in their source address. Since we are 650 discussing the transition period, we can assume that a prefix 651 covering the EIDs belonging to the LISP site is advertised to the 652 global routing tables by a P-ITR, and the PE router has a route 653 towards it. However, the next hop will not be on the interface 654 towards the CE router, so non-encapsulated packets will fail uRPF 655 checks. 657 To avoid this filtering, the affected ITR encapsulates packets 658 towards the locator of the P-ETR for non-LISP destinations. Now the 659 source address of the packets, as seen by the PE router is the ITR's 660 locator, which will not fail the uRPF check. The P-ETR then 661 decapsulates and forwards the packets. 663 The second use case is IPv4-to-IPv6 transition. Service providers 664 using older access network hardware, which only supports IPv4 can 665 still offer IPv6 to their clients, by providing a CPE device running 666 LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP 667 sites, with IPv6-only locators. Packets originating from the client 668 LISP site for these destinations would be encapsulated towards the 669 P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, 670 decapsulating and forwarding packets. For non-LISP destination, the 671 packet travels natively from the P-ETR. For LISP destinations with 672 IPv6-only locators, the packet will go through a P-ITR, in order to 673 reach its destination. 675 For more details on P-ETRs see the [I-D.ietf-lisp-interworking] 676 draft. 678 P-ETRs can be deployed by ISPs wishing to offer value-added services 679 to their customers. As is the case with P-ITRs, P-ETRs too may 680 introduce path stretch. Because of this the ISP needs to consider 681 the tradeoff of using several devices, close to the customers, to 682 minimize it, or few devices, farther away from the customers, 683 minimizing cost instead. 685 Since the deployment incentives for P-ITRs and P-ETRs are different, 686 it is likely they will be deployed in separate devices, except for 687 the CDN case, which may deploy both in a single device. 689 In all cases, the existence of a P-ETR involves another step in the 690 configuration of a LISP router. CPE routers, which are typically 691 configured by DHCP, stand to benefit most from P-ETRs. To enable 692 autoconfiguration of the P-ETR locator, a DHCP option would be 693 required. 695 As a security measure, access to P-ETRs should be limited to 696 legitimate users by enforcing ACLs. 698 5. Migration to LISP 700 This section discusses a deployment architecture to support the 701 migration to a LISP-enabled Internet. The loosely defined terms of 702 "early transition phase", "late transition phase", and "LISP Internet 703 phase" refer to time periods when LISP sites are a minority, a 704 majority, or represent all edge networks respectively. 706 5.1. LISP+BGP 708 For sites wishing to go LISP with their PI prefix the least 709 disruptive way is to upgrade their border routers to support LISP, 710 register the prefix into the LISP mapping system, but keep announcing 711 it with BGP as well. This way LISP sites will reach them over LISP, 712 while legacy sites will be unaffected by the change. The main 713 disadvantage of this approach is that no decrease in the DFZ routing 714 table size is achieved. Still, just increasing the number of LISP 715 sites is an important gain, as an increasing LISP/non-LISP site ratio 716 will slowly decrease the need for BGP-based traffic engineering that 717 leads to prefix deaggregation. That, in turn, may lead to a decrease 718 in the DFZ size in the late transition phase. 720 This scenario is not limited to sites that already have their 721 prefixes announced with BGP. Newly allocated EID blocks could follow 722 this strategy as well during the early LISP deployment phase, 723 depending on the cost/benefit analysis of the individual networks. 724 Since this leads to an increase in the DFZ size, the following 725 architecture should be preferred for new allocations. 727 5.2. Mapping Service Provider (MSP) P-ITR Service 729 In addition to publishing their clients' registered prefixes in the 730 mapping system, MSPs with enough transit capacity can offer them 731 P-ITR service as a separate service. This service is especially 732 useful for new PI allocations, to sites without existing BGP 733 infrastructure, that wish to avoid BGP altogether. The MSP announces 734 the prefix into the DFZ, and the client benefits from ingress traffic 735 engineering without prefix deaggregation. The downside of this 736 scenario is path stretch, which may be greater than 1. 738 Routing all non-LISP ingress traffic through a third party which is 739 not one of its ISPs is only feasible for sites with modest amounts of 740 traffic (like those using the IPv6 tunnel broker services today), 741 especially in the first stage of the transition to LISP, with a 742 significant number of legacy sites. When the LISP/non-LISP site 743 ratio becomes high enough, this approach can prove increasingly 744 attractive. 746 Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix 747 deaggregation for traffic engineering purposes, resulting in slower 748 routing table increase in the case of new allocations and potential 749 decrease for existing ones. Moreover, MSPs serving different clients 750 with adjacent aggregable prefixes may lead to additional decrease, 751 but quantifying this decrease is subject to future research study. 753 5.3. Proxy-ITR Route Distribution 755 Instead of a LISP site, or the MSP, announcing their EIDs with BGP to 756 the DFZ, this function can be outsourced to a third party, a P-ITR 757 Service Provider (PSP). This will result in a decrease of the 758 operational complexity both at the site and at the MSP. 760 The PSP manages a set of distributed P-ITR(s) that will advertise the 761 corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) 762 will then encapsulate the traffic they receive for those EIDs towards 763 the RLOCs of the LISP site, ensuring their reachability from non-LISP 764 sites. 766 While it is possible for a PSP to manually configure each client's 767 EID routes to be announced, this approach offers little flexibility 768 and is not scalable. This section presents a scalable architecture 769 that offers automatic distribution of EID routes to LISP sites and 770 service providers. 772 The architecture requires no modification to existing LISP network 773 elements, but it introduces a new (conceptual) network element, the 774 EID Route Server, defined as a router that either propagates routes 775 learned from other EID Route Servers, or it originates EID Routes. 776 The EID-Routes that it originates are those that it is authoritative 777 for. It propagates these routes to Proxy-ITRs within the AS of the 778 EID Route Server. It is worth to note that a BGP capable router can 779 be also considered as an EID Route Server. 781 Further, an EID-Route is defined as a prefix originated via the Route 782 Server of the mapping service provider, which should be aggregated if 783 the MSP has multiple customers inside a single netblock. This prefix 784 is propagated to other P-ITRs both within the MSP and to other P-ITR 785 operators it peers with. EID Route Servers are operated either by 786 the LISP site, MSPs or PSPs, and they may be collocated with a Map- 787 Server or P-ITR, but are a functionally discrete entity. They 788 distribute EID-Routes, using BGP, to other domains, according to 789 policies set by participants. 791 MSP (AS64500) 792 RS ---> P-ITR 793 | / 794 | _.--./ 795 ,-'' /`--. 796 LISP site ---,' | v `. 797 ( | DFZ )----- Mapping system 798 non-LISP site ----. | ^ ,' 799 `--. / _.-' 800 | `--'' 801 v / 802 P-ITR 803 PSP (AS64501) 805 Figure 5: The P-ITR Route Distribution architecture 807 The architecture described above decouples EID origination from route 808 propagation, with the following benefits: 810 o Can accurately represent business relationships between P-ITR 811 operators 813 o More mapping system agnostic (no reliance on ALT) 815 o Minor changes to P-ITR implementation, no changes to other 816 components 818 In the example in the figure we have a MSP providing services to the 819 LISP site. The LISP site does not run BGP, and gets an EID 820 allocation directly from a RIR, or from the MSP, who may be a LIR. 821 Existing PI allocations can be migrated as well. The MSP ensures the 822 presence of the prefix in the mapping system, and runs an EID Route 823 Server to distribute it to P-ITR service providers. Since the LISP 824 site does not run BGP, the prefix will be originated with the AS 825 number of the MSP. 827 In the simple case depicted in Figure 5 the EID-Route of LISP Site 828 will be originated by the Route Server, and announced to the DFZ by 829 the PSP's P-ITRs with AS path 64501 64500. From that point on, the 830 usual BGP dynamics apply. This way, routes announced by P-ITR are 831 still originated by the authoritative Route Server. Note that the 832 peering relationships between MSP/PSPs and those in the underlying 833 forwarding plane may not be congruent, making the AS path to a P-ITR 834 shorter than it is in reality. 836 The non-LISP site will select the best path towards the EID-prefix, 837 according to its local BGP policies. Since AS-path length is usually 838 an important metric for selecting paths, a careful placement of P-ITR 839 could significantly reduce path-stretch between LISP and non-LISP 840 sites. 842 The architecture allows for flexible policies between MSP/PSPs. 843 Consider the EID Route Server networks as control plane overlays, 844 facilitating the implementation of policies necessary to reflect the 845 business relationships between participants. The results are then 846 injected to the common underlying forwarding plane. For example, 847 some MSP/PSPs may agree to exchange EID-Prefixes and only announce 848 them to each of their forwarding plane customers. Global 849 reachability of an EID-prefix depends on the MSP the LISP site buys 850 service from, and is also subject to agreement between the mentioned 851 parties. 853 In terms of impact on the DFZ, this architecture results in a slower 854 routing table increase for new allocations, since traffic engineering 855 will be done at the LISP level. For existing allocations migrating 856 to LISP, the DFZ may decrease since MSPs may be able to aggregate the 857 prefixes announced. 859 Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix 860 deaggregation for traffic engineering purposes, resulting in slower 861 routing table increase in the case of new allocations and potential 862 decrease for existing ones. Moreover, MSPs serving different clients 863 with adjacent aggregable prefixes may lead to additional decrease, 864 but quantifying this decrease is subject to future research study. 866 The flexibility and scalability of this architecture does not come 867 without a cost however: A PSP operator has to establish either 868 transit or peering relationships to improve their connectivity. 870 5.4. Migration Summary 872 The following table presents the expected effects of the different 873 transition scenarios during a certain phase on the DFZ routing table 874 size: 876 Phase | LISP+BGP | MSP P-ITR | PITR-RD 877 -----------------+--------------+-----------------+---------------- 878 Early transition | no change | slower increase | slower increase 879 Late transition | may decrease | slower increase | slower increase 880 LISP Internet | considerable decrease 882 It is expected that PITR-RD will co-exist with LISP+BGP during the 883 migration, with the latter being more popular in the early transition 884 phase. As the transition progresses and the MSP P-ITR and PITR-RD 885 ecosystem gets more ubiquitous, LISP+BGP should become less 886 attractive, slowing down the increase of the number of routes in the 887 DFZ. 889 6. Security Considerations 891 Security implications of LISP deployments are to be discussed in 892 separate documents. [I-D.saucez-lisp-security] gives an overview of 893 LISP threat models, while securing mapping lookups is discussed in 894 [I-D.ietf-lisp-sec]. 896 7. IANA Considerations 898 This memo includes no request to IANA. 900 8. Acknowledgements 902 Many thanks to Margaret Wasserman for her contribution to the IETF76 903 presentation that kickstarted this work. The authors would also like 904 to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, 905 Dino Farinacci, Terry Manderson, Noel Chiappa, and everyone else who 906 provided input. 908 9. References 910 9.1. Normative References 912 [I-D.ietf-lisp] 913 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 914 "Locator/ID Separation Protocol (LISP)", 915 draft-ietf-lisp-15 (work in progress), July 2011. 917 [I-D.ietf-lisp-alt] 918 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 919 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07 920 (work in progress), June 2011. 922 [I-D.ietf-lisp-interworking] 923 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 924 "Interworking LISP with IPv4 and IPv6", 925 draft-ietf-lisp-interworking-02 (work in progress), 926 June 2011. 928 [I-D.ietf-lisp-ms] 929 Fuller, V. and D. Farinacci, "LISP Map Server", 930 draft-ietf-lisp-ms-10 (work in progress), July 2011. 932 [I-D.ietf-lisp-sec] 933 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 934 and O. Bonaventure, "LISP-Security (LISP-SEC)", 935 draft-ietf-lisp-sec-00 (work in progress), July 2011. 937 [I-D.saucez-lisp-security] 938 Saucez, D., Iannone, L., and O. Bonaventure, "LISP 939 Security Threats", draft-saucez-lisp-security-03 (work in 940 progress), March 2011. 942 9.2. Informative References 944 [I-D.ietf-lisp-eid-block] 945 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 946 EID Block", draft-ietf-lisp-eid-block-00 (work in 947 progress), July 2011. 949 [I-D.lear-lisp-nerd] 950 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 951 draft-lear-lisp-nerd-08 (work in progress), March 2010. 953 [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS 954 performance and the effectiveness of caching", 2002. 956 Authors' Addresses 958 Lorand Jakab 959 Technical University of Catalonia 960 C/Jordi Girona, s/n 961 BARCELONA 08034 962 Spain 964 Email: ljakab@ac.upc.edu 966 Albert Cabellos-Aparicio 967 Technical University of Catalonia 968 C/Jordi Girona, s/n 969 BARCELONA 08034 970 Spain 972 Email: acabello@ac.upc.edu 973 Florin Coras 974 Technical University of Catalonia 975 C/Jordi Girona, s/n 976 BARCELONA 08034 977 Spain 979 Email: fcoras@ac.upc.edu 981 Jordi Domingo-Pascual 982 Technical University of Catalonia 983 C/Jordi Girona, s/n 984 BARCELONA 08034 985 Spain 987 Email: jordi.domingo@ac.upc.edu 989 Darrel Lewis 990 Cisco Systems 991 170 Tasman Drive 992 San Jose, CA 95134 993 USA 995 Email: darlewis@cisco.com