--- 1/draft-ietf-lisp-deployment-06.txt 2013-04-11 14:14:08.028903882 +0100 +++ 2/draft-ietf-lisp-deployment-07.txt 2013-04-11 14:14:08.080905160 +0100 @@ -1,24 +1,24 @@ Network Working Group L. Jakab Internet-Draft Cisco Systems Intended status: Informational A. Cabellos-Aparicio -Expires: July 30, 2013 F. Coras +Expires: September 21, 2013 F. Coras J. Domingo-Pascual Technical University of Catalonia D. Lewis Cisco Systems - January 26, 2013 + March 20, 2013 LISP Network Element Deployment Considerations - draft-ietf-lisp-deployment-06.txt + draft-ietf-lisp-deployment-07.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 @@ -27,21 +27,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 July 30, 2013. + This Internet-Draft will expire on September 21, 2013. Copyright Notice Copyright (c) 2013 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 @@ -200,21 +200,22 @@ Another thing to consider when placing tunnel routers are MTU issues. Since encapsulating packets increases overhead, the MTU of the end- to-end path may decrease, when encapsulated packets need to travel over segments having close to minimum MTU. Some transit networks are known to provide larger MTU than the typical value of 1500 bytes of popular access technologies used at end hosts (e.g., IEEE 802.3 and 802.11). However, placing the LISP router connecting to such a network at the customer edge could possibly bring up MTU issues, depending on the link type to the provider as opposed to the following scenario. See [RFC4459] for MTU considerations of - tunneling protocols. + tunneling protocols on how to mitigate potential issues. Still, even + with these mitigations, path MTU issues are still possible. 2.2. Provider Edge The other location at the core-edge boundary for deploying LISP routers is at the Internet service provider edge. The main incentive for this case is that the customer does not have to upgrade the CE router(s), or change the configuration of any equipment. Encapsulation/decapsulation happens in the provider's network, which may be able to serve several customers with a single device. For large ISPs with many residential/business customers asking for LISP @@ -478,21 +479,21 @@ would collide on the port forwarding. 2.6. Summary and Feature Matrix Feature CE PE Split Recursive ------------------------------------------------------------- Control of ingress TE x - x x No modifications to existing int. network infrastructure x x - - Loc-Status-Bits sync x - x x - MTU/PMTUD issues minimized - x - x + MTU/PMTUD issues minimized - x - - 3. Map Resolvers and Map Servers 3.1. Map Servers The Map Server learns EID-to-RLOC mapping entries from an authoritative source and publishes them in the distributed mapping database. These entries are learned through authenticated Map- Register messages sent by authoritative ETRs. Also, upon reception of a Map-Request, the Map Server verifies that the destination EID @@ -900,21 +901,21 @@ * Have customer upgrade (if necessary, software and/or hardware) to be LISP capable. 3. Obtain current running configuration of CE router. A suggested LISP router configuration example can be customized to the customer's existing environment. 4. Verify MTU Handling - * Request increase in MTU to 1556 on service provider + * Request increase in MTU to 1556 or more on service provider connections. Prior to MTU change verify that 1500 byte packet from P-xTR to RLOC with do not fragment (DF-bit) bit set. * Ensure they are not filtering ICMP unreachable or time- exceeded on their firewall or router. LISP, like any tunneling protocol, will increase the size of packets when the LISP header is appended. If increasing the MTU of the access links is not possible, care must be taken that ICMP is not being filtered in order to allow for Path MTU Discovery to @@ -1025,21 +1026,21 @@ 8. IANA Considerations This memo includes no request to IANA. 9. 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, Hannu Flinck, Paul - Vinciguerra and everyone else who provided input. + Vinciguerra, Fred Templin, and everyone else who provided input. 10. References 10.1. Normative References [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, January 2013. [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, @@ -1047,32 +1048,32 @@ (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. 10.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-03 (work in - progress), November 2012. + EID Block", draft-ietf-lisp-eid-block-04 (work in + progress), February 2013. [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-04 (work in progress), October 2012. [I-D.ietf-lisp-threats] Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats - Analysis", draft-ietf-lisp-threats-03 (work in progress), - October 2012. + Analysis", draft-ietf-lisp-threats-04 (work in progress), + February 2013. [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, April 2006. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013. [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS performance and the effectiveness of caching", 2002.