--- 1/draft-ietf-lisp-deployment-01.txt 2011-11-01 01:14:32.166671829 +0100 +++ 2/draft-ietf-lisp-deployment-02.txt 2011-11-01 01:14:32.210671507 +0100 @@ -1,22 +1,22 @@ Network Working Group L. Jakab Internet-Draft A. Cabellos-Aparicio Intended status: Informational F. Coras -Expires: January 12, 2012 J. Domingo-Pascual +Expires: May 4, 2012 J. Domingo-Pascual Technical University of Catalonia D. Lewis Cisco Systems - July 11, 2011 + November 1, 2011 LISP Network Element Deployment Considerations - draft-ietf-lisp-deployment-01.txt + draft-ietf-lisp-deployment-02.txt Abstract This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -25,21 +25,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 12, 2012. + This Internet-Draft will expire on May 4, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -63,21 +63,21 @@ 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 3. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 11 3.1. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 11 3.2. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 12 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16 - 5.3. Proxy-ITR Route Distribution . . . . . . . . . . . . . . . 17 + 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 19 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction @@ -347,48 +347,48 @@ With LISP, two LISP sites can route packets among them and control their ingress TE policies. Typically, LISP is seen as applicable to stub networks, however the LISP protocol can also be applied to transit networks recursively. Consider the scenario depicted in Figure 4. Packets originating from the LISP site Stub1, client of ISP_A, with destination Stub4, client of ISP_B, are LISP encapsulated at their entry point into the ISP_A's network. The external IP header now has as the source RLOC an IP - from ISP_A's address space (R_A1, R_A2, or R_A3) and destination RLOC - from ISP_B's address space (R_B1 or R_B2). One or more ASes separate - ISP_A from ISP_B. With a single level of LISP encapsulation, Stub4 - has control over its ingress traffic. However, ISP_B only has the - current tools (such as BGP prefix deaggregation) to control on which - of his own upstream or peering links should packets enter. This is - either not feasible (if fine-grained per-customer control is - required, the very specific prefixes may not be propagated) or - increases DFZ table size. + from ISP_A's address space and destination RLOC from ISP_B's address + space. One or more ASes separate ISP_A from ISP_B. With a single + level of LISP encapsulation, Stub4 has control over its ingress + traffic. However, ISP_B only has the current tools (such as BGP + prefix deaggregation) to control on which of his own upstream or + peering links should packets enter. This is either not feasible (if + fine-grained per-customer control is required, the very specific + prefixes may not be propagated) or increases DFZ table size. _.--. Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 \ | R_A1|----,' `. ---|R_B1 | / --| R_A2|---( Transit ) | |-- Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 +-------+ `--. _.-' +-------+ ... ISP_A `--'' ISP_B ... Figure 4: Inter-Service provider TE scenario A solution for this is to apply LISP recursively. ISP_A and ISP_B may reach a bilateral agreement to deploy their own private mapping system. ISP_A then encapsulates packets destined for the prefixes of ISP_B, which are listed in the shared mapping system. Note that in - this case the packet is double-encapsulated. ISP_B's ETR removes the - outer, second layer of LISP encapsulation from the incoming packet, - and routes it towards the original RLOC, the ETR of Stub4, which does - the final decapsulation. + this case the packet is double-encapsulated (using R_A1, R_A2 or R_A3 + as source and R_B1 or R_B2 as destination in the example above). + ISP_B's ETR removes the outer, second layer of LISP encapsulation + from the incoming packet, and routes it towards the original RLOC, + the ETR of Stub4, which does the final decapsulation. If ISP_A and ISP_B agree to share a private distributed mapping database, both can control their ingress TE without the need of disaggregating prefixes. In this scenario the private database contains RLOC-to-RLOC bindings. The convergence time on the TE policies updates is expected to be fast, since ISPs only have to update/query a mapping to/from the database. This deployment scenario includes two important recommendations. First, it is intended to be deployed only between two ISPs (ISP_A and @@ -412,20 +412,28 @@ o The ISP ITR must encapsulate packets and therefore must know the RLOC-to-RLOC binding. These bindings are stored in a mapping database and may be cached in the ITR's mapping cache. Cache misses lead to an extra lookup latency, unless NERD [I-D.lear-lisp-nerd] is used for the lookups. o The operational overhead of maintaining the shared mapping database. + o If an IPv6 address block is reserved for EID use, as specified in + [I-D.ietf-lisp-eid-block], the EID-to-RLOC encapsulation (first + level) can avoid LISP processing altogether for non-LISP + destinations. The ISP tunnel routers however will not be able to + take advantage of this optimization, all RLOC-to-RLOC mappings + need a lookup in the private database (or map-cache, once results + are cached). + 2.5. Tunnel Routers Behind NAT NAT in this section refers to IPv4 network address and port translation. 2.5.1. ITR Packets encapsulated by an ITR are just UDP packets from a NAT device's point of view, and they are handled like any UDP packet, there are no additional requirements for LISP data packets. @@ -743,21 +752,21 @@ ratio becomes high enough, this approach can prove increasingly attractive. Compared to LISP+BGP, this approach avoids DFZ bloat caused by prefix deaggregation for traffic engineering purposes, resulting in slower routing table increase in the case of new allocations and potential decrease for existing ones. Moreover, MSPs serving different clients with adjacent aggregable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study. -5.3. Proxy-ITR Route Distribution +5.3. Proxy-ITR Route Distribution (PITR-RD) Instead of a LISP site, or the MSP, announcing their EIDs with BGP to the DFZ, this function can be outsourced to a third party, a P-ITR Service Provider (PSP). This will result in a decrease of the operational complexity both at the site and at the MSP. The PSP manages a set of distributed P-ITR(s) that will advertise the corresponding EID prefixes through BGP to the DFZ. These P-ITR(s) will then encapsulate the traffic they receive for those EIDs towards the RLOCs of the LISP site, ensuring their reachability from non-LISP @@ -895,63 +904,63 @@ 7. IANA Considerations This memo includes no request to IANA. 8. Acknowledgements Many thanks to Margaret Wasserman for her contribution to the IETF76 presentation that kickstarted this work. The authors would also like to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller, - Dino Farinacci, Terry Manderson, Noel Chiappa, and everyone else who - provided input. + Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, and + everyone else who provided input. 9. References 9.1. Normative References [I-D.ietf-lisp] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-15 (work in progress), July 2011. [I-D.ietf-lisp-alt] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP - Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-07 - (work in progress), June 2011. + Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-09 + (work in progress), September 2011. [I-D.ietf-lisp-interworking] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking LISP with IPv4 and IPv6", draft-ietf-lisp-interworking-02 (work in progress), June 2011. [I-D.ietf-lisp-ms] - Fuller, V. and D. Farinacci, "LISP Map Server", - draft-ietf-lisp-ms-10 (work in progress), July 2011. + Fuller, V. and D. Farinacci, "LISP Map Server Interface", + draft-ietf-lisp-ms-12 (work in progress), October 2011. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-00 (work in progress), July 2011. [I-D.saucez-lisp-security] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Security Threats", draft-saucez-lisp-security-03 (work in progress), March 2011. 9.2. Informative References [I-D.ietf-lisp-eid-block] Iannone, L., Lewis, D., Meyer, D., and V. Fuller, "LISP - EID Block", draft-ietf-lisp-eid-block-00 (work in - progress), July 2011. + EID Block", draft-ietf-lisp-eid-block-01 (work in + progress), October 2011. [I-D.lear-lisp-nerd] Lear, E., "NERD: A Not-so-novel EID to RLOC Database", draft-lear-lisp-nerd-08 (work in progress), March 2010. [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS performance and the effectiveness of caching", 2002. Authors' Addresses