idnits 2.17.1 draft-ietf-lisp-deployment-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 485 has weird spacing: '...ructure x ...' -- The document date (March 12, 2012) is 4400 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-09 == 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-12 == 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-01 == 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: September 13, 2012 J. Domingo-Pascual 6 Technical University of 7 Catalonia 8 D. Lewis 9 Cisco Systems 10 March 12, 2012 12 LISP Network Element Deployment Considerations 13 draft-ietf-lisp-deployment-03.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 September 13, 2012. 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 . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . . . . 16 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 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 . . . . . . . . . . . . . . . . . . 24 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 While the boundary between the core and edge is not strictly defined, 99 one widely accepted definition places it at the border routers of 100 stub autonomous systems, which may carry a partial or complete 101 default-free zone (DFZ) routing table. The initial design of LISP 102 took this location as a baseline for protocol development. However, 103 the applications of LISP go beyond of just decreasing the size of the 104 DFZ routing table, and include improved multihoming and ingress 105 traffic engineering (TE) support for edge networks, and even 106 individual hosts. Throughout the draft we will use the term LISP 107 site to refer to these networks/hosts behind a LISP Tunnel Router. 108 We formally define it as: 110 LISP site: A single host or a set of network elements in an edge 111 network under the administrative control of a single organization, 112 delimited from other networks by LISP Tunnel Router(s). 114 Since LISP is a protocol which can be used for different purposes, it 115 is important to identify possible deployment scenarios and the 116 additional requirements they may impose on the protocol specification 117 and other protocols. The main specification [I-D.ietf-lisp] mentions 118 positioning of tunnel routers, but without an in-depth discussion. 119 This document fills that gap, by exploring the most common cases. 120 While the theoretical combinations of device placements are quite 121 numerous, the more practical scenarios are given preference in the 122 following. 124 Additionally, this documents is intended as a guide for the 125 operational community for LISP deployments in their networks. It is 126 expected to evolve as LISP deployment progresses, and the described 127 scenarios are better understood or new scenarios are discovered. 129 Each subsection considers an element type, discussing the impact of 130 deployment scenarios on the protocol specification. For definition 131 of terms, please refer to the appropriate documents (as cited in the 132 respective sections). 134 Comments and discussions about this memo should be directed to the 135 LISP working group mailing list: lisp@ietf.org. 137 2. Tunnel Routers 139 LISP is a map-and-encap protocol, with the main goal of improving 140 global routing scalability. To achieve its goal, it introduces 141 several new network elements, each performing specific functions 142 necessary to separate the edge from the core. The device that is the 143 gateway between the edge and the core is called Tunnel Router (xTR), 144 performing one or both of two separate functions: 146 1. Encapsulating packets originating from an end host to be 147 transported over intermediary (transit) networks towards the 148 other end-point of the communication 150 2. Decapsulating packets entering from intermediary (transit) 151 networks, originated at a remote end host. 153 The first function is performed by an Ingress Tunnel Router (ITR), 154 the second by an Egress Tunnel Router (ETR). 156 Section 8 of the main LISP specification [I-D.ietf-lisp] has a short 157 discussion of where Tunnel Routers can be deployed and some of the 158 associated advantages and disadvantages. This section adds more 159 detail to the scenarios presented there, and provides additional 160 scenarios as well. 162 2.1. Customer Edge 164 LISP was designed with deployment at the core-edge boundary in mind, 165 which can be approximated as the set of DFZ routers belonging to non- 166 transit ASes. For the purposes of this document, we will consider 167 this boundary to be consisting of the routers connecting LISP sites 168 to their upstreams. As such, this is the most common expected 169 scenario for xTRs, and this document considers it the reference 170 location, comparing the other scenarios to this one. 172 ISP1 ISP2 173 | | 174 | | 175 +----+ +----+ 176 +--|xTR1|--|xTR2|--+ 177 | +----+ +----+ | 178 | | 179 | LISP site | 180 +------------------+ 182 Figure 1: xTRs at the customer edge 184 From the LISP site perspective the main advantage of this type of 185 deployment (compared to the one described in the next section) is 186 having direct control over its ingress traffic engineering. This 187 makes it is easy to set up and maintain active/active, active/backup, 188 or more complex TE policies, without involving third parties. 190 Being under the same administrative control, reachability information 191 of all ETRs is easier to synchronize, because the necessary control 192 traffic can be allowed between the locators of the ETRs. A correct 193 synchronous global view of the reachability status is thus available, 194 and the Loc-Status-Bits can be set correctly in the LISP data header 195 of outgoing packets. 197 By placing the tunnel router at the edge of the site, existing 198 internal network configuration does not need to be modified. 199 Firewall rules, router configurations and address assignments inside 200 the LISP site remain unchanged. This helps with incremental 201 deployment and allows a quick upgrade path to LISP. For larger sites 202 with many external connections, distributed in geographically diverse 203 PoPs, and complex internal topology, it may however make more sense 204 to both encapsulate and decapsulate as soon as possible, to benefit 205 from the information in the IGP to choose the best path (see 206 Section 2.3 for a discussion of this scenario). 208 Another thing to consider when placing tunnel routers are MTU issues. 209 Since encapsulating packets increases overhead, the MTU of the end- 210 to-end path may decrease, when encapsulated packets need to travel 211 over segments having close to minimum MTU. Some transit networks are 212 known to provide larger MTU than the typical value of 1500 bytes of 213 popular access technologies used at end hosts (e.g., IEEE 802.3 and 214 802.11). However, placing the LISP router connecting to such a 215 network at the customer edge could possibly bring up MTU issues, 216 depending on the link type to the provider as opposed to the 217 following scenario. 219 2.2. Provider Edge 221 The other location at the core-edge boundary for deploying LISP 222 routers is at the Internet service provider edge. The main incentive 223 for this case is that the customer does not have to upgrade the CE 224 router(s), or change the configuration of any equipment. 225 Encapsulation/decapsulation happens in the provider's network, which 226 may be able to serve several customers with a single device. For 227 large ISPs with many residential/business customers asking for LISP 228 this can lead to important savings, since there is no need to upgrade 229 the software (or hardware, if it's the case) at each client's 230 location. Instead, they can upgrade the software (or hardware) on a 231 few PE routers serving the customers. This scenario is depicted in 232 Figure 2. 234 +----------+ +------------------+ 235 | ISP1 | | ISP2 | 236 | | | | 237 | +----+ | | +----+ +----+ | 238 +--|xTR1|--+ +--|xTR2|--|xTR3|--+ 239 +----+ +----+ +----+ 240 | | | 241 | | | 242 +--<[LISP site]>---+-------+ 244 Figure 2: xTR at the PE 246 While this approach can make transition easy for customers and may be 247 cheaper for providers, the LISP site looses one of the main benefits 248 of LISP: ingress traffic engineering. Since the provider controls 249 the ETRs, additional complexity would be needed to allow customers to 250 modify their mapping entries. 252 The problem is aggravated when the LISP site is multihomed. Consider 253 the scenario in Figure 2: whenever a change to TE policies is 254 required, the customer contacts both ISP1 and ISP2 to make the 255 necessary changes on the routers (if they provide this possibility). 256 It is however unlikely, that both ISPs will apply changes 257 simultaneously, which may lead to inconsistent state for the mappings 258 of the LISP site. Since the different upstream ISPs are usually 259 competing business entities, the ETRs may even be configured to 260 compete, either to attract all the traffic or to get no traffic. The 261 former will happen if the customer pays per volume, the latter if the 262 connectivity has a fixed price. A solution could be to have the 263 mappings in the Map-Server(s), and have their operator give control 264 over the entries to customer, much like in today's DNS. 266 Additionally, since xTR1, xTR2, and xTR3 are in different 267 administrative domains, locator reachability information is unlikely 268 to be exchanged among them, making it difficult to set Loc-Status- 269 Bits correctly on encapsulated packets. 271 Compared to the customer edge scenario, deploying LISP at the 272 provider edge might have the advantage of diminishing potential MTU 273 issues, because the tunnel router is closer to the core, where links 274 typically have higher MTUs than edge network links. 276 2.3. Split ITR/ETR 278 In a simple LISP deployment, xTRs are located at the border of the 279 LISP site (see Section 2.1). In this scenario packets are routed 280 inside the domain according to the EID. However, more complex 281 networks may want to route packets according to the destination RLOC. 283 This would enable them to choose the best egress point. 285 The LISP specification separates the ITR and ETR functionality and 286 considers that both entities can be deployed in separated network 287 equipment. ITRs can be deployed closer to the host (i.e., access 288 routers). This way packets are encapsulated as soon as possible, and 289 packets exit the network through the best egress point in terms of 290 BGP policy. In turn, ETRs can be deployed at the border routers of 291 the network, and packets are decapsulated as soon as possible. 292 Again, once decapsulated packets are routed according to the EID, and 293 can follow the best path according to internal routing policy. 295 In the following figure we can see an example. The Source (S) 296 transmits packets using its EID and in this particular case packets 297 are encapsulated at ITR_1. The encapsulated packets are routed 298 inside the domain according to the destination RLOC, and can egress 299 the network through the best point (i.e., closer to the RLOC's AS). 300 On the other hand, inbound packets are received by ETR_1 which 301 decapsulates them. Then packets are routed towards S according to 302 the EID, again following the best path. 304 +---------------------------------------+ 305 | | 306 | +-------+ +-------+ +-------+ 307 | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | 308 | +-------+ | +-------+ +-------+ 309 | +-+ | | | 310 | |S| | IGP | | 311 | +-+ | | | 312 | +-------+ | +-------+ +-------+ 313 | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | 314 | +-------+ +-------+ +-------+ 315 | | 316 +---------------------------------------+ 318 Figure 3: Split ITR/ETR Scenario 320 This scenario has a set of implications: 322 o The site must carry at least partial BGP routes in order to choose 323 the best egress point, increasing the complexity of the network. 324 However, this is usually already the case for LISP sites that 325 would benefit from this scenario. 327 o If the site is multihomed to different ISPs and any of the 328 upstream ISPs is doing uRPF filtering, this scenario may become 329 impractical. ITRs need to determine the exit ETR, for setting the 330 correct source RLOC in the encapsulation header. This adds 331 complexity and reliability concerns. 333 o In LISP, ITRs set the reachability bits when encapsulating data 334 packets. Hence, ITRs need a mechanism to be aware of the liveness 335 of ETRs. 337 o ITRs encapsulate packets and in order to achieve efficient 338 communications, the MTU of the site must be large enough to 339 accommodate this extra header. 341 o In this scenario, each ITR is serving fewer hosts than in the case 342 when it is deployed at the border of the network. It has been 343 shown that cache hit ratio grows logarithmically with the amount 344 of users [cache]. Taking this into account, when ITRs are 345 deployed closer to the host the effectiveness of the mapping cache 346 may be lower (i.e., the miss ratio is higher). Another 347 consequence of this is that the site will transmit a higher amount 348 of Map-Requests, increasing the load on the distributed mapping 349 database. 351 2.4. Inter-Service Provider Traffic Engineering 353 With LISP, two LISP sites can route packets among them and control 354 their ingress TE policies. Typically, LISP is seen as applicable to 355 stub networks, however the LISP protocol can also be applied to 356 transit networks recursively. 358 Consider the scenario depicted in Figure 4. Packets originating from 359 the LISP site Stub1, client of ISP_A, with destination Stub4, client 360 of ISP_B, are LISP encapsulated at their entry point into the ISP_A's 361 network. The external IP header now has as the source RLOC an IP 362 from ISP_A's address space and destination RLOC from ISP_B's address 363 space. One or more ASes separate ISP_A from ISP_B. With a single 364 level of LISP encapsulation, Stub4 has control over its ingress 365 traffic. However, ISP_B only has the current tools (such as BGP 366 prefix deaggregation) to control on which of his own upstream or 367 peering links should packets enter. This is either not feasible (if 368 fine-grained per-customer control is required, the very specific 369 prefixes may not be propagated) or increases DFZ table size. 371 _.--. 372 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 373 \ | R_A1|----,' `. ---|R_B1 | / 374 --| R_A2|---( Transit ) | |-- 375 Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 376 +-------+ `--. _.-' +-------+ 377 ... ISP_A `--'' ISP_B ... 379 Figure 4: Inter-Service provider TE scenario 381 A solution for this is to apply LISP recursively. ISP_A and ISP_B 382 may reach a bilateral agreement to deploy their own private mapping 383 system. ISP_A then encapsulates packets destined for the prefixes of 384 ISP_B, which are listed in the shared mapping system. Note that in 385 this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3 386 as source and R_B1 or R_B2 as destination in the example above). 387 ISP_B's ETR removes the outer, second layer of LISP encapsulation 388 from the incoming packet, and routes it towards the original RLOC, 389 the ETR of Stub4, which does the final decapsulation. 391 If ISP_A and ISP_B agree to share a private distributed mapping 392 database, both can control their ingress TE without the need of 393 disaggregating prefixes. In this scenario the private database 394 contains RLOC-to-RLOC bindings. The convergence time on the TE 395 policies updates is expected to be fast, since ISPs only have to 396 update/query a mapping to/from the database. 398 This deployment scenario includes two important recommendations. 399 First, it is intended to be deployed only between two ISPs (ISP_A and 400 ISP_B in Figure 4). If more than two ISPs use this approach, then 401 the xTRs deployed at the participating ISPs must either query 402 multiple mapping systems, or the ISPs must agree on a common shared 403 mapping system. Second, the scenario is only recommended for ISPs 404 providing connectivity to LISP sites, such that source RLOCs of 405 packets to be reencapsulated belong to said ISP. Otherwise the 406 participating ISPs must register prefixes they do not own in the 407 above mentioned private mapping system. Failure to follow these 408 recommendations may lead to operational and security issues when 409 deploying this scenario. 411 Besides these recommendations, the main disadvantages of this 412 deployment case are: 414 o Extra LISP header is needed. This increases the packet size and, 415 for efficient communications, it requires that the MTU between 416 both ISPs can accommodate double-encapsulated packets. 418 o The ISP ITR must encapsulate packets and therefore must know the 419 RLOC-to-RLOC binding. These bindings are stored in a mapping 420 database and may be cached in the ITR's mapping cache. Cache 421 misses lead to an extra lookup latency, unless NERD 422 [I-D.lear-lisp-nerd] is used for the lookups. 424 o The operational overhead of maintaining the shared mapping 425 database. 427 o If an IPv6 address block is reserved for EID use, as specified in 428 [I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first 429 level) can avoid LISP processing altogether for non-LISP 430 destinations. The ISP tunnel routers however will not be able to 431 take advantage of this optimization, all RLOC-to-RLOC mappings 432 need a lookup in the private database (or map-cache, once results 433 are cached). 435 2.5. Tunnel Routers Behind NAT 437 NAT in this section refers to IPv4 network address and port 438 translation. 440 2.5.1. ITR 442 Packets encapsulated by an ITR are just UDP packets from a NAT 443 device's point of view, and they are handled like any UDP packet, 444 there are no additional requirements for LISP data packets. 446 Map-Requests sent by an ITR, which create the state in the NAT table 447 have a different 5-tuple in the IP header than the Map-Reply 448 generated by the authoritative ETR. Since the source address of this 449 packet is different from the destination address of the request 450 packet, no state will be matched in the NAT table and the packet will 451 be dropped. To avoid this, the NAT device has to do the following: 453 o Send all UDP packets with source port 4342, regardless of the 454 destination port, to the RLOC of the ITR. The most simple way to 455 achieve this is configuring 1:1 NAT mode from the external RLOC of 456 the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer 457 broadband routers). 459 o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in 460 the payload. 462 This setup supports a single ITR behind the NAT device. 464 2.5.2. ETR 466 An ETR placed behind NAT is reachable from the outside by the 467 Internet-facing locator of the NAT device. It needs to know this 468 locator (and configure a loopback interface with it), so that it can 469 use it in Map-Reply and Map-Register messages. Thus support for 470 dynamic locators for the mapping database is needed in LISP 471 equipment. 473 Again, only one ETR behind the NAT device is supported. 475 An implication of the issues described above is that LISP sites with 476 xTRs can not be behind carrier based NATs, since two different sites 477 would collide on the port forwarding. 479 2.6. Summary and Feature Matrix 481 Feature CE PE Split Rec. 482 -------------------------------------------------------- 483 Control of ingress TE x - x x 484 No modifications to existing 485 int. network infrastructure x x - - 486 Loc-Status-Bits sync x - x x 487 MTU/PMTUD issues minimized - x - x 489 3. Map-Resolvers and Map-Servers 491 3.1. Map-Servers 493 The Map-Server learns EID-to-RLOC mapping entries from an 494 authoritative source and publishes them in the distributed mapping 495 database. These entries are learned through authenticated Map- 496 Register messages sent by authoritative ETRs. Also, upon reception 497 of a Map-Request, the Map-Server verifies that the destination EID 498 matches an EID-prefix for which it is authoritative for, and then re- 499 encapsulates and forwards it to a matching ETR. Map-Server 500 functionality is described in detail in [I-D.ietf-lisp-ms]. 502 The Map-Server is provided by a Mapping Service Provider (MSP). A 503 MSP can be any of the following: 505 o EID registrar. Since the IPv4 address space is nearing 506 exhaustion, IPv4 EIDs will come from already allocated Provider 507 Independent (PI) space. The registrars in this case remain the 508 current five Regional Internet Registries (RIRs). In the case of 509 IPv6, the possibility of reserving a /16 block as EID space is 510 currently under consideration [I-D.ietf-lisp-eid-block]. If 511 granted by IANA, the community will have to determine the body 512 responsible for allocations from this block, and the associated 513 policies. For already allocated IPv6 prefixes the principles from 514 IPv4 should be applied. 516 o Third parties. Participating in the LISP mapping system is 517 similar to participating in global routing or DNS: as long as 518 there is at least another already participating entity willing to 519 forward the newcomer's traffic, there is no barrier to entry. 520 Still, just like routing and DNS, LISP mappings have the issue of 521 trust, with efforts underway to make the published information 522 verifiable. When these mechanisms will be deployed in the LISP 523 mapping system, the burden of providing and verifying trust should 524 be kept away from MSPs, which will simply host the secured 525 mappings. This will keep the low barrier of entry to become an 526 MSP for third parties. 528 In all cases, the MSP configures its Map-Server(s) to publish the 529 prefixes of its clients in the distributed mapping database and start 530 encapsulating and forwarding Map-Requests to the ETRs of the AS. 531 These ETRs register their prefix(es) with the Map-Server(s) through 532 periodic authenticated Map-Register messages. In this context, for 533 some LISP end sites, there is a need for mechanisms to: 535 o Automatically distribute EID prefix(es) shared keys between the 536 ETRs and the EID-registrar Map-Server. 538 o Dynamically obtain the address of the Map-Server in the ETR of the 539 AS. 541 The Map-Server plays a key role in the reachability of the EID- 542 prefixes it is serving. On the one hand it is publishing these 543 prefixes into the distributed mapping database and on the other hand 544 it is encapsulating and forwarding Map-Requests to the authoritative 545 ETRs of these prefixes. ITRs encapsulating towards EIDs under the 546 responsibility of a failed Map-Server will be unable to look up any 547 of their covering prefixes. The only exception are the ITRs that 548 already contain the mappings in their local cache. In this case ITRs 549 can reach ETRs until the entry expires (typically 24 hours). For 550 this reason, redundant Map-Server deployments are desirable. A set 551 of Map-Servers providing high-availability service to the same set of 552 prefixes is called a redundancy group. ETRs are configured to send 553 Map-Register messages to all Map-Servers in the redundancy group. To 554 achieve fail-over (or load-balancing, if desired), current known BGP 555 practices can be used on the LISP+ALT BGP overlay network. 557 Additionally, if a Map-Server has no reachability for any ETR serving 558 a given EID block, it should not originate that block into the 559 mapping system. 561 3.2. Map-Resolvers 563 A Map-Resolver a is a network infrastructure component which accepts 564 LISP encapsulated Map-Requests, typically from an ITR, and finds the 565 appropriate EID-to-RLOC mapping by either consulting its local cache 566 or by consulting the distributed mapping database. Map-Resolver 567 functionality is described in detail in [I-D.ietf-lisp-ms]. 569 Anyone with access to the distributed mapping database can set up a 570 Map-Resolver and provide EID-to-RLOC mapping lookup service. In the 571 case of the LISP+ALT mapping system, the Map-Resolver needs to become 572 part of the ALT overlay so that it can forward packets to the 573 appropriate Map-Servers. For more detail on how the ALT overlay 574 works, see [I-D.ietf-lisp-alt] 576 For performance reasons, it is recommended that LISP sites use Map- 577 Resolvers that are topologically close to their ITRs. ISPs 578 supporting LISP will provide this service to their customers, 579 possibly restricting access to their user base. LISP sites not in 580 this position can use open access Map-Resolvers, if available. 581 However, regardless of the availability of open access resolvers, the 582 MSP providing the Map-Server(s) for a LISP site should also make 583 available Map-Resolver(s) for the use of that site. 585 In medium to large-size ASes, ITRs must be configured with the RLOC 586 of a Map-Resolver, operation which can be done manually. However, in 587 Small Office Home Office (SOHO) scenarios a mechanism for 588 autoconfiguration should be provided. 590 One solution to avoid manual configuration in LISP sites of any size 591 is the use of anycast RLOCs for Map-Resolvers similar to the DNS root 592 server infrastructure. Since LISP uses UDP encapsulation, the use of 593 anycast would not affect reliability. LISP routers are then shipped 594 with a preconfigured list of well know Map-Resolver RLOCs, which can 595 be edited by the network administrator, if needed. 597 The use of anycast also helps improving mapping lookup performance. 598 Large MSPs can increase the number and geographical diversity of 599 their Map-Resolver infrastructure, using a single anycasted RLOC. 600 Once LISP deployment is advanced enough, very large content providers 601 may also be interested running this kind of setup, to ensure minimal 602 connection setup latency for those connecting to their network from 603 LISP sites. 605 While Map-Servers and Map-Resolvers implement different 606 functionalities within the LISP mapping system, they can coexist on 607 the same device. For example, MSPs offering both services, can 608 deploy a single Map-Resolver/Map-Server in each PoP where they have a 609 presence. 611 4. Proxy Tunnel Routers 613 4.1. P-ITR 615 Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP 616 transition mechanism, allowing non-LISP sites to reach LISP sites. 618 They announce via BGP certain EID prefixes (aggregated, whenever 619 possible) to attract traffic from non-LISP sites towards EIDs in the 620 covered range. They do the mapping system lookup, and encapsulate 621 received packets towards the appropriate ETR. Note that for the 622 reverse path LISP sites can reach non-LISP sites simply by not 623 encapsulating traffic. See [I-D.ietf-lisp-interworking] for a 624 detailed description of P-ITR functionality. 626 The success of new protocols depends greatly on their ability to 627 maintain backwards compatibility and inter-operate with the 628 protocol(s) they intend to enhance or replace, and on the incentives 629 to deploy the necessary new software or equipment. A LISP site needs 630 an interworking mechanism to be reachable from non-LISP sites. A 631 P-ITR can fulfill this role, enabling early adopters to see the 632 benefits of LISP, similar to tunnel brokers helping the transition 633 from IPv4 to IPv6. A site benefits from new LISP functionality 634 (proportionally with existing global LISP deployment) when going 635 LISP, so it has the incentives to deploy the necessary tunnel 636 routers. In order to be reachable from non-LISP sites it has two 637 options: keep announcing its prefix(es) with BGP, or have a P-ITR 638 announce prefix(es) covering them. 640 If the goal of reducing the DFZ routing table size is to be reached, 641 the second option is preferred. Moreover, the second option allows 642 LISP-based ingress traffic engineering from all sites. However, the 643 placement of P-ITRs significantly influences performance and 644 deployment incentives. Section Section 5 is dedicated to the 645 migration to a LISP-enabled Internet, and includes deployment 646 scenarios for P-ITRs. 648 4.2. P-ETR 650 In contrast to P-ITRs, P-ETRs are not required for the correct 651 functioning of all LISP sites. There are two cases, where they can 652 be of great help: 654 o LISP sites with unicast reverse path forwarding (uRPF) 655 restrictions, and 657 o LISP sites without native IPv6 communicating with LISP nodes with 658 IPv6-only locators. 660 In the first case, uRPF filtering is applied at their upstream PE 661 router. When forwarding traffic to non-LISP sites, an ITR does not 662 encapsulate packets, leaving the original IP headers intact. As a 663 result, packets will have EIDs in their source address. Since we are 664 discussing the transition period, we can assume that a prefix 665 covering the EIDs belonging to the LISP site is advertised to the 666 global routing tables by a P-ITR, and the PE router has a route 667 towards it. However, the next hop will not be on the interface 668 towards the CE router, so non-encapsulated packets will fail uRPF 669 checks. 671 To avoid this filtering, the affected ITR encapsulates packets 672 towards the locator of the P-ETR for non-LISP destinations. Now the 673 source address of the packets, as seen by the PE router is the ITR's 674 locator, which will not fail the uRPF check. The P-ETR then 675 decapsulates and forwards the packets. 677 The second use case is IPv4-to-IPv6 transition. Service providers 678 using older access network hardware, which only supports IPv4 can 679 still offer IPv6 to their clients, by providing a CPE device running 680 LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP 681 sites, with IPv6-only locators. Packets originating from the client 682 LISP site for these destinations would be encapsulated towards the 683 P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, 684 decapsulating and forwarding packets. For non-LISP destination, the 685 packet travels natively from the P-ETR. For LISP destinations with 686 IPv6-only locators, the packet will go through a P-ITR, in order to 687 reach its destination. 689 For more details on P-ETRs see the [I-D.ietf-lisp-interworking] 690 draft. 692 P-ETRs can be deployed by ISPs wishing to offer value-added services 693 to their customers. As is the case with P-ITRs, P-ETRs too may 694 introduce path stretch. Because of this the ISP needs to consider 695 the tradeoff of using several devices, close to the customers, to 696 minimize it, or few devices, farther away from the customers, 697 minimizing cost instead. 699 Since the deployment incentives for P-ITRs and P-ETRs are different, 700 it is likely they will be deployed in separate devices, except for 701 the CDN case, which may deploy both in a single device. 703 In all cases, the existence of a P-ETR involves another step in the 704 configuration of a LISP router. CPE routers, which are typically 705 configured by DHCP, stand to benefit most from P-ETRs. To enable 706 autoconfiguration of the P-ETR locator, a DHCP option would be 707 required. 709 As a security measure, access to P-ETRs should be limited to 710 legitimate users by enforcing ACLs. 712 5. Migration to LISP 714 This section discusses a deployment architecture to support the 715 migration to a LISP-enabled Internet. The loosely defined terms of 716 "early transition phase", "late transition phase", and "LISP Internet 717 phase" refer to time periods when LISP sites are a minority, a 718 majority, or represent all edge networks respectively. 720 5.1. LISP+BGP 722 For sites wishing to go LISP with their PI prefix the least 723 disruptive way is to upgrade their border routers to support LISP, 724 register the prefix into the LISP mapping system, but keep announcing 725 it with BGP as well. This way LISP sites will reach them over LISP, 726 while legacy sites will be unaffected by the change. The main 727 disadvantage of this approach is that no decrease in the DFZ routing 728 table size is achieved. Still, just increasing the number of LISP 729 sites is an important gain, as an increasing LISP/non-LISP site ratio 730 will slowly decrease the need for BGP-based traffic engineering that 731 leads to prefix deaggregation. That, in turn, may lead to a decrease 732 in the DFZ size in the late transition phase. 734 This scenario is not limited to sites that already have their 735 prefixes announced with BGP. Newly allocated EID blocks could follow 736 this strategy as well during the early LISP deployment phase, 737 depending on the cost/benefit analysis of the individual networks. 738 Since this leads to an increase in the DFZ size, the following 739 architecture should be preferred for new allocations. 741 5.2. Mapping Service Provider (MSP) P-ITR Service 743 In addition to publishing their clients' registered prefixes in the 744 mapping system, MSPs with enough transit capacity can offer them 745 P-ITR service as a separate service. This service is especially 746 useful for new PI allocations, to sites without existing BGP 747 infrastructure, that wish to avoid BGP altogether. The MSP announces 748 the prefix into the DFZ, and the client benefits from ingress traffic 749 engineering without prefix deaggregation. The downside of this 750 scenario is path stretch, which may be greater than 1. 752 Routing all non-LISP ingress traffic through a third party which is 753 not one of its ISPs is only feasible for sites with modest amounts of 754 traffic (like those using the IPv6 tunnel broker services today), 755 especially in the first stage of the transition to LISP, with a 756 significant number of legacy sites. When the LISP/non-LISP site 757 ratio becomes high enough, this approach can prove increasingly 758 attractive. 760 Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix 761 deaggregation for traffic engineering purposes, resulting in slower 762 routing table increase in the case of new allocations and potential 763 decrease for existing ones. Moreover, MSPs serving different clients 764 with adjacent aggregable prefixes may lead to additional decrease, 765 but quantifying this decrease is subject to future research study. 767 5.3. Proxy-ITR Route Distribution (PITR-RD) 769 Instead of a LISP site, or the MSP, announcing their EIDs with BGP to 770 the DFZ, this function can be outsourced to a third party, a P-ITR 771 Service Provider (PSP). This will result in a decrease of the 772 operational complexity both at the site and at the MSP. 774 The PSP manages a set of distributed P-ITR(s) that will advertise the 775 corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) 776 will then encapsulate the traffic they receive for those EIDs towards 777 the RLOCs of the LISP site, ensuring their reachability from non-LISP 778 sites. 780 While it is possible for a PSP to manually configure each client's 781 EID routes to be announced, this approach offers little flexibility 782 and is not scalable. This section presents a scalable architecture 783 that offers automatic distribution of EID routes to LISP sites and 784 service providers. 786 The architecture requires no modification to existing LISP network 787 elements, but it introduces a new (conceptual) network element, the 788 EID Route Server, defined as a router that either propagates routes 789 learned from other EID Route Servers, or it originates EID Routes. 790 The EID-Routes that it originates are those that it is authoritative 791 for. It propagates these routes to Proxy-ITRs within the AS of the 792 EID Route Server. It is worth to note that a BGP capable router can 793 be also considered as an EID Route Server. 795 Further, an EID-Route is defined as a prefix originated via the Route 796 Server of the mapping service provider, which should be aggregated if 797 the MSP has multiple customers inside a single netblock. This prefix 798 is propagated to other P-ITRs both within the MSP and to other P-ITR 799 operators it peers with. EID Route Servers are operated either by 800 the LISP site, MSPs or PSPs, and they may be collocated with a Map- 801 Server or P-ITR, but are a functionally discrete entity. They 802 distribute EID-Routes, using BGP, to other domains, according to 803 policies set by participants. 805 MSP (AS64500) 806 RS ---> P-ITR 807 | / 808 | _.--./ 809 ,-'' /`--. 810 LISP site ---,' | v `. 811 ( | DFZ )----- Mapping system 812 non-LISP site ----. | ^ ,' 813 `--. / _.-' 814 | `--'' 815 v / 816 P-ITR 817 PSP (AS64501) 819 Figure 5: The P-ITR Route Distribution architecture 821 The architecture described above decouples EID origination from route 822 propagation, with the following benefits: 824 o Can accurately represent business relationships between P-ITR 825 operators 827 o More mapping system agnostic (no reliance on ALT) 829 o Minor changes to P-ITR implementation, no changes to other 830 components 832 In the example in the figure we have a MSP providing services to the 833 LISP site. The LISP site does not run BGP, and gets an EID 834 allocation directly from a RIR, or from the MSP, who may be a LIR. 835 Existing PI allocations can be migrated as well. The MSP ensures the 836 presence of the prefix in the mapping system, and runs an EID Route 837 Server to distribute it to P-ITR service providers. Since the LISP 838 site does not run BGP, the prefix will be originated with the AS 839 number of the MSP. 841 In the simple case depicted in Figure 5 the EID-Route of LISP Site 842 will be originated by the Route Server, and announced to the DFZ by 843 the PSP's P-ITRs with AS path 64501 64500. From that point on, the 844 usual BGP dynamics apply. This way, routes announced by P-ITR are 845 still originated by the authoritative Route Server. Note that the 846 peering relationships between MSP/PSPs and those in the underlying 847 forwarding plane may not be congruent, making the AS path to a P-ITR 848 shorter than it is in reality. 850 The non-LISP site will select the best path towards the EID-prefix, 851 according to its local BGP policies. Since AS-path length is usually 852 an important metric for selecting paths, a careful placement of P-ITR 853 could significantly reduce path-stretch between LISP and non-LISP 854 sites. 856 The architecture allows for flexible policies between MSP/PSPs. 857 Consider the EID Route Server networks as control plane overlays, 858 facilitating the implementation of policies necessary to reflect the 859 business relationships between participants. The results are then 860 injected to the common underlying forwarding plane. For example, 861 some MSP/PSPs may agree to exchange EID-Prefixes and only announce 862 them to each of their forwarding plane customers. Global 863 reachability of an EID-prefix depends on the MSP the LISP site buys 864 service from, and is also subject to agreement between the mentioned 865 parties. 867 In terms of impact on the DFZ, this architecture results in a slower 868 routing table increase for new allocations, since traffic engineering 869 will be done at the LISP level. For existing allocations migrating 870 to LISP, the DFZ may decrease since MSPs may be able to aggregate the 871 prefixes announced. 873 Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix 874 deaggregation for traffic engineering purposes, resulting in slower 875 routing table increase in the case of new allocations and potential 876 decrease for existing ones. Moreover, MSPs serving different clients 877 with adjacent aggregable prefixes may lead to additional decrease, 878 but quantifying this decrease is subject to future research study. 880 The flexibility and scalability of this architecture does not come 881 without a cost however: A PSP operator has to establish either 882 transit or peering relationships to improve their connectivity. 884 5.4. Migration Summary 886 The following table presents the expected effects of the different 887 transition scenarios during a certain phase on the DFZ routing table 888 size: 890 Phase | LISP+BGP | MSP P-ITR | PITR-RD 891 -----------------+--------------+-----------------+---------------- 892 Early transition | no change | slower increase | slower increase 893 Late transition | may decrease | slower increase | slower increase 894 LISP Internet | considerable decrease 896 It is expected that PITR-RD will co-exist with LISP+BGP during the 897 migration, with the latter being more popular in the early transition 898 phase. As the transition progresses and the MSP P-ITR and PITR-RD 899 ecosystem gets more ubiquitous, LISP+BGP should become less 900 attractive, slowing down the increase of the number of routes in the 901 DFZ. 903 6. Step-by-Step BGP to LISP Migration Procedure 905 6.1. Customer Pre-Install and Pre-Turn-up Checklist 907 1. Determine how many current physical service provider connections 908 the customer has and their existing bandwidth and traffic 909 engineering requirements. 911 This information will determine the number of routing locators, 912 and the priorities and weights that should be configured on the 913 xTRs. 915 2. Make sure customer router has LISP capabilities. 917 * Obtain output of 'show version' from the CE router. 919 This information can be used to determine if the platform is 920 appropriate to support LISP, in order to determine if a 921 software and/or hardware upgrade is required. 923 * Have customer upgrade (if necessary, software and/or hardware) 924 to be LISP capable. 926 3. Obtain current running configuration of CE router. A suggested 927 LISP router configuration example can be customized to the 928 customer's existing environment. 930 4. Verify MTU Handling 932 * Request increase in MTU to (1556) on service provider 933 connections. Prior to MTU change verify that 1500 byte packet 934 from P-xTR to RLOC with do not fragment (DF-bit) bit set. 936 * Ensure they are not filtering ICMP unreachable or time- 937 exceeded on their firewall or router. 939 LISP, like any tunneling protocol, will increase the size of 940 packets when the LISP header is appended. If increasing the MTU 941 of the access links is not possible, care must be taken that ICMP 942 is not being filtered in order to allow for Path MTU Discovery to 943 take place. 945 5. Validate member prefix allocation. 947 This step is to check if the prefix used by the customer is a 948 direct (Provider Independent), or if it is a prefix assigned by a 949 physical service provider (Provider Allocated). If the prefixes 950 are assigned by other service provivers then a Letter of 951 Agreement is required to announce prefixes through the Proxy 952 Service Provider. 954 6. Verify the member RLOCs and their reachability. 956 This step ensures that the RLOCs configured on the CE router are 957 in fact reachable and working. 959 7. Prepare for cut-over. 961 * If possible, have a host outside of all security and filtering 962 policies connected to the console port of the edge router or 963 switch. 965 * Make sure customer has access to the router in order to 966 configure it. 968 6.2. Customer Activating LISP Service 970 1. Customer configures LISP on CE router(s) from service provider 971 recommended configuration. 973 The LISP configuration consists of the EID prefix, the locators, 974 and the weights and priorities of the mapping between the two 975 values. In addition, the xTR must be configured with Map- 976 Resolver(s), Map-Server(s) and the shared key for registering to 977 Map-Server(s). If required, Proxy-ETR(s) may be configured as 978 well. 980 In addition to the LISP configuration, the following: 982 * Ensure default route(s) to next-hop external neighbors are 983 included and RLOCs are present in configuration. 985 * If two or more routers are used, ensure all RLOCs are included 986 in the LISP configuration on all routers. 988 * It will be necessary to redistribute default route via IGP 989 between the external routers. 991 2. When transition is ready perform a soft shutdown on existing eBGP 992 peer session(s) 994 * From CE router, use LIG to ensure registration is successful. 996 * To verify LISP connectivity, ping LISP connected sites. See 997 http://www.lisp4.net/ and/or http://www.lisp6.net/ for 998 potential candidates. 1000 * To verify connectivity to non-LISP sites, try accessing major 1001 Internet sites via a web browser. 1003 6.3. Cut-Over Provider Preparation and Changes 1005 1. Verify site configuration and then active registration on Map- 1006 Server(s) 1008 * Authentication key 1010 * EID prefix 1012 2. Add EID space to map-cache on proxies 1014 3. Add networks to BGP advertisement on proxies 1016 * Modify route-maps/policies on P-xTRs 1018 * Modify route policies on core routers (if non-connected 1019 member) 1021 * Modify ingress policers on core routers 1023 * Ensure route announcement in looking glass servers, RouteViews 1025 4. Perform traffic verification test 1027 * Ensure MTU handling is as expected (PMTUD working) 1029 * Ensure proxy-ITR map-cache population 1031 * Ensure access from traceroute/ping servers around Internet 1033 * Use a looking glass, to check for external visibility of 1034 registration via several Map-Resolvers (e.g., 1035 http://lispmon.net/). 1037 7. Security Considerations 1039 Security implications of LISP deployments are to be discussed in 1040 separate documents. [I-D.saucez-lisp-security] gives an overview of 1041 LISP threat models, while securing mapping lookups is discussed in 1042 [I-D.ietf-lisp-sec]. 1044 8. IANA Considerations 1046 This memo includes no request to IANA. 1048 9. Acknowledgements 1050 Many thanks to Margaret Wasserman for her contribution to the IETF76 1051 presentation that kickstarted this work. The authors would also like 1052 to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, 1053 Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, and 1054 everyone else who provided input. 1056 10. References 1058 10.1. Normative References 1060 [I-D.ietf-lisp] 1061 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1062 "Locator/ID Separation Protocol (LISP)", 1063 draft-ietf-lisp-15 (work in progress), July 2011. 1065 [I-D.ietf-lisp-alt] 1066 Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP 1067 Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09 1068 (work in progress), September 2011. 1070 [I-D.ietf-lisp-interworking] 1071 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 1072 "Interworking LISP with IPv4 and IPv6", 1073 draft-ietf-lisp-interworking-02 (work in progress), 1074 June 2011. 1076 [I-D.ietf-lisp-ms] 1077 Fuller, V. and D. Farinacci, "LISP Map Server Interface", 1078 draft-ietf-lisp-ms-12 (work in progress), October 2011. 1080 [I-D.ietf-lisp-sec] 1081 Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., 1082 and O. Bonaventure, "LISP-Security (LISP-SEC)", 1083 draft-ietf-lisp-sec-00 (work in progress), July 2011. 1085 [I-D.saucez-lisp-security] 1086 Saucez, D., Iannone, L., and O. Bonaventure, "LISP 1087 Security Threats", draft-saucez-lisp-security-03 (work in 1088 progress), March 2011. 1090 10.2. Informative References 1092 [I-D.ietf-lisp-eid-block] 1093 Lewis, D., Meyer, D., Iannone, L., and V. Fuller, "LISP 1094 EID Block", draft-ietf-lisp-eid-block-01 (work in 1095 progress), October 2011. 1097 [I-D.lear-lisp-nerd] 1098 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 1099 draft-lear-lisp-nerd-08 (work in progress), March 2010. 1101 [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS 1102 performance and the effectiveness of caching", 2002. 1104 Authors' Addresses 1106 Lorand Jakab 1107 Technical University of Catalonia 1108 C/Jordi Girona, s/n 1109 BARCELONA 08034 1110 Spain 1112 Email: ljakab@ac.upc.edu 1114 Albert Cabellos-Aparicio 1115 Technical University of Catalonia 1116 C/Jordi Girona, s/n 1117 BARCELONA 08034 1118 Spain 1120 Email: acabello@ac.upc.edu 1122 Florin Coras 1123 Technical University of Catalonia 1124 C/Jordi Girona, s/n 1125 BARCELONA 08034 1126 Spain 1128 Email: fcoras@ac.upc.edu 1129 Jordi Domingo-Pascual 1130 Technical University of Catalonia 1131 C/Jordi Girona, s/n 1132 BARCELONA 08034 1133 Spain 1135 Email: jordi.domingo@ac.upc.edu 1137 Darrel Lewis 1138 Cisco Systems 1139 170 Tasman Drive 1140 San Jose, CA 95134 1141 USA 1143 Email: darlewis@cisco.com