--- 1/draft-ietf-lisp-deployment-11.txt 2014-01-17 06:14:36.915563280 -0800 +++ 2/draft-ietf-lisp-deployment-12.txt 2014-01-17 06:14:36.971564744 -0800 @@ -1,24 +1,24 @@ Network Working Group L. Jakab Internet-Draft Cisco Systems Intended status: Experimental A. Cabellos-Aparicio -Expires: June 12, 2014 F. Coras +Expires: July 21, 2014 F. Coras J. Domingo-Pascual Technical University of Catalonia D. Lewis Cisco Systems - December 9, 2013 + January 17, 2014 LISP Network Element Deployment Considerations - draft-ietf-lisp-deployment-11.txt + draft-ietf-lisp-deployment-12.txt Abstract This document is a snapshot of different Locator/Identifier Separation Protocol (LISP) deployment scenarios. It discusses the placement of new network elements introduced by the protocol, representing the thinking of the LISP working group as of Summer 2013. LISP deployment scenarios may have evolved since. This memo represents one stable point in that evolution of understanding. @@ -30,25 +30,25 @@ 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 June 12, 2014. + This Internet-Draft will expire on July 21, 2014. Copyright Notice - Copyright (c) 2013 IETF Trust and the persons identified as the + Copyright (c) 2014 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 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -109,22 +109,22 @@ places it at the border routers of stub autonomous systems, which may carry a partial or complete default-free zone (DFZ) routing table. The initial design of LISP took this location as a baseline for protocol development. However, the applications of LISP go beyond just decreasing the size of the DFZ routing table, and include improved multihoming and ingress traffic engineering (TE) support for edge networks, and even individual hosts. Throughout the document we will use the term LISP site to refer to these networks/hosts behind a LISP Tunnel Router. We formally define the following two terms: - Network element: Active or passive device that is connected to other - active or passive devices for transporting packet switched data. + Network element: Facility or equipment used in the provision of a + communications service over the Internet [TELCO96]. LISP site: A single host or a set of network elements in an edge network under the administrative control of a single organization, delimited from other networks by LISP Tunnel Router(s). Since LISP is a protocol which can be used for different purposes, it is important to identify possible deployment scenarios and the additional requirements they may impose on the protocol specification and other protocols. Additionally, this document is intended as a guide for the operational community for LISP deployments in their @@ -430,21 +430,21 @@ o In LISP, ITRs set the reachability bits when encapsulating data packets. Hence, ITRs need a mechanism to be aware of the liveness of all ETRs serving their site. o MTU within the site network must be large enough to accommodate encapsulated packets. o In this scenario, each ITR is serving fewer hosts than in the case when it is deployed at the border of the network. It has been shown that cache hit ratio grows logarithmically with the amount - of users [cache]. Taking this into account, when ITRs are + of users [CACHE]. Taking this into account, when ITRs are deployed closer to the host the effectiveness of the mapping cache may be lower (i.e., the miss ratio is higher). Another consequence of this is that the site may transmit a higher amount of Map-Requests, increasing the load on the distributed mapping database. o By placing the ITRs inside the site, they will still need global RLOCs, and this may add complexity to intra-site routing configuration, and further intra-site issues when there is a change of providers. @@ -621,21 +621,21 @@ according to the specific mapping system that is employed (e.g., ALT [RFC6836], DDT [I-D.ietf-lisp-ddt]). Participation in the mapping database, and the storing of EID-to-RLOC mapping data is subject to the policies of the "root" operators, who should check ownership rights for the EID prefixes stored in the database by participants. These policies are out of the scope of this document. The LISP DDT protocol is used by LISP Mapping Service providers to provide reachability between those providers' Map-Resolvers and Map- Servers. The DDT Root is currently operated by a collection of - organizations on an open basis. See [DDT-Root] for more details. + organizations on an open basis. See [DDT-ROOT] for more details. Similarly to the DNS root, it has several different server instances using names of the letters of the Greek alphabet (alpha, delta, etc.), operated by independent organizations. When this document was published, there were 5 such instances, one of them being anycasted. The Root provides the list of server instances on their web site and configuration files for several map server implementations. The DDT Root, and LISP Mapping Providers both rely on and abide by existing allocation policies by Regional Internet Registries to determine prefix ownership for use as EIDs. @@ -1032,22 +1032,23 @@ Note that throughout Section 5 we focused on the effects of LISP deployment on the DFZ route table size. Other metrics may be impacted as well, but to the best of our knowlegde have not been measured as of yet. 6. Security Considerations All security implications of LISP deployments are to be discussed in separate documents. [I-D.ietf-lisp-threats] gives an overview of - LISP threat models, while securing mapping lookups is discussed in - [I-D.ietf-lisp-sec]. + LISP threat models, including ETR operators attracting traffic by + overclaiming an EID-prefix (Section 4.4.3). Securing mapping lookups + is discussed in [I-D.ietf-lisp-sec]. 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, @@ -1066,21 +1067,24 @@ [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, "Interworking between Locator/ID Separation Protocol (LISP) and Non-LISP Sites", RFC 6832, January 2013. [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation Protocol (LISP) Map-Server Interface", RFC 6833, January 2013. 9.2. Informative References - [DDT-Root] + [CACHE] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS + performance and the effectiveness of caching", 2002. + + [DDT-ROOT] "DDT Root", . [I-D.ietf-lisp-ddt] Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Delegated Database Tree", draft-ietf-lisp-ddt-01 (work in progress), March 2013. [I-D.ietf-lisp-sec] Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D., and O. Bonaventure, "LISP-Security (LISP-SEC)", @@ -1106,22 +1110,21 @@ January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol Alternative Logical Topology (LISP+ALT)", RFC 6836, January 2013. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. - [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS - performance and the effectiveness of caching", 2002. + [TELCO96] "Telecommunications Act of 1996", 1996. Appendix A. Step-by-Step Example BGP to LISP Migration Procedure To help the operational community deploy LISP, this informative section offers a step-by-step guide for migrating a BGP based Internet presence to a LISP site. It includes a pre-install/ pre-turn-up checklist, and customer and provider activation procedures. A.1. Customer Pre-Install and Pre-Turn-up Checklist