idnits 2.17.1 draft-ietf-lisp-deployment-05.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 475 has weird spacing: '...ructure x ...' -- The document date (October 20, 2012) is 4178 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-23 == Outdated reference: A later version (-13) exists of draft-ietf-lisp-eid-block-02 == Outdated reference: A later version (-29) exists of draft-ietf-lisp-sec-04 Summary: 0 errors (**), 0 flaws (~~), 5 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: April 23, 2013 J. Domingo-Pascual 6 Technical University of 7 Catalonia 8 D. Lewis 9 Cisco Systems 10 October 20, 2012 12 LISP Network Element Deployment Considerations 13 draft-ietf-lisp-deployment-05.txt 15 Abstract 17 This document discusses the different scenarios for the deployment of 18 the new network elements introduced by the Locator/Identifier 19 Separation Protocol (LISP). 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on April 23, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 59 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 6 60 2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 61 2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10 62 2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 10 64 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 65 3. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 11 66 3.1. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 11 67 3.2. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 12 68 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13 69 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 15 72 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16 74 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17 75 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19 76 6. Step-by-Step Example BGP to LISP Migration Procedure . . . . . 20 77 6.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 20 78 6.2. Customer Activating LISP Service . . . . . . . . . . . . . 21 79 6.3. Cut-Over Provider Preparation and Changes . . . . . . . . 22 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 82 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23 83 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 84 10.1. Normative References . . . . . . . . . . . . . . . . . . . 23 85 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 88 1. Introduction 90 The Locator/Identifier Separation Protocol (LISP) addresses the 91 scaling issues of the global Internet routing system by separating 92 the current addressing scheme into Endpoint IDentifiers (EIDs) and 93 Routing LOCators (RLOCs). The main protocol specification 94 [I-D.ietf-lisp] describes how the separation is achieved, which new 95 network elements are introduced, and details the packet formats for 96 the data and control planes. 98 LISP assumes that such separation is between the edge and core. 99 While the boundary between both is not strictly defined, one widely 100 accepted definition places it at the border routers of stub 101 autonomous systems, which may carry a partial or complete default- 102 free zone (DFZ) routing table. The initial design of LISP took this 103 location as a baseline for protocol development. However, the 104 applications of LISP go beyond of just decreasing the size of the DFZ 105 routing table, and include improved multihoming and ingress traffic 106 engineering (TE) support for edge networks, and even individual 107 hosts. Throughout the draft we will use the term LISP site to refer 108 to these networks/hosts behind a LISP Tunnel Router. We formally 109 define it as: 111 LISP site: A single host or a set of network elements in an edge 112 network under the administrative control of a single organization, 113 delimited from other networks by LISP Tunnel Router(s). 115 Since LISP is a protocol which can be used for different purposes, it 116 is important to identify possible deployment scenarios and the 117 additional requirements they may impose on the protocol specification 118 and other protocols. Additionally, this document is intended as a 119 guide for the operational community for LISP deployments in their 120 networks. It is expected to evolve as LISP deployment progresses, 121 and the described scenarios are better understood or new scenarios 122 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 2. Tunnel Routers 131 LISP is a map-and-encap protocol, with the main goal of improving 132 global routing scalability. To achieve its goal, it introduces 133 several new network elements, each performing specific functions 134 necessary to separate the edge from the core. The device that is the 135 gateway between the edge and the core is called Tunnel Router (xTR), 136 performing one or both of two separate functions: 138 1. Encapsulating packets originating from an end host to be 139 transported over intermediary (transit) networks towards the 140 other end-point of the communication 142 2. Decapsulating packets entering from intermediary (transit) 143 networks, originated at a remote end host. 145 The first function is performed by an Ingress Tunnel Router (ITR), 146 the second by an Egress Tunnel Router (ETR). 148 Section 8 of the main LISP specification [I-D.ietf-lisp] has a short 149 discussion of where Tunnel Routers can be deployed and some of the 150 associated advantages and disadvantages. This section adds more 151 detail to the scenarios presented there, and provides additional 152 scenarios as well. 154 2.1. Customer Edge 156 LISP was designed with deployment at the core-edge boundary in mind, 157 which can be approximated as the set of DFZ routers belonging to non- 158 transit ASes. For the purposes of this document, we will consider 159 this boundary to be consisting of the routers connecting LISP sites 160 to their upstreams. As such, this is the most common expected 161 scenario for xTRs, and this document considers it the reference 162 location, comparing the other scenarios to this one. 164 ISP1 ISP2 165 | | 166 | | 167 +----+ +----+ 168 +--|xTR1|--|xTR2|--+ 169 | +----+ +----+ | 170 | | 171 | LISP site | 172 +------------------+ 174 Figure 1: xTRs at the customer edge 176 From the LISP site perspective the main advantage of this type of 177 deployment (compared to the one described in the next section) is 178 having direct control over its ingress traffic engineering. This 179 makes it is easy to set up and maintain active/active, active/backup, 180 or more complex TE policies, without involving third parties. 182 Being under the same administrative control, reachability information 183 of all ETRs is easier to synchronize, because the necessary control 184 traffic can be allowed between the locators of the ETRs. A correct 185 synchronous global view of the reachability status is thus available, 186 and the Loc-Status-Bits can be set correctly in the LISP data header 187 of outgoing packets. 189 By placing the tunnel router at the edge of the site, existing 190 internal network configuration does not need to be modified. 191 Firewall rules, router configurations and address assignments inside 192 the LISP site remain unchanged. This helps with incremental 193 deployment and allows a quick upgrade path to LISP. For larger sites 194 with many external connections, distributed in geographically diverse 195 PoPs, and complex internal topology, it may however make more sense 196 to both encapsulate and decapsulate as soon as possible, to benefit 197 from the information in the IGP to choose the best path (see 198 Section 2.3 for a discussion of this scenario). 200 Another thing to consider when placing tunnel routers are MTU issues. 201 Since encapsulating packets increases overhead, the MTU of the end- 202 to-end path may decrease, when encapsulated packets need to travel 203 over segments having close to minimum MTU. Some transit networks are 204 known to provide larger MTU than the typical value of 1500 bytes of 205 popular access technologies used at end hosts (e.g., IEEE 802.3 and 206 802.11). However, placing the LISP router connecting to such a 207 network at the customer edge could possibly bring up MTU issues, 208 depending on the link type to the provider as opposed to the 209 following scenario. 211 2.2. Provider Edge 213 The other location at the core-edge boundary for deploying LISP 214 routers is at the Internet service provider edge. The main incentive 215 for this case is that the customer does not have to upgrade the CE 216 router(s), or change the configuration of any equipment. 217 Encapsulation/decapsulation happens in the provider's network, which 218 may be able to serve several customers with a single device. For 219 large ISPs with many residential/business customers asking for LISP 220 this can lead to important savings, since there is no need to upgrade 221 the software (or hardware, if it's the case) at each client's 222 location. Instead, they can upgrade the software (or hardware) on a 223 few PE routers serving the customers. This scenario is depicted in 224 Figure 2. 226 +----------+ +------------------+ 227 | ISP1 | | ISP2 | 228 | | | | 229 | +----+ | | +----+ +----+ | 230 +--|xTR1|--+ +--|xTR2|--|xTR3|--+ 231 +----+ +----+ +----+ 232 | | | 233 | | | 234 +--<[LISP site]>---+-------+ 236 Figure 2: xTR at the PE 238 While this approach can make transition easy for customers and may be 239 cheaper for providers, the LISP site looses one of the main benefits 240 of LISP: ingress traffic engineering. Since the provider controls 241 the ETRs, additional complexity would be needed to allow customers to 242 modify their mapping entries. 244 The problem is aggravated when the LISP site is multihomed. Consider 245 the scenario in Figure 2: whenever a change to TE policies is 246 required, the customer contacts both ISP1 and ISP2 to make the 247 necessary changes on the routers (if they provide this possibility). 248 It is however unlikely, that both ISPs will apply changes 249 simultaneously, which may lead to inconsistent state for the mappings 250 of the LISP site. Since the different upstream ISPs are usually 251 competing business entities, the ETRs may even be configured to 252 compete, either to attract all the traffic or to get no traffic. The 253 former will happen if the customer pays per volume, the latter if the 254 connectivity has a fixed price. A solution could be to have the 255 mappings in the Map-Server(s), and have their operator give control 256 over the entries to customer, much like in the Domain Name System at 257 the time of this writing. 259 Additionally, since xTR1, xTR2, and xTR3 are in different 260 administrative domains, locator reachability information is unlikely 261 to be exchanged among them, making it difficult to set Loc-Status- 262 Bits correctly on encapsulated packets. 264 Compared to the customer edge scenario, deploying LISP at the 265 provider edge might have the advantage of diminishing potential MTU 266 issues, because the tunnel router is closer to the core, where links 267 typically have higher MTUs than edge network links. 269 2.3. Split ITR/ETR 271 In a simple LISP deployment, xTRs are located at the border of the 272 LISP site (see Section 2.1). In this scenario packets are routed 273 inside the domain according to the EID. However, more complex 274 networks may want to route packets according to the destination RLOC. 275 This would enable them to choose the best egress point. 277 The LISP specification separates the ITR and ETR functionality and 278 considers that both entities can be deployed in separated network 279 equipment. ITRs can be deployed closer to the host (i.e., access 280 routers). This way packets are encapsulated as soon as possible, and 281 packets exit the network through the best egress point in terms of 282 BGP policy. In turn, ETRs can be deployed at the border routers of 283 the network, and packets are decapsulated as soon as possible. Once 284 decapsulated, packets are routed based on destination EID, according 285 to internal routing policy. 287 In the following figure we can see an example. The Source (S) 288 transmits packets using its EID and in this particular case packets 289 are encapsulated at ITR_1. The encapsulated packets are routed 290 inside the domain according to the destination RLOC, and can egress 291 the network through the best point (i.e., closer to the RLOC's AS). 292 On the other hand, inbound packets are received by ETR_1 which 293 decapsulates them. Then packets are routed towards S according to 294 the EID, again following the best path. 296 +---------------------------------------+ 297 | | 298 | +-------+ +-------+ +-------+ 299 | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | 300 | +-------+ | +-------+ +-------+ 301 | +-+ | | | 302 | |S| | IGP | | 303 | +-+ | | | 304 | +-------+ | +-------+ +-------+ 305 | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | 306 | +-------+ +-------+ +-------+ 307 | | 308 +---------------------------------------+ 310 Figure 3: Split ITR/ETR Scenario 312 This scenario has a set of implications: 314 o The site must carry at least partial BGP routes in order to choose 315 the best egress point, increasing the complexity of the network. 316 However, this is usually already the case for LISP sites that 317 would benefit from this scenario. 319 o If the site is multihomed to different ISPs and any of the 320 upstream ISPs is doing uRPF filtering, this scenario may become 321 impractical. ITRs need to determine the exit ETR, for setting the 322 correct source RLOC in the encapsulation header. This adds 323 complexity and reliability concerns. 325 o In LISP, ITRs set the reachability bits when encapsulating data 326 packets. Hence, ITRs need a mechanism to be aware of the liveness 327 of all ETRs serving their site. 329 o MTU within the site network must be large enough to accommodate 330 encapsulated packets. 332 o In this scenario, each ITR is serving fewer hosts than in the case 333 when it is deployed at the border of the network. It has been 334 shown that cache hit ratio grows logarithmically with the amount 335 of users [cache]. Taking this into account, when ITRs are 336 deployed closer to the host the effectiveness of the mapping cache 337 may be lower (i.e., the miss ratio is higher). Another 338 consequence of this is that the site may transmit a higher amount 339 of Map-Requests, increasing the load on the distributed mapping 340 database. 342 2.4. Inter-Service Provider Traffic Engineering 344 With LISP, two LISP sites can route packets among them and control 345 their ingress TE policies. Typically, LISP is seen as applicable to 346 stub networks, however the LISP protocol can also be applied to 347 transit networks recursively. 349 Consider the scenario depicted in Figure 4. Packets originating from 350 the LISP site Stub1, client of ISP_A, with destination Stub4, client 351 of ISP_B, are LISP encapsulated at their entry point into the ISP_A's 352 network. The external IP header now has as the source RLOC an IP 353 from ISP_A's address space and destination RLOC from ISP_B's address 354 space. One or more ASes separate ISP_A from ISP_B. With a single 355 level of LISP encapsulation, Stub4 has control over its ingress 356 traffic. However, at the time of this writing, ISP_B has only BGP 357 tools (such as prefix deaggregation) to control on which of his own 358 upstream or peering links should packets enter. This is either not 359 feasible (if fine-grained per-customer control is required, the very 360 specific prefixes may not be propagated) or increases DFZ table size. 362 _.--. 363 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 364 \ | R_A1|----,' `. ---|R_B1 | / 365 --| R_A2|---( Transit ) | |-- 366 Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 367 +-------+ `--. _.-' +-------+ 368 ... ISP_A `--'' ISP_B ... 370 Figure 4: Inter-Service provider TE scenario 372 A solution for this is to apply LISP recursively. ISP_A and ISP_B 373 may reach a bilateral agreement to deploy their own private mapping 374 system. ISP_A then encapsulates packets destined for the prefixes of 375 ISP_B, which are listed in the shared mapping system. Note that in 376 this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3 377 as source and R_B1 or R_B2 as destination in the example above). 378 ISP_B's ETR removes the outer, second layer of LISP encapsulation 379 from the incoming packet, and routes it towards the original RLOC, 380 the ETR of Stub4, which does the final decapsulation. 382 If ISP_A and ISP_B agree to share a private distributed mapping 383 database, both can control their ingress TE without the need of 384 deaggregating prefixes. In this scenario the private database 385 contains RLOC-to-RLOC bindings. The convergence time on the TE 386 policies updates is expected to be fast, since ISPs only have to 387 update/query a mapping to/from the database. 389 This deployment scenario includes two important caveats. First, it 390 is intended to be deployed between only two ISPs (ISP_A and ISP_B in 391 Figure 4). If more than two ISPs use this approach, then the xTRs 392 deployed at the participating ISPs must either query multiple mapping 393 systems, or the ISPs must agree on a common shared mapping system. 394 Second, the scenario is only recommended for ISPs providing 395 connectivity to LISP sites, such that source RLOCs of packets to be 396 reencapsulated belong to said ISP. Otherwise the participating ISPs 397 must register prefixes they do not own in the above mentioned private 398 mapping system. Failure to follow these recommendations may lead to 399 operational and security issues when deploying this scenario. 401 Besides these recommendations, the main disadvantages of this 402 deployment case are: 404 o Extra LISP header is needed. This increases the packet size and 405 requires that the MTU between both ISPs accommodates double- 406 encapsulated packets. 408 o The ISP ITR must encapsulate packets and therefore must know the 409 RLOC-to-RLOC binding. These bindings are stored in a mapping 410 database and may be cached in the ITR's mapping cache. Cache 411 misses lead to an additional lookup latency, unless a push based 412 mapping system is used for the private mapping system. 414 o The operational overhead of maintaining the shared mapping 415 database. 417 o If an IPv6 address block is reserved for EID use, as specified in 418 [I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first 419 level) can avoid LISP processing altogether for non-LISP 420 destinations. The ISP tunnel routers however will not be able to 421 take advantage of this optimization, all RLOC-to-RLOC mappings 422 need a lookup in the private database (or map-cache, once results 423 are cached). 425 2.5. Tunnel Routers Behind NAT 427 NAT in this section refers to IPv4 network address and port 428 translation. 430 2.5.1. ITR 432 Packets encapsulated by an ITR are just UDP packets from a NAT 433 device's point of view, and they are handled like any UDP packet, 434 there are no additional requirements for LISP data packets. 436 Map-Requests sent by an ITR, which create the state in the NAT table, 437 have a different 5-tuple in the IP header than the Map-Reply 438 generated by the authoritative ETR. Since the source address of this 439 packet is different from the destination address of the request 440 packet, no state will be matched in the NAT table and the packet will 441 be dropped. To avoid this, the NAT device has to do the following: 443 o Send all UDP packets with source port 4342, regardless of the 444 destination port, to the RLOC of the ITR. The most simple way to 445 achieve this is configuring 1:1 NAT mode from the external RLOC of 446 the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer 447 broadband routers). 449 o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in 450 the payload. 452 This setup supports a single ITR behind the NAT device. 454 2.5.2. ETR 456 An ETR placed behind NAT is reachable from the outside by the 457 Internet-facing locator of the NAT device. It needs to know this 458 locator (and configure a loopback interface with it), so that it can 459 use it in Map-Reply and Map-Register messages. Thus support for 460 dynamic locators for the mapping database is needed in LISP 461 equipment. 463 Again, only one ETR behind the NAT device is supported. 465 An implication of the issues described above is that LISP sites with 466 xTRs can not be behind carrier based NATs, since two different sites 467 would collide on the port forwarding. 469 2.6. Summary and Feature Matrix 471 Feature CE PE Split Rec. 472 -------------------------------------------------------- 473 Control of ingress TE x - x x 474 No modifications to existing 475 int. network infrastructure x x - - 476 Loc-Status-Bits sync x - x x 477 MTU/PMTUD issues minimized - x - x 479 3. Map-Resolvers and Map-Servers 481 3.1. Map-Servers 483 The Map-Server learns EID-to-RLOC mapping entries from an 484 authoritative source and publishes them in the distributed mapping 485 database. These entries are learned through authenticated Map- 486 Register messages sent by authoritative ETRs. Also, upon reception 487 of a Map-Request, the Map-Server verifies that the destination EID 488 matches an EID-prefix for which it is authoritative for, and then re- 489 encapsulates and forwards it to a matching ETR. Map-Server 490 functionality is described in detail in [I-D.ietf-lisp-ms]. 492 The Map-Server is provided by a Mapping Service Provider (MSP). A 493 MSP can be any of the following: 495 o EID registrar. Since the IPv4 address space is nearing 496 exhaustion, IPv4 EIDs will come from already allocated Provider 497 Independent (PI) space. The registrars in this case remain the 498 current five Regional Internet Registries (RIRs). In the case of 499 IPv6, the possibility of reserving a /16 block as EID space is 500 currently under consideration [I-D.ietf-lisp-eid-block]. If 501 granted by IANA, the community will have to determine the body 502 responsible for allocations from this block, and the associated 503 policies. Existing allocation policies apply to EIDs outside this 504 block. 506 o Third parties. Participating in the LISP mapping system is 507 similar to participating in global routing or DNS: as long as 508 there is at least another already participating entity willing to 509 forward the newcomer's traffic, there is no barrier to entry. 510 Still, just like routing and DNS, LISP mappings have the issue of 511 trust, with efforts underway to make the published information 512 verifiable. When these mechanisms will be deployed in the LISP 513 mapping system, the burden of providing and verifying trust should 514 be kept away from MSPs, which will simply host the secured 515 mappings. This will keep the low barrier of entry to become an 516 MSP for third parties. 518 In all cases, the MSP configures its Map-Server(s) to publish the 519 prefixes of its clients in the distributed mapping database and start 520 encapsulating and forwarding Map-Requests to the ETRs of the AS. 521 These ETRs register their prefix(es) with the Map-Server(s) through 522 periodic authenticated Map-Register messages. In this context, for 523 some LISP end sites, there is a need for mechanisms to: 525 o Automatically distribute EID prefix(es) shared keys between the 526 ETRs and the EID-registrar Map-Server. 528 o Dynamically obtain the address of the Map-Server in the ETR of the 529 AS. 531 The Map-Server plays a key role in the reachability of the EID- 532 prefixes it is serving. On the one hand it is publishing these 533 prefixes into the distributed mapping database and on the other hand 534 it is encapsulating and forwarding Map-Requests to the authoritative 535 ETRs of these prefixes. ITRs encapsulating towards EIDs under the 536 responsibility of a failed Map-Server will be unable to look up any 537 of their covering prefixes. The only exception are the ITRs that 538 already contain the mappings in their local cache. In this case ITRs 539 can reach ETRs until the entry expires (typically 24 hours). For 540 this reason, redundant Map-Server deployments are desirable. A set 541 of Map-Servers providing high-availability service to the same set of 542 prefixes is called a redundancy group. ETRs are configured to send 543 Map-Register messages to all Map-Servers in the redundancy group. To 544 achieve fail-over (or load-balancing, if desired), known mapping 545 system specific best practices should be used. 547 Additionally, if a Map-Server has no reachability for any ETR serving 548 a given EID block, it should not originate that block into the 549 mapping system. 551 3.2. Map-Resolvers 553 A Map-Resolver a is a network infrastructure component which accepts 554 LISP encapsulated Map-Requests, typically from an ITR, and finds the 555 appropriate EID-to-RLOC mapping by either consulting its local cache 556 or by consulting the distributed mapping database. Map-Resolver 557 functionality is described in detail in [I-D.ietf-lisp-ms]. 559 Anyone with access to the distributed mapping database can set up a 560 Map-Resolver and provide EID-to-RLOC mapping lookup service. 561 Database access setup is mapping system specific. 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 5 is dedicated to the migration to a 631 LISP-enabled Internet, and includes deployment scenarios for P-ITRs. 633 4.2. P-ETR 635 In contrast to P-ITRs, P-ETRs are not required for the correct 636 functioning of all LISP sites. There are two cases, where they can 637 be of great help: 639 o LISP sites with unicast reverse path forwarding (uRPF) 640 restrictions, and 642 o Communication between sites using different address family RLOCs. 644 In the first case, uRPF filtering is applied at their upstream PE 645 router. When forwarding traffic to non-LISP sites, an ITR does not 646 encapsulate packets, leaving the original IP headers intact. As a 647 result, packets will have EIDs in their source address. Since we are 648 discussing the transition period, we can assume that a prefix 649 covering the EIDs belonging to the LISP site is advertised to the 650 global routing tables by a P-ITR, and the PE router has a route 651 towards it. However, the next hop will not be on the interface 652 towards the CE router, so non-encapsulated packets will fail uRPF 653 checks. 655 To avoid this filtering, the affected ITR encapsulates packets 656 towards the locator of the P-ETR for non-LISP destinations. Now the 657 source address of the packets, as seen by the PE router is the ITR's 658 locator, which will not fail the uRPF check. The P-ETR then 659 decapsulates and forwards the packets. 661 The second use case is IPv4-to-IPv6 transition. Service providers 662 using older access network hardware, which only supports IPv4 can 663 still offer IPv6 to their clients, by providing a CPE device running 664 LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP 665 sites, with IPv6-only locators. Packets originating from the client 666 LISP site for these destinations would be encapsulated towards the 667 P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, 668 decapsulating and forwarding packets. For non-LISP destination, the 669 packet travels natively from the P-ETR. For LISP destinations with 670 IPv6-only locators, the packet will go through a P-ITR, in order to 671 reach its destination. 673 For more details on P-ETRs see the [I-D.ietf-lisp-interworking] 674 draft. 676 P-ETRs can be deployed by ISPs wishing to offer value-added services 677 to their customers. As is the case with P-ITRs, P-ETRs too may 678 introduce path stretch. Because of this the ISP needs to consider 679 the tradeoff of using several devices, close to the customers, to 680 minimize it, or few devices, farther away from the customers, 681 minimizing cost instead. 683 Since the deployment incentives for P-ITRs and P-ETRs are different, 684 it is likely they will be deployed in separate devices, except for 685 the CDN case, which may deploy both in a single device. 687 In all cases, the existence of a P-ETR involves another step in the 688 configuration of a LISP router. CPE routers, which are typically 689 configured by DHCP, stand to benefit most from P-ETRs. 690 Autoconfiguration of the P-ETR locator could be achieved by a DHCP 691 option, or adding a P-ETR field to either Map-Notifys or Map-Replies. 693 As a security measure, access to P-ETRs should be limited to 694 legitimate users by enforcing ACLs. 696 5. Migration to LISP 698 This section discusses a deployment architecture to support the 699 migration to a LISP-enabled Internet. The loosely defined terms of 700 "early transition phase", "late transition phase", and "LISP Internet 701 phase" refer to time periods when LISP sites are a minority, a 702 majority, or represent all edge networks respectively. 704 5.1. LISP+BGP 706 For sites wishing to go LISP with their PI prefix the least 707 disruptive way is to upgrade their border routers to support LISP, 708 register the prefix into the LISP mapping system, but keep announcing 709 it with BGP as well. This way LISP sites will reach them over LISP, 710 while legacy sites will be unaffected by the change. The main 711 disadvantage of this approach is that no decrease in the DFZ routing 712 table size is achieved. Still, just increasing the number of LISP 713 sites is an important gain, as an increasing LISP/non-LISP site ratio 714 will slowly decrease the need for BGP-based traffic engineering that 715 leads to prefix deaggregation. That, in turn, may lead to a decrease 716 in the DFZ size in the late transition phase. 718 This scenario is not limited to sites that already have their 719 prefixes announced with BGP. Newly allocated EID blocks could follow 720 this strategy as well during the early LISP deployment phase, 721 depending on the cost/benefit analysis of the individual networks. 722 Since this leads to an increase in the DFZ size, the following 723 architecture should be preferred for new allocations. 725 5.2. Mapping Service Provider (MSP) P-ITR Service 727 In addition to publishing their clients' registered prefixes in the 728 mapping system, MSPs with enough transit capacity can offer them 729 P-ITR service as a separate service. This service is especially 730 useful for new PI allocations, to sites without existing BGP 731 infrastructure, that wish to avoid BGP altogether. The MSP announces 732 the prefix into the DFZ, and the client benefits from ingress traffic 733 engineering without prefix deaggregation. The downside of this 734 scenario is adding path stretch. 736 Routing all non-LISP ingress traffic through a third party which is 737 not one of its ISPs is only feasible for sites with modest amounts of 738 traffic (like those using the IPv6 tunnel broker services today), 739 especially in the first stage of the transition to LISP, with a 740 significant number of legacy sites. When the LISP/non-LISP site 741 ratio becomes high enough, this approach can prove increasingly 742 attractive. 744 Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix 745 deaggregation for traffic engineering purposes, resulting in slower 746 routing table increase in the case of new allocations and potential 747 decrease for existing ones. Moreover, MSPs serving different clients 748 with adjacent aggregable prefixes may lead to additional decrease, 749 but quantifying this decrease is subject to future research study. 751 5.3. Proxy-ITR Route Distribution (PITR-RD) 753 Instead of a LISP site, or the MSP, announcing their EIDs with BGP to 754 the DFZ, this function can be outsourced to a third party, a P-ITR 755 Service Provider (PSP). This will result in a decrease of the 756 operational complexity both at the site and at the MSP. 758 The PSP manages a set of distributed P-ITR(s) that will advertise the 759 corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) 760 will then encapsulate the traffic they receive for those EIDs towards 761 the RLOCs of the LISP site, ensuring their reachability from non-LISP 762 sites. 764 While it is possible for a PSP to manually configure each client's 765 EID routes to be announced, this approach offers little flexibility 766 and is not scalable. This section presents a scalable architecture 767 that offers automatic distribution of EID routes to LISP sites and 768 service providers. 770 The architecture requires no modification to existing LISP network 771 elements, but it introduces a new (conceptual) network element, the 772 EID Route Server, defined as a router that either propagates routes 773 learned from other EID Route Servers, or it originates EID Routes. 774 The EID-Routes that it originates are those that it is authoritative 775 for. It propagates these routes to Proxy-ITRs within the AS of the 776 EID Route Server. It is worth to note that a BGP capable router can 777 be also considered as an EID Route Server. 779 Further, an EID-Route is defined as a prefix originated via the Route 780 Server of the mapping service provider, which should be aggregated if 781 the MSP has multiple customers inside a single netblock. This prefix 782 is propagated to other P-ITRs both within the MSP and to other P-ITR 783 operators it peers with. EID Route Servers are operated either by 784 the LISP site, MSPs or PSPs, and they may be collocated with a Map- 785 Server or P-ITR, but are a functionally discrete entity. They 786 distribute EID-Routes, using BGP, to other domains, according to 787 policies set by participants. 789 MSP (AS64500) 790 RS ---> P-ITR 791 | / 792 | _.--./ 793 ,-'' /`--. 794 LISP site ---,' | v `. 795 ( | DFZ )----- Mapping system 796 non-LISP site ----. | ^ ,' 797 `--. / _.-' 798 | `--'' 799 v / 800 P-ITR 801 PSP (AS64501) 803 Figure 5: The P-ITR Route Distribution architecture 805 The architecture described above decouples EID origination from route 806 propagation, with the following benefits: 808 o Can accurately represent business relationships between P-ITR 809 operators 811 o More mapping system agnostic 813 o Minor changes to P-ITR implementation, no changes to other 814 components 816 In the example in the figure we have a MSP providing services to the 817 LISP site. The LISP site does not run BGP, and gets an EID 818 allocation directly from a RIR, or from the MSP, who may be a LIR. 819 Existing PI allocations can be migrated as well. The MSP ensures the 820 presence of the prefix in the mapping system, and runs an EID Route 821 Server to distribute it to P-ITR service providers. Since the LISP 822 site does not run BGP, the prefix will be originated with the AS 823 number of the MSP. 825 In the simple case depicted in Figure 5 the EID-Route of LISP Site 826 will be originated by the Route Server, and announced to the DFZ by 827 the PSP's P-ITRs with AS path 64501 64500. From that point on, the 828 usual BGP dynamics apply. This way, routes announced by P-ITR are 829 still originated by the authoritative Route Server. Note that the 830 peering relationships between MSP/PSPs and those in the underlying 831 forwarding plane may not be congruent, making the AS path to a P-ITR 832 shorter than it is in reality. 834 The non-LISP site will select the best path towards the EID-prefix, 835 according to its local BGP policies. Since AS-path length is usually 836 an important metric for selecting paths, a careful placement of P-ITR 837 could significantly reduce path-stretch between LISP and non-LISP 838 sites. 840 The architecture allows for flexible policies between MSP/PSPs. 841 Consider the EID Route Server networks as control plane overlays, 842 facilitating the implementation of policies necessary to reflect the 843 business relationships between participants. The results are then 844 injected to the common underlying forwarding plane. For example, 845 some MSP/PSPs may agree to exchange EID-Prefixes and only announce 846 them to each of their forwarding plane customers. Global 847 reachability of an EID-prefix depends on the MSP the LISP site buys 848 service from, and is also subject to agreement between the mentioned 849 parties. 851 In terms of impact on the DFZ, this architecture results in a slower 852 routing table increase for new allocations, since traffic engineering 853 will be done at the LISP level. For existing allocations migrating 854 to LISP, the DFZ may decrease since MSPs may be able to aggregate the 855 prefixes announced. 857 Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix 858 deaggregation for traffic engineering purposes, resulting in slower 859 routing table increase in the case of new allocations and potential 860 decrease for existing ones. Moreover, MSPs serving different clients 861 with adjacent aggregable prefixes may lead to additional decrease, 862 but quantifying this decrease is subject to future research study. 864 The flexibility and scalability of this architecture does not come 865 without a cost however: A PSP operator has to establish either 866 transit or peering relationships to improve their connectivity. 868 5.4. Migration Summary 870 The following table presents the expected effects of the different 871 transition scenarios during a certain phase on the DFZ routing table 872 size: 874 Phase | LISP+BGP | MSP P-ITR | PITR-RD 875 -----------------+--------------+-----------------+---------------- 876 Early transition | no change | slower increase | slower increase 877 Late transition | may decrease | slower increase | slower increase 878 LISP Internet | considerable decrease 880 It is expected that PITR-RD will co-exist with LISP+BGP during the 881 migration, with the latter being more popular in the early transition 882 phase. As the transition progresses and the MSP P-ITR and PITR-RD 883 ecosystem gets more ubiquitous, LISP+BGP should become less 884 attractive, slowing down the increase of the number of routes in the 885 DFZ. 887 6. Step-by-Step Example BGP to LISP Migration Procedure 889 6.1. Customer Pre-Install and Pre-Turn-up Checklist 891 1. Determine how many current physical service provider connections 892 the customer has and their existing bandwidth and traffic 893 engineering requirements. 895 This information will determine the number of routing locators, 896 and the priorities and weights that should be configured on the 897 xTRs. 899 2. Make sure customer router has LISP capabilities. 901 * Obtain output of 'show version' from the CE router. 903 This information can be used to determine if the platform is 904 appropriate to support LISP, in order to determine if a 905 software and/or hardware upgrade is required. 907 * Have customer upgrade (if necessary, software and/or hardware) 908 to be LISP capable. 910 3. Obtain current running configuration of CE router. A suggested 911 LISP router configuration example can be customized to the 912 customer's existing environment. 914 4. Verify MTU Handling 916 * Request increase in MTU to (1556) on service provider 917 connections. Prior to MTU change verify that 1500 byte packet 918 from P-xTR to RLOC with do not fragment (DF-bit) bit set. 920 * Ensure they are not filtering ICMP unreachable or time- 921 exceeded on their firewall or router. 923 LISP, like any tunneling protocol, will increase the size of 924 packets when the LISP header is appended. If increasing the MTU 925 of the access links is not possible, care must be taken that ICMP 926 is not being filtered in order to allow for Path MTU Discovery to 927 take place. 929 5. Validate member prefix allocation. 931 This step is to check if the prefix used by the customer is a 932 direct (Provider Independent), or if it is a prefix assigned by a 933 physical service provider (Provider Allocated). If the prefixes 934 are assigned by other service provivers then a Letter of 935 Agreement is required to announce prefixes through the Proxy 936 Service Provider. 938 6. Verify the member RLOCs and their reachability. 940 This step ensures that the RLOCs configured on the CE router are 941 in fact reachable and working. 943 7. Prepare for cut-over. 945 * If possible, have a host outside of all security and filtering 946 policies connected to the console port of the edge router or 947 switch. 949 * Make sure customer has access to the router in order to 950 configure it. 952 6.2. Customer Activating LISP Service 954 1. Customer configures LISP on CE router(s) from service provider 955 recommended configuration. 957 The LISP configuration consists of the EID prefix, the locators, 958 and the weights and priorities of the mapping between the two 959 values. In addition, the xTR must be configured with Map- 960 Resolver(s), Map-Server(s) and the shared key for registering to 961 Map-Server(s). If required, Proxy-ETR(s) may be configured as 962 well. 964 In addition to the LISP configuration, the following: 966 * Ensure default route(s) to next-hop external neighbors are 967 included and RLOCs are present in configuration. 969 * If two or more routers are used, ensure all RLOCs are included 970 in the LISP configuration on all routers. 972 * It will be necessary to redistribute default route via IGP 973 between the external routers. 975 2. When transition is ready perform a soft shutdown on existing eBGP 976 peer session(s) 978 * From CE router, use LIG to ensure registration is successful. 980 * To verify LISP connectivity, ping LISP connected sites. See 981 http://www.lisp4.net/ and/or http://www.lisp6.net/ for 982 potential candidates. 984 * To verify connectivity to non-LISP sites, try accessing major 985 Internet sites via a web browser. 987 6.3. Cut-Over Provider Preparation and Changes 989 1. Verify site configuration and then active registration on Map- 990 Server(s) 992 * Authentication key 994 * EID prefix 996 2. Add EID space to map-cache on proxies 998 3. Add networks to BGP advertisement on proxies 1000 * Modify route-maps/policies on P-xTRs 1002 * Modify route policies on core routers (if non-connected 1003 member) 1005 * Modify ingress policers on core routers 1007 * Ensure route announcement in looking glass servers, RouteViews 1009 4. Perform traffic verification test 1011 * Ensure MTU handling is as expected (PMTUD working) 1013 * Ensure proxy-ITR map-cache population 1015 * Ensure access from traceroute/ping servers around Internet 1017 * Use a looking glass, to check for external visibility of 1018 registration via several Map-Resolvers (e.g., 1019 http://lispmon.net/). 1021 7. Security Considerations 1023 Security implications of LISP deployments are to be discussed in 1024 separate documents. [I-D.saucez-lisp-security] gives an overview of 1025 LISP threat models, while securing mapping lookups is discussed in 1026 [I-D.ietf-lisp-sec]. 1028 8. IANA Considerations 1030 This memo includes no request to IANA. 1032 9. Acknowledgements 1034 Many thanks to Margaret Wasserman for her contribution to the IETF76 1035 presentation that kickstarted this work. The authors would also like 1036 to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, 1037 Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, and 1038 everyone else who provided input. 1040 10. References 1042 10.1. Normative References 1044 [I-D.ietf-lisp] 1045 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1046 "Locator/ID Separation Protocol (LISP)", 1047 draft-ietf-lisp-23 (work in progress), May 2012. 1049 [I-D.ietf-lisp-interworking] 1050 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1051 "Interworking LISP with IPv4 and IPv6", 1052 draft-ietf-lisp-interworking-06 (work in progress), 1053 March 2012. 1055 [I-D.ietf-lisp-ms] 1056 Fuller, V. and D. Farinacci, "LISP Map Server Interface", 1057 draft-ietf-lisp-ms-16 (work in progress), March 2012. 1059 10.2. Informative References 1061 [I-D.ietf-lisp-eid-block] 1062 Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP 1063 EID Block", draft-ietf-lisp-eid-block-02 (work in 1064 progress), April 2012. 1066 [I-D.ietf-lisp-sec] 1067 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 1068 and O. Bonaventure, "LISP-Security (LISP-SEC)", 1069 draft-ietf-lisp-sec-04 (work in progress), October 2012. 1071 [I-D.saucez-lisp-security] 1072 Saucez, D., Iannone, L., and O. Bonaventure, "LISP 1073 Security Threats", draft-saucez-lisp-security-03 (work in 1074 progress), March 2011. 1076 [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS 1077 performance and the effectiveness of caching", 2002. 1079 Authors' Addresses 1081 Lorand Jakab 1082 Technical University of Catalonia 1083 C/Jordi Girona, s/n 1084 BARCELONA 08034 1085 Spain 1087 Email: ljakab@ac.upc.edu 1089 Albert Cabellos-Aparicio 1090 Technical University of Catalonia 1091 C/Jordi Girona, s/n 1092 BARCELONA 08034 1093 Spain 1095 Email: acabello@ac.upc.edu 1097 Florin Coras 1098 Technical University of Catalonia 1099 C/Jordi Girona, s/n 1100 BARCELONA 08034 1101 Spain 1103 Email: fcoras@ac.upc.edu 1105 Jordi Domingo-Pascual 1106 Technical University of Catalonia 1107 C/Jordi Girona, s/n 1108 BARCELONA 08034 1109 Spain 1111 Email: jordi.domingo@ac.upc.edu 1112 Darrel Lewis 1113 Cisco Systems 1114 170 Tasman Drive 1115 San Jose, CA 95134 1116 USA 1118 Email: darlewis@cisco.com