From ljakab@ac.upc.edu Tue Jun 4 06:50:12 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53DB421F9E37 for ; Tue, 4 Jun 2013 06:50:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.398 X-Spam-Level: X-Spam-Status: No, score=-1.398 tagged_above=-999 required=5 tests=[BAYES_50=0.001, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvQ98RPaHwoM for ; Tue, 4 Jun 2013 06:49:55 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC5121E804C for ; Tue, 4 Jun 2013 05:16:55 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r54CGpsD018030; Tue, 4 Jun 2013 14:16:51 +0200 Received: from [10.81.80.7] (unknown [109.96.76.231]) by gw.ac.upc.edu (Postfix) with ESMTP id AD5F16B01C4; Tue, 4 Jun 2013 14:16:48 +0200 (CEST) Message-ID: <51ADDAAD.3050300@ac.upc.edu> Date: Tue, 04 Jun 2013 15:16:45 +0300 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Brian Haberman References: <5192763F.2010205@innovationslab.net> <51A39293.9000506@cisco.com> <51A4B85D.1070107@innovationslab.net> <51A75469.6030009@ac.upc.edu> <51A759BC.3070908@innovationslab.net> <51A75BAC.60809@ac.upc.edu> In-Reply-To: <51A75BAC.60809@ac.upc.edu> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: multipart/mixed; boundary="------------010801020008060206040104" Cc: draft-ietf-lisp-deployment@tools.ietf.org, Lori Jakab , lisp@ietf.org Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2013 13:50:12 -0000 This is a multi-part message in MIME format. --------------010801020008060206040104 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Brian, WG members, Please find attached a revised draft, and the diff from the -07 version. We responded with changes to all the comments in the AD review, except for #7.1, for which we are preparing revised text (Section 2.4). Let us know if the proposed changes in this revision satisfactorily address the rest of the comments. Best regards, -Lori Jakab On 05/30/2013 05:01 PM, Lori Jakab wrote: > On 05/30/2013 04:53 PM, Brian Haberman wrote: >> On 5/30/13 9:30 AM, Lori Jakab wrote: >>> [...] >>> >>>>>> 13. Section 5.1 >>>>>> >>>>>> * I would like to see some justification for the statement that the >>>>>> increase in LISP deployment will reduce the need for BGP-based TE. I >>>>>> can envision some scenarios where LISP could increase the >>>>>> BGP-based TE >>>>>> in order to access the "correct" ETR (or P-ETR). Is there some >>>>>> studies >>>>>> that back up this claim? >>>>> I'm not aware of any conclusive study on this subject, that's why we >>>>> worded the statement "may lead to a decrease" and explicitly mentioned >>>>> the "late transition phase", when most sites use LISP. >>>>> >>>> But, it does not say "may lead to a decrease", it says "will slowly >>>> decrease the need..." and that sounds like a definitive claim. >>> Would s/will/may/ resolve your concern? >>> >> How about "may decrease the need"? That way, you don't have to leave >> the reader wondering about the speed of the possible reduction. > Sounds good, thank you. > > Regards, > -Lori > >> Regards, >> Brian >> --------------010801020008060206040104 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-lisp-deployment-08.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-deployment-08.txt" Network Working Group L. Jakab Internet-Draft Cisco Systems Intended status: Informational A. Cabellos-Aparicio Expires: December 6, 2013 F. Coras J. Domingo-Pascual Technical University of Catalonia D. Lewis Cisco Systems June 4, 2013 LISP Network Element Deployment Considerations draft-ietf-lisp-deployment-08.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 provisions of BCP 78 and BCP 79. 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 December 6, 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 carefully, as they describe your rights and restrictions with respect Jakab, et al. Expires December 6, 2013 [Page 1] Internet-Draft LISP Deployment June 2013 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10 2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.3. Additional Notes . . . . . . . . . . . . . . . . . . . 11 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 3. Map Resolvers and Map Servers . . . . . . . . . . . . . . . . 11 3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 13 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 14 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 (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 Appendix A. Step-by-Step Example BGP to LISP Migration Procedure . . . . . . . . . . . . . . . . . . . . . . 22 A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22 A.2. Customer Activating LISP Service . . . . . . . . . . . . . 23 A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Jakab, et al. Expires December 6, 2013 [Page 2] Internet-Draft LISP Deployment June 2013 1. Introduction The Locator/Identifier Separation Protocol (LISP) is designed to address the scaling issues of the global Internet routing system identified in [RFC4984] by separating the current addressing scheme into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The main protocol specification [RFC6830] describes how the separation is achieved, which new network elements are introduced, and details the packet formats for the data and control planes. LISP assumes that such separation is between the edge and core and uses mapping and encapsulation for forwarding. While the boundary between both is not strictly defined, one widely accepted definition 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. 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 networks. It is expected to evolve as LISP deployment progresses, and the described scenarios are better understood or new scenarios are discovered. Each subsection considers an element type, discussing the impact of deployment scenarios on the protocol specification. For definition of terms, please refer to the appropriate documents (as cited in the respective sections). 2. Tunnel Routers The device that is the gateway between the edge and the core is Jakab, et al. Expires December 6, 2013 [Page 3] Internet-Draft LISP Deployment June 2013 called a Tunnel Router (xTR), performing one or both of two separate functions: 1. Encapsulating packets originating from an end host to be transported over intermediary (transit) networks towards the other end-point of the communication 2. Decapsulating packets entering from intermediary (transit) networks, originated at a remote end host. The first function is performed by an Ingress Tunnel Router (ITR), the second by an Egress Tunnel Router (ETR). Section 8 of the main LISP specification [RFC6830] has a short discussion of where Tunnel Routers can be deployed and some of the associated advantages and disadvantages. This section adds more detail to the scenarios presented there, and provides additional scenarios as well. 2.1. Customer Edge The first scenario we discuss is customer edge, when xTR functionality is placed on the router(s) that connect the LISP site to its upstream(s), but are under its control. As such, this is the most common expected scenario for xTRs, and this document considers it the reference location, comparing the other scenarios to this one. ISP1 ISP2 | | | | +----+ +----+ +--|xTR1|--|xTR2|--+ | +----+ +----+ | | | | LISP site | +------------------+ Figure 1: xTRs at the customer edge From the LISP site perspective the main advantage of this type of deployment (compared to the one described in the next section) is having direct control over its ingress traffic engineering. This makes it easy to set up and maintain active/active, active/backup, or more complex TE policies, without involving third parties. Being under the same administrative control, reachability information of all ETRs is easier to synchronize, because the necessary control traffic can be allowed between the locators of the ETRs. A correct Jakab, et al. Expires December 6, 2013 [Page 4] Internet-Draft LISP Deployment June 2013 synchronous global view of the reachability status is thus available, and the Locator Status Bits (Loc-Status-Bits, defined in [RFC6830]) can be set correctly in the LISP data header of outgoing packets. By placing the tunnel router at the edge of the site, existing internal network configuration does not need to be modified. Firewall rules, router configurations and address assignments inside the LISP site remain unchanged. This helps with incremental deployment and allows a quick upgrade path to LISP. For larger sites with many external connections, distributed in geographically diverse points of presence (PoPs), and complex internal topology, it may however make more sense to both encapsulate and decapsulate as soon as possible, to benefit from the information in the IGP to choose the best path (see Section 2.3 for a discussion of this scenario). Another thing to consider when placing tunnel routers is MTU issues. Encapsulation increases the amount of overhead associated with each packet. This added overhead decreases the effective end-to-end path MTU (unless fragmentation and reassembly is used). 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 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 this can lead to important savings, since there is no need to upgrade the software (or hardware, if it's the case) at each client's location. Instead, they can upgrade the software (or hardware) on a few PE routers serving the customers. This scenario is depicted in Figure 2. Jakab, et al. Expires December 6, 2013 [Page 5] Internet-Draft LISP Deployment June 2013 +----------+ +------------------+ | ISP1 | | ISP2 | | | | | | +----+ | | +----+ +----+ | +--|xTR1|--+ +--|xTR2|--|xTR3|--+ +----+ +----+ +----+ | | | | | | +--<[LISP site]>---+-------+ Figure 2: xTR at the PE While this approach can make transition easy for customers and may be cheaper for providers, the LISP site loses one of the main benefits of LISP: ingress traffic engineering. Since the provider controls the ETRs, additional complexity would be needed to allow customers to modify their mapping entries. The problem is aggravated when the LISP site is multihomed. Consider the scenario in Figure 2: whenever a change to TE policies is required, the customer contacts both ISP1 and ISP2 to make the necessary changes on the routers (if they provide this possibility). It is however unlikely, that both ISPs will apply changes simultaneously, which may lead to inconsistent state for the mappings of the LISP site. Since the different upstream ISPs are usually competing business entities, the ETRs may even be configured to compete, either to attract all the traffic or to get no traffic. The former will happen if the customer pays per volume, the latter if the connectivity has a fixed price. A solution could be to have the mappings in the Map Server(s), and have their operator give control over the entries to customer, much like in the Domain Name System at the time of this writing. Additionally, since xTR1, xTR2, and xTR3 are in different administrative domains, locator reachability information is unlikely to be exchanged among them, making it difficult to set Loc-Status- Bits (LSB) correctly on encapsulated packets. Because of this, and due to the security concerns about LSB described in [I-D.ietf-lisp-threats] their use is discouraged without verifying ETR reachability through the mapping system or other means. Mapping versioning is another alternative [RFC6834]. Compared to the customer edge scenario, deploying LISP at the provider edge might have the advantage of diminishing potential MTU issues, because the tunnel router is closer to the core, where links typically have higher MTUs than edge network links. Jakab, et al. Expires December 6, 2013 [Page 6] Internet-Draft LISP Deployment June 2013 2.3. Split ITR/ETR In a simple LISP deployment, xTRs are located at the border of the LISP site (see Section 2.1). In this scenario packets are routed inside the domain according to the EID. However, more complex networks may want to route packets according to the destination RLOC. This would enable them to choose the best egress point. The LISP specification separates the ITR and ETR functionality and allows both entities to be deployed in separated network equipment. ITRs can be deployed closer to the host (i.e., access routers). This way packets are encapsulated as soon as possible, and egress point selection is driven by operational policy. In turn, ETRs can be deployed at the border routers of the network, and packets are decapsulated as soon as possible. Once decapsulated, packets are routed based on destination EID, according to internal routing policy. In the following figure we can see an example. The Source (S) transmits packets using its EID and in this particular case packets are encapsulated at ITR_1. The encapsulated packets are routed inside the domain according to the destination RLOC, and can egress the network through the best point (i.e., closer to the RLOC's AS). On the other hand, inbound packets are received by ETR_1 which decapsulates them. Then packets are routed towards S according to the EID, again following the best path. +---------------------------------------+ | | | +-------+ +-------+ +-------+ | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | | +-------+ | +-------+ +-------+ | +-+ | | | | |S| | IGP | | | +-+ | | | | +-------+ | +-------+ +-------+ | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | | +-------+ +-------+ +-------+ | | +---------------------------------------+ Figure 3: Split ITR/ETR Scenario This scenario has a set of implications: o The site must carry at least partial BGP routes in order to choose the best egress point, increasing the complexity of the network. However, this is usually already the case for LISP sites that Jakab, et al. Expires December 6, 2013 [Page 7] Internet-Draft LISP Deployment June 2013 would benefit from this scenario. o If the site is multihomed to different ISPs and any of the upstream ISPs are doing uRPF filtering, this scenario may become impractical. ITRs need to determine the exit ETR, for setting the correct source RLOC in the encapsulation header. This adds complexity and reliability concerns. 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 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. To lower the impact, the site could use a local caching Map Resolver. 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. 2.4. Inter-Service Provider Traffic Engineering 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 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, at the time of this writing, ISP_B has only BGP tools (such as prefix deaggregation) to control on which of his own upstream or peering links should packets enter. This is either not Jakab, et al. Expires December 6, 2013 [Page 8] Internet-Draft LISP Deployment June 2013 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 (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 deaggregating 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 caveats. First, it is intended to be deployed between only two ISPs (ISP_A and ISP_B in Figure 4). If more than two ISPs use this approach, then the xTRs deployed at the participating ISPs must either query multiple mapping systems, or the ISPs must agree on a common shared mapping system. Second, the scenario is only recommended for ISPs providing connectivity to LISP sites, such that source RLOCs of packets to be reencapsulated belong to said ISP. Otherwise the participating ISPs must register prefixes they do not own in the above mentioned private mapping system. Failure to follow these recommendations may lead to operational and security issues when deploying this scenario. Besides these recommendations, the main disadvantages of this deployment case are: o Extra LISP header is needed. This increases the packet size and requires that the MTU between both ISPs accommodates double- encapsulated packets. Jakab, et al. Expires December 6, 2013 [Page 9] Internet-Draft LISP Deployment June 2013 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 additional lookup latency, unless a push based mapping system is used for the private mapping system. o The operational overhead of maintaining the shared mapping database. 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. Map-Requests sent by an ITR, which create the state in the NAT table, have a different 5-tuple in the IP header than the Map-Reply generated by the authoritative ETR. Since the source address of this packet is different from the destination address of the request packet, no state will be matched in the NAT table and the packet will be dropped. To avoid this, the NAT device has to do the following: o Send all UDP packets with source port 4342, regardless of the destination port, to the RLOC of the ITR. The most simple way to achieve this is configuring 1:1 NAT mode from the external RLOC of the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer broadband routers). o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in the payload. This setup supports only a single ITR behind the NAT device. 2.5.2. ETR An ETR placed behind NAT is reachable from the outside by the Internet-facing locator of the NAT device. It needs to know this locator (and configure a loopback interface with it), so that it can use it in Map-Reply and Map-Register messages. Thus support for dynamic locators for the mapping database is needed in LISP equipment. Again, only one ETR behind the NAT device is supported. Jakab, et al. Expires December 6, 2013 [Page 10] Internet-Draft LISP Deployment June 2013 2.5.3. Additional Notes An implication of the issues described above is that LISP sites with xTRs can not be behind carrier based NATs, since two different sites would collide on the port forwarding. An alternative to static hole- punching to explore is the use of the Port Control Protocol (PCP) [RFC6887]. 2.6. Summary and Feature Matrix The following table gives a quick overview of the features supported by each of the deployment scenarios discussed above (marked with an "x") in the appropriate column: "CE" for customer edge, "PE" for provider edge, "Split" for split ITR/ETR, and "Recursive" for inter- service provider traffic engineering. The discussed features include: Control of ingress TE: The scenario allows the LISP site to easily control LISP ingress traffic engineering policies. No modifcations to existing int. network infrastruncture: The scenario doesn't require the LISP site to modify internal network configurations. Loc-Status-Bits sync: The scenario allows easy synchronization of the Locator Status Bits. MTU/PMTUD issues minimized: The scenario minimizes potential MTU and Path MTU Discovery issues. 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 - - 3. Map Resolvers and Map Servers Map Resolvers and Map Servers make up the LISP mapping system and provide a means to find authoritative EID-to-RLOC mapping information, conforming to [RFC6833]. They are meant to be deployed in RLOC space, and their operation behind NAT is not supported. Jakab, et al. Expires December 6, 2013 [Page 11] Internet-Draft LISP Deployment June 2013 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 matches an EID-prefix for which it is authoritative for, and then re- encapsulates and forwards it to a matching ETR. Map Server functionality is described in detail in [RFC6833]. The Map Server is provided by a Mapping Service Provider (MSP). The MSP participates in the global distributed mapping database infrastructure, by setting up connections to other participants, 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. In all cases, the MSP configures its Map Server(s) to publish the prefixes of its clients in the distributed mapping database and start encapsulating and forwarding Map-Requests to the ETRs of the AS. These ETRs register their prefix(es) with the Map Server(s) through periodic authenticated Map-Register messages. In this context, for some LISP sites, there is a need for mechanisms to: o Automatically distribute EID prefix(es) shared keys between the ETRs and the EID-registrar Map Server. o Dynamically obtain the address of the Map Server in the ETR of the AS. The Map Server plays a key role in the reachability of the EID- prefixes it is serving. On the one hand it is publishing these prefixes into the distributed mapping database and on the other hand it is encapsulating and forwarding Map-Requests to the authoritative ETRs of these prefixes. ITRs encapsulating towards EIDs under the responsibility of a failed Map Server will be unable to look up any of their covering prefixes. The only exception are the ITRs that already contain the mappings in their local cache. In this case ITRs can reach ETRs until the entry expires (typically 24 hours). For this reason, redundant Map Server deployments are desirable. A set of Map Servers providing high-availability service to the same set of prefixes is called a redundancy group. ETRs are configured to send Map-Register messages to all Map Servers in the redundancy group. The configuration for fail-over (or load-balancing, if desired) among Jakab, et al. Expires December 6, 2013 [Page 12] Internet-Draft LISP Deployment June 2013 the members of the group depends on the technology behind the mapping system being deployed. Since ALT is based on BGP and DDT was inspired from DNS, deployments can leverage current industry best practices for redundancy in BGP and DNS. These best practices are out of the scope of this document. Additionally, if a Map Server has no reachability for any ETR serving a given EID block, it should not originate that block into the mapping system. 3.2. Map Resolvers A Map Resolver is a network infrastructure component which accepts LISP encapsulated Map-Requests, typically from an ITR, and finds the appropriate EID-to-RLOC mapping by either consulting its local cache or by consulting the distributed mapping database. Map Resolver functionality is described in detail in [RFC6833]. Anyone with access to the distributed mapping database can set up a Map Resolver and provide EID-to-RLOC mapping lookup service. Database access setup is mapping system specific. For performance reasons, it is recommended that LISP sites use Map Resolvers that are topologically close to their ITRs. ISPs supporting LISP will provide this service to their customers, possibly restricting access to their user base. LISP sites not in this position can use open access Map Resolvers, if available. However, regardless of the availability of open access resolvers, the MSP providing the Map Server(s) for a LISP site should also make available Map Resolver(s) for the use of that site. In medium to large-size ASes, ITRs must be configured with the RLOC of a Map Resolver, operation which can be done manually. However, in Small Office Home Office (SOHO) scenarios a mechanism for autoconfiguration should be provided. One solution to avoid manual configuration in LISP sites of any size is the use of anycast RLOCs [RFC4786] for Map Resolvers similar to the DNS root server infrastructure. Since LISP uses UDP encapsulation, the use of anycast would not affect reliability. LISP routers are then shipped with a preconfigured list of well know Map Resolver RLOCs, which can be edited by the network administrator, if needed. The use of anycast also helps improve mapping lookup performance. Large MSPs can increase the number and geographical diversity of their Map Resolver infrastructure, using a single anycasted RLOC. Once LISP deployment is advanced enough, very large content providers Jakab, et al. Expires December 6, 2013 [Page 13] Internet-Draft LISP Deployment June 2013 may also be interested running this kind of setup, to ensure minimal connection setup latency for those connecting to their network from LISP sites. While Map Servers and Map Resolvers implement different functionalities within the LISP mapping system, they can coexist on the same device. For example, MSPs offering both services, can deploy a single Map Resolver/Map Server in each PoP where they have a presence. 4. Proxy Tunnel Routers 4.1. P-ITR Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP transition mechanism, allowing non-LISP sites to reach LISP sites. They announce via BGP certain EID prefixes (aggregated, whenever possible) to attract traffic from non-LISP sites towards EIDs in the covered range. They do the mapping system lookup, and encapsulate received packets towards the appropriate ETR. Note that for the reverse path LISP sites can reach non-LISP sites simply by not encapsulating traffic. See [RFC6832] for a detailed description of P-ITR functionality. The success of new protocols depends greatly on their ability to maintain backwards compatibility and inter-operate with the protocol(s) they intend to enhance or replace, and on the incentives to deploy the necessary new software or equipment. A LISP site needs an interworking mechanism to be reachable from non-LISP sites. A P-ITR can fulfill this role, enabling early adopters to see the benefits of LISP, similar to tunnel brokers helping the transition from IPv4 to IPv6. A site benefits from new LISP functionality (proportionally with existing global LISP deployment) when going LISP, so it has the incentives to deploy the necessary tunnel routers. In order to be reachable from non-LISP sites it has two options: keep announcing its prefix(es) with BGP, or have a P-ITR announce prefix(es) covering them. If the goal of reducing the DFZ routing table size is to be reached, the second option is preferred. Moreover, the second option allows LISP-based ingress traffic engineering from all sites. However, the placement of P-ITRs significantly influences performance and deployment incentives. Section 5 is dedicated to the migration to a LISP-enabled Internet, and includes deployment scenarios for P-ITRs. Jakab, et al. Expires December 6, 2013 [Page 14] Internet-Draft LISP Deployment June 2013 4.2. P-ETR In contrast to P-ITRs, P-ETRs are not required for the correct functioning of all LISP sites. There are two cases, where they can be of great help: o LISP sites with unicast reverse path forwarding (uRPF) restrictions, and o Communication between sites using different address family RLOCs. In the first case, uRPF filtering is applied at their upstream PE router. When forwarding traffic to non-LISP sites, an ITR does not encapsulate packets, leaving the original IP headers intact. As a result, packets will have EIDs in their source address. Since we are discussing the transition period, we can assume that a prefix covering the EIDs belonging to the LISP site is advertised to the global routing tables by a P-ITR, and the PE router has a route towards it. However, the next hop will not be on the interface towards the CE router, so non-encapsulated packets will fail uRPF checks. To avoid this filtering, the affected ITR encapsulates packets towards the locator of the P-ETR for non-LISP destinations. Now the source address of the packets, as seen by the PE router is the ITR's locator, which will not fail the uRPF check. The P-ETR then decapsulates and forwards the packets. The second use case is IPv4-to-IPv6 transition. Service providers using older access network hardware, which only supports IPv4 can still offer IPv6 to their clients, by providing a CPE device running LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP sites, with IPv6-only locators. Packets originating from the client LISP site for these destinations would be encapsulated towards the P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, decapsulating and forwarding packets. For non-LISP destination, the packet travels natively from the P-ETR. For LISP destinations with IPv6-only locators, the packet will go through a P-ITR, in order to reach its destination. For more details on P-ETRs see the [RFC6832] draft. P-ETRs can be deployed by ISPs wishing to offer value-added services to their customers. As is the case with P-ITRs, P-ETRs too may introduce path stretch (the ratio between the cost of the selected path and that of the optimal path). Because of this the ISP needs to consider the tradeoff of using several devices, close to the customers, to minimize it, or few devices, farther away from the Jakab, et al. Expires December 6, 2013 [Page 15] Internet-Draft LISP Deployment June 2013 customers, minimizing cost instead. Since the deployment incentives for P-ITRs and P-ETRs are different, it is likely they will be deployed in separate devices, except for the CDN case, which may deploy both in a single device. In all cases, the existence of a P-ETR involves another step in the configuration of a LISP router. CPE routers, which are typically configured by DHCP, stand to benefit most from P-ETRs. Autoconfiguration of the P-ETR locator could be achieved by a DHCP option, or adding a P-ETR field to either Map-Notifys or Map-Replies. 5. Migration to LISP This section discusses a deployment architecture to support the migration to a LISP-enabled Internet. The loosely defined terms of "early transition phase", "late transition phase", and "LISP Internet phase" refer to time periods when LISP sites are a minority, a majority, or represent all edge networks respectively. 5.1. LISP+BGP For sites wishing to go LISP with their PI prefix the least disruptive way is to upgrade their border routers to support LISP, register the prefix into the LISP mapping system, but keep announcing it with BGP as well. This way LISP sites will reach them over LISP, while legacy sites will be unaffected by the change. The main disadvantage of this approach is that no decrease in the DFZ routing table size is achieved. Still, just increasing the number of LISP sites is an important gain, as an increasing LISP/non-LISP site ratio may decrease the need for BGP-based traffic engineering that leads to prefix deaggregation. That, in turn, may lead to a decrease in the DFZ size and churn in the late transition phase. This scenario is not limited to sites that already have their prefixes announced with BGP. Newly allocated EID blocks could follow this strategy as well during the early LISP deployment phase, depending on the cost/benefit analysis of the individual networks. Since this leads to an increase in the DFZ size, the following architecture should be preferred for new allocations. 5.2. Mapping Service Provider (MSP) P-ITR Service In addition to publishing their clients' registered prefixes in the mapping system, MSPs with enough transit capacity can offer them P-ITR service as a separate service. This service is especially useful for new PI allocations, to sites without existing BGP Jakab, et al. Expires December 6, 2013 [Page 16] Internet-Draft LISP Deployment June 2013 infrastructure, that wish to avoid BGP altogether. The MSP announces the prefix into the DFZ, and the client benefits from ingress traffic engineering without prefix deaggregation. The downside of this scenario is adding path stretch. Routing all non-LISP ingress traffic through a third party which is not one of its ISPs is only feasible for sites with modest amounts of traffic (like those using the IPv6 tunnel broker services today), especially in the first stage of the transition to LISP, with a significant number of legacy sites. This is because the handling of said traffic is likely to result in additional costs, which would be passed down to the client. When the LISP/non-LISP site 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 aggregatable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study. 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 sites. While it is possible for a PSP to manually configure each client's EID routes to be announced, this approach offers little flexibility and is not scalable. This section presents a scalable architecture that offers automatic distribution of EID routes to LISP sites and service providers. The architecture requires no modification to existing LISP network elements, but it introduces a new (conceptual) network element, the EID Route Server, defined as a router that either propagates routes learned from other EID Route Servers, or it originates EID Routes. The EID-Routes that it originates are those that it is authoritative for. It propagates these routes to Proxy-ITRs within the AS of the EID Route Server. It is worth to note that a BGP capable router can be also considered as an EID Route Server. Jakab, et al. Expires December 6, 2013 [Page 17] Internet-Draft LISP Deployment June 2013 Further, an EID-Route is defined as a prefix originated via the Route Server of the mapping service provider, which should be aggregated if the MSP has multiple customers inside a single large continuous prefix. This prefix is propagated to other P-ITRs both within the MSP and to other P-ITR operators it peers with. EID Route Servers are operated either by the LISP site, MSPs or PSPs, and they may be collocated with a Map Server or P-ITR, but are a functionally discrete entity. They distribute EID-Routes, using BGP, to other domains, according to policies set by participants. MSP (AS64500) RS ---> P-ITR | / | _.--./ ,-'' /`--. LISP site ---,' | v `. ( | DFZ )----- Mapping system non-LISP site ----. | ^ ,' `--. / _.-' | `--'' v / P-ITR PSP (AS64501) Figure 5: The P-ITR Route Distribution architecture The architecture described above decouples EID origination from route propagation, with the following benefits: o Can accurately represent business relationships between P-ITR operators o More mapping system agnostic o Minor changes to P-ITR implementation, no changes to other components In the example in the figure we have a MSP providing services to the LISP site. The LISP site does not run BGP, and gets an EID allocation directly from a RIR, or from the MSP, who may be a LIR. Existing PI allocations can be migrated as well. The MSP ensures the presence of the prefix in the mapping system, and runs an EID Route Server to distribute it to P-ITR service providers. Since the LISP site does not run BGP, the prefix will be originated with the AS number of the MSP. In the simple case depicted in Figure 5 the EID-Route of LISP site will be originated by the Route Server, and announced to the DFZ by Jakab, et al. Expires December 6, 2013 [Page 18] Internet-Draft LISP Deployment June 2013 the PSP's P-ITRs with AS path 64501 64500. From that point on, the usual BGP dynamics apply. This way, routes announced by P-ITR are still originated by the authoritative Route Server. Note that the peering relationships between MSP/PSPs and those in the underlying forwarding plane may not be congruent, making the AS path to a P-ITR shorter than it is in reality. The non-LISP site will select the best path towards the EID-prefix, according to its local BGP policies. Since AS-path length is usually an important metric for selecting paths, a careful placement of P-ITR could significantly reduce path-stretch between LISP and non-LISP sites. The architecture allows for flexible policies between MSP/PSPs. Consider the EID Route Server networks as control plane overlays, facilitating the implementation of policies necessary to reflect the business relationships between participants. The results are then injected to the common underlying forwarding plane. For example, some MSP/PSPs may agree to exchange EID-Prefixes and only announce them to each of their forwarding plane customers. Global reachability of an EID-prefix depends on the MSP the LISP site buys service from, and is also subject to agreement between the mentioned parties. In terms of impact on the DFZ, this architecture results in a slower routing table increase for new allocations, since traffic engineering will be done at the LISP level. For existing allocations migrating to LISP, the DFZ may decrease since MSPs may be able to aggregate the prefixes announced. 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 aggregatable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study. The flexibility and scalability of this architecture does not come without a cost however: A PSP operator has to establish either transit or peering relationships to improve their connectivity. 5.4. Migration Summary The following table presents the expected effects of the different transition scenarios during a certain phase on the DFZ routing table size: Jakab, et al. Expires December 6, 2013 [Page 19] Internet-Draft LISP Deployment June 2013 Phase | LISP+BGP | MSP P-ITR | PITR-RD -----------------+--------------+-----------------+---------------- Early transition | no change | slower increase | slower increase Late transition | may decrease | slower increase | slower increase LISP Internet | considerable decrease It is expected that PITR-RD will co-exist with LISP+BGP during the migration, with the latter being more popular in the early transition phase. As the transition progresses and the MSP P-ITR and PITR-RD ecosystem gets more ubiquitous, LISP+BGP should become less attractive, slowing down the increase of the number of routes in the DFZ. 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 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]. 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, Hannu Flinck, Paul Vinciguerra, Fred Templin, Brian Haberman, and everyone else who provided input. 9. References 9.1. Normative References [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The Locator/ID Separation Protocol (LISP)", RFC 6830, Jakab, et al. Expires December 6, 2013 [Page 20] Internet-Draft LISP Deployment June 2013 January 2013. [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 [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)", 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-04 (work in progress), February 2013. [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, April 2006. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, 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. Jakab, et al. Expires December 6, 2013 [Page 21] Internet-Draft LISP Deployment June 2013 [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS performance and the effectiveness of caching", 2002. 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 1. Determine how many current physical service provider connections the customer has and their existing bandwidth and traffic engineering requirements. This information will determine the number of routing locators, and the priorities and weights that should be configured on the xTRs. 2. Make sure customer router has LISP capabilities. * Check OS version of the CE router. If LISP is an add-on, check if it is installed. This information can be used to determine if the platform is appropriate to support LISP, in order to determine if a software and/or hardware upgrade is required. * 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 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 Jakab, et al. Expires December 6, 2013 [Page 22] Internet-Draft LISP Deployment June 2013 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 take place. 5. Validate member prefix allocation. This step is to check if the prefix used by the customer is a direct (Provider Independent), or if it is a prefix assigned by a physical service provider (Provider Aggregatable). If the prefixes are assigned by other service providers then a Letter of Agreement is required to announce prefixes through the Proxy Service Provider. 6. Verify the member RLOCs and their reachability. This step ensures that the RLOCs configured on the CE router are in fact reachable and working. 7. Prepare for cut-over. * If possible, have a host outside of all security and filtering policies connected to the console port of the edge router or switch. * Make sure customer has access to the router in order to configure it. A.2. Customer Activating LISP Service 1. Customer configures LISP on CE router(s) from service provider recommended configuration. The LISP configuration consists of the EID prefix, the locators, and the weights and priorities of the mapping between the two values. In addition, the xTR must be configured with Map Resolver(s), Map Server(s) and the shared key for registering to Map Server(s). If required, Proxy-ETR(s) may be configured as well. In addition to the LISP configuration, the following: * Ensure default route(s) to next-hop external neighbors are included and RLOCs are present in configuration. * If two or more routers are used, ensure all RLOCs are included in the LISP configuration on all routers. Jakab, et al. Expires December 6, 2013 [Page 23] Internet-Draft LISP Deployment June 2013 * It will be necessary to redistribute default route via IGP between the external routers. 2. When transition is ready perform a soft shutdown on existing eBGP peer session(s) * From CE router, use LIG to ensure registration is successful. * To verify LISP connectivity, find and ping LISP connected sites. If possible, find ping destinations that are not covered by a prefix in the global BGP routing system, because PITRs may deliver the packets even if LISP connectivity is not working. Traceroutes may help discover if this is the case. * To verify connectivity to non-LISP sites, try accessing a landmark (e.g., a major Internet site) via a web browser. A.3. Cut-Over Provider Preparation and Changes 1. Verify site configuration and then active registration on Map Server(s) * Authentication key * EID prefix 2. Add EID space to map-cache on proxies 3. Add networks to BGP advertisement on proxies * Modify route-maps/policies on P-xTRs * Modify route policies on core routers (if non-connected member) * Modify ingress policers on core routers * Ensure route announcement in looking glass servers, RouteViews 4. Perform traffic verification test * Ensure MTU handling is as expected (PMTUD working) * Ensure proxy-ITR map-cache population * Ensure access from traceroute/ping servers around Internet Jakab, et al. Expires December 6, 2013 [Page 24] Internet-Draft LISP Deployment June 2013 * Use a looking glass, to check for external visibility of registration via several Map Resolvers Authors' Addresses Lorand Jakab Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: lojakab@cisco.com Albert Cabellos-Aparicio Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain Email: acabello@ac.upc.edu Florin Coras Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain Email: fcoras@ac.upc.edu Jordi Domingo-Pascual Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain Email: jordi.domingo@ac.upc.edu Jakab, et al. Expires December 6, 2013 [Page 25] Internet-Draft LISP Deployment June 2013 Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: darlewis@cisco.com Jakab, et al. Expires December 6, 2013 [Page 26] --------------010801020008060206040104 Content-Type: text/html; name="draft-ietf-lisp-deployment-07-08.diff.htm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-deployment-07-08.diff.htm" wdiff draft-ietf-lisp-deployment-07.txt draft-ietf-lisp-deployment-08.txt 

Network Working Group                                           L. Jakab
Internet-Draft                                             Cisco Systems
Intended status: Informational                      A. Cabellos-Aparicio
Expires: September 21, December 6, 2013                                       F. Coras
                                                      J. Domingo-Pascual
                                                 Technical University of
                                                               Catalonia
                                                                D. Lewis
                                                           Cisco Systems
                                                          March 20,
                                                            June 4, 2013

             LISP Network Element Deployment Considerations
                   draft-ietf-lisp-deployment-07.txt
                   draft-ietf-lisp-deployment-08.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
   provisions of BCP 78 and BCP 79.

   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 September 21, December 6, 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
   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
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . .  4  3
     2.1.  Customer Edge  . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Provider Edge  . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Split ITR/ETR  . . . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Inter-Service Provider Traffic Engineering . . . . . . . .  8
     2.5.  Tunnel Routers Behind NAT  . . . . . . . . . . . . . . . . 10
       2.5.1.  ITR  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.5.2.  ETR  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.5.3.  Additional Notes . . . . . . . . . . . . . . . . . . . 11
     2.6.  Summary and Feature Matrix . . . . . . . . . . . . . . . . 11
   3.  Map Resolvers and Map Servers  . . . . . . . . . . . . . . . . 11
     3.1.  Map Servers  . . . . . . . . . . . . . . . . . . . . . . . 11 12
     3.2.  Map Resolvers  . . . . . . . . . . . . . . . . . . . . . . 12 13
   4.  Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 13 14
     4.1.  P-ITR  . . . . . . . . . . . . . . . . . . . . . . . . . . 13 14
     4.2.  P-ETR  . . . . . . . . . . . . . . . . . . . . . . . . . . 14 15
   5.  Migration to LISP  . . . . . . . . . . . . . . . . . . . . . . 15 16
     5.1.  LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 15 16
     5.2.  Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16
     5.3.  Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 16 17
     5.4.  Migration Summary  . . . . . . . . . . . . . . . . . . . . 19
   6.  Step-by-Step Example BGP to LISP Migration Procedure  Security Considerations  . . . . . 19
     6.1.  Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 19
     6.2.  Customer Activating LISP Service . . . . . . . . 20
   7.  IANA Considerations  . . . . . 21
     6.3.  Cut-Over Provider Preparation and Changes . . . . . . . . 21
   7.  Security Considerations . . . . . . . . 20
   8.  Acknowledgements . . . . . . . . . . . . 22
   8.  IANA Considerations . . . . . . . . . . . 20
   9.  References . . . . . . . . . . 22
   9.  Acknowledgements . . . . . . . . . . . . . . . . 20
     9.1.  Normative References . . . . . . . 22
   10. References . . . . . . . . . . . . 20
     9.2.  Informative References . . . . . . . . . . . . . . . . 23
     10.1. Normative References . . 21
   Appendix A.  Step-by-Step Example BGP to LISP Migration
                Procedure . . . . . . . . . . . . . . . . . 23
     10.2. Informative References . . . . . 22
     A.1.  Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22
     A.2.  Customer Activating LISP Service . . . . . . . . . . . . . 23
     A.3.  Cut-Over Provider Preparation and Changes  . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 25

1.  Introduction

   The Locator/Identifier Separation Protocol (LISP) addresses is designed to
   address the scaling issues of the global Internet routing system
   identified in [RFC4984] by separating the current addressing scheme
   into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs).  The
   main protocol specification [RFC6830] describes how the separation is
   achieved, which new network elements are introduced, and details the
   packet formats for the data and control planes.

   LISP assumes that such separation is between the edge and core and
   uses a map-and-encap scheme mapping and encapsulation for forwarding.  While the boundary
   between both is not strictly defined, one widely accepted definition
   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 of
   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 draft document we
   will use the term LISP site to refer to these networks/hosts behind a
   LISP Tunnel Router.  We formally define it as: the following two terms:

   Network element:  Active or passive device that is connected to other
      active or passive devices for transporting packet switched data.

   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).

   Network element:  Active or passive device that is connected
      connected to other active or passive devices for transporting
      packet switched data.

   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
   networks.  It is expected to evolve as LISP deployment progresses,
   and the described scenarios are better understood or new scenarios
   are discovered.

   Each subsection considers an element type, discussing the impact of
   deployment scenarios on the protocol specification.  For definition
   of terms, please refer to the appropriate documents (as cited in the
   respective sections).

2.  Tunnel Routers

   The device that is the gateway between the edge and the core is
   called a Tunnel Router (xTR), performing one or both of two separate
   functions:

   1.  Encapsulating packets originating from an end host to be
       transported over intermediary (transit) networks towards the
       other end-point of the communication

   2.  Decapsulating packets entering from intermediary (transit)
       networks, originated at a remote end host.

   The first function is performed by an Ingress Tunnel Router (ITR),
   the second by an Egress Tunnel Router (ETR).

   Section 8 of the main LISP specification [RFC6830] has a short
   discussion of where Tunnel Routers can be deployed and some of the
   associated advantages and disadvantages.  This section adds more
   detail to the scenarios presented there, and provides additional
   scenarios as well.

2.1.  Customer Edge

   The first scenario we discuss is customer edge, when xTR
   functionality is placed on the router(s) that connect the LISP site
   to its upstream(s), but are under its control.  As such, this is the
   most common expected scenario for xTRs, and this document considers
   it the reference location, comparing the other scenarios to this one.

                                ISP1    ISP2
                                 |        |
                                 |        |
                               +----+  +----+
                            +--|xTR1|--|xTR2|--+
                            |  +----+  +----+  |
                            |                  |
                            |     LISP site    |
                            +------------------+

                    Figure 1: xTRs at the customer edge

   From the LISP site perspective the main advantage of this type of
   deployment (compared to the one described in the next section) is
   having direct control over its ingress traffic engineering.  This
   makes it easy to set up and maintain active/active, active/backup, or
   more complex TE policies, without involving third parties.

   Being under the same administrative control, reachability information
   of all ETRs is easier to synchronize, because the necessary control
   traffic can be allowed between the locators of the ETRs.  A correct
   synchronous global view of the reachability status is thus available,
   and the Loc-Status-Bits Locator Status Bits (Loc-Status-Bits, defined in [RFC6830])
   can be set correctly in the LISP data header of outgoing packets.

   By placing the tunnel router at the edge of the site, existing
   internal network configuration does not need to be modified.
   Firewall rules, router configurations and address assignments inside
   the LISP site remain unchanged.  This helps with incremental
   deployment and allows a quick upgrade path to LISP.  For larger sites
   with many external connections, distributed in geographically diverse
   PoPs,
   points of presence (PoPs), and complex internal topology, it may
   however make more sense to both encapsulate and decapsulate as soon
   as possible, to benefit from the information in the IGP to choose the
   best path (see Section 2.3 for a discussion of this scenario).

   Another thing to consider when placing tunnel routers are is MTU issues.
   Since encapsulating packets
   Encapsulation increases overhead, the MTU amount of overhead associated with each
   packet.  This added overhead decreases the end-
   to-end effective end-to-end path may decrease, when encapsulated packets need to travel
   over segments having close to minimum MTU.
   MTU (unless fragmentation and reassembly is used).  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 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
   this can lead to important savings, since there is no need to upgrade
   the software (or hardware, if it's the case) at each client's
   location.  Instead, they can upgrade the software (or hardware) on a
   few PE routers serving the customers.  This scenario is depicted in
   Figure 2.

                  +----------+        +------------------+
                  |   ISP1   |        |       ISP2       |
                  |          |        |                  |
                  |  +----+  |        |  +----+  +----+  |
                  +--|xTR1|--+        +--|xTR2|--|xTR3|--+
                     +----+              +----+  +----+
                        |                  |       |
                        |                  |       |
                        +--<[LISP site]>---+-------+

                          Figure 2: xTR at the PE

   While this approach can make transition easy for customers and may be
   cheaper for providers, the LISP site looses loses one of the main benefits
   of LISP: ingress traffic engineering.  Since the provider controls
   the ETRs, additional complexity would be needed to allow customers to
   modify their mapping entries.

   The problem is aggravated when the LISP site is multihomed.  Consider
   the scenario in Figure 2: whenever a change to TE policies is
   required, the customer contacts both ISP1 and ISP2 to make the
   necessary changes on the routers (if they provide this possibility).
   It is however unlikely, that both ISPs will apply changes
   simultaneously, which may lead to inconsistent state for the mappings
   of the LISP site.  Since the different upstream ISPs are usually
   competing business entities, the ETRs may even be configured to
   compete, either to attract all the traffic or to get no traffic.  The
   former will happen if the customer pays per volume, the latter if the
   connectivity has a fixed price.  A solution could be to have the
   mappings in the Map Server(s), and have their operator give control
   over the entries to customer, much like in the Domain Name System at
   the time of this writing.

   Additionally, since xTR1, xTR2, and xTR3 are in different
   administrative domains, locator reachability information is unlikely
   to be exchanged among them, making it difficult to set Loc-Status-
   Bits (LSB) correctly on encapsulated packets.  Because of this, and
   due to the security concerns about LSB described in
   [I-D.ietf-lisp-threats] their use is discouraged without verifying
   ETR reachability through the mapping system or other means.  Mapping
   versioning is another alternative [RFC6834].

   Compared to the customer edge scenario, deploying LISP at the
   provider edge might have the advantage of diminishing potential MTU
   issues, because the tunnel router is closer to the core, where links
   typically have higher MTUs than edge network links.

2.3.  Split ITR/ETR

   In a simple LISP deployment, xTRs are located at the border of the
   LISP site (see Section 2.1).  In this scenario packets are routed
   inside the domain according to the EID.  However, more complex
   networks may want to route packets according to the destination RLOC.
   This would enable them to choose the best egress point.

   The LISP specification separates the ITR and ETR functionality and
   considers that
   allows both entities can to be deployed in separated network equipment.
   ITRs can be deployed closer to the host (i.e., access routers).  This
   way packets are encapsulated as soon as possible, and
   packets exit the network through the best egress point in terms of
   BGP
   selection is driven by operational policy.  In turn, ETRs can be
   deployed at the border routers of the network, and packets are
   decapsulated as soon as possible.  Once decapsulated, packets are
   routed based on destination EID, according to internal routing
   policy.

   In the following figure we can see an example.  The Source (S)
   transmits packets using its EID and in this particular case packets
   are encapsulated at ITR_1.  The encapsulated packets are routed
   inside the domain according to the destination RLOC, and can egress
   the network through the best point (i.e., closer to the RLOC's AS).
   On the other hand, inbound packets are received by ETR_1 which
   decapsulates them.  Then packets are routed towards S according to
   the EID, again following the best path.

      +---------------------------------------+
      |                                       |
      |       +-------+                   +-------+         +-------+
      |       | ITR_1 |---------+         | ETR_1 |-RLOC_A--| ISP_A |
      |       +-------+         |         +-------+         +-------+
      |  +-+        |           |             |
      |  |S|        |    IGP    |             |
      |  +-+        |           |             |
      |       +-------+         |         +-------+         +-------+
      |       | ITR_2 |---------+         | ETR_2 |-RLOC_B--| ISP_B |
      |       +-------+                   +-------+         +-------+
      |                                       |
      +---------------------------------------+

                     Figure 3: Split ITR/ETR Scenario

   This scenario has a set of implications:

   o  The site must carry at least partial BGP routes in order to choose
      the best egress point, increasing the complexity of the network.
      However, this is usually already the case for LISP sites that
      would benefit from this scenario.

   o  If the site is multihomed to different ISPs and any of the
      upstream ISPs is are doing uRPF filtering, this scenario may become
      impractical.  ITRs need to determine the exit ETR, for setting the
      correct source RLOC in the encapsulation header.  This adds
      complexity and reliability concerns.

   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
      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.  To lower the impact, the site could use a local caching
      Map Resolver.

   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.

2.4.  Inter-Service Provider Traffic Engineering

   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 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, at the time of this writing, ISP_B has only BGP
   tools (such as 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 (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
   deaggregating 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 caveats.  First, it
   is intended to be deployed between only two ISPs (ISP_A and ISP_B in
   Figure 4).  If more than two ISPs use this approach, then the xTRs
   deployed at the participating ISPs must either query multiple mapping
   systems, or the ISPs must agree on a common shared mapping system.
   Second, the scenario is only recommended for ISPs providing
   connectivity to LISP sites, such that source RLOCs of packets to be
   reencapsulated belong to said ISP.  Otherwise the participating ISPs
   must register prefixes they do not own in the above mentioned private
   mapping system.  Failure to follow these recommendations may lead to
   operational and security issues when deploying this scenario.

   Besides these recommendations, the main disadvantages of this
   deployment case are:

   o  Extra LISP header is needed.  This increases the packet size and
      requires that the MTU between both ISPs accommodates double-
      encapsulated packets.

   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 additional lookup latency, unless a push based
      mapping system is used for the private mapping system.

   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.

   Map-Requests sent by an ITR, which create the state in the NAT table,
   have a different 5-tuple in the IP header than the Map-Reply
   generated by the authoritative ETR.  Since the source address of this
   packet is different from the destination address of the request
   packet, no state will be matched in the NAT table and the packet will
   be dropped.  To avoid this, the NAT device has to do the following:

   o  Send all UDP packets with source port 4342, regardless of the
      destination port, to the RLOC of the ITR.  The most simple way to
      achieve this is configuring 1:1 NAT mode from the external RLOC of
      the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer
      broadband routers).

   o  Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in
      the payload.

   This setup supports only a single ITR behind the NAT device.

2.5.2.  ETR

   An ETR placed behind NAT is reachable from the outside by the
   Internet-facing locator of the NAT device.  It needs to know this
   locator (and configure a loopback interface with it), so that it can
   use it in Map-Reply and Map-Register messages.  Thus support for
   dynamic locators for the mapping database is needed in LISP
   equipment.

   Again, only one ETR behind the NAT device is supported.

2.5.3.  Additional Notes

   An implication of the issues described above is that LISP sites with
   xTRs can not be behind carrier based NATs, since two different sites
   would collide on the port forwarding.  An alternative to static hole-
   punching to explore is the use of the Port Control Protocol (PCP)
   [RFC6887].

2.6.  Summary and Feature Matrix

   The following table gives a quick overview of the features supported
   by each of the deployment scenarios discussed above (marked with an
   "x") in the appropriate column: "CE" for customer edge, "PE" for
   provider edge, "Split" for split ITR/ETR, and "Recursive" for inter-
   service provider traffic engineering.  The discussed features
   include:

   Control of ingress TE:  The scenario allows the LISP site to easily
      control LISP ingress traffic engineering policies.

   No modifcations to existing int. network infrastruncture:  The
      scenario doesn't require the LISP site to modify internal network
      configurations.

   Loc-Status-Bits sync:  The scenario allows easy synchronization of
      the Locator Status Bits.

   MTU/PMTUD issues minimized:  The scenario minimizes potential MTU and
      Path MTU Discovery issues.

       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      -         -

3.  Map Resolvers and Map Servers

   Map Resolvers and Map Servers make up the LISP mapping system and
   provide a means to find authoritative EID-to-RLOC mapping
   information, conforming to [RFC6833].  They are meant to be deployed
   in RLOC space, and their operation behind NAT is not supported.

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
   matches an EID-prefix for which it is authoritative for, and then re-
   encapsulates and forwards it to a matching ETR.  Map Server
   functionality is described in detail in [RFC6833].

   The Map Server is provided by a Mapping Service Provider (MSP).  The
   MSP participates in the global distributed mapping database
   infrastructure, by setting up connections to other participants,
   according to the specific mapping system that is employed (e.g., ALT,
   DDT). ALT
   [RFC6836], DDT [I-D.ietf-lisp-ddt]).  Participation in the mapping
   database, and the storing of EID-
   to-RLOC EID-to-RLOC mapping data is subject to
   the policies of the "root" operators, who SHOULD should check ownership
   rights for the EID prefixes stored in the database by participants.
   These policies are out of the scope of this document.

   In all cases, the MSP configures its Map Server(s) to publish the
   prefixes of its clients in the distributed mapping database and start
   encapsulating and forwarding Map-Requests to the ETRs of the AS.
   These ETRs register their prefix(es) with the Map Server(s) through
   periodic authenticated Map-Register messages.  In this context, for
   some LISP end sites, there is a need for mechanisms to:

   o  Automatically distribute EID prefix(es) shared keys between the
      ETRs and the EID-registrar Map Server.

   o  Dynamically obtain the address of the Map Server in the ETR of the
      AS.

   The Map Server plays a key role in the reachability of the EID-
   prefixes it is serving.  On the one hand it is publishing these
   prefixes into the distributed mapping database and on the other hand
   it is encapsulating and forwarding Map-Requests to the authoritative
   ETRs of these prefixes.  ITRs encapsulating towards EIDs under the
   responsibility of a failed Map Server will be unable to look up any
   of their covering prefixes.  The only exception are the ITRs that
   already contain the mappings in their local cache.  In this case ITRs
   can reach ETRs until the entry expires (typically 24 hours).  For
   this reason, redundant Map Server deployments are desirable.  A set
   of Map Servers providing high-availability service to the same set of
   prefixes is called a redundancy group.  ETRs are configured to send
   Map-Register messages to all Map Servers in the redundancy group.  To
   achieve
   The configuration for fail-over (or load-balancing, if desired), known desired) among
   the members of the group depends on the technology behind the mapping
   system specific being deployed.  Since ALT is based on BGP and DDT was
   inspired from DNS, deployments can leverage current industry best
   practices should be used. for redundancy in BGP and DNS.  These best practices are
   out of the scope of this document.

   Additionally, if a Map Server has no reachability for any ETR serving
   a given EID block, it should not originate that block into the
   mapping system.

3.2.  Map Resolvers

   A Map Resolver a is a network infrastructure component which accepts
   LISP encapsulated Map-Requests, typically from an ITR, and finds the
   appropriate EID-to-RLOC mapping by either consulting its local cache
   or by consulting the distributed mapping database.  Map Resolver
   functionality is described in detail in [RFC6833].

   Anyone with access to the distributed mapping database can set up a
   Map Resolver and provide EID-to-RLOC mapping lookup service.
   Database access setup is mapping system specific.

   For performance reasons, it is recommended that LISP sites use Map
   Resolvers that are topologically close to their ITRs.  ISPs
   supporting LISP will provide this service to their customers,
   possibly restricting access to their user base.  LISP sites not in
   this position can use open access Map Resolvers, if available.
   However, regardless of the availability of open access resolvers, the
   MSP providing the Map Server(s) for a LISP site should also make
   available Map Resolver(s) for the use of that site.

   In medium to large-size ASes, ITRs must be configured with the RLOC
   of a Map Resolver, operation which can be done manually.  However, in
   Small Office Home Office (SOHO) scenarios a mechanism for
   autoconfiguration should be provided.

   One solution to avoid manual configuration in LISP sites of any size
   is the use of anycast RLOCs [RFC4786] for Map Resolvers similar to
   the DNS root server infrastructure.  Since LISP uses UDP
   encapsulation, the use of anycast would not affect reliability.  LISP
   routers are then shipped with a preconfigured list of well know Map
   Resolver RLOCs, which can be edited by the network administrator, if
   needed.

   The use of anycast also helps improving improve mapping lookup performance.
   Large MSPs can increase the number and geographical diversity of
   their Map Resolver infrastructure, using a single anycasted RLOC.
   Once LISP deployment is advanced enough, very large content providers
   may also be interested running this kind of setup, to ensure minimal
   connection setup latency for those connecting to their network from
   LISP sites.

   While Map Servers and Map Resolvers implement different
   functionalities within the LISP mapping system, they can coexist on
   the same device.  For example, MSPs offering both services, can
   deploy a single Map Resolver/Map Server in each PoP where they have a
   presence.

4.  Proxy Tunnel Routers

4.1.  P-ITR

   Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP
   transition mechanism, allowing non-LISP sites to reach LISP sites.
   They announce via BGP certain EID prefixes (aggregated, whenever
   possible) to attract traffic from non-LISP sites towards EIDs in the
   covered range.  They do the mapping system lookup, and encapsulate
   received packets towards the appropriate ETR.  Note that for the
   reverse path LISP sites can reach non-LISP sites simply by not
   encapsulating traffic.  See [RFC6832] for a detailed description of
   P-ITR functionality.

   The success of new protocols depends greatly on their ability to
   maintain backwards compatibility and inter-operate with the
   protocol(s) they intend to enhance or replace, and on the incentives
   to deploy the necessary new software or equipment.  A LISP site needs
   an interworking mechanism to be reachable from non-LISP sites.  A
   P-ITR can fulfill this role, enabling early adopters to see the
   benefits of LISP, similar to tunnel brokers helping the transition
   from IPv4 to IPv6.  A site benefits from new LISP functionality
   (proportionally with existing global LISP deployment) when going
   LISP, so it has the incentives to deploy the necessary tunnel
   routers.  In order to be reachable from non-LISP sites it has two
   options: keep announcing its prefix(es) with BGP, or have a P-ITR
   announce prefix(es) covering them.

   If the goal of reducing the DFZ routing table size is to be reached,
   the second option is preferred.  Moreover, the second option allows
   LISP-based ingress traffic engineering from all sites.  However, the
   placement of P-ITRs significantly influences performance and
   deployment incentives.  Section 5 is dedicated to the migration to a
   LISP-enabled Internet, and includes deployment scenarios for P-ITRs.

4.2.  P-ETR

   In contrast to P-ITRs, P-ETRs are not required for the correct
   functioning of all LISP sites.  There are two cases, where they can
   be of great help:

   o  LISP sites with unicast reverse path forwarding (uRPF)
      restrictions, and

   o  Communication between sites using different address family RLOCs.

   In the first case, uRPF filtering is applied at their upstream PE
   router.  When forwarding traffic to non-LISP sites, an ITR does not
   encapsulate packets, leaving the original IP headers intact.  As a
   result, packets will have EIDs in their source address.  Since we are
   discussing the transition period, we can assume that a prefix
   covering the EIDs belonging to the LISP site is advertised to the
   global routing tables by a P-ITR, and the PE router has a route
   towards it.  However, the next hop will not be on the interface
   towards the CE router, so non-encapsulated packets will fail uRPF
   checks.

   To avoid this filtering, the affected ITR encapsulates packets
   towards the locator of the P-ETR for non-LISP destinations.  Now the
   source address of the packets, as seen by the PE router is the ITR's
   locator, which will not fail the uRPF check.  The P-ETR then
   decapsulates and forwards the packets.

   The second use case is IPv4-to-IPv6 transition.  Service providers
   using older access network hardware, which only supports IPv4 can
   still offer IPv6 to their clients, by providing a CPE device running
   LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP
   sites, with IPv6-only locators.  Packets originating from the client
   LISP site for these destinations would be encapsulated towards the
   P-ETR's IPv4 locator.  The P-ETR is in a native IPv6 network,
   decapsulating and forwarding packets.  For non-LISP destination, the
   packet travels natively from the P-ETR.  For LISP destinations with
   IPv6-only locators, the packet will go through a P-ITR, in order to
   reach its destination.

   For more details on P-ETRs see the [RFC6832] draft.

   P-ETRs can be deployed by ISPs wishing to offer value-added services
   to their customers.  As is the case with P-ITRs, P-ETRs too may
   introduce path stretch. stretch (the ratio between the cost of the selected
   path and that of the optimal path).  Because of this the ISP needs to
   consider the tradeoff of using several devices, close to the
   customers, to minimize it, or few devices, farther away from the
   customers, minimizing cost instead.

   Since the deployment incentives for P-ITRs and P-ETRs are different,
   it is likely they will be deployed in separate devices, except for
   the CDN case, which may deploy both in a single device.

   In all cases, the existence of a P-ETR involves another step in the
   configuration of a LISP router.  CPE routers, which are typically
   configured by DHCP, stand to benefit most from P-ETRs.
   Autoconfiguration of the P-ETR locator could be achieved by a DHCP
   option, or adding a P-ETR field to either Map-Notifys or Map-Replies.

5.  Migration to LISP

   This section discusses a deployment architecture to support the
   migration to a LISP-enabled Internet.  The loosely defined terms of
   "early transition phase", "late transition phase", and "LISP Internet
   phase" refer to time periods when LISP sites are a minority, a
   majority, or represent all edge networks respectively.

5.1.  LISP+BGP

   For sites wishing to go LISP with their PI prefix the least
   disruptive way is to upgrade their border routers to support LISP,
   register the prefix into the LISP mapping system, but keep announcing
   it with BGP as well.  This way LISP sites will reach them over LISP,
   while legacy sites will be unaffected by the change.  The main
   disadvantage of this approach is that no decrease in the DFZ routing
   table size is achieved.  Still, just increasing the number of LISP
   sites is an important gain, as an increasing LISP/non-LISP site ratio
   will slowly
   may decrease the need for BGP-based traffic engineering that leads to
   prefix deaggregation.  That, in turn, may lead to a decrease in the
   DFZ size and churn in the late transition phase.

   This scenario is not limited to sites that already have their
   prefixes announced with BGP.  Newly allocated EID blocks could follow
   this strategy as well during the early LISP deployment phase,
   depending on the cost/benefit analysis of the individual networks.
   Since this leads to an increase in the DFZ size, the following
   architecture should be preferred for new allocations.

5.2.  Mapping Service Provider (MSP) P-ITR Service

   In addition to publishing their clients' registered prefixes in the
   mapping system, MSPs with enough transit capacity can offer them
   P-ITR service as a separate service.  This service is especially
   useful for new PI allocations, to sites without existing BGP
   infrastructure, that wish to avoid BGP altogether.  The MSP announces
   the prefix into the DFZ, and the client benefits from ingress traffic
   engineering without prefix deaggregation.  The downside of this
   scenario is adding path stretch.

   Routing all non-LISP ingress traffic through a third party which is
   not one of its ISPs is only feasible for sites with modest amounts of
   traffic (like those using the IPv6 tunnel broker services today),
   especially in the first stage of the transition to LISP, with a
   significant number of legacy sites.  This is because the handling of
   said traffic is likely to result in additional costs, which would be
   passed down to the client.  When the LISP/non-LISP site 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 aggregatable prefixes may lead to additional decrease,
   but quantifying this decrease is subject to future research study.

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
   sites.  Note that handling non-LISP-originated traffic may incur
   additional costs for the PSP, which may be passed down to the client.

   While it is possible

   While it is possible for a PSP to manually configure each client's
   EID routes to be announced, this approach offers little flexibility
   and is not scalable.  This section presents a scalable architecture
   that offers automatic distribution of EID routes to LISP sites and
   service providers.

   The architecture requires no modification to existing LISP network
   elements, but it introduces a new (conceptual) network element, the
   EID Route Server, defined as a router that either propagates routes
   learned from other EID Route Servers, or it originates EID Routes.
   The EID-Routes that it originates are those that it is authoritative
   for.  It propagates these routes to Proxy-ITRs within the AS of the
   EID Route Server.  It is worth to note that a BGP capable router can
   be also considered as an EID Route Server.

   Further, an EID-Route is defined as a prefix originated via the Route
   Server of the mapping service provider, which should be aggregated if
   the MSP has multiple customers inside a single large continuous
   prefix.  This prefix is propagated to other P-ITRs both within the
   MSP and to other P-ITR operators it peers with.  EID Route Servers
   are operated either by the LISP site, MSPs or PSPs, and they may be
   collocated with a Map Server or P-ITR, but are a functionally
   discrete entity.  They distribute EID-Routes, using BGP, to other
   domains, according to policies set by participants.

                              MSP (AS64500)
                              RS ---> P-ITR
                               |        /
                               |  _.--./
                              ,-''    /`--.
             LISP site   ---,' |     v     `.
                           (   |   DFZ       )----- Mapping system
         non-LISP site   ----. |    ^      ,'
                              `--. /   _.-'
                               |  `--''
                               v /
                             P-ITR
                             PSP (AS64501)

            Figure 5: The P-ITR Route Distribution architecture

   The architecture described above decouples EID origination from route
   propagation, with the following benefits:

   o  Can accurately represent business relationships between P-ITR
      operators

   o  More mapping system agnostic

   o  Minor changes to P-ITR implementation, no changes to other
      components

   In the example in the figure we have a MSP providing services to the
   LISP site.  The LISP site does not run BGP, and gets an EID
   allocation directly from a RIR, or from the MSP, who may be a LIR.
   Existing PI allocations can be migrated as well.  The MSP ensures the
   presence of the prefix in the mapping system, and runs an EID Route
   Server to distribute it to P-ITR service providers.  Since the LISP
   site does not run BGP, the prefix will be originated with the AS
   number of the MSP.

   In the simple case depicted in Figure 5 the EID-Route of LISP Site site
   will be originated by the Route Server, and announced to the DFZ by
   the PSP's P-ITRs with AS path 64501 64500.  From that point on, the
   usual BGP dynamics apply.  This way, routes announced by P-ITR are
   still originated by the authoritative Route Server.  Note that the
   peering relationships between MSP/PSPs and those in the underlying
   forwarding plane may not be congruent, making the AS path to a P-ITR
   shorter than it is in reality.

   The non-LISP site will select the best path towards the EID-prefix,
   according to its local BGP policies.  Since AS-path length is usually
   an important metric for selecting paths, a careful placement of P-ITR
   could significantly reduce path-stretch between LISP and non-LISP
   sites.

   The architecture allows for flexible policies between MSP/PSPs.
   Consider the EID Route Server networks as control plane overlays,
   facilitating the implementation of policies necessary to reflect the
   business relationships between participants.  The results are then
   injected to the common underlying forwarding plane.  For example,
   some MSP/PSPs may agree to exchange EID-Prefixes and only announce
   them to each of their forwarding plane customers.  Global
   reachability of an EID-prefix depends on the MSP the LISP site buys
   service from, and is also subject to agreement between the mentioned
   parties.

   In terms of impact on the DFZ, this architecture results in a slower
   routing table increase for new allocations, since traffic engineering
   will be done at the LISP level.  For existing allocations migrating
   to LISP, the DFZ may decrease since MSPs may be able to aggregate the
   prefixes announced.

   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 aggregatable prefixes may lead to additional decrease,
   but quantifying this decrease is subject to future research study.

   The flexibility and scalability of this architecture does not come
   without a cost however: A PSP operator has to establish either
   transit or peering relationships to improve their connectivity.

5.4.  Migration Summary

   The following table presents the expected effects of the different
   transition scenarios during a certain phase on the DFZ routing table
   size:

    Phase            | LISP+BGP     | MSP P-ITR       | PITR-RD
    -----------------+--------------+-----------------+----------------
    Early transition | no change    | slower increase | slower increase
    Late transition  | may decrease | slower increase | slower increase
    LISP Internet    |             considerable decrease

   It is expected that PITR-RD will co-exist with LISP+BGP during the
   migration, with the latter being more popular in the early transition
   phase.  As the transition progresses and the MSP P-ITR and PITR-RD
   ecosystem gets more ubiquitous, LISP+BGP should become less
   attractive, slowing down the increase of the number of routes in the
   DFZ.

6.  Step-by-Step Example BGP to LISP Migration Procedure

6.1.  Customer Pre-Install and Pre-Turn-up Checklist

   1.  Determine how many current physical service provider connections
       the customer has and their existing bandwidth and traffic
       engineering requirements.

       This information will determine the number of routing locators,
       and the priorities and weights

   Note that should be configured throughout Section 5 we focused on the
       xTRs.

   2.  Make sure customer router has LISP capabilities.

       *  Check OS version effects of the CE router.  If LISP is an add-on,
          check if it is installed.

          This information can
   deployment on the DFZ route table size.  Other metrics may be used
   impacted as well, but to determine if the platform is
          appropriate to support LISP, in order to determine if a
          software and/or hardware upgrade is required.

       *  Have customer upgrade (if necessary, software and/or hardware) best of our knowlegde have not been
   measured as of yet.

6.  Security Considerations

   Security implications of LISP deployments are to be LISP capable.

   3.  Obtain current running configuration discussed in
   separate documents.  [I-D.ietf-lisp-threats] gives an overview of CE router.  A suggested
   LISP router configuration example can be customized to the
       customer's existing environment.

   4.  Verify MTU Handling

       *  Request increase threat models, while securing mapping lookups is discussed in MTU
   [I-D.ietf-lisp-sec].

7.  IANA Considerations

   This memo includes no request to 1556 or more on service provider
          connections.  Prior IANA.

8.  Acknowledgements

   Many thanks to MTU change verify Margaret Wasserman for her contribution to the IETF76
   presentation that 1500 byte packet
          from P-xTR kickstarted this work.  The authors would also like
   to RLOC with do not fragment (DF-bit) bit set.

       *  Ensure they are not thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
   Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul
   Vinciguerra, Fred Templin, Brian Haberman, and everyone else who
   provided input.

9.  References

9.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,
              "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

   [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)",
              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-04 (work in progress),
              February 2013.

   [RFC4459]  Savola, P., "MTU and Fragmentation Issues with In-the-
              Network Tunneling", RFC 4459, April 2006.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, December 2006.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", RFC 6834,
              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.

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

   1.  Determine how many current physical service provider connections
       the customer has and their existing bandwidth and traffic
       engineering requirements.

       This information will determine the number of routing locators,
       and the priorities and weights that should be configured on the
       xTRs.

   2.  Make sure customer router has LISP capabilities.

       *  Check OS version of the CE router.  If LISP is an add-on,
          check if it is installed.

          This information can be used to determine if the platform is
          appropriate to support LISP, in order to determine if a
          software and/or hardware upgrade is required.

       *  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 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
       take place.

   5.  Validate member prefix allocation.

       This step is to check if the prefix used by the customer is a
       direct (Provider Independent), or if it is a prefix assigned by a
       physical service provider (Provider Aggregatable).  If the
       prefixes are assigned by other service provivers providers then a Letter of
       Agreement is required to announce prefixes through the Proxy
       Service Provider.

   6.  Verify the member RLOCs and their reachability.

       This step ensures that the RLOCs configured on the CE router are
       in fact reachable and working.

   7.  Prepare for cut-over.

       *  If possible, have a host outside of all security and filtering
          policies connected to the console port of the edge router or
          switch.

       *  Make sure customer has access to the router in order to
          configure it.

6.2.

A.2.  Customer Activating LISP Service

   1.  Customer configures LISP on CE router(s) from service provider
       recommended configuration.

       The LISP configuration consists of the EID prefix, the locators,
       and the weights and priorities of the mapping between the two
       values.  In addition, the xTR must be configured with Map
       Resolver(s), Map Server(s) and the shared key for registering to
       Map Server(s).  If required, Proxy-ETR(s) may be configured as
       well.

       In addition to the LISP configuration, the following:

       *  Ensure default route(s) to next-hop external neighbors are
          included and RLOCs are present in configuration.

       *  If two or more routers are used, ensure all RLOCs are included
          in the LISP configuration on all routers.

       *  It will be necessary to redistribute default route via IGP
          between the external routers.

   2.  When transition is ready perform a soft shutdown on existing eBGP
       peer session(s)

       *  From CE router, use LIG to ensure registration is successful.

       *  To verify LISP connectivity, ping LISP connected sites.  See
          http://www.lisp4.net/ and/or http://www.lisp6.net/ for
          potential candidates.  If possible, find ping destinations
          that are not covered by a prefix in the global BGP routing
          system, because PITRs may deliver the packets even if LISP
          connectivity is not working.  Traceroutes may help discover if
          this is the case.

       *  To verify connectivity to non-LISP sites, try accessing a
          landmark (e.g., a major Internet site) via a web browser.

6.3.  Cut-Over Provider Preparation and Changes

   1.  Verify site configuration and then active registration on Map
       Server(s)
       *  Authentication key

       *  EID prefix

   2.  Add EID space to map-cache on proxies

   3.  Add networks to BGP advertisement on proxies

       *  Modify route-maps/policies on P-xTRs

       *  Modify route policies on core routers (if non-connected
          member)

       *  Modify ingress policers on core routers

       *  Ensure route announcement in looking glass servers, RouteViews

   4.  Perform traffic verification test

       *  Ensure MTU handling is as expected (PMTUD working)

       *  Ensure proxy-ITR map-cache population

       *  Ensure access from traceroute/ping servers around Internet

       *  Use a looking glass, default route(s) to check for next-hop external visibility of
          registration via several Map Resolvers (e.g.,
          http://lispmon.net/).

7.  Security Considerations

   Security implications of LISP deployments neighbors are to be discussed
          included and RLOCs are present in
   separate documents.  [I-D.ietf-lisp-threats] gives an overview of
   LISP threat models, while securing mapping lookups is discussed configuration.

       *  If two or more routers are used, ensure all RLOCs are included
          in
   [I-D.ietf-lisp-sec].

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 LISP configuration on all routers.

       *  It will be necessary to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince Fuller,
   Dino Farinacci, Terry Manderson, Noel Chiappa, Hannu Flinck, Paul
   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,
              "Interworking redistribute default route via IGP
          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.

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-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., the external routers.

   2.  When transition is ready perform a soft shutdown on existing eBGP
       peer session(s)

       *  From CE router, use LIG to ensure registration is successful.

       *  To verify LISP connectivity, find and O. Bonaventure, "LISP Threats
              Analysis", draft-ietf-lisp-threats-04 (work ping LISP connected
          sites.  If possible, find ping destinations that are not
          covered by a prefix 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., the global BGP routing system, because
          PITRs may deliver the packets even if LISP connectivity is not
          working.  Traceroutes may help discover if this is the case.

       *  To verify connectivity to non-LISP sites, try accessing a
          landmark (e.g., a major Internet site) via a web browser.

A.3.  Cut-Over Provider Preparation and R. Morris, "DNS
              performance Changes

   1.  Verify site configuration and the effectiveness then active registration on Map
       Server(s)

       *  Authentication key

       *  EID prefix

   2.  Add EID space to map-cache on proxies

   3.  Add networks to BGP advertisement on proxies

       *  Modify route-maps/policies on P-xTRs

       *  Modify route policies on core routers (if non-connected
          member)

       *  Modify ingress policers on core routers

       *  Ensure route announcement in looking glass servers, RouteViews

   4.  Perform traffic verification test

       *  Ensure MTU handling is as expected (PMTUD working)

       *  Ensure proxy-ITR map-cache population

       *  Ensure access from traceroute/ping servers around Internet
       *  Use a looking glass, to check for external visibility of caching", 2002.
          registration via several Map Resolvers

Authors' Addresses

   Lorand Jakab
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Email: lojakab@cisco.com

   Albert Cabellos-Aparicio
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: acabello@ac.upc.edu

   Florin Coras
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: fcoras@ac.upc.edu

   Jordi Domingo-Pascual
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: jordi.domingo@ac.upc.edu
   Darrel Lewis
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com
--------------010801020008060206040104-- From brian@innovationslab.net Wed Jun 5 11:25:56 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59A0421F9BAF for ; Wed, 5 Jun 2013 11:25:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.799 X-Spam-Level: X-Spam-Status: No, score=-102.799 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOJP16F+olt4 for ; Wed, 5 Jun 2013 11:25:50 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D7A3921F9BA7 for ; Wed, 5 Jun 2013 11:25:49 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 665DA880F7; Wed, 5 Jun 2013 11:25:43 -0700 (PDT) Received: from 102523118.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E7D07130003; Wed, 5 Jun 2013 11:25:42 -0700 (PDT) Message-ID: <51AF82A4.6040506@innovationslab.net> Date: Wed, 05 Jun 2013 14:25:40 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Lori Jakab References: <5192763F.2010205@innovationslab.net> <51A39293.9000506@cisco.com> <51A4B85D.1070107@innovationslab.net> <51A75469.6030009@ac.upc.edu> <51A759BC.3070908@innovationslab.net> <51A75BAC.60809@ac.upc.edu> <51ADDAAD.3050300@ac.upc.edu> In-Reply-To: <51ADDAAD.3050300@ac.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-deployment@tools.ietf.org, Lori Jakab , lisp@ietf.org Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 18:25:56 -0000 Hi Lori, These changes look fine to me. I will await updated text for the remaining open comment and any feedback from the WG on these changes. Regards, Brian On 6/4/13 8:16 AM, Lori Jakab wrote: > Hi Brian, WG members, > > Please find attached a revised draft, and the diff from the -07 version. > We responded with changes to all the comments in the AD review, except > for #7.1, for which we are preparing revised text (Section 2.4). Let us > know if the proposed changes in this revision satisfactorily address the > rest of the comments. > > Best regards, > -Lori Jakab > > On 05/30/2013 05:01 PM, Lori Jakab wrote: >> On 05/30/2013 04:53 PM, Brian Haberman wrote: >>> On 5/30/13 9:30 AM, Lori Jakab wrote: >>>> [...] >>>> >>>>>>> 13. Section 5.1 >>>>>>> >>>>>>> * I would like to see some justification for the statement that the >>>>>>> increase in LISP deployment will reduce the need for BGP-based TE. I >>>>>>> can envision some scenarios where LISP could increase the >>>>>>> BGP-based TE >>>>>>> in order to access the "correct" ETR (or P-ETR). Is there some >>>>>>> studies >>>>>>> that back up this claim? >>>>>> I'm not aware of any conclusive study on this subject, that's why we >>>>>> worded the statement "may lead to a decrease" and explicitly mentioned >>>>>> the "late transition phase", when most sites use LISP. >>>>>> >>>>> But, it does not say "may lead to a decrease", it says "will slowly >>>>> decrease the need..." and that sounds like a definitive claim. >>>> Would s/will/may/ resolve your concern? >>>> >>> How about "may decrease the need"? That way, you don't have to leave >>> the reader wondering about the speed of the possible reduction. >> Sounds good, thank you. >> >> Regards, >> -Lori >> >>> Regards, >>> Brian >>> > From internet-drafts@ietf.org Mon Jun 17 10:58:59 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19E8821F9D2F; Mon, 17 Jun 2013 10:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9vyGZqEGlQoZ; Mon, 17 Jun 2013 10:58:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2851C21F9CB9; Mon, 17 Jun 2013 10:58:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130617175854.13125.24549.idtracker@ietfa.amsl.com> Date: Mon, 17 Jun 2013 10:58:54 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-mib-11.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 17:58:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP MIB Author(s) : Gregg Schudel Amit Jain Victor Moreno Filename : draft-ietf-lisp-mib-11.txt Pages : 64 Date : 2013-06-17 Abstract: This document defines the MIB module that contains managed objects to support the monitoring devices that support the Locator/ID Separation Protocol (LISP). These objects provide information useful for monitoring LISP devices, including determining basic LISP configuration information, LISP functional status, and operational counters and other statistics. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-mib There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-mib-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-mib-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ljakab@ac.upc.edu Tue Jun 18 04:28:15 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4ABD21F9EAF for ; Tue, 18 Jun 2013 04:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.998 X-Spam-Level: X-Spam-Status: No, score=-3.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQdW-+WBPGtr for ; Tue, 18 Jun 2013 04:28:09 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1391521F9EA7 for ; Tue, 18 Jun 2013 04:28:02 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r5IBS038014518; Tue, 18 Jun 2013 13:28:00 +0200 Received: from [10.21.87.237] (128-107-239-233.cisco.com [128.107.239.233]) by gw.ac.upc.edu (Postfix) with ESMTP id 84A8E6B01C6; Tue, 18 Jun 2013 13:27:55 +0200 (CEST) Message-ID: <51C04438.9070807@ac.upc.edu> Date: Tue, 18 Jun 2013 14:27:52 +0300 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Brian Haberman References: <5192763F.2010205@innovationslab.net> <51A39293.9000506@cisco.com> <51A4B85D.1070107@innovationslab.net> <51A75469.6030009@ac.upc.edu> <51A759BC.3070908@innovationslab.net> <51A75BAC.60809@ac.upc.edu> <51ADDAAD.3050300@ac.upc.edu> <51AF82A4.6040506@innovationslab.net> In-Reply-To: <51AF82A4.6040506@innovationslab.net> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: multipart/mixed; boundary="------------090105050802010807060803" Cc: draft-ietf-lisp-deployment@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 11:28:15 -0000 This is a multi-part message in MIME format. --------------090105050802010807060803 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Brian, all, Sorry for the long delay, here's updated text for section 2.4. As previously, I attached both the diff from the previous revision I sent to the list, and the full draft. Best regards, -Lori (on behalf of the authors) On 06/05/2013 09:25 PM, Brian Haberman wrote: > Hi Lori, > These changes look fine to me. I will await updated text for the > remaining open comment and any feedback from the WG on these changes. > > Regards, > Brian > > On 6/4/13 8:16 AM, Lori Jakab wrote: >> Hi Brian, WG members, >> >> Please find attached a revised draft, and the diff from the -07 version. >> We responded with changes to all the comments in the AD review, except >> for #7.1, for which we are preparing revised text (Section 2.4). Let us >> know if the proposed changes in this revision satisfactorily address the >> rest of the comments. >> >> Best regards, >> -Lori Jakab >> >> On 05/30/2013 05:01 PM, Lori Jakab wrote: >>> On 05/30/2013 04:53 PM, Brian Haberman wrote: >>>> On 5/30/13 9:30 AM, Lori Jakab wrote: >>>>> [...] >>>>> >>>>>>>> 13. Section 5.1 >>>>>>>> >>>>>>>> * I would like to see some justification for the statement that >>>>>>>> the >>>>>>>> increase in LISP deployment will reduce the need for BGP-based >>>>>>>> TE. I >>>>>>>> can envision some scenarios where LISP could increase the >>>>>>>> BGP-based TE >>>>>>>> in order to access the "correct" ETR (or P-ETR). Is there some >>>>>>>> studies >>>>>>>> that back up this claim? >>>>>>> I'm not aware of any conclusive study on this subject, that's >>>>>>> why we >>>>>>> worded the statement "may lead to a decrease" and explicitly >>>>>>> mentioned >>>>>>> the "late transition phase", when most sites use LISP. >>>>>>> >>>>>> But, it does not say "may lead to a decrease", it says "will slowly >>>>>> decrease the need..." and that sounds like a definitive claim. >>>>> Would s/will/may/ resolve your concern? >>>>> >>>> How about "may decrease the need"? That way, you don't have to leave >>>> the reader wondering about the speed of the possible reduction. >>> Sounds good, thank you. >>> >>> Regards, >>> -Lori >>> >>>> Regards, >>>> Brian >>>> >> > --------------090105050802010807060803 Content-Type: text/html; name="draft-ietf-lisp-deployment-08-08.diff.htm" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-deployment-08-08.diff.htm" wdiff draft-ietf-lisp-deployment-08.1.txt draft-ietf-lisp-deployment-08.txt 

Network Working Group                                           L. Jakab
Internet-Draft                                             Cisco Systems
Intended status: Informational                      A. Cabellos-Aparicio
Expires: December 6, 20, 2013                                      F. Coras
                                                      J. Domingo-Pascual
                                                 Technical University of
                                                               Catalonia
                                                                D. Lewis
                                                           Cisco Systems
                                                           June 4, 18, 2013

             LISP Network Element Deployment Considerations
                   draft-ietf-lisp-deployment-08.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
   provisions of BCP 78 and BCP 79.

   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 December 6, 20, 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
   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
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Customer Edge  . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Provider Edge  . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Split ITR/ETR  . . . . . . . . . . . . . . . . . . . . . .  7
     2.4.  Inter-Service Provider Traffic Engineering . . . . . . . .  8
     2.5.  Tunnel Routers Behind NAT  . . . . . . . . . . . . . . . . 10
       2.5.1.  ITR  . . . . . . . . . . . . . . . . . . . . . . . . . 10
       2.5.2.  ETR  . . . . . . . . . . . . . . . . . . . . . . . . . 10 11
       2.5.3.  Additional Notes . . . . . . . . . . . . . . . . . . . 11
     2.6.  Summary and Feature Matrix . . . . . . . . . . . . . . . . 11
   3.  Map Resolvers and Map Servers  . . . . . . . . . . . . . . . . 11 12
     3.1.  Map Servers  . . . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  Map Resolvers  . . . . . . . . . . . . . . . . . . . . . . 13
   4.  Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 14
     4.1.  P-ITR  . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     4.2.  P-ETR  . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   5.  Migration to LISP  . . . . . . . . . . . . . . . . . . . . . . 16
     5.1.  LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16
     5.2.  Mapping Service Provider (MSP) P-ITR Service . . . . . . . 16 17
     5.3.  Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17
     5.4.  Migration Summary  . . . . . . . . . . . . . . . . . . . . 19 20
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 21
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 20 21
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 21
   Appendix A.  Step-by-Step Example BGP to LISP Migration
                Procedure . . . . . . . . . . . . . . . . . . . . . . 22
     A.1.  Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22
     A.2.  Customer Activating LISP Service . . . . . . . . . . . . . 23
     A.3.  Cut-Over Provider Preparation and Changes  . . . . . . . . 24
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25

1.  Introduction

   The Locator/Identifier Separation Protocol (LISP) is designed to
   address the scaling issues of the global Internet routing system
   identified in [RFC4984] by separating the current addressing scheme
   into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs).  The
   main protocol specification [RFC6830] describes how the separation is
   achieved, which new network elements are introduced, and details the
   packet formats for the data and control planes.

   LISP assumes that such separation is between the edge and core and
   uses mapping and encapsulation for forwarding.  While the boundary
   between both is not strictly defined, one widely accepted definition
   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.

   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
   networks.  It is expected to evolve as LISP deployment progresses,
   and the described scenarios are better understood or new scenarios
   are discovered.

   Each subsection considers an element type, discussing the impact of
   deployment scenarios on the protocol specification.  For definition
   of terms, please refer to the appropriate documents (as cited in the
   respective sections).

2.  Tunnel Routers

   The device that is the gateway between the edge and the core is
   called a Tunnel Router (xTR), performing one or both of two separate
   functions:

   1.  Encapsulating packets originating from an end host to be
       transported over intermediary (transit) networks towards the
       other end-point of the communication

   2.  Decapsulating packets entering from intermediary (transit)
       networks, originated at a remote end host.

   The first function is performed by an Ingress Tunnel Router (ITR),
   the second by an Egress Tunnel Router (ETR).

   Section 8 of the main LISP specification [RFC6830] has a short
   discussion of where Tunnel Routers can be deployed and some of the
   associated advantages and disadvantages.  This section adds more
   detail to the scenarios presented there, and provides additional
   scenarios as well.

2.1.  Customer Edge

   The first scenario we discuss is customer edge, when xTR
   functionality is placed on the router(s) that connect the LISP site
   to its upstream(s), but are under its control.  As such, this is the
   most common expected scenario for xTRs, and this document considers
   it the reference location, comparing the other scenarios to this one.

                                ISP1    ISP2
                                 |        |
                                 |        |
                               +----+  +----+
                            +--|xTR1|--|xTR2|--+
                            |  +----+  +----+  |
                            |                  |
                            |     LISP site    |
                            +------------------+

                    Figure 1: xTRs at the customer edge

   From the LISP site perspective the main advantage of this type of
   deployment (compared to the one described in the next section) is
   having direct control over its ingress traffic engineering.  This
   makes it easy to set up and maintain active/active, active/backup, or
   more complex TE policies, without involving third parties.

   Being under the same administrative control, reachability information
   of all ETRs is easier to synchronize, because the necessary control
   traffic can be allowed between the locators of the ETRs.  A correct
   synchronous global view of the reachability status is thus available,
   and the Locator Status Bits (Loc-Status-Bits, defined in [RFC6830])
   can be set correctly in the LISP data header of outgoing packets.

   By placing the tunnel router at the edge of the site, existing
   internal network configuration does not need to be modified.
   Firewall rules, router configurations and address assignments inside
   the LISP site remain unchanged.  This helps with incremental
   deployment and allows a quick upgrade path to LISP.  For larger sites
   with many external connections, distributed in geographically diverse
   points of presence (PoPs), and complex internal topology, it may
   however make more sense to both encapsulate and decapsulate as soon
   as possible, to benefit from the information in the IGP to choose the
   best path (see Section 2.3 for a discussion of this scenario).

   Another thing to consider when placing tunnel routers is MTU issues.
   Encapsulation increases the amount of overhead associated with each
   packet.  This added overhead decreases the effective end-to-end path
   MTU (unless fragmentation and reassembly is used).  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 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
   this can lead to important savings, since there is no need to upgrade
   the software (or hardware, if it's the case) at each client's
   location.  Instead, they can upgrade the software (or hardware) on a
   few PE routers serving the customers.  This scenario is depicted in
   Figure 2.

                  +----------+        +------------------+
                  |   ISP1   |        |       ISP2       |
                  |          |        |                  |
                  |  +----+  |        |  +----+  +----+  |
                  +--|xTR1|--+        +--|xTR2|--|xTR3|--+
                     +----+              +----+  +----+
                        |                  |       |
                        |                  |       |
                        +--<[LISP site]>---+-------+

                          Figure 2: xTR at the PE

   While this approach can make transition easy for customers and may be
   cheaper for providers, the LISP site loses one of the main benefits
   of LISP: ingress traffic engineering.  Since the provider controls
   the ETRs, additional complexity would be needed to allow customers to
   modify their mapping entries.

   The problem is aggravated when the LISP site is multihomed.  Consider
   the scenario in Figure 2: whenever a change to TE policies is
   required, the customer contacts both ISP1 and ISP2 to make the
   necessary changes on the routers (if they provide this possibility).
   It is however unlikely, that both ISPs will apply changes
   simultaneously, which may lead to inconsistent state for the mappings
   of the LISP site.  Since the different upstream ISPs are usually
   competing business entities, the ETRs may even be configured to
   compete, either to attract all the traffic or to get no traffic.  The
   former will happen if the customer pays per volume, the latter if the
   connectivity has a fixed price.  A solution could be to have the
   mappings in the Map Server(s), and have their operator give control
   over the entries to customer, much like in the Domain Name System at
   the time of this writing.

   Additionally, since xTR1, xTR2, and xTR3 are in different
   administrative domains, locator reachability information is unlikely
   to be exchanged among them, making it difficult to set Loc-Status-
   Bits (LSB) correctly on encapsulated packets.  Because of this, and
   due to the security concerns about LSB described in
   [I-D.ietf-lisp-threats] their use is discouraged without verifying
   ETR reachability through the mapping system or other means.  Mapping
   versioning is another alternative [RFC6834].

   Compared to the customer edge scenario, deploying LISP at the
   provider edge might have the advantage of diminishing potential MTU
   issues, because the tunnel router is closer to the core, where links
   typically have higher MTUs than edge network links.

2.3.  Split ITR/ETR

   In a simple LISP deployment, xTRs are located at the border of the
   LISP site (see Section 2.1).  In this scenario packets are routed
   inside the domain according to the EID.  However, more complex
   networks may want to route packets according to the destination RLOC.
   This would enable them to choose the best egress point.

   The LISP specification separates the ITR and ETR functionality and
   allows both entities to be deployed in separated network equipment.
   ITRs can be deployed closer to the host (i.e., access routers).  This
   way packets are encapsulated as soon as possible, and egress point
   selection is driven by operational policy.  In turn, ETRs can be
   deployed at the border routers of the network, and packets are
   decapsulated as soon as possible.  Once decapsulated, packets are
   routed based on destination EID, according to internal routing
   policy.

   In the following figure we can see an example.  The Source (S)
   transmits packets using its EID and in this particular case packets
   are encapsulated at ITR_1.  The encapsulated packets are routed
   inside the domain according to the destination RLOC, and can egress
   the network through the best point (i.e., closer to the RLOC's AS).
   On the other hand, inbound packets are received by ETR_1 which
   decapsulates them.  Then packets are routed towards S according to
   the EID, again following the best path.

      +---------------------------------------+
      |                                       |
      |       +-------+                   +-------+         +-------+
      |       | ITR_1 |---------+         | ETR_1 |-RLOC_A--| ISP_A |
      |       +-------+         |         +-------+         +-------+
      |  +-+        |           |             |
      |  |S|        |    IGP    |             |
      |  +-+        |           |             |
      |       +-------+         |         +-------+         +-------+
      |       | ITR_2 |---------+         | ETR_2 |-RLOC_B--| ISP_B |
      |       +-------+                   +-------+         +-------+
      |                                       |
      +---------------------------------------+

                     Figure 3: Split ITR/ETR Scenario

   This scenario has a set of implications:

   o  The site must carry at least partial BGP routes in order to choose
      the best egress point, increasing the complexity of the network.
      However, this is usually already the case for LISP sites that
      would benefit from this scenario.

   o  If the site is multihomed to different ISPs and any of the
      upstream ISPs are doing uRPF filtering, this scenario may become
      impractical.  ITRs need to determine the exit ETR, for setting the
      correct source RLOC in the encapsulation header.  This adds
      complexity and reliability concerns.

   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
      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.  To lower the impact, the site could use a local caching
      Map Resolver.

   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.

2.4.  Inter-Service Provider Traffic Engineering

   With LISP,

   At the time of this writing, if two LISP sites can route packets among them and ISPs want to control their
   ingress TE policies. policies for transit traffic between them, they need to
   rely on existing BGP mechanisms.  This typically means deaggregating
   prefixes to choose on which upstream link packets should 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.

   Typically, LISP is seen as applicable only to stub networks, however the
   LISP protocol can also be also applied in a recursive manner, providing
   service provider ingress/egress TE capabilities without impacting the
   DFZ table size.

   In order to
   transit networks recursively.

   Consider implement this functionality with LISP 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 two ISPs willing to achieve
   ingress/egress TE are labeled as the source RLOC an IP
   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 and ISP_B, they are servicing
   Stub1 and Stub2 respectively, both are required to be LISP encapsulation, Stub4 has control over its ingress
   traffic.  However, at the time of sites.  In
   this writing, scenario we assume that Stub1 and Stub2 are communicating and
   thus, ISP_A and ISP_B offer transit for such communications.  ISP_A
   has only BGP
   tools (such RLOC_A1 and RLOC_A2 as prefix deaggregation) to control on which of his own upstream or peering links should packets enter.  This IP addresses while ISP_B has
   RLOC_B1 and RLOC_B2.  The shared goal among ISP_A and ISP_B is either not
   feasible (if fine-grained per-customer to
   control is required, the very
   specific prefixes may not be propagated) or increases DFZ table size. transit traffic flow between RLOC_A1/A2 and RLOC_B1/B2.

                                   _.--.
    Stub1 ...   +-------+      ,-''     `--.      +-------+   ... Stub3 Stub2
             \  |   R_A1|----,'             `. ---|R_B1   |  /
              --|   R_A2|---(       |   (     Transit     )   |       |--
    Stub2
     ...  .../  |   R_A3|-----.   R_A2|-----.             ,' ---|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

   Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively
   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  This mapping system.  Note that in
   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 system contains bindings between the outer, second layer RLOCs of LISP encapsulation
   from the incoming packet,
   Stub1 and routes it towards the original RLOC,
   the ETR of Stub4, which does the final decapsulation.

   If Stub2 (owned by ISP_A and ISP_B agree to share a private distributed mapping
   database, both can control their ingress TE without respectively) and
   RLOC_A1/A2 and RLOC_B1/B2.  Such bindings are in fact the need of
   deaggregating prefixes.  In this scenario TE policies
   between both ISPs and 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.

   The packet flow is as follows.  First, a packet originated at Stub1
   towards Stub2 is LISP encapsulated by Stub1's xTR.  The xTR of ISP_A
   reencapsulates it and, according to the TE policies stored in the
   private mapping system, the ISP_A xTR chooses RLOC_B1 or RLOC_B2 as
   the reencapsulation destination.  Note that the packet transits
   between ISP_A and ISP_B double-encapsulated.  Upon reception at the
   xTR of ISP_B the packet is decapsulated and sent towards Stub2 which
   performs the last decapsulation.

   This deployment scenario scenario, which uses recursive LISP, includes two
   important caveats.  First, it is intended to be deployed between only
   two ISPs (ISP_A and ISP_B in
   Figure 4). ISPs.  If more than two ISPs use this approach, then the xTRs
   deployed at the participating ISPs must either query multiple mapping
   systems, or the ISPs must agree on a common shared mapping system.
   Furthemore, keeping this deployment scenario restricted to only two
   ISPs maintains the solution scalable, given that only two entities
   need to agree on using recursive LISP, and only one private mapping
   system is involved.

   Second, the scenario is only recommended for ISPs providing
   connectivity to LISP sites, such that source RLOCs of packets to be
   reencapsulated belong to said ISP.  Otherwise the participating ISPs
   must register prefixes they do not own in the above mentioned private
   mapping system.  Failure to follow these recommendations may lead to
   operational and security issues when deploying this scenario.

   Besides these recommendations, the main disadvantages of this
   deployment case are:

   o  Extra LISP header is needed.  This increases the packet size and
      requires that the MTU between both ISPs accommodates double-
      encapsulated packets.

   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 additional lookup latency, unless a push based
      mapping system is used for the private mapping system.

   o  The operational overhead of maintaining the shared mapping
      database.

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.

   Map-Requests sent by an ITR, which create the state in the NAT table,
   have a different 5-tuple in the IP header than the Map-Reply
   generated by the authoritative ETR.  Since the source address of this
   packet is different from the destination address of the request
   packet, no state will be matched in the NAT table and the packet will
   be dropped.  To avoid this, the NAT device has to do the following:

   o  Send all UDP packets with source port 4342, regardless of the
      destination port, to the RLOC of the ITR.  The most simple way to
      achieve this is configuring 1:1 NAT mode from the external RLOC of
      the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer
      broadband routers).

   o  Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in
      the payload.

   This setup supports only a single ITR behind the NAT device.

2.5.2.  ETR

   An ETR placed behind NAT is reachable from the outside by the
   Internet-facing locator of the NAT device.  It needs to know this
   locator (and configure a loopback interface with it), so that it can
   use it in Map-Reply and Map-Register messages.  Thus support for
   dynamic locators for the mapping database is needed in LISP
   equipment.

   Again, only one ETR behind the NAT device is supported.

2.5.3.  Additional Notes

   An implication of the issues described above is that LISP sites with
   xTRs can not be behind carrier based NATs, since two different sites
   would collide on the port forwarding.  An alternative to static hole-
   punching to explore is the use of the Port Control Protocol (PCP)
   [RFC6887].

2.6.  Summary and Feature Matrix

   The following table gives a quick overview of the features supported
   by each of the deployment scenarios discussed above (marked with an
   "x") in the appropriate column: "CE" for customer edge, "PE" for
   provider edge, "Split" for split ITR/ETR, and "Recursive" for inter-
   service provider traffic engineering.  The discussed features
   include:

   Control of ingress TE:  The scenario allows the LISP site to easily
      control LISP ingress traffic engineering policies.

   No modifcations to existing int. network infrastruncture:  The
      scenario doesn't require the LISP site to modify internal network
      configurations.

   Loc-Status-Bits sync:  The scenario allows easy synchronization of
      the Locator Status Bits.

   MTU/PMTUD issues minimized:  The scenario minimizes potential MTU and
      Path MTU Discovery issues.

       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      -         -

3.  Map Resolvers and Map Servers

   Map Resolvers and Map Servers make up the LISP mapping system and
   provide a means to find authoritative EID-to-RLOC mapping
   information, conforming to [RFC6833].  They are meant to be deployed
   in RLOC space, and their operation behind NAT is not supported.

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
   matches an EID-prefix for which it is authoritative for, and then re-
   encapsulates and forwards it to a matching ETR.  Map Server
   functionality is described in detail in [RFC6833].

   The Map Server is provided by a Mapping Service Provider (MSP).  The
   MSP participates in the global distributed mapping database
   infrastructure, by setting up connections to other participants,
   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.

   In all cases, the MSP configures its Map Server(s) to publish the
   prefixes of its clients in the distributed mapping database and start
   encapsulating and forwarding Map-Requests to the ETRs of the AS.
   These ETRs register their prefix(es) with the Map Server(s) through
   periodic authenticated Map-Register messages.  In this context, for
   some LISP sites, there is a need for mechanisms to:

   o  Automatically distribute EID prefix(es) shared keys between the
      ETRs and the EID-registrar Map Server.

   o  Dynamically obtain the address of the Map Server in the ETR of the
      AS.

   The Map Server plays a key role in the reachability of the EID-
   prefixes it is serving.  On the one hand it is publishing these
   prefixes into the distributed mapping database and on the other hand
   it is encapsulating and forwarding Map-Requests to the authoritative
   ETRs of these prefixes.  ITRs encapsulating towards EIDs under the
   responsibility of a failed Map Server will be unable to look up any
   of their covering prefixes.  The only exception are the ITRs that
   already contain the mappings in their local cache.  In this case ITRs
   can reach ETRs until the entry expires (typically 24 hours).  For
   this reason, redundant Map Server deployments are desirable.  A set
   of Map Servers providing high-availability service to the same set of
   prefixes is called a redundancy group.  ETRs are configured to send
   Map-Register messages to all Map Servers in the redundancy group.
   The configuration for fail-over (or load-balancing, if desired) among
   the members of the group depends on the technology behind the mapping
   system being deployed.  Since ALT is based on BGP and DDT was
   inspired from DNS, deployments can leverage current industry best
   practices for redundancy in BGP and DNS.  These best practices are
   out of the scope of this document.

   Additionally, if a Map Server has no reachability for any ETR serving
   a given EID block, it should not originate that block into the
   mapping system.

3.2.  Map Resolvers

   A Map Resolver is a network infrastructure component which accepts
   LISP encapsulated Map-Requests, typically from an ITR, and finds the
   appropriate EID-to-RLOC mapping by either consulting its local cache
   or by consulting the distributed mapping database.  Map Resolver
   functionality is described in detail in [RFC6833].

   Anyone with access to the distributed mapping database can set up a
   Map Resolver and provide EID-to-RLOC mapping lookup service.
   Database access setup is mapping system specific.

   For performance reasons, it is recommended that LISP sites use Map
   Resolvers that are topologically close to their ITRs.  ISPs
   supporting LISP will provide this service to their customers,
   possibly restricting access to their user base.  LISP sites not in
   this position can use open access Map Resolvers, if available.
   However, regardless of the availability of open access resolvers, the
   MSP providing the Map Server(s) for a LISP site should also make
   available Map Resolver(s) for the use of that site.

   In medium to large-size ASes, ITRs must be configured with the RLOC
   of a Map Resolver, operation which can be done manually.  However, in
   Small Office Home Office (SOHO) scenarios a mechanism for
   autoconfiguration should be provided.

   One solution to avoid manual configuration in LISP sites of any size
   is the use of anycast RLOCs [RFC4786] for Map Resolvers similar to
   the DNS root server infrastructure.  Since LISP uses UDP
   encapsulation, the use of anycast would not affect reliability.  LISP
   routers are then shipped with a preconfigured list of well know Map
   Resolver RLOCs, which can be edited by the network administrator, if
   needed.

   The use of anycast also helps improve mapping lookup performance.
   Large MSPs can increase the number and geographical diversity of
   their Map Resolver infrastructure, using a single anycasted RLOC.
   Once LISP deployment is advanced enough, very large content providers
   may also be interested running this kind of setup, to ensure minimal
   connection setup latency for those connecting to their network from
   LISP sites.

   While Map Servers and Map Resolvers implement different
   functionalities within the LISP mapping system, they can coexist on
   the same device.  For example, MSPs offering both services, can
   deploy a single Map Resolver/Map Server in each PoP where they have a
   presence.

4.  Proxy Tunnel Routers

4.1.  P-ITR

   Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP
   transition mechanism, allowing non-LISP sites to reach LISP sites.
   They announce via BGP certain EID prefixes (aggregated, whenever
   possible) to attract traffic from non-LISP sites towards EIDs in the
   covered range.  They do the mapping system lookup, and encapsulate
   received packets towards the appropriate ETR.  Note that for the
   reverse path LISP sites can reach non-LISP sites simply by not
   encapsulating traffic.  See [RFC6832] for a detailed description of
   P-ITR functionality.

   The success of new protocols depends greatly on their ability to
   maintain backwards compatibility and inter-operate with the
   protocol(s) they intend to enhance or replace, and on the incentives
   to deploy the necessary new software or equipment.  A LISP site needs
   an interworking mechanism to be reachable from non-LISP sites.  A
   P-ITR can fulfill this role, enabling early adopters to see the
   benefits of LISP, similar to tunnel brokers helping the transition
   from IPv4 to IPv6.  A site benefits from new LISP functionality
   (proportionally with existing global LISP deployment) when going
   LISP, so it has the incentives to deploy the necessary tunnel
   routers.  In order to be reachable from non-LISP sites it has two
   options: keep announcing its prefix(es) with BGP, or have a P-ITR
   announce prefix(es) covering them.

   If the goal of reducing the DFZ routing table size is to be reached,
   the second option is preferred.  Moreover, the second option allows
   LISP-based ingress traffic engineering from all sites.  However, the
   placement of P-ITRs significantly influences performance and
   deployment incentives.  Section 5 is dedicated to the migration to a
   LISP-enabled Internet, and includes deployment scenarios for P-ITRs.

4.2.  P-ETR

   In contrast to P-ITRs, P-ETRs are not required for the correct
   functioning of all LISP sites.  There are two cases, where they can
   be of great help:

   o  LISP sites with unicast reverse path forwarding (uRPF)
      restrictions, and

   o  Communication between sites using different address family RLOCs.

   In the first case, uRPF filtering is applied at their upstream PE
   router.  When forwarding traffic to non-LISP sites, an ITR does not
   encapsulate packets, leaving the original IP headers intact.  As a
   result, packets will have EIDs in their source address.  Since we are
   discussing the transition period, we can assume that a prefix
   covering the EIDs belonging to the LISP site is advertised to the
   global routing tables by a P-ITR, and the PE router has a route
   towards it.  However, the next hop will not be on the interface
   towards the CE router, so non-encapsulated packets will fail uRPF
   checks.

   To avoid this filtering, the affected ITR encapsulates packets
   towards the locator of the P-ETR for non-LISP destinations.  Now the
   source address of the packets, as seen by the PE router is the ITR's
   locator, which will not fail the uRPF check.  The P-ETR then
   decapsulates and forwards the packets.

   The second use case is IPv4-to-IPv6 transition.  Service providers
   using older access network hardware, which only supports IPv4 can
   still offer IPv6 to their clients, by providing a CPE device running
   LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP
   sites, with IPv6-only locators.  Packets originating from the client
   LISP site for these destinations would be encapsulated towards the
   P-ETR's IPv4 locator.  The P-ETR is in a native IPv6 network,
   decapsulating and forwarding packets.  For non-LISP destination, the
   packet travels natively from the P-ETR.  For LISP destinations with
   IPv6-only locators, the packet will go through a P-ITR, in order to
   reach its destination.

   For more details on P-ETRs see the [RFC6832] draft.

   P-ETRs can be deployed by ISPs wishing to offer value-added services
   to their customers.  As is the case with P-ITRs, P-ETRs too may
   introduce path stretch (the ratio between the cost of the selected
   path and that of the optimal path).  Because of this the ISP needs to
   consider the tradeoff of using several devices, close to the
   customers, to minimize it, or few devices, farther away from the
   customers, minimizing cost instead.

   Since the deployment incentives for P-ITRs and P-ETRs are different,
   it is likely they will be deployed in separate devices, except for
   the CDN case, which may deploy both in a single device.

   In all cases, the existence of a P-ETR involves another step in the
   configuration of a LISP router.  CPE routers, which are typically
   configured by DHCP, stand to benefit most from P-ETRs.
   Autoconfiguration of the P-ETR locator could be achieved by a DHCP
   option, or adding a P-ETR field to either Map-Notifys or Map-Replies.

5.  Migration to LISP

   This section discusses a deployment architecture to support the
   migration to a LISP-enabled Internet.  The loosely defined terms of
   "early transition phase", "late transition phase", and "LISP Internet
   phase" refer to time periods when LISP sites are a minority, a
   majority, or represent all edge networks respectively.

5.1.  LISP+BGP

   For sites wishing to go LISP with their PI prefix the least
   disruptive way is to upgrade their border routers to support LISP,
   register the prefix into the LISP mapping system, but keep announcing
   it with BGP as well.  This way LISP sites will reach them over LISP,
   while legacy sites will be unaffected by the change.  The main
   disadvantage of this approach is that no decrease in the DFZ routing
   table size is achieved.  Still, just increasing the number of LISP
   sites is an important gain, as an increasing LISP/non-LISP site ratio
   may decrease the need for BGP-based traffic engineering that leads to
   prefix deaggregation.  That, in turn, may lead to a decrease in the
   DFZ size and churn in the late transition phase.

   This scenario is not limited to sites that already have their
   prefixes announced with BGP.  Newly allocated EID blocks could follow
   this strategy as well during the early LISP deployment phase,
   depending on the cost/benefit analysis of the individual networks.
   Since this leads to an increase in the DFZ size, the following
   architecture should be preferred for new allocations.

5.2.  Mapping Service Provider (MSP) P-ITR Service

   In addition to publishing their clients' registered prefixes in the
   mapping system, MSPs with enough transit capacity can offer them
   P-ITR service as a separate service.  This service is especially
   useful for new PI allocations, to sites without existing BGP
   infrastructure, that wish to avoid BGP altogether.  The MSP announces
   the prefix into the DFZ, and the client benefits from ingress traffic
   engineering without prefix deaggregation.  The downside of this
   scenario is adding path stretch.

   Routing all non-LISP ingress traffic through a third party which is
   not one of its ISPs is only feasible for sites with modest amounts of
   traffic (like those using the IPv6 tunnel broker services today),
   especially in the first stage of the transition to LISP, with a
   significant number of legacy sites.  This is because the handling of
   said traffic is likely to result in additional costs, which would be
   passed down to the client.  When the LISP/non-LISP site 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 aggregatable prefixes may lead to additional decrease,
   but quantifying this decrease is subject to future research study.

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
   sites.

   While it is possible for a PSP to manually configure each client's
   EID routes to be announced, this approach offers little flexibility
   and is not scalable.  This section presents a scalable architecture
   that offers automatic distribution of EID routes to LISP sites and
   service providers.

   The architecture requires no modification to existing LISP network
   elements, but it introduces a new (conceptual) network element, the
   EID Route Server, defined as a router that either propagates routes
   learned from other EID Route Servers, or it originates EID Routes.
   The EID-Routes that it originates are those that it is authoritative
   for.  It propagates these routes to Proxy-ITRs within the AS of the
   EID Route Server.  It is worth to note that a BGP capable router can
   be also considered as an EID Route Server.

   Further, an EID-Route is defined as a prefix originated via the Route
   Server of the mapping service provider, which should be aggregated if
   the MSP has multiple customers inside a single large continuous
   prefix.  This prefix is propagated to other P-ITRs both within the
   MSP and to other P-ITR operators it peers with.  EID Route Servers
   are operated either by the LISP site, MSPs or PSPs, and they may be
   collocated with a Map Server or P-ITR, but are a functionally
   discrete entity.  They distribute EID-Routes, using BGP, to other
   domains, according to policies set by participants.

                              MSP (AS64500)
                              RS ---> P-ITR
                               |        /
                               |  _.--./
                              ,-''    /`--.
             LISP site   ---,' |     v     `.
                           (   |   DFZ       )----- Mapping system
         non-LISP site   ----. |    ^      ,'
                              `--. /   _.-'
                               |  `--''
                               v /
                             P-ITR
                             PSP (AS64501)

            Figure 5: The P-ITR Route Distribution architecture

   The architecture described above decouples EID origination from route
   propagation, with the following benefits:

   o  Can accurately represent business relationships between P-ITR
      operators

   o  More mapping system agnostic

   o  Minor changes to P-ITR implementation, no changes to other
      components

   In the example in the figure we have a MSP providing services to the
   LISP site.  The LISP site does not run BGP, and gets an EID
   allocation directly from a RIR, or from the MSP, who may be a LIR.
   Existing PI allocations can be migrated as well.  The MSP ensures the
   presence of the prefix in the mapping system, and runs an EID Route
   Server to distribute it to P-ITR service providers.  Since the LISP
   site does not run BGP, the prefix will be originated with the AS
   number of the MSP.

   In the simple case depicted in Figure 5 the EID-Route of LISP site
   will be originated by the Route Server, and announced to the DFZ by
   the PSP's P-ITRs with AS path 64501 64500.  From that point on, the
   usual BGP dynamics apply.  This way, routes announced by P-ITR are
   still originated by the authoritative Route Server.  Note that the
   peering relationships between MSP/PSPs and those in the underlying
   forwarding plane may not be congruent, making the AS path to a P-ITR
   shorter than it is in reality.

   The non-LISP site will select the best path towards the EID-prefix,
   according to its local BGP policies.  Since AS-path length is usually
   an important metric for selecting paths, a careful placement of P-ITR
   could significantly reduce path-stretch between LISP and non-LISP
   sites.

   The architecture allows for flexible policies between MSP/PSPs.
   Consider the EID Route Server networks as control plane overlays,
   facilitating the implementation of policies necessary to reflect the
   business relationships between participants.  The results are then
   injected to the common underlying forwarding plane.  For example,
   some MSP/PSPs may agree to exchange EID-Prefixes and only announce
   them to each of their forwarding plane customers.  Global
   reachability of an EID-prefix depends on the MSP the LISP site buys
   service from, and is also subject to agreement between the mentioned
   parties.

   In terms of impact on the DFZ, this architecture results in a slower
   routing table increase for new allocations, since traffic engineering
   will be done at the LISP level.  For existing allocations migrating
   to LISP, the DFZ may decrease since MSPs may be able to aggregate the
   prefixes announced.

   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 aggregatable prefixes may lead to additional decrease,
   but quantifying this decrease is subject to future research study.

   The flexibility and scalability of this architecture does not come
   without a cost however: A PSP operator has to establish either
   transit or peering relationships to improve their connectivity.

5.4.  Migration Summary

   The following table presents the expected effects of the different
   transition scenarios during a certain phase on the DFZ routing table
   size:

    Phase            | LISP+BGP     | MSP P-ITR       | PITR-RD
    -----------------+--------------+-----------------+----------------
    Early transition | no change    | slower increase | slower increase
    Late transition  | may decrease | slower increase | slower increase
    LISP Internet    |             considerable decrease

   It is expected that PITR-RD will co-exist with LISP+BGP during the
   migration, with the latter being more popular in the early transition
   phase.  As the transition progresses and the MSP P-ITR and PITR-RD
   ecosystem gets more ubiquitous, LISP+BGP should become less
   attractive, slowing down the increase of the number of routes in the
   DFZ.

   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

   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].

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, Hannu Flinck, Paul
   Vinciguerra, Fred Templin, Brian Haberman, and everyone else who
   provided input.

9.  References

9.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,
              "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

   [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)",
              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-04 (work in progress),
              February 2013.

   [RFC4459]  Savola, P., "MTU and Fragmentation Issues with In-the-
              Network Tunneling", RFC 4459, April 2006.

   [RFC4786]  Abley, J. and K. Lindqvist, "Operation of Anycast
              Services", BCP 126, RFC 4786, December 2006.

   [RFC4984]  Meyer, D., Zhang, L., and K. Fall, "Report from the IAB
              Workshop on Routing and Addressing", RFC 4984,
              September 2007.

   [RFC6834]  Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
              Separation Protocol (LISP) Map-Versioning", RFC 6834,
              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.

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

   1.  Determine how many current physical service provider connections
       the customer has and their existing bandwidth and traffic
       engineering requirements.

       This information will determine the number of routing locators,
       and the priorities and weights that should be configured on the
       xTRs.

   2.  Make sure customer router has LISP capabilities.

       *  Check OS version of the CE router.  If LISP is an add-on,
          check if it is installed.

          This information can be used to determine if the platform is
          appropriate to support LISP, in order to determine if a
          software and/or hardware upgrade is required.

       *  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 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
       take place.

   5.  Validate member prefix allocation.

       This step is to check if the prefix used by the customer is a
       direct (Provider Independent), or if it is a prefix assigned by a
       physical service provider (Provider Aggregatable).  If the
       prefixes are assigned by other service providers then a Letter of
       Agreement is required to announce prefixes through the Proxy
       Service Provider.

   6.  Verify the member RLOCs and their reachability.

       This step ensures that the RLOCs configured on the CE router are
       in fact reachable and working.

   7.  Prepare for cut-over.

       *  If possible, have a host outside of all security and filtering
          policies connected to the console port of the edge router or
          switch.

       *  Make sure customer has access to the router in order to
          configure it.

A.2.  Customer Activating LISP Service

   1.  Customer configures LISP on CE router(s) from service provider
       recommended configuration.

       The LISP configuration consists of the EID prefix, the locators,
       and the weights and priorities of the mapping between the two
       values.  In addition, the xTR must be configured with Map
       Resolver(s), Map Server(s) and the shared key for registering to
       Map Server(s).  If required, Proxy-ETR(s) may be configured as
       well.

       In addition to the LISP configuration, the following:

       *  Ensure default route(s) to next-hop external neighbors are
          included and RLOCs are present in configuration.

       *  If two or more routers are used, ensure all RLOCs are included
          in the LISP configuration on all routers.

       *  It will be necessary to redistribute default route via IGP
          between the external routers.

   2.  When transition is ready perform a soft shutdown on existing eBGP
       peer session(s)

       *  From CE router, use LIG to ensure registration is successful.

       *  To verify LISP connectivity, find and ping LISP connected
          sites.  If possible, find ping destinations that are not
          covered by a prefix in the global BGP routing system, because
          PITRs may deliver the packets even if LISP connectivity is not
          working.  Traceroutes may help discover if this is the case.

       *  To verify connectivity to non-LISP sites, try accessing a
          landmark (e.g., a major Internet site) via a web browser.

A.3.  Cut-Over Provider Preparation and Changes

   1.  Verify site configuration and then active registration on Map
       Server(s)

       *  Authentication key

       *  EID prefix

   2.  Add EID space to map-cache on proxies

   3.  Add networks to BGP advertisement on proxies

       *  Modify route-maps/policies on P-xTRs

       *  Modify route policies on core routers (if non-connected
          member)

       *  Modify ingress policers on core routers

       *  Ensure route announcement in looking glass servers, RouteViews

   4.  Perform traffic verification test

       *  Ensure MTU handling is as expected (PMTUD working)

       *  Ensure proxy-ITR map-cache population

       *  Ensure access from traceroute/ping servers around Internet

       *  Use a looking glass, to check for external visibility of
          registration via several Map Resolvers

Authors' Addresses

   Lorand Jakab
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Email: lojakab@cisco.com

   Albert Cabellos-Aparicio
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: acabello@ac.upc.edu

   Florin Coras
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: fcoras@ac.upc.edu
   Jordi Domingo-Pascual
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: jordi.domingo@ac.upc.edu

   Darrel Lewis
   Cisco Systems
   170 Tasman Drive
   San Jose, CA  95134
   USA

   Email: darlewis@cisco.com
--------------090105050802010807060803 Content-Type: text/plain; charset=UTF-8; name="draft-ietf-lisp-deployment-08.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="draft-ietf-lisp-deployment-08.txt" Network Working Group L. Jakab Internet-Draft Cisco Systems Intended status: Informational A. Cabellos-Aparicio Expires: December 20, 2013 F. Coras J. Domingo-Pascual Technical University of Catalonia D. Lewis Cisco Systems June 18, 2013 LISP Network Element Deployment Considerations draft-ietf-lisp-deployment-08.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 provisions of BCP 78 and BCP 79. 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 December 20, 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 carefully, as they describe your rights and restrictions with respect Jakab, et al. Expires December 20, 2013 [Page 1] Internet-Draft LISP Deployment June 2013 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 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 7 2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 2.5. Tunnel Routers Behind NAT . . . . . . . . . . . . . . . . 10 2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 10 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.5.3. Additional Notes . . . . . . . . . . . . . . . . . . . 11 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 11 3. Map Resolvers and Map Servers . . . . . . . . . . . . . . . . 12 3.1. Map Servers . . . . . . . . . . . . . . . . . . . . . . . 12 3.2. Map Resolvers . . . . . . . . . . . . . . . . . . . . . . 13 4. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 14 4.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Migration to LISP . . . . . . . . . . . . . . . . . . . . . . 16 5.1. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2. Mapping Service Provider (MSP) P-ITR Service . . . . . . . 17 5.3. Proxy-ITR Route Distribution (PITR-RD) . . . . . . . . . . 17 5.4. Migration Summary . . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Appendix A. Step-by-Step Example BGP to LISP Migration Procedure . . . . . . . . . . . . . . . . . . . . . . 22 A.1. Customer Pre-Install and Pre-Turn-up Checklist . . . . . . 22 A.2. Customer Activating LISP Service . . . . . . . . . . . . . 23 A.3. Cut-Over Provider Preparation and Changes . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Jakab, et al. Expires December 20, 2013 [Page 2] Internet-Draft LISP Deployment June 2013 1. Introduction The Locator/Identifier Separation Protocol (LISP) is designed to address the scaling issues of the global Internet routing system identified in [RFC4984] by separating the current addressing scheme into Endpoint IDentifiers (EIDs) and Routing LOCators (RLOCs). The main protocol specification [RFC6830] describes how the separation is achieved, which new network elements are introduced, and details the packet formats for the data and control planes. LISP assumes that such separation is between the edge and core and uses mapping and encapsulation for forwarding. While the boundary between both is not strictly defined, one widely accepted definition 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. 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 networks. It is expected to evolve as LISP deployment progresses, and the described scenarios are better understood or new scenarios are discovered. Each subsection considers an element type, discussing the impact of deployment scenarios on the protocol specification. For definition of terms, please refer to the appropriate documents (as cited in the respective sections). 2. Tunnel Routers The device that is the gateway between the edge and the core is Jakab, et al. Expires December 20, 2013 [Page 3] Internet-Draft LISP Deployment June 2013 called a Tunnel Router (xTR), performing one or both of two separate functions: 1. Encapsulating packets originating from an end host to be transported over intermediary (transit) networks towards the other end-point of the communication 2. Decapsulating packets entering from intermediary (transit) networks, originated at a remote end host. The first function is performed by an Ingress Tunnel Router (ITR), the second by an Egress Tunnel Router (ETR). Section 8 of the main LISP specification [RFC6830] has a short discussion of where Tunnel Routers can be deployed and some of the associated advantages and disadvantages. This section adds more detail to the scenarios presented there, and provides additional scenarios as well. 2.1. Customer Edge The first scenario we discuss is customer edge, when xTR functionality is placed on the router(s) that connect the LISP site to its upstream(s), but are under its control. As such, this is the most common expected scenario for xTRs, and this document considers it the reference location, comparing the other scenarios to this one. ISP1 ISP2 | | | | +----+ +----+ +--|xTR1|--|xTR2|--+ | +----+ +----+ | | | | LISP site | +------------------+ Figure 1: xTRs at the customer edge From the LISP site perspective the main advantage of this type of deployment (compared to the one described in the next section) is having direct control over its ingress traffic engineering. This makes it easy to set up and maintain active/active, active/backup, or more complex TE policies, without involving third parties. Being under the same administrative control, reachability information of all ETRs is easier to synchronize, because the necessary control traffic can be allowed between the locators of the ETRs. A correct Jakab, et al. Expires December 20, 2013 [Page 4] Internet-Draft LISP Deployment June 2013 synchronous global view of the reachability status is thus available, and the Locator Status Bits (Loc-Status-Bits, defined in [RFC6830]) can be set correctly in the LISP data header of outgoing packets. By placing the tunnel router at the edge of the site, existing internal network configuration does not need to be modified. Firewall rules, router configurations and address assignments inside the LISP site remain unchanged. This helps with incremental deployment and allows a quick upgrade path to LISP. For larger sites with many external connections, distributed in geographically diverse points of presence (PoPs), and complex internal topology, it may however make more sense to both encapsulate and decapsulate as soon as possible, to benefit from the information in the IGP to choose the best path (see Section 2.3 for a discussion of this scenario). Another thing to consider when placing tunnel routers is MTU issues. Encapsulation increases the amount of overhead associated with each packet. This added overhead decreases the effective end-to-end path MTU (unless fragmentation and reassembly is used). 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 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 this can lead to important savings, since there is no need to upgrade the software (or hardware, if it's the case) at each client's location. Instead, they can upgrade the software (or hardware) on a few PE routers serving the customers. This scenario is depicted in Figure 2. Jakab, et al. Expires December 20, 2013 [Page 5] Internet-Draft LISP Deployment June 2013 +----------+ +------------------+ | ISP1 | | ISP2 | | | | | | +----+ | | +----+ +----+ | +--|xTR1|--+ +--|xTR2|--|xTR3|--+ +----+ +----+ +----+ | | | | | | +--<[LISP site]>---+-------+ Figure 2: xTR at the PE While this approach can make transition easy for customers and may be cheaper for providers, the LISP site loses one of the main benefits of LISP: ingress traffic engineering. Since the provider controls the ETRs, additional complexity would be needed to allow customers to modify their mapping entries. The problem is aggravated when the LISP site is multihomed. Consider the scenario in Figure 2: whenever a change to TE policies is required, the customer contacts both ISP1 and ISP2 to make the necessary changes on the routers (if they provide this possibility). It is however unlikely, that both ISPs will apply changes simultaneously, which may lead to inconsistent state for the mappings of the LISP site. Since the different upstream ISPs are usually competing business entities, the ETRs may even be configured to compete, either to attract all the traffic or to get no traffic. The former will happen if the customer pays per volume, the latter if the connectivity has a fixed price. A solution could be to have the mappings in the Map Server(s), and have their operator give control over the entries to customer, much like in the Domain Name System at the time of this writing. Additionally, since xTR1, xTR2, and xTR3 are in different administrative domains, locator reachability information is unlikely to be exchanged among them, making it difficult to set Loc-Status- Bits (LSB) correctly on encapsulated packets. Because of this, and due to the security concerns about LSB described in [I-D.ietf-lisp-threats] their use is discouraged without verifying ETR reachability through the mapping system or other means. Mapping versioning is another alternative [RFC6834]. Compared to the customer edge scenario, deploying LISP at the provider edge might have the advantage of diminishing potential MTU issues, because the tunnel router is closer to the core, where links typically have higher MTUs than edge network links. Jakab, et al. Expires December 20, 2013 [Page 6] Internet-Draft LISP Deployment June 2013 2.3. Split ITR/ETR In a simple LISP deployment, xTRs are located at the border of the LISP site (see Section 2.1). In this scenario packets are routed inside the domain according to the EID. However, more complex networks may want to route packets according to the destination RLOC. This would enable them to choose the best egress point. The LISP specification separates the ITR and ETR functionality and allows both entities to be deployed in separated network equipment. ITRs can be deployed closer to the host (i.e., access routers). This way packets are encapsulated as soon as possible, and egress point selection is driven by operational policy. In turn, ETRs can be deployed at the border routers of the network, and packets are decapsulated as soon as possible. Once decapsulated, packets are routed based on destination EID, according to internal routing policy. In the following figure we can see an example. The Source (S) transmits packets using its EID and in this particular case packets are encapsulated at ITR_1. The encapsulated packets are routed inside the domain according to the destination RLOC, and can egress the network through the best point (i.e., closer to the RLOC's AS). On the other hand, inbound packets are received by ETR_1 which decapsulates them. Then packets are routed towards S according to the EID, again following the best path. +---------------------------------------+ | | | +-------+ +-------+ +-------+ | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | | +-------+ | +-------+ +-------+ | +-+ | | | | |S| | IGP | | | +-+ | | | | +-------+ | +-------+ +-------+ | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | | +-------+ +-------+ +-------+ | | +---------------------------------------+ Figure 3: Split ITR/ETR Scenario This scenario has a set of implications: o The site must carry at least partial BGP routes in order to choose the best egress point, increasing the complexity of the network. However, this is usually already the case for LISP sites that Jakab, et al. Expires December 20, 2013 [Page 7] Internet-Draft LISP Deployment June 2013 would benefit from this scenario. o If the site is multihomed to different ISPs and any of the upstream ISPs are doing uRPF filtering, this scenario may become impractical. ITRs need to determine the exit ETR, for setting the correct source RLOC in the encapsulation header. This adds complexity and reliability concerns. 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 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. To lower the impact, the site could use a local caching Map Resolver. 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. 2.4. Inter-Service Provider Traffic Engineering At the time of this writing, if two ISPs want to control their ingress TE policies for transit traffic between them, they need to rely on existing BGP mechanisms. This typically means deaggregating prefixes to choose on which upstream link packets should 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. Typically, LISP is seen applicable only to stub networks, however the LISP protocol can be also applied in a recursive manner, providing service provider ingress/egress TE capabilities without impacting the DFZ table size. In order to implement this functionality with LISP consider the scenario depicted in Figure 4. The two ISPs willing to achieve Jakab, et al. Expires December 20, 2013 [Page 8] Internet-Draft LISP Deployment June 2013 ingress/egress TE are labeled as ISP_A and ISP_B, they are servicing Stub1 and Stub2 respectively, both are required to be LISP sites. In this scenario we assume that Stub1 and Stub2 are communicating and thus, ISP_A and ISP_B offer transit for such communications. ISP_A has RLOC_A1 and RLOC_A2 as upstream IP addresses while ISP_B has RLOC_B1 and RLOC_B2. The shared goal among ISP_A and ISP_B is to control the transit traffic flow between RLOC_A1/A2 and RLOC_B1/B2. _.--. Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub2 \ | R_A1|----,' `. ---|R_B1 | / --| | ( Transit ) | |-- ... .../ | R_A2|-----. ,' ---|R_B2 | \... ... +-------+ `--. _.-' +-------+ ... ... ISP_A `--'' ISP_B ... ... Figure 4: Inter-Service provider TE scenario Both ISPs deploy xTRs on on RLOC_A1/A2 and RLOC_B1/B2 respectively and reach a bilateral agreement to deploy their own private mapping system. This mapping system contains bindings between the RLOCs of Stub1 and Stub2 (owned by ISP_A and ISP_B respectively) and RLOC_A1/A2 and RLOC_B1/B2. Such bindings are in fact the TE policies between both ISPs and the convergence time is expected to be fast, since ISPs only have to update/query a mapping to/from the database. The packet flow is as follows. First, a packet originated at Stub1 towards Stub2 is LISP encapsulated by Stub1's xTR. The xTR of ISP_A reencapsulates it and, according to the TE policies stored in the private mapping system, the ISP_A xTR chooses RLOC_B1 or RLOC_B2 as the reencapsulation destination. Note that the packet transits between ISP_A and ISP_B double-encapsulated. Upon reception at the xTR of ISP_B the packet is decapsulated and sent towards Stub2 which performs the last decapsulation. This deployment scenario, which uses recursive LISP, includes two important caveats. First, it is intended to be deployed between only two ISPs. If more than two ISPs use this approach, then the xTRs deployed at the participating ISPs must either query multiple mapping systems, or the ISPs must agree on a common shared mapping system. Furthemore, keeping this deployment scenario restricted to only two ISPs maintains the solution scalable, given that only two entities need to agree on using recursive LISP, and only one private mapping system is involved. Second, the scenario is only recommended for ISPs providing connectivity to LISP sites, such that source RLOCs of packets to be reencapsulated belong to said ISP. Otherwise the participating ISPs Jakab, et al. Expires December 20, 2013 [Page 9] Internet-Draft LISP Deployment June 2013 must register prefixes they do not own in the above mentioned private mapping system. Failure to follow these recommendations may lead to operational and security issues when deploying this scenario. Besides these recommendations, the main disadvantages of this deployment case are: o Extra LISP header is needed. This increases the packet size and requires that the MTU between both ISPs accommodates double- encapsulated packets. 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 additional lookup latency, unless a push based mapping system is used for the private mapping system. o The operational overhead of maintaining the shared mapping database. 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. Map-Requests sent by an ITR, which create the state in the NAT table, have a different 5-tuple in the IP header than the Map-Reply generated by the authoritative ETR. Since the source address of this packet is different from the destination address of the request packet, no state will be matched in the NAT table and the packet will be dropped. To avoid this, the NAT device has to do the following: o Send all UDP packets with source port 4342, regardless of the destination port, to the RLOC of the ITR. The most simple way to achieve this is configuring 1:1 NAT mode from the external RLOC of the NAT device to the ITR's RLOC (Called "DMZ" mode in consumer broadband routers). o Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in the payload. This setup supports only a single ITR behind the NAT device. Jakab, et al. Expires December 20, 2013 [Page 10] Internet-Draft LISP Deployment June 2013 2.5.2. ETR An ETR placed behind NAT is reachable from the outside by the Internet-facing locator of the NAT device. It needs to know this locator (and configure a loopback interface with it), so that it can use it in Map-Reply and Map-Register messages. Thus support for dynamic locators for the mapping database is needed in LISP equipment. Again, only one ETR behind the NAT device is supported. 2.5.3. Additional Notes An implication of the issues described above is that LISP sites with xTRs can not be behind carrier based NATs, since two different sites would collide on the port forwarding. An alternative to static hole- punching to explore is the use of the Port Control Protocol (PCP) [RFC6887]. 2.6. Summary and Feature Matrix The following table gives a quick overview of the features supported by each of the deployment scenarios discussed above (marked with an "x") in the appropriate column: "CE" for customer edge, "PE" for provider edge, "Split" for split ITR/ETR, and "Recursive" for inter- service provider traffic engineering. The discussed features include: Control of ingress TE: The scenario allows the LISP site to easily control LISP ingress traffic engineering policies. No modifcations to existing int. network infrastruncture: The scenario doesn't require the LISP site to modify internal network configurations. Loc-Status-Bits sync: The scenario allows easy synchronization of the Locator Status Bits. MTU/PMTUD issues minimized: The scenario minimizes potential MTU and Path MTU Discovery issues. 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 Jakab, et al. Expires December 20, 2013 [Page 11] Internet-Draft LISP Deployment June 2013 MTU/PMTUD issues minimized - x - - 3. Map Resolvers and Map Servers Map Resolvers and Map Servers make up the LISP mapping system and provide a means to find authoritative EID-to-RLOC mapping information, conforming to [RFC6833]. They are meant to be deployed in RLOC space, and their operation behind NAT is not supported. 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 matches an EID-prefix for which it is authoritative for, and then re- encapsulates and forwards it to a matching ETR. Map Server functionality is described in detail in [RFC6833]. The Map Server is provided by a Mapping Service Provider (MSP). The MSP participates in the global distributed mapping database infrastructure, by setting up connections to other participants, 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. In all cases, the MSP configures its Map Server(s) to publish the prefixes of its clients in the distributed mapping database and start encapsulating and forwarding Map-Requests to the ETRs of the AS. These ETRs register their prefix(es) with the Map Server(s) through periodic authenticated Map-Register messages. In this context, for some LISP sites, there is a need for mechanisms to: o Automatically distribute EID prefix(es) shared keys between the ETRs and the EID-registrar Map Server. o Dynamically obtain the address of the Map Server in the ETR of the AS. The Map Server plays a key role in the reachability of the EID- prefixes it is serving. On the one hand it is publishing these prefixes into the distributed mapping database and on the other hand it is encapsulating and forwarding Map-Requests to the authoritative Jakab, et al. Expires December 20, 2013 [Page 12] Internet-Draft LISP Deployment June 2013 ETRs of these prefixes. ITRs encapsulating towards EIDs under the responsibility of a failed Map Server will be unable to look up any of their covering prefixes. The only exception are the ITRs that already contain the mappings in their local cache. In this case ITRs can reach ETRs until the entry expires (typically 24 hours). For this reason, redundant Map Server deployments are desirable. A set of Map Servers providing high-availability service to the same set of prefixes is called a redundancy group. ETRs are configured to send Map-Register messages to all Map Servers in the redundancy group. The configuration for fail-over (or load-balancing, if desired) among the members of the group depends on the technology behind the mapping system being deployed. Since ALT is based on BGP and DDT was inspired from DNS, deployments can leverage current industry best practices for redundancy in BGP and DNS. These best practices are out of the scope of this document. Additionally, if a Map Server has no reachability for any ETR serving a given EID block, it should not originate that block into the mapping system. 3.2. Map Resolvers A Map Resolver is a network infrastructure component which accepts LISP encapsulated Map-Requests, typically from an ITR, and finds the appropriate EID-to-RLOC mapping by either consulting its local cache or by consulting the distributed mapping database. Map Resolver functionality is described in detail in [RFC6833]. Anyone with access to the distributed mapping database can set up a Map Resolver and provide EID-to-RLOC mapping lookup service. Database access setup is mapping system specific. For performance reasons, it is recommended that LISP sites use Map Resolvers that are topologically close to their ITRs. ISPs supporting LISP will provide this service to their customers, possibly restricting access to their user base. LISP sites not in this position can use open access Map Resolvers, if available. However, regardless of the availability of open access resolvers, the MSP providing the Map Server(s) for a LISP site should also make available Map Resolver(s) for the use of that site. In medium to large-size ASes, ITRs must be configured with the RLOC of a Map Resolver, operation which can be done manually. However, in Small Office Home Office (SOHO) scenarios a mechanism for autoconfiguration should be provided. One solution to avoid manual configuration in LISP sites of any size is the use of anycast RLOCs [RFC4786] for Map Resolvers similar to Jakab, et al. Expires December 20, 2013 [Page 13] Internet-Draft LISP Deployment June 2013 the DNS root server infrastructure. Since LISP uses UDP encapsulation, the use of anycast would not affect reliability. LISP routers are then shipped with a preconfigured list of well know Map Resolver RLOCs, which can be edited by the network administrator, if needed. The use of anycast also helps improve mapping lookup performance. Large MSPs can increase the number and geographical diversity of their Map Resolver infrastructure, using a single anycasted RLOC. Once LISP deployment is advanced enough, very large content providers may also be interested running this kind of setup, to ensure minimal connection setup latency for those connecting to their network from LISP sites. While Map Servers and Map Resolvers implement different functionalities within the LISP mapping system, they can coexist on the same device. For example, MSPs offering both services, can deploy a single Map Resolver/Map Server in each PoP where they have a presence. 4. Proxy Tunnel Routers 4.1. P-ITR Proxy Ingress Tunnel Routers (P-ITRs) are part of the non-LISP/LISP transition mechanism, allowing non-LISP sites to reach LISP sites. They announce via BGP certain EID prefixes (aggregated, whenever possible) to attract traffic from non-LISP sites towards EIDs in the covered range. They do the mapping system lookup, and encapsulate received packets towards the appropriate ETR. Note that for the reverse path LISP sites can reach non-LISP sites simply by not encapsulating traffic. See [RFC6832] for a detailed description of P-ITR functionality. The success of new protocols depends greatly on their ability to maintain backwards compatibility and inter-operate with the protocol(s) they intend to enhance or replace, and on the incentives to deploy the necessary new software or equipment. A LISP site needs an interworking mechanism to be reachable from non-LISP sites. A P-ITR can fulfill this role, enabling early adopters to see the benefits of LISP, similar to tunnel brokers helping the transition from IPv4 to IPv6. A site benefits from new LISP functionality (proportionally with existing global LISP deployment) when going LISP, so it has the incentives to deploy the necessary tunnel routers. In order to be reachable from non-LISP sites it has two options: keep announcing its prefix(es) with BGP, or have a P-ITR announce prefix(es) covering them. Jakab, et al. Expires December 20, 2013 [Page 14] Internet-Draft LISP Deployment June 2013 If the goal of reducing the DFZ routing table size is to be reached, the second option is preferred. Moreover, the second option allows LISP-based ingress traffic engineering from all sites. However, the placement of P-ITRs significantly influences performance and deployment incentives. Section 5 is dedicated to the migration to a LISP-enabled Internet, and includes deployment scenarios for P-ITRs. 4.2. P-ETR In contrast to P-ITRs, P-ETRs are not required for the correct functioning of all LISP sites. There are two cases, where they can be of great help: o LISP sites with unicast reverse path forwarding (uRPF) restrictions, and o Communication between sites using different address family RLOCs. In the first case, uRPF filtering is applied at their upstream PE router. When forwarding traffic to non-LISP sites, an ITR does not encapsulate packets, leaving the original IP headers intact. As a result, packets will have EIDs in their source address. Since we are discussing the transition period, we can assume that a prefix covering the EIDs belonging to the LISP site is advertised to the global routing tables by a P-ITR, and the PE router has a route towards it. However, the next hop will not be on the interface towards the CE router, so non-encapsulated packets will fail uRPF checks. To avoid this filtering, the affected ITR encapsulates packets towards the locator of the P-ETR for non-LISP destinations. Now the source address of the packets, as seen by the PE router is the ITR's locator, which will not fail the uRPF check. The P-ETR then decapsulates and forwards the packets. The second use case is IPv4-to-IPv6 transition. Service providers using older access network hardware, which only supports IPv4 can still offer IPv6 to their clients, by providing a CPE device running LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP sites, with IPv6-only locators. Packets originating from the client LISP site for these destinations would be encapsulated towards the P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, decapsulating and forwarding packets. For non-LISP destination, the packet travels natively from the P-ETR. For LISP destinations with IPv6-only locators, the packet will go through a P-ITR, in order to reach its destination. For more details on P-ETRs see the [RFC6832] draft. Jakab, et al. Expires December 20, 2013 [Page 15] Internet-Draft LISP Deployment June 2013 P-ETRs can be deployed by ISPs wishing to offer value-added services to their customers. As is the case with P-ITRs, P-ETRs too may introduce path stretch (the ratio between the cost of the selected path and that of the optimal path). Because of this the ISP needs to consider the tradeoff of using several devices, close to the customers, to minimize it, or few devices, farther away from the customers, minimizing cost instead. Since the deployment incentives for P-ITRs and P-ETRs are different, it is likely they will be deployed in separate devices, except for the CDN case, which may deploy both in a single device. In all cases, the existence of a P-ETR involves another step in the configuration of a LISP router. CPE routers, which are typically configured by DHCP, stand to benefit most from P-ETRs. Autoconfiguration of the P-ETR locator could be achieved by a DHCP option, or adding a P-ETR field to either Map-Notifys or Map-Replies. 5. Migration to LISP This section discusses a deployment architecture to support the migration to a LISP-enabled Internet. The loosely defined terms of "early transition phase", "late transition phase", and "LISP Internet phase" refer to time periods when LISP sites are a minority, a majority, or represent all edge networks respectively. 5.1. LISP+BGP For sites wishing to go LISP with their PI prefix the least disruptive way is to upgrade their border routers to support LISP, register the prefix into the LISP mapping system, but keep announcing it with BGP as well. This way LISP sites will reach them over LISP, while legacy sites will be unaffected by the change. The main disadvantage of this approach is that no decrease in the DFZ routing table size is achieved. Still, just increasing the number of LISP sites is an important gain, as an increasing LISP/non-LISP site ratio may decrease the need for BGP-based traffic engineering that leads to prefix deaggregation. That, in turn, may lead to a decrease in the DFZ size and churn in the late transition phase. This scenario is not limited to sites that already have their prefixes announced with BGP. Newly allocated EID blocks could follow this strategy as well during the early LISP deployment phase, depending on the cost/benefit analysis of the individual networks. Since this leads to an increase in the DFZ size, the following architecture should be preferred for new allocations. Jakab, et al. Expires December 20, 2013 [Page 16] Internet-Draft LISP Deployment June 2013 5.2. Mapping Service Provider (MSP) P-ITR Service In addition to publishing their clients' registered prefixes in the mapping system, MSPs with enough transit capacity can offer them P-ITR service as a separate service. This service is especially useful for new PI allocations, to sites without existing BGP infrastructure, that wish to avoid BGP altogether. The MSP announces the prefix into the DFZ, and the client benefits from ingress traffic engineering without prefix deaggregation. The downside of this scenario is adding path stretch. Routing all non-LISP ingress traffic through a third party which is not one of its ISPs is only feasible for sites with modest amounts of traffic (like those using the IPv6 tunnel broker services today), especially in the first stage of the transition to LISP, with a significant number of legacy sites. This is because the handling of said traffic is likely to result in additional costs, which would be passed down to the client. When the LISP/non-LISP site 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 aggregatable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study. 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 sites. While it is possible for a PSP to manually configure each client's EID routes to be announced, this approach offers little flexibility and is not scalable. This section presents a scalable architecture that offers automatic distribution of EID routes to LISP sites and service providers. The architecture requires no modification to existing LISP network elements, but it introduces a new (conceptual) network element, the Jakab, et al. Expires December 20, 2013 [Page 17] Internet-Draft LISP Deployment June 2013 EID Route Server, defined as a router that either propagates routes learned from other EID Route Servers, or it originates EID Routes. The EID-Routes that it originates are those that it is authoritative for. It propagates these routes to Proxy-ITRs within the AS of the EID Route Server. It is worth to note that a BGP capable router can be also considered as an EID Route Server. Further, an EID-Route is defined as a prefix originated via the Route Server of the mapping service provider, which should be aggregated if the MSP has multiple customers inside a single large continuous prefix. This prefix is propagated to other P-ITRs both within the MSP and to other P-ITR operators it peers with. EID Route Servers are operated either by the LISP site, MSPs or PSPs, and they may be collocated with a Map Server or P-ITR, but are a functionally discrete entity. They distribute EID-Routes, using BGP, to other domains, according to policies set by participants. MSP (AS64500) RS ---> P-ITR | / | _.--./ ,-'' /`--. LISP site ---,' | v `. ( | DFZ )----- Mapping system non-LISP site ----. | ^ ,' `--. / _.-' | `--'' v / P-ITR PSP (AS64501) Figure 5: The P-ITR Route Distribution architecture The architecture described above decouples EID origination from route propagation, with the following benefits: o Can accurately represent business relationships between P-ITR operators o More mapping system agnostic o Minor changes to P-ITR implementation, no changes to other components In the example in the figure we have a MSP providing services to the LISP site. The LISP site does not run BGP, and gets an EID allocation directly from a RIR, or from the MSP, who may be a LIR. Existing PI allocations can be migrated as well. The MSP ensures the Jakab, et al. Expires December 20, 2013 [Page 18] Internet-Draft LISP Deployment June 2013 presence of the prefix in the mapping system, and runs an EID Route Server to distribute it to P-ITR service providers. Since the LISP site does not run BGP, the prefix will be originated with the AS number of the MSP. In the simple case depicted in Figure 5 the EID-Route of LISP site will be originated by the Route Server, and announced to the DFZ by the PSP's P-ITRs with AS path 64501 64500. From that point on, the usual BGP dynamics apply. This way, routes announced by P-ITR are still originated by the authoritative Route Server. Note that the peering relationships between MSP/PSPs and those in the underlying forwarding plane may not be congruent, making the AS path to a P-ITR shorter than it is in reality. The non-LISP site will select the best path towards the EID-prefix, according to its local BGP policies. Since AS-path length is usually an important metric for selecting paths, a careful placement of P-ITR could significantly reduce path-stretch between LISP and non-LISP sites. The architecture allows for flexible policies between MSP/PSPs. Consider the EID Route Server networks as control plane overlays, facilitating the implementation of policies necessary to reflect the business relationships between participants. The results are then injected to the common underlying forwarding plane. For example, some MSP/PSPs may agree to exchange EID-Prefixes and only announce them to each of their forwarding plane customers. Global reachability of an EID-prefix depends on the MSP the LISP site buys service from, and is also subject to agreement between the mentioned parties. In terms of impact on the DFZ, this architecture results in a slower routing table increase for new allocations, since traffic engineering will be done at the LISP level. For existing allocations migrating to LISP, the DFZ may decrease since MSPs may be able to aggregate the prefixes announced. 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 aggregatable prefixes may lead to additional decrease, but quantifying this decrease is subject to future research study. The flexibility and scalability of this architecture does not come without a cost however: A PSP operator has to establish either transit or peering relationships to improve their connectivity. Jakab, et al. Expires December 20, 2013 [Page 19] Internet-Draft LISP Deployment June 2013 5.4. Migration Summary The following table presents the expected effects of the different transition scenarios during a certain phase on the DFZ routing table size: Phase | LISP+BGP | MSP P-ITR | PITR-RD -----------------+--------------+-----------------+---------------- Early transition | no change | slower increase | slower increase Late transition | may decrease | slower increase | slower increase LISP Internet | considerable decrease It is expected that PITR-RD will co-exist with LISP+BGP during the migration, with the latter being more popular in the early transition phase. As the transition progresses and the MSP P-ITR and PITR-RD ecosystem gets more ubiquitous, LISP+BGP should become less attractive, slowing down the increase of the number of routes in the DFZ. 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 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]. 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, Hannu Flinck, Paul Vinciguerra, Fred Templin, Brian Haberman, and everyone else who provided input. Jakab, et al. Expires December 20, 2013 [Page 20] Internet-Draft LISP Deployment June 2013 9. References 9.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, "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 [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)", 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-04 (work in progress), February 2013. [RFC4459] Savola, P., "MTU and Fragmentation Issues with In-the- Network Tunneling", RFC 4459, April 2006. [RFC4786] Abley, J. and K. Lindqvist, "Operation of Anycast Services", BCP 126, RFC 4786, December 2006. [RFC4984] Meyer, D., Zhang, L., and K. Fall, "Report from the IAB Workshop on Routing and Addressing", RFC 4984, September 2007. [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID Separation Protocol (LISP) Map-Versioning", RFC 6834, January 2013. [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, Jakab, et al. Expires December 20, 2013 [Page 21] Internet-Draft LISP Deployment June 2013 "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. 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 1. Determine how many current physical service provider connections the customer has and their existing bandwidth and traffic engineering requirements. This information will determine the number of routing locators, and the priorities and weights that should be configured on the xTRs. 2. Make sure customer router has LISP capabilities. * Check OS version of the CE router. If LISP is an add-on, check if it is installed. This information can be used to determine if the platform is appropriate to support LISP, in order to determine if a software and/or hardware upgrade is required. * 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 Jakab, et al. Expires December 20, 2013 [Page 22] Internet-Draft LISP Deployment June 2013 * 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 take place. 5. Validate member prefix allocation. This step is to check if the prefix used by the customer is a direct (Provider Independent), or if it is a prefix assigned by a physical service provider (Provider Aggregatable). If the prefixes are assigned by other service providers then a Letter of Agreement is required to announce prefixes through the Proxy Service Provider. 6. Verify the member RLOCs and their reachability. This step ensures that the RLOCs configured on the CE router are in fact reachable and working. 7. Prepare for cut-over. * If possible, have a host outside of all security and filtering policies connected to the console port of the edge router or switch. * Make sure customer has access to the router in order to configure it. A.2. Customer Activating LISP Service 1. Customer configures LISP on CE router(s) from service provider recommended configuration. The LISP configuration consists of the EID prefix, the locators, and the weights and priorities of the mapping between the two values. In addition, the xTR must be configured with Map Resolver(s), Map Server(s) and the shared key for registering to Map Server(s). If required, Proxy-ETR(s) may be configured as well. Jakab, et al. Expires December 20, 2013 [Page 23] Internet-Draft LISP Deployment June 2013 In addition to the LISP configuration, the following: * Ensure default route(s) to next-hop external neighbors are included and RLOCs are present in configuration. * If two or more routers are used, ensure all RLOCs are included in the LISP configuration on all routers. * It will be necessary to redistribute default route via IGP between the external routers. 2. When transition is ready perform a soft shutdown on existing eBGP peer session(s) * From CE router, use LIG to ensure registration is successful. * To verify LISP connectivity, find and ping LISP connected sites. If possible, find ping destinations that are not covered by a prefix in the global BGP routing system, because PITRs may deliver the packets even if LISP connectivity is not working. Traceroutes may help discover if this is the case. * To verify connectivity to non-LISP sites, try accessing a landmark (e.g., a major Internet site) via a web browser. A.3. Cut-Over Provider Preparation and Changes 1. Verify site configuration and then active registration on Map Server(s) * Authentication key * EID prefix 2. Add EID space to map-cache on proxies 3. Add networks to BGP advertisement on proxies * Modify route-maps/policies on P-xTRs * Modify route policies on core routers (if non-connected member) * Modify ingress policers on core routers * Ensure route announcement in looking glass servers, RouteViews Jakab, et al. Expires December 20, 2013 [Page 24] Internet-Draft LISP Deployment June 2013 4. Perform traffic verification test * Ensure MTU handling is as expected (PMTUD working) * Ensure proxy-ITR map-cache population * Ensure access from traceroute/ping servers around Internet * Use a looking glass, to check for external visibility of registration via several Map Resolvers Authors' Addresses Lorand Jakab Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: lojakab@cisco.com Albert Cabellos-Aparicio Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain Email: acabello@ac.upc.edu Florin Coras Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain Email: fcoras@ac.upc.edu Jakab, et al. Expires December 20, 2013 [Page 25] Internet-Draft LISP Deployment June 2013 Jordi Domingo-Pascual Technical University of Catalonia C/Jordi Girona, s/n BARCELONA 08034 Spain Email: jordi.domingo@ac.upc.edu Darrel Lewis Cisco Systems 170 Tasman Drive San Jose, CA 95134 USA Email: darlewis@cisco.com Jakab, et al. Expires December 20, 2013 [Page 26] --------------090105050802010807060803-- From brian@innovationslab.net Tue Jun 18 05:55:14 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8126C21F9E7E for ; Tue, 18 Jun 2013 05:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.616 X-Spam-Level: X-Spam-Status: No, score=-102.616 tagged_above=-999 required=5 tests=[AWL=-0.017, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T7DKwy-aOkfR for ; Tue, 18 Jun 2013 05:55:06 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9813121F9E7B for ; Tue, 18 Jun 2013 05:54:35 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 6147288114; Tue, 18 Jun 2013 05:54:35 -0700 (PDT) Received: from 10252371.rudm1.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id E9F3A13680CF; Tue, 18 Jun 2013 05:54:34 -0700 (PDT) Message-ID: <51C0588B.4040207@innovationslab.net> Date: Tue, 18 Jun 2013 08:54:35 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Lori Jakab References: <5192763F.2010205@innovationslab.net> <51A39293.9000506@cisco.com> <51A4B85D.1070107@innovationslab.net> <51A75469.6030009@ac.upc.edu> <51A759BC.3070908@innovationslab.net> <51A75BAC.60809@ac.upc.edu> <51ADDAAD.3050300@ac.upc.edu> <51AF82A4.6040506@innovationslab.net> <51C04438.9070807@ac.upc.edu> In-Reply-To: <51C04438.9070807@ac.upc.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-deployment@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 12:55:14 -0000 The new text in section 2.4 is (in general) fine. If there are no objections from the WG, you can submit this version and we can move to the next step in the publication process. Regards, Brian On 6/18/13 7:27 AM, Lori Jakab wrote: > Hi Brian, all, > > Sorry for the long delay, here's updated text for section 2.4. As > previously, I attached both the diff from the previous revision I sent > to the list, and the full draft. > > Best regards, > -Lori (on behalf of the authors) > > On 06/05/2013 09:25 PM, Brian Haberman wrote: >> Hi Lori, >> These changes look fine to me. I will await updated text for the >> remaining open comment and any feedback from the WG on these changes. >> >> Regards, >> Brian >> >> On 6/4/13 8:16 AM, Lori Jakab wrote: >>> Hi Brian, WG members, >>> >>> Please find attached a revised draft, and the diff from the -07 version. >>> We responded with changes to all the comments in the AD review, except >>> for #7.1, for which we are preparing revised text (Section 2.4). Let us >>> know if the proposed changes in this revision satisfactorily address the >>> rest of the comments. >>> >>> Best regards, >>> -Lori Jakab >>> >>> On 05/30/2013 05:01 PM, Lori Jakab wrote: >>>> On 05/30/2013 04:53 PM, Brian Haberman wrote: >>>>> On 5/30/13 9:30 AM, Lori Jakab wrote: >>>>>> [...] >>>>>> >>>>>>>>> 13. Section 5.1 >>>>>>>>> >>>>>>>>> * I would like to see some justification for the statement that >>>>>>>>> the >>>>>>>>> increase in LISP deployment will reduce the need for BGP-based >>>>>>>>> TE. I >>>>>>>>> can envision some scenarios where LISP could increase the >>>>>>>>> BGP-based TE >>>>>>>>> in order to access the "correct" ETR (or P-ETR). Is there some >>>>>>>>> studies >>>>>>>>> that back up this claim? >>>>>>>> I'm not aware of any conclusive study on this subject, that's >>>>>>>> why we >>>>>>>> worded the statement "may lead to a decrease" and explicitly >>>>>>>> mentioned >>>>>>>> the "late transition phase", when most sites use LISP. >>>>>>>> >>>>>>> But, it does not say "may lead to a decrease", it says "will slowly >>>>>>> decrease the need..." and that sounds like a definitive claim. >>>>>> Would s/will/may/ resolve your concern? >>>>>> >>>>> How about "may decrease the need"? That way, you don't have to leave >>>>> the reader wondering about the speed of the possible reduction. >>>> Sounds good, thank you. >>>> >>>> Regards, >>>> -Lori >>>> >>>>> Regards, >>>>> Brian >>>>> >>> >> > From ljakab@ac.upc.edu Tue Jun 18 06:25:44 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B2721F935A for ; Tue, 18 Jun 2013 06:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fkwnsg-8dlUI for ; Tue, 18 Jun 2013 06:25:38 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 1E00821F9DF5 for ; Tue, 18 Jun 2013 06:25:29 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r5IDPSga019240; Tue, 18 Jun 2013 15:25:28 +0200 Received: from [10.81.80.7] (unknown [92.82.46.64]) by gw.ac.upc.edu (Postfix) with ESMTP id CBA826B01C6; Tue, 18 Jun 2013 15:25:27 +0200 (CEST) Message-ID: <51C05FC7.4020902@ac.upc.edu> Date: Tue, 18 Jun 2013 16:25:27 +0300 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Brian Haberman References: <5192763F.2010205@innovationslab.net> <51A39293.9000506@cisco.com> <51A4B85D.1070107@innovationslab.net> <51A75469.6030009@ac.upc.edu> <51A759BC.3070908@innovationslab.net> <51A75BAC.60809@ac.upc.edu> <51ADDAAD.3050300@ac.upc.edu> <51AF82A4.6040506@innovationslab.net> <51C04438.9070807@ac.upc.edu> <51C0588B.4040207@innovationslab.net> In-Reply-To: <51C0588B.4040207@innovationslab.net> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-deployment@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 13:25:45 -0000 On 06/18/2013 03:54 PM, Brian Haberman wrote: > The new text in section 2.4 is (in general) fine. If there are no > objections from the WG, you can submit this version and we can move to > the next step in the publication process. Thank you, Brian! Best regards, -Lori > > Regards, > Brian > > On 6/18/13 7:27 AM, Lori Jakab wrote: >> Hi Brian, all, >> >> Sorry for the long delay, here's updated text for section 2.4. As >> previously, I attached both the diff from the previous revision I sent >> to the list, and the full draft. >> >> Best regards, >> -Lori (on behalf of the authors) >> >> On 06/05/2013 09:25 PM, Brian Haberman wrote: >>> Hi Lori, >>> These changes look fine to me. I will await updated text for the >>> remaining open comment and any feedback from the WG on these changes. >>> >>> Regards, >>> Brian >>> >>> On 6/4/13 8:16 AM, Lori Jakab wrote: >>>> Hi Brian, WG members, >>>> >>>> Please find attached a revised draft, and the diff from the -07 >>>> version. >>>> We responded with changes to all the comments in the AD review, except >>>> for #7.1, for which we are preparing revised text (Section 2.4). >>>> Let us >>>> know if the proposed changes in this revision satisfactorily >>>> address the >>>> rest of the comments. >>>> >>>> Best regards, >>>> -Lori Jakab >>>> >>>> On 05/30/2013 05:01 PM, Lori Jakab wrote: >>>>> On 05/30/2013 04:53 PM, Brian Haberman wrote: >>>>>> On 5/30/13 9:30 AM, Lori Jakab wrote: >>>>>>> [...] >>>>>>> >>>>>>>>>> 13. Section 5.1 >>>>>>>>>> >>>>>>>>>> * I would like to see some justification for the statement that >>>>>>>>>> the >>>>>>>>>> increase in LISP deployment will reduce the need for BGP-based >>>>>>>>>> TE. I >>>>>>>>>> can envision some scenarios where LISP could increase the >>>>>>>>>> BGP-based TE >>>>>>>>>> in order to access the "correct" ETR (or P-ETR). Is there some >>>>>>>>>> studies >>>>>>>>>> that back up this claim? >>>>>>>>> I'm not aware of any conclusive study on this subject, that's >>>>>>>>> why we >>>>>>>>> worded the statement "may lead to a decrease" and explicitly >>>>>>>>> mentioned >>>>>>>>> the "late transition phase", when most sites use LISP. >>>>>>>>> >>>>>>>> But, it does not say "may lead to a decrease", it says "will >>>>>>>> slowly >>>>>>>> decrease the need..." and that sounds like a definitive claim. >>>>>>> Would s/will/may/ resolve your concern? >>>>>>> >>>>>> How about "may decrease the need"? That way, you don't have to >>>>>> leave >>>>>> the reader wondering about the speed of the possible reduction. >>>>> Sounds good, thank you. >>>>> >>>>> Regards, >>>>> -Lori >>>>> >>>>>> Regards, >>>>>> Brian >>>>>> >>>> >>> >> > From arnatal@ac.upc.edu Wed Jun 19 04:24:19 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F50E21F9A33 for ; Wed, 19 Jun 2013 04:24:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fVte4eYcYCr3 for ; Wed, 19 Jun 2013 04:24:14 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6F09F21F9A1E for ; Wed, 19 Jun 2013 04:24:12 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r5JBOBVl020402 for ; Wed, 19 Jun 2013 13:24:11 +0200 Received: from mail-la0-f43.google.com (mail-la0-f43.google.com [209.85.215.43]) by gw.ac.upc.edu (Postfix) with ESMTP id 8F7DC6B0211 for ; Wed, 19 Jun 2013 13:24:10 +0200 (CEST) Received: by mail-la0-f43.google.com with SMTP id gw10so4464474lab.2 for ; Wed, 19 Jun 2013 04:24:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=n/Goc+mYjr/wj8u4nRmsTSLJ8KfHOIL4nP3iOXlnEC0=; b=aCSt+FXVteWh5WB8pbc7bWXHcVnXuLqEAo+NkYtpT+t6SwqbygRBne4rBRN1qSfoBv a3zeyaZtAKvS7kY/GRET+2wC54AhgauYkOSm4ecE31LEW9OM+9GQa8Cx8jj+Dpi8yxhT lL3tiS0kDClmVJGpa3/0H0XYsvgz57HUgwsjxL7QM402zTxqLW2oTFrFyHmHzkvGmJ0x 5OuVaLGgER4Es0KBFMWjvKZpdNNJRdiB/6b7D6kLhVuRzLAlFOG2n/DHkti09k4qv5ga DFwO9tqmKppKXOfQQf5c+pf93EoNhqLk0Gxx0xA6ZVm1u94C3xUoSy6h+DxU+YlFvN12 Mw+Q== X-Received: by 10.112.150.68 with SMTP id ug4mr3049784lbb.81.1371641050490; Wed, 19 Jun 2013 04:24:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.139.233 with HTTP; Wed, 19 Jun 2013 04:23:50 -0700 (PDT) From: Alberto Rodriguez-Natal Date: Wed, 19 Jun 2013 13:23:50 +0200 Message-ID: To: lisp@ietf.org, lisp-beta@external.cisco.com, lispers@cisco.com, lisp-ops@external.cisco.com Content-Type: multipart/alternative; boundary=047d7b342d4892ed8b04df801171 Subject: [lisp] LIG tool extended X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Jun 2013 11:24:19 -0000 --047d7b342d4892ed8b04df801171 Content-Type: text/plain; charset=ISO-8859-1 Hi all, The LISPmob team has extended the LIG tool to support sending arbitrary Map-Registers and non-encapsulated Map-Requests. You can download the code here https://github.com/LISPmob/lig-lispmob, and obtain support at users@lispmob.org Best, Alberto --047d7b342d4892ed8b04df801171 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all,

The LISPmob team has extended the LIG t= ool to support sending arbitrary Map-Registers and non-encapsulated Map-Req= uests. You can download the code here https://github.com/LISPmob/lig-lispmob, and obtain support at us= ers@lispmob.org

Best,
Alberto
 --047d7b342d4892ed8b04df801171-- From internet-drafts@ietf.org Wed Jun 26 09:57:52 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD9EF11E80F5; Wed, 26 Jun 2013 09:57:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lpjLDlA262KS; Wed, 26 Jun 2013 09:57:52 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BAF721E811D; Wed, 26 Jun 2013 09:57:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.51.p2 Message-ID: <20130626165732.23344.3735.idtracker@ietfa.amsl.com> Date: Wed, 26 Jun 2013 09:57:32 -0700 Cc: lisp@ietf.org Subject: [lisp] I-D Action: draft-ietf-lisp-deployment-08.txt X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 16:57:53 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Locator/ID Separation Protocol Working Gr= oup of the IETF. Title : LISP Network Element Deployment Considerations Author(s) : Lorand Jakab Albert Cabellos-Aparicio Florin Coras Jordi Domingo-Pascual Darrel Lewis Filename : draft-ietf-lisp-deployment-08.txt Pages : 26 Date : 2013-06-26 Abstract: This document discusses the different scenarios for the deployment of the new network elements introduced by the Locator/Identifier Separation Protocol (LISP). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lisp-deployment There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-lisp-deployment-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-lisp-deployment-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ljakab@ac.upc.edu Wed Jun 26 10:00:53 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA00C11E80F5 for ; Wed, 26 Jun 2013 10:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzkYJK3IVYDv for ; Wed, 26 Jun 2013 10:00:47 -0700 (PDT) Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 9E44421E8126 for ; Wed, 26 Jun 2013 10:00:14 -0700 (PDT) Received: from gw.ac.upc.edu (gw.ac.upc.es [147.83.30.3]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id r5QH0D4u009341; Wed, 26 Jun 2013 19:00:13 +0200 Received: from [10.81.80.7] (unknown [89.123.70.90]) by gw.ac.upc.edu (Postfix) with ESMTP id 008EE6B01C4; Wed, 26 Jun 2013 19:00:11 +0200 (CEST) Message-ID: <51CB1E1B.9010508@ac.upc.edu> Date: Wed, 26 Jun 2013 20:00:11 +0300 From: Lori Jakab Organization: UPC/BarcelonaTECH MIME-Version: 1.0 To: Brian Haberman References: <5192763F.2010205@innovationslab.net> <51A39293.9000506@cisco.com> <51A4B85D.1070107@innovationslab.net> <51A75469.6030009@ac.upc.edu> <51A759BC.3070908@innovationslab.net> <51A75BAC.60809@ac.upc.edu> <51ADDAAD.3050300@ac.upc.edu> <51AF82A4.6040506@innovationslab.net> <51C04438.9070807@ac.upc.edu> <51C0588B.4040207@innovationslab.net> In-Reply-To: <51C0588B.4040207@innovationslab.net> OpenPGP: url=http://personals.ac.upc.edu/ljakab/lorand.jakab.pub.asc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: draft-ietf-lisp-deployment@tools.ietf.org, "lisp@ietf.org" Subject: Re: [lisp] AD Evaluation: draft-ietf-lisp-deployment X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:00:53 -0000 On 06/18/2013 03:54 PM, Brian Haberman wrote: > The new text in section 2.4 is (in general) fine. If there are no > objections from the WG, you can submit this version and we can move to > the next step in the publication process. Since no objections were received in the last week, I proceeded with the publication of the text as the -08 revision of the draft. Best regards, -Lori > > Regards, > Brian > > On 6/18/13 7:27 AM, Lori Jakab wrote: >> Hi Brian, all, >> >> Sorry for the long delay, here's updated text for section 2.4. As >> previously, I attached both the diff from the previous revision I sent >> to the list, and the full draft. >> >> Best regards, >> -Lori (on behalf of the authors) >> >> On 06/05/2013 09:25 PM, Brian Haberman wrote: >>> Hi Lori, >>> These changes look fine to me. I will await updated text for the >>> remaining open comment and any feedback from the WG on these changes. >>> >>> Regards, >>> Brian >>> >>> On 6/4/13 8:16 AM, Lori Jakab wrote: >>>> Hi Brian, WG members, >>>> >>>> Please find attached a revised draft, and the diff from the -07 >>>> version. >>>> We responded with changes to all the comments in the AD review, except >>>> for #7.1, for which we are preparing revised text (Section 2.4). >>>> Let us >>>> know if the proposed changes in this revision satisfactorily >>>> address the >>>> rest of the comments. >>>> >>>> Best regards, >>>> -Lori Jakab >>>> >>>> On 05/30/2013 05:01 PM, Lori Jakab wrote: >>>>> On 05/30/2013 04:53 PM, Brian Haberman wrote: >>>>>> On 5/30/13 9:30 AM, Lori Jakab wrote: >>>>>>> [...] >>>>>>> >>>>>>>>>> 13. Section 5.1 >>>>>>>>>> >>>>>>>>>> * I would like to see some justification for the statement that >>>>>>>>>> the >>>>>>>>>> increase in LISP deployment will reduce the need for BGP-based >>>>>>>>>> TE. I >>>>>>>>>> can envision some scenarios where LISP could increase the >>>>>>>>>> BGP-based TE >>>>>>>>>> in order to access the "correct" ETR (or P-ETR). Is there some >>>>>>>>>> studies >>>>>>>>>> that back up this claim? >>>>>>>>> I'm not aware of any conclusive study on this subject, that's >>>>>>>>> why we >>>>>>>>> worded the statement "may lead to a decrease" and explicitly >>>>>>>>> mentioned >>>>>>>>> the "late transition phase", when most sites use LISP. >>>>>>>>> >>>>>>>> But, it does not say "may lead to a decrease", it says "will >>>>>>>> slowly >>>>>>>> decrease the need..." and that sounds like a definitive claim. >>>>>>> Would s/will/may/ resolve your concern? >>>>>>> >>>>>> How about "may decrease the need"? That way, you don't have to >>>>>> leave >>>>>> the reader wondering about the speed of the possible reduction. >>>>> Sounds good, thank you. >>>>> >>>>> Regards, >>>>> -Lori >>>>> >>>>>> Regards, >>>>>> Brian >>>>>> >>>> >>> >> > From terry.manderson@icann.org Thu Jun 27 19:03:53 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3027621F9DD4 for ; Thu, 27 Jun 2013 19:03:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0ymEqN00wOK for ; Thu, 27 Jun 2013 19:03:47 -0700 (PDT) Received: from EXPFE100-2.exc.icann.org (expfe100-2.exc.icann.org [64.78.22.237]) by ietfa.amsl.com (Postfix) with ESMTP id 5240711E8130 for ; Thu, 27 Jun 2013 19:03:47 -0700 (PDT) Received: from EXVPMBX100-1.exc.icann.org ([64.78.22.232]) by EXPFE100-2.exc.icann.org ([64.78.22.237]) with mapi; Thu, 27 Jun 2013 19:03:46 -0700 From: Terry Manderson To: "lisp@ietf.org" Date: Thu, 27 Jun 2013 19:03:44 -0700 Thread-Topic: No LISP meeting for Berlin Thread-Index: Ac5zo7iY5mCoajswR++PaeEgPYCu6g== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3455265824_54705092" MIME-Version: 1.0 Subject: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 02:03:53 -0000 --B_3455265824_54705092 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Dear LISP Work Group, We, the Co-Chairs, have been watching the workgroup closely for activity on the current set of documents that have been adopted. Apart from the items which have been passed to the IESG we do not believe there has been significant progress, discussion, or review of these 'in-play' drafts to warrant having a meeting in Berlin. We have communicated our observations with the responsible AD and amongst us there is full agreement to cancel the LISP session request for Berlin. Thus, we have done so. To iterate, there will be NO MEETING FOR LISP at IETF87. We do apologise if this note causes you concern. However, as chairs we must consider the LISP workgroup outputs on their merit, and at this stage those outputs do not warrant using up agenda time. If you would like to talk with us (the co-chairs) during IETF87, we are happy to make hallway time to discuss ways of making progress on the WG chartered items. LISP Co-Chairs Joel and Terry --B_3455265824_54705092 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIITvAYJKoZIhvcNAQcCoIITrTCCE6kCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EYgwggcDMIIF66ADAgECAhAPz2lJUZsAlD35l4oJxf0FMA0GCSqGSIb3DQEBBQUAMGIxCzAJ BgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2VydCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2Vy dC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFzc3VyZWQgSUQgQ0EtMTAeFw0xMjAzMjcwMDAw MDBaFw0xNTAzMjcxMjAwMDBaMIGsMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2FsaWZvcm5p YTEXMBUGA1UEBxMOTWFyaW5hIGRlbCBSZXkxPDA6BgNVBAoTM0ludGVybmV0IENvcnBvcmF0 aW9uIGZvciBBc3NpZ25lZCBOYW1lcyBhbmQgTnVtYmVyczEXMBUGA1UECxMORE5TIE9wZXJh dGlvbnMxGDAWBgNVBAMTD1RlcnJ5IE1hbmRlcnNvbjCCASIwDQYJKoZIhvcNAQEBBQADggEP ADCCAQoCggEBAKRhZ4W3U6MnfS2woYEFCIyN+g1MNILokbUKk+PTl5mmK3QtWQxTSOu2sdzN xHMy6p2RoT9BMGOamttFq2WswSru6/7JT1TflytGaPHfK5kMP/pI47hmcwUEm9Z169I5ar7z BTiEAQA06cGKtgJ8XiiLFUIHLVuRq3WGxjnFTHlAHXY6mdgDT/ntAnoEvvPVm4XqUnjJiZTS ojzyr1q2RqFvyXs2blOARumDqvLI33yLGcUuaEL+A+hgodzM/fL4kdoy964mXvmEerpm4d4f Y/JfbRUWxc0Eomu9nwGFNk6ijO41qk+OIboct2qeA+5PPclXJNNHYVfzT2dyWfGgxaMCAwEA AaOCA2gwggNkMB8GA1UdIwQYMBaAFBUAEisTmLKZB+0e36K+Vw0rZwLNMB0GA1UdDgQWBBSz wvR2YXpP9XjS9cknMX5g3LM2jTAkBgNVHREEHTAbgRl0ZXJyeS5tYW5kZXJzb25AaWNhbm4u b3JnMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwfQYD VR0fBHYwdDA4oDagNIYyaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJl ZElEQ0EtMS5jcmwwOKA2oDSGMmh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydEFz c3VyZWRJRENBLTEuY3JsMIIBxQYDVR0gBIIBvDCCAbgwggG0BgpghkgBhv1sBAECMIIBpDA6 BggrBgEFBQcCARYuaHR0cDovL3d3dy5kaWdpY2VydC5jb20vc3NsLWNwcy1yZXBvc2l0b3J5 Lmh0bTCCAWQGCCsGAQUFBwICMIIBVh6CAVIAQQBuAHkAIAB1AHMAZQAgAG8AZgAgAHQAaABp AHMAIABDAGUAcgB0AGkAZgBpAGMAYQB0AGUAIABjAG8AbgBzAHQAaQB0AHUAdABlAHMAIABh AGMAYwBlAHAAdABhAG4AYwBlACAAbwBmACAAdABoAGUAIABEAGkAZwBpAEMAZQByAHQAIABD AFAALwBDAFAAUwAgAGEAbgBkACAAdABoAGUAIABSAGUAbAB5AGkAbgBnACAAUABhAHIAdAB5 ACAAQQBnAHIAZQBlAG0AZQBuAHQAIAB3AGgAaQBjAGgAIABsAGkAbQBpAHQAIABsAGkAYQBi AGkAbABpAHQAeQAgAGEAbgBkACAAYQByAGUAIABpAG4AYwBvAHIAcABvAHIAYQB0AGUAZAAg AGgAZQByAGUAaQBuACAAYgB5ACAAcgBlAGYAZQByAGUAbgBjAGUALjB3BggrBgEFBQcBAQRr MGkwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRpZ2ljZXJ0LmNvbTBBBggrBgEFBQcwAoY1 aHR0cDovL2NhY2VydHMuZGlnaWNlcnQuY29tL0RpZ2lDZXJ0QXNzdXJlZElEQ0EtMS5jcnQw DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOCAQEAYpwxK/KvdhbyQqrKp2ylMQpNzqVH ofo4hPILTnp/o+UyYVn6daWSilaV+XNBzE5Rm/f7ms2iA1zBzOvGv55pLH0n6lgIRTeuAGzf KIsPCwPvYQkkMAPXHzh9A44m19hvigTgOPNyjzcOTiHqwwCJSDTEZx17CEkrzQPq1vfG1Lvk +AWjEtxCsGmsuCHHaZjwQ8SsGI7W5cA1Y4RTcQf6S9eIpSsOwXIYdDgWq9Uhi/amW7ryW06Y GH7BHaitqgmm32MZuid3UzJUU6+Ljx7uGA9Fe6k1uPEHhaXTAoobPSpPdOgGmnxUCRQu2OI7 +I8vHiSe7DC/LmxEDC5kB+lUTjCCBsIwggWqoAMCAQICEAoE3yF0XU0rjOozcgUAUOkwDQYJ KoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcG A1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBS b290IENBMB4XDTA2MTExMDAwMDAwMFoXDTIxMTExMDAwMDAwMFowYjELMAkGA1UEBhMCVVMx FTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEhMB8G A1UEAxMYRGlnaUNlcnQgQXNzdXJlZCBJRCBDQS0xMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8A MIIBCgKCAQEA6IItmfnKwkKVpYBzQHDSnlZUXKnE0kEGj8kz/E1FkVyBn+0snPgWWd+etSQV wpi5tHdJ3InECtqvy15r7a2wcTHrzzpADEZNk+yLejYIA6sMNP4YSYL+x8cxSIB8HqIPkg5Q ycaH6zY/2DDD/6b3+6LNb3Mj/qxWBZDwMiEWicZwiPkFl32jx0PdAug7Pe2xQaPtP77blUjE 7h6z8rwMK5nQxl0SQoHhg26Ccz8mSxSQrllmCsSNvtLOBq6thG9IhJtPQLnxTPKvmPv2zkBd XPao8S+v7Iki8msYZbHBc63X8djPHgp0XEK4aH631XcKJ1Z8D2KkPzIUYJX9BwSiCQIDAQAB o4IDbzCCA2swDgYDVR0PAQH/BAQDAgGGMDsGA1UdJQQ0MDIGCCsGAQUFBwMBBggrBgEFBQcD AgYIKwYBBQUHAwMGCCsGAQUFBwMEBggrBgEFBQcDCDCCAcYGA1UdIASCAb0wggG5MIIBtQYL YIZIAYb9bAEDAAQwggGkMDoGCCsGAQUFBwIBFi5odHRwOi8vd3d3LmRpZ2ljZXJ0LmNvbS9z c2wtY3BzLXJlcG9zaXRvcnkuaHRtMIIBZAYIKwYBBQUHAgIwggFWHoIBUgBBAG4AeQAgAHUA cwBlACAAbwBmACAAdABoAGkAcwAgAEMAZQByAHQAaQBmAGkAYwBhAHQAZQAgAGMAbwBuAHMA dABpAHQAdQB0AGUAcwAgAGEAYwBjAGUAcAB0AGEAbgBjAGUAIABvAGYAIAB0AGgAZQAgAEQA aQBnAGkAQwBlAHIAdAAgAEMAUAAvAEMAUABTACAAYQBuAGQAIAB0AGgAZQAgAFIAZQBsAHkA aQBuAGcAIABQAGEAcgB0AHkAIABBAGcAcgBlAGUAbQBlAG4AdAAgAHcAaABpAGMAaAAgAGwA aQBtAGkAdAAgAGwAaQBhAGIAaQBsAGkAdAB5ACAAYQBuAGQAIABhAHIAZQAgAGkAbgBjAG8A cgBwAG8AcgBhAHQAZQBkACAAaABlAHIAZQBpAG4AIABiAHkAIAByAGUAZgBlAHIAZQBuAGMA ZQAuMA8GA1UdEwEB/wQFMAMBAf8wfQYIKwYBBQUHAQEEcTBvMCQGCCsGAQUFBzABhhhodHRw Oi8vb2NzcC5kaWdpY2VydC5jb20wRwYIKwYBBQUHMAKGO2h0dHA6Ly93d3cuZGlnaWNlcnQu Y29tL0NBQ2VydHMvRGlnaUNlcnRBc3N1cmVkSURSb290Q0EuY3J0MIGBBgNVHR8EejB4MDqg OKA2hjRodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURSb290Q0Eu Y3JsMDqgOKA2hjRodHRwOi8vY3JsNC5kaWdpY2VydC5jb20vRGlnaUNlcnRBc3N1cmVkSURS b290Q0EuY3JsMB0GA1UdDgQWBBQVABIrE5iymQftHt+ivlcNK2cCzTAfBgNVHSMEGDAWgBRF 66Kv9JLLgjEtUYunpyGd823IDzANBgkqhkiG9w0BAQUFAAOCAQEAhGFOQR64dgQqtbbvj/JV hbldVv4KmObkvWWKfUAp0/yxXUX9OrgqWzNLJFzNubTkc61hXXatdDOKZtUjr0wfcm5F2XVA u6I7z41JL8BBsOIpo1E4Q1CZFKwzBjViiX13qVIH5WwgV7aBum+8s8KU7XYCgNl8zoWoHOzH Q0pLsVfPcs7f9SU8yyJP/Z9S0TfLCLs4PuDVPm95Ca1bfDGzdzXD5GP5aAqYB+dGOHeE0j6X vAqgqKwlT0RukeHSWq9r7zAcjaNEQrMQiyP61+Y1dDesz+urWB/JiCP/NtQH6jRqR+qdlWye KU9T7eMrlSBOKs+WYHr4LIDwlVLOKZaBYjCCA7cwggKfoAMCAQICEAzn4OUX2Eb+j+Vg/Bvw MDkwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IElu YzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNvbTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJl ZCBJRCBSb290IENBMB4XDTA2MTExMDAwMDAwMFoXDTMxMTExMDAwMDAwMFowZTELMAkGA1UE BhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3LmRpZ2ljZXJ0LmNv bTEkMCIGA1UEAxMbRGlnaUNlcnQgQXNzdXJlZCBJRCBSb290IENBMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEArQ4VzuRDgFyxh/O3YPlxEqWu3CaUiKr0zvUgOShYYAz4gNqp FZUyYTy1sSiEiorcnwoMgxd6j5Csiud5U1wxhCr2D5gyNnbM3t08qKLvavsh8lJh358g1x/i sdn+GGTSEltf+VgYNbxHzaE2+Wt/1LA4PsEbw4wz2dgvGP4oD7Ong9bDbkTAYTWWFv5ZnIt2 bdfxoksNK/8LctqeYNCOkDXGeFWHIKHP5W0KyEl8MZgzbCLph9AyWqK6E4IR7TkXnZk6cqHm +qTZ1Rcxda6FfSKuPwFGhvYoecix2uRXF8R+HA6wtJKmVrO9spftqqfwt8WoP5UW0P+hlusI Xxh3TwIDAQABo2MwYTAOBgNVHQ8BAf8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4E FgQUReuir/SSy4IxLVGLp6chnfNtyA8wHwYDVR0jBBgwFoAUReuir/SSy4IxLVGLp6chnfNt yA8wDQYJKoZIhvcNAQEFBQADggEBAKIOvN/i7fDjcnN6ZJS/93Jm2DLkQnVirofr8tXZ3laz n8zOFCi5DZdgXBJMWOTTPYNJRViXNWkaqEfqVsZ5qxLYZ4GE338JPJTmuCYsIL09syiJ91// IuKXhB/pZe+H4N/BZ0mzXeuyCSrrJu14vn0/K/O3JjVtX4kBtklbnwEFm6s9JcHMtn/C8W+G xvpkaOuBLZTrQrf6jB7dYvG+UGe3bL3z8R9rDDYHFn83fKlbbXrxEkZgg9cnBL5Lzpe+w2cq aBHfgOcMM2a/Ew0UbvN/H2MQHvqNGyVtbI+lt2EBsdKjJqEQcZ2t4sP5w5lRtysHCM4u5lCy p/oKRS+i8PIxggH8MIIB+AIBATB2MGIxCzAJBgNVBAYTAlVTMRUwEwYDVQQKEwxEaWdpQ2Vy dCBJbmMxGTAXBgNVBAsTEHd3dy5kaWdpY2VydC5jb20xITAfBgNVBAMTGERpZ2lDZXJ0IEFz c3VyZWQgSUQgQ0EtMQIQD89pSVGbAJQ9+ZeKCcX9BTAJBgUrDgMCGgUAoF0wIwYJKoZIhvcN AQkEMRYEFH5dJQWJpMSELdY/Ai/xx5mrGQmIMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEzMDYyODAyMDM0NFowDQYJKoZIhvcNAQEBBQAEggEAgK8dD+R5 gyAFXnm3TRb76qGCVhxmQfm+X8XbRcl0PmKQRhUbrkagypkSjDuP77xtpmfdrbdyDvXuQpWy RiCv2uq8kOXt5EcSK5+753rnCIIdwjqOwlN81pG/ZHfdlU0x0PD+GCkVc89rimTedmvolX+v aBtWMkqZU1Yq8pDJNh+nd+ASYebNZKwDiDkIFJ/OJVc0/LpciLvjltX9EZF58BjOela8id1O 1otgTsOE/5ljrTu3T46pDQ3g33Z9yVS/dIxEvmx4tsoy5AW/gEnGZaC+LD+sYS3VgmcqPszM 4Qv6FkEZ6UJc1o5gpz1dUn9o4kv0SlR4OjCLzq1QthWyyA== --B_3455265824_54705092-- From farinacci@gmail.com Thu Jun 27 20:36:22 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F9C311E80F4 for ; Thu, 27 Jun 2013 20:36:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YryC4+PmltG5 for ; Thu, 27 Jun 2013 20:36:21 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 8C46111E80E1 for ; Thu, 27 Jun 2013 20:36:21 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so1717778pbc.23 for ; Thu, 27 Jun 2013 20:36:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to; bh=tVCiGyl330J0C1Yibl+ZYzYFXf6kb8tqC7KuNOuLXgI=; b=rbGLzLeWot/th9pkiEm6vWkSBi2xCSEqTOM2chTqoSijRfoKc5c2zRsIAeRUQr4qW2 rUym7TfuYv7ZD/pjkWOShSQfmG96wbpl5kqDd3FhBYeHDCxejsw45vKr1rPLQE5Y1CRy Ei9BM8rkN7lZFX/j1LCpWi4r9CnF8XuB8xlXHm22kVYKHYGNuj0K/aocyW19JhoScrFg qhh3pWLBBRYxBHrn6IAwPA5SaW9uTk/8FZjpxit5Zfff1hooaD2oAZoo1uL2azCSWaF+ YfDwBuAqsOUQRGEKqFm7oT4YOrpHnuj2uWyFjUBUOnERWuyIEufAnnpnmnD3PZ6Fn885 9auA== X-Received: by 10.68.60.132 with SMTP id h4mr5245545pbr.177.1372390581316; Thu, 27 Jun 2013 20:36:21 -0700 (PDT) Received: from [192.168.1.9] (173-8-188-29-SFBA.hfc.comcastbusiness.net. [173.8.188.29]) by mx.google.com with ESMTPSA id fn9sm6703465pab.2.2013.06.27.20.36.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 27 Jun 2013 20:36:20 -0700 (PDT) References: Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <4576AF63-0544-4762-981F-427FFD010679@gmail.com> X-Mailer: iPhone Mail (10B350) From: Dino Farinacci Date: Thu, 27 Jun 2013 20:36:17 -0700 To: Terry Manderson Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 03:36:22 -0000 Maybe this creates an opportunity to have a get together to discuss future i= tems and brainstorm a bit about future use-cases for LISP. Not under WG purv= iew and not a BOF. Just he had 5 years ago when we started LISP.=20 Having said that we could get a room, schedule a time, and have some present= ations on future topics. We can keep this open and not be constrained by the= WG charter.=20 I am a bit concerned that the WG is not keeping up with industry trends wher= e LISP is a viable solution. We, the working group, do not want to be in a s= ituation like the NVO3 working group is going through. That is, defining a p= roblem statement, framework, and terminology when the industry is way ahead w= ith solutions.=20 Would people be interested in participating? If so, I can facilitate.=20 Dino=20 On Jun 27, 2013, at 7:03 PM, Terry Manderson wro= te: > Dear LISP Work Group, >=20 > We, the Co-Chairs, have been watching the workgroup closely for activity > on the current set of documents that have been adopted. Apart from the > items which have been passed to the IESG we do not believe there has been > significant progress, discussion, or review of these 'in-play' drafts to > warrant having a meeting in Berlin. >=20 > We have communicated our observations with the responsible AD and amongst > us there is full agreement to cancel the LISP session request for Berlin. >=20 > Thus, we have done so. >=20 > To iterate, there will be NO MEETING FOR LISP at IETF87. >=20 > We do apologise if this note causes you concern. However, as chairs we > must consider the LISP workgroup outputs on their merit, and at this stage= > those outputs do not warrant using up agenda time. >=20 > If you would like to talk with us (the co-chairs) during IETF87, we are > happy to > make hallway time to discuss ways of making progress on the WG chartered= > items. >=20 >=20 > LISP Co-Chairs > Joel and Terry > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp From Sharon@Contextream.com Thu Jun 27 22:17:16 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A64B21F9F76 for ; Thu, 27 Jun 2013 22:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fl6QuTQhw6uP for ; Thu, 27 Jun 2013 22:17:11 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id D2D9121F9F75 for ; Thu, 27 Jun 2013 22:17:10 -0700 (PDT) Received: from mail135-db9-R.bigfish.com (10.174.16.226) by DB9EHSOBE013.bigfish.com (10.174.14.76) with Microsoft SMTP Server id 14.1.225.23; Fri, 28 Jun 2013 05:17:09 +0000 Received: from mail135-db9 (localhost [127.0.0.1]) by mail135-db9-R.bigfish.com (Postfix) with ESMTP id BB7B8201EF; Fri, 28 Jun 2013 05:17:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.53; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0610HT005.eurprd06.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371I1432I1506Jdb82hzz1f42h1ee6h1de0h1fdah1202h1e76h1d1ah1d2ah1fc6h1f8fiz8dhz1033IL8275bh8275dhz32i2a8h668h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1155h) Received: from mail135-db9 (localhost.localdomain [127.0.0.1]) by mail135-db9 (MessageSwitch) id 1372396627649803_24254; Fri, 28 Jun 2013 05:17:07 +0000 (UTC) Received: from DB9EHSMHS003.bigfish.com (unknown [10.174.16.234]) by mail135-db9.bigfish.com (Postfix) with ESMTP id 8F5FD380046; Fri, 28 Jun 2013 05:17:07 +0000 (UTC) Received: from DB3PRD0610HT005.eurprd06.prod.outlook.com (157.56.252.53) by DB9EHSMHS003.bigfish.com (10.174.14.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 28 Jun 2013 05:17:07 +0000 Received: from DB3PRD0610MB379.eurprd06.prod.outlook.com ([169.254.11.40]) by DB3PRD0610HT005.eurprd06.prod.outlook.com ([10.255.47.40]) with mapi id 14.16.0324.000; Fri, 28 Jun 2013 05:17:06 +0000 From: Sharon Barkai To: Dino Farinacci Thread-Topic: [lisp] No LISP meeting for Berlin Thread-Index: Ac5zo7iY5mCoajswR++PaeEgPYCu6gADO0CAAAOFWyg= Date: Fri, 28 Jun 2013 05:17:05 +0000 Message-ID: References: , <4576AF63-0544-4762-981F-427FFD010679@gmail.com> In-Reply-To: <4576AF63-0544-4762-981F-427FFD010679@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [166.137.184.31] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: Contextream.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 05:17:16 -0000 Very much interested in sharing and getting updates on the lisp sdn front, lisp in open daylight efforts, lisp-flow by lispmob, and the draft lisp4nfv= use case . Perhaps this proposal makes most sense since these topics may b= e beyond charter. --szb On Jun 27, 2013, at 8:36 PM, "Dino Farinacci" wrote: > Maybe this creates an opportunity to have a get together to discuss futur= e items and brainstorm a bit about future use-cases for LISP. Not under WG = purview and not a BOF. Just he had 5 years ago when we started LISP.=20 >=20 > Having said that we could get a room, schedule a time, and have some pres= entations on future topics. We can keep this open and not be constrained by= the WG charter.=20 >=20 > I am a bit concerned that the WG is not keeping up with industry trends w= here LISP is a viable solution. We, the working group, do not want to be in= a situation like the NVO3 working group is going through. That is, definin= g a problem statement, framework, and terminology when the industry is way = ahead with solutions.=20 >=20 > Would people be interested in participating? If so, I can facilitate.=20 >=20 > Dino=20 >=20 > On Jun 27, 2013, at 7:03 PM, Terry Manderson = wrote: >=20 >> Dear LISP Work Group, >>=20 >> We, the Co-Chairs, have been watching the workgroup closely for activity >> on the current set of documents that have been adopted. Apart from the >> items which have been passed to the IESG we do not believe there has bee= n >> significant progress, discussion, or review of these 'in-play' drafts to >> warrant having a meeting in Berlin. >>=20 >> We have communicated our observations with the responsible AD and amongs= t >> us there is full agreement to cancel the LISP session request for Berlin= . >>=20 >> Thus, we have done so. >>=20 >> To iterate, there will be NO MEETING FOR LISP at IETF87. >>=20 >> We do apologise if this note causes you concern. However, as chairs we >> must consider the LISP workgroup outputs on their merit, and at this sta= ge >> those outputs do not warrant using up agenda time. >>=20 >> If you would like to talk with us (the co-chairs) during IETF87, we are >> happy to >> make hallway time to discuss ways of making progress on the WG chartere= d >> items. >>=20 >>=20 >> LISP Co-Chairs >> Joel and Terry >> _______________________________________________ >> lisp mailing list >> lisp@ietf.org >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp >=20 From sander@steffann.nl Fri Jun 28 00:05:29 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5671721F9E22 for ; Fri, 28 Jun 2013 00:05:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.311 X-Spam-Level: X-Spam-Status: No, score=0.311 tagged_above=-999 required=5 tests=[HOST_MISMATCH_NET=0.311] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VIMi686O+wQF for ; Fri, 28 Jun 2013 00:05:19 -0700 (PDT) Received: from mail.sintact.nl (mail.sintact.nl [IPv6:2001:4038:0:16::7]) by ietfa.amsl.com (Postfix) with ESMTP id DE1C321F9E30 for ; Fri, 28 Jun 2013 00:05:14 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sintact.nl (Postfix) with ESMTP id 1CAEB201A; Fri, 28 Jun 2013 09:05:13 +0200 (CEST) X-Virus-Scanned: amavisd-new at mail.sintact.nl Received: from mail.sintact.nl ([127.0.0.1]) by localhost (mail.sintact.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lkoppyM7GB86; Fri, 28 Jun 2013 09:05:08 +0200 (CEST) Received: from nbk-solcon-56.solcon.local (gw01.dro2.network.solcon.net [212.45.32.70]) by mail.sintact.nl (Postfix) with ESMTP id A88FA2050; Fri, 28 Jun 2013 09:05:06 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Sander Steffann In-Reply-To: <4576AF63-0544-4762-981F-427FFD010679@gmail.com> Date: Fri, 28 Jun 2013 09:05:07 +0200 Content-Transfer-Encoding: 7bit Message-Id: <225A8B96-A099-448D-8A24-D057FDDDF587@steffann.nl> References: <4576AF63-0544-4762-981F-427FFD010679@gmail.com> To: Dino Farinacci X-Mailer: Apple Mail (2.1508) Cc: "lisp@ietf.org" Subject: Re: [lisp] No LISP meeting for Berlin X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 07:05:29 -0000 Hi Dino, > Would people be interested in participating? If so, I can facilitate. Sure, Sander From zhengyli@cisco.com Thu Jun 27 23:41:54 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A254B21F9E4F for ; Thu, 27 Jun 2013 23:41:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.999 X-Spam-Level: X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hw5-AT75da9u for ; Thu, 27 Jun 2013 23:41:43 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 86C8721F9E40 for ; Thu, 27 Jun 2013 23:41:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3624; q=dns/txt; s=iport; t=1372401703; x=1373611303; h=from:to:subject:date:message-id:mime-version; bh=3LZ49ZBgkI3PIk0QZG5uV76VvBpW3kn25KOxBmXbp78=; b=VG3uEDDlEhmeVx3EH4StGLHAJ7D8bhshCtUcgLL+c12ikl+4UJk/Vc9F O1fYlqmIoZ0mFkGsS/CMB+jaikirIabWkILIGb+fTgmo06jfbUsI1na43 xGdFKuuw1fzPTDYELNFWOQQ0VHNQP6QeuQLbRh70rZPjcL4uzvwkZHMW7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAFwvzVGtJXG+/2dsb2JhbABbgkVEer8QgQQWdIIlAQRrIAEMHlYnBBuIBpshoDSPJIM6YwOpCoMRgig X-IronPort-AV: E=Sophos;i="4.87,957,1363132800"; d="scan'208,217";a="228485775" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-6.cisco.com with ESMTP; 28 Jun 2013 06:41:43 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r5S6fgDR020603 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 28 Jun 2013 06:41:42 GMT Received: from xmb-aln-x12.cisco.com ([169.254.7.22]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 01:41:42 -0500 From: "Rockson Li (zhengyli)" To: "lisp@ietf.org" Thread-Topic: Does Map resolver get map reply Thread-Index: AQHOc8qL9fpSFBj3WU+bJPJ3VSQ4iQ== Date: Fri, 28 Jun 2013 06:41:37 +0000 Message-ID: <6FFCD2B684E3EE4A96850F334095D67707CA3BAD@xmb-aln-x12.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.104.169.74] Content-Type: multipart/alternative; boundary="_000_6FFCD2B684E3EE4A96850F334095D67707CA3BADxmbalnx12ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 28 Jun 2013 08:26:14 -0700 Subject: [lisp] Does Map resolver get map reply X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 06:41:54 -0000 --_000_6FFCD2B684E3EE4A96850F334095D67707CA3BADxmbalnx12ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello experts, I got a question on if map resolver should get map reply. >From sec 4.3 of RFC6833 Unless also acting as a Map-Resolver, a Map-Server should never receive Map= -Replies It seems a map resolver could possibly get map reply. However, from sec 4.4, it seems to me a map resolver should not get a map r= eply at all. The Map-Resolver does not send any response to the ITR; since the source RLOC is that of the ITR, the ETR or Map-Server that receives the Map-Request over the ALT and responds will do so **directly** to the ITR. Can someone clarify please? Thanks Regards, -Rockson --_000_6FFCD2B684E3EE4A96850F334095D67707CA3BADxmbalnx12ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: <8B02DE59C9828145A07C6D950C929C06@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
Hello experts,

I got a question on if map resolver should= get map reply.
From sec 4.3 of RFC6833
<snip>
Unless also&nb= sp;acting as a Map-Resolver, a Map-Server should never receive Map-Rep= lies
</snip><= /span>

It seems a map resolver could possibly get= map reply.

However, from sec 4.4, it seems to me a ma= p resolver should not get a map reply at all.

<snip>
  The Map= -Resolver does not send any response
   t= o the ITR; since the source RLOC is that of the ITR, the ETR or
   M= ap-Server that receives the Map-Request over the ALT and responds
   w= ill do so **directly** to the ITR.
</snip><= /span>

Can someone clarify please?

Thanks
Regards,
-Rockson
--_000_6FFCD2B684E3EE4A96850F334095D67707CA3BADxmbalnx12ciscoc_-- From farinacci@gmail.com Fri Jun 28 09:39:41 2013 Return-Path: X-Original-To: lisp@ietfa.amsl.com Delivered-To: lisp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7576E21F9A83 for ; Fri, 28 Jun 2013 09:39:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-1eqOsgIm4t for ; Fri, 28 Jun 2013 09:39:40 -0700 (PDT) Received: from mail-pb0-x236.google.com (mail-pb0-x236.google.com [IPv6:2607:f8b0:400e:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id A25C121F9A80 for ; Fri, 28 Jun 2013 09:39:40 -0700 (PDT) Received: by mail-pb0-f54.google.com with SMTP id ro2so2480720pbb.41 for ; Fri, 28 Jun 2013 09:39:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=WjzYkBn4awtdLUX1ZCIngMyrP2VdK2CjisHxluYAQRM=; b=yHnFO2P/tv6j3L9nGIAadLPh6aA0dMtbj1U9mTOlMjiktb7xOeQrhDedBnRhQUAkzY 9n6W91ejKfFY5MrBwZn2V8fHTk1nLClYTIQm9mKVwuW8sCckJuIMPErf5By2PkHkurg3 ZeK0lH/ZvG5M1UhoZ+RxaqwOXOk/syBu5YDDMYmRbPjS1MWXl6ZTxCPa5UJMUuH+P+J1 3GoHuXzrPs6WhZGSL+FTD97xAKaU7qcmvedYYkBK/ebXNsXcswolDpb2tw2+63hG16TV tcWGg0ieMvb3a35aMxHh3XrbH+ARqxaNVyinb+y3F0BF1J97ur5NqkTmx8HID1bRdEz0 /Xlg== X-Received: by 10.68.104.196 with SMTP id gg4mr12432379pbb.25.1372437580228; Fri, 28 Jun 2013 09:39:40 -0700 (PDT) Received: from [10.169.113.83] (71-6-80-11.static-ip.telepacific.net. [71.6.80.11]) by mx.google.com with ESMTPSA id bg3sm8825933pbb.44.2013.06.28.09.39.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 28 Jun 2013 09:39:39 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: Dino Farinacci In-Reply-To: <6FFCD2B684E3EE4A96850F334095D67707CA3BAD@xmb-aln-x12.cisco.com> Date: Fri, 28 Jun 2013 09:39:37 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6FFCD2B684E3EE4A96850F334095D67707CA3BAD@xmb-aln-x12.cisco.com> To: "Rockson Li (zhengyli)" X-Mailer: Apple Mail (2.1503) Cc: "lisp@ietf.org" Subject: Re: [lisp] Does Map resolver get map reply X-BeenThere: lisp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: List for the discussion of the Locator/ID Separation Protocol List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 16:39:41 -0000 > Hello experts, >=20 > I got a question on if map resolver should get map reply. > =46rom sec 4.3 of RFC6833 > > Unless also acting as a Map-Resolver, a Map-Server should never = receive Map-Replies > >=20 > It seems a map resolver could possibly get map reply. A Map-Resolver would only get a Map-Reply if it *originated* a = Map-Request. Versus, it forwarding one on behalf of an ITR.=20 When a Map-Resolver is part of a LISP-DDT hierarchy, it receives = Map-Referral messages in response to Map-Requests it forwards on behalf = of ITRs. It does this, so it can build a *referral-cache* versus a = *map-cache* which ITRs build. > However, from sec 4.4, it seems to me a map resolver should not get a = map reply at all. And this text is correct. > > The Map-Resolver does not send any response > to the ITR; since the source RLOC is that of the ITR, the ETR or > Map-Server that receives the Map-Request over the ALT and responds > will do so **directly** to the ITR. > >=20 > Can someone clarify please? Here is the relative text in 4.3: If none of the ETRs have requested proxy reply service, then the =20 Map-Server re-encapsulates and forwards the resulting Encapsulated Map-Request to one of the registered ETRs. It does not otherwise alter the Map-Request, so any Map-Reply sent by the ETR is returned to the RLOC in the Map-Request, not to the Map-Server. Unless also acting as a Map-Resolver, a Map-Server should never receive Map-Replies; any such messages should be discarded without response, perhaps accompanied by the logging of a diagnostic message if the rate of Map-Replies is suggestive of malicious traffic. An ETR returning a Map-Reply always goes to the RLOC from the ITR-RLOCs = list in the Map-Request. So I wanted to clarify that first. The "Unless = also acting as a Map-Resolver" is indeed misleading, making the reader = think that if a Map-Server is also a Map-Resolver that it could receive = Map-Replies. Well, there is really no reason for it to receive = Map-Replies, because as I state above a proper Map-Resolver does not = keep a map-cache, unless of course it is an ITR. ;-) We will fix the text in a future update. Thanks for the comment. Dino > Thanks > Regards, > -Rockson > _______________________________________________ > lisp mailing list > lisp@ietf.org > https://www.ietf.org/mailman/listinfo/lisp