Network Working Group                                           L. Jakab
Internet-Draft                                      A. Cabellos-Aparicio
Intended status: Informational                                  F. Coras
Expires: April 28, 2011                               J. Domingo-Pascual
                                       Technical University of Catalonia
                                                                D. Lewis
                                                           Cisco Systems
                                                        October 25, 2010


             LISP Network Element Deployment Considerations
                   draft-jakab-lisp-deployment-01.txt

Abstract

   This document discusses the different scenarios in which the LISP
   protocol may be deployed.  Changes or extensions to other protocols
   needed by some of the scenarios are also highlighted.

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 April 28, 2011.

Copyright Notice

   Copyright (c) 2010 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



Jakab, et al.            Expires April 28, 2011                 [Page 1]


Internet-Draft               LISP Deployment                October 2010


   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
     2.1.  Customer Edge  . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Provider Edge  . . . . . . . . . . . . . . . . . . . . . .  5
     2.3.  Split ITR/ETR  . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Inter-Service Provider Traffic Engineering . . . . . . . .  8
     2.5.  Tunnel Routers behind NAT  . . . . . . . . . . . . . . . .  9
       2.5.1.  ITR  . . . . . . . . . . . . . . . . . . . . . . . . .  9
       2.5.2.  ETR  . . . . . . . . . . . . . . . . . . . . . . . . . 10
     2.6.  Summary and Feature Matrix . . . . . . . . . . . . . . . . 10
   3.  Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 10
     3.1.  P-ITR  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
       3.1.1.  EID registrar P-ITR services . . . . . . . . . . . . . 10
       3.1.2.  LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . 11
       3.1.3.  Content Delivery Network P-ITR services  . . . . . . . 11
       3.1.4.  Content Delivery Network load balancing  . . . . . . . 11
       3.1.5.  ISP P-ITR services . . . . . . . . . . . . . . . . . . 11
     3.2.  P-ETR  . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.  Map-Resolvers and Map-Servers  . . . . . . . . . . . . . . . . 13
     4.1.  Map-Servers  . . . . . . . . . . . . . . . . . . . . . . . 14
     4.2.  Map-Resolvers  . . . . . . . . . . . . . . . . . . . . . . 14
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

















Jakab, et al.            Expires April 28, 2011                 [Page 2]


Internet-Draft               LISP Deployment                October 2010


1.  Introduction

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

   While the boundary between the core and edge 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 we will use the term LISP
   site to refer to these networks/hosts behind a LISP Tunnel Router.
   We formally define it as:

   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 network 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 requierements they may impose on the protocol
   specification.  The main specification [I-D.ietf-lisp] mentions
   positioning of tunnel routers, but without an in-depth discussion.
   This document fills that gap, by exploring the most common cases.
   While the theoretical combinations of device placements are quite
   numerous, the more practical scenarios are given preference in the
   following.

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

   Comments and discussions about this memo should be directed to the
   LISP working group: lisp@ietf.org.







Jakab, et al.            Expires April 28, 2011                 [Page 3]


Internet-Draft               LISP Deployment                October 2010


2.  Tunnel Routers

   LISP is a map-and-encap protocol, with the main goal of improving
   global routing scalability.  To achieve its goal, it introduces
   several new network elements, each performing specific functions
   necessary to separate the edge from the core.  The device that is the
   gateway between the edge and the core is called 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 [I-D.ietf-lisp] 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

   As mentioned in the Introduction, LISP was designed with deployment
   at the core-edge boundary in mind, which can be approximated as the
   set of DFZ routers belonging to non-transit ASes.  For the purposes
   of this document, we will consider this boundary to be consisting of
   the routers connecting LISP sites to their upstreams.  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|--+
                            |  +----+  +----+  |
                            |                  |
                            |     Customer     |
                            +------------------+

                    Figure 1: xTRs at the customer edge




Jakab, et al.            Expires April 28, 2011                 [Page 4]


Internet-Draft               LISP Deployment                October 2010


   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 is 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 can be easily synchronized, 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 can be set correctly in the LISP data header
   of outgoing packets.

   By choosing the encapsulate last, decapsulate first policy, 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 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 MTU issues.
   Since encapsulating packets increases overhead, the MTU of the end-
   to-end path may decrease, when encapsulated packets need to travel
   over segments having close to minimum MTU.  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 at the CE could possibly
   bring up MTU issues, depending on the link type to the provider.

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 April 28, 2011                 [Page 5]


Internet-Draft               LISP Deployment                October 2010


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

                          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 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
   simultanously, which may lead to unconsistent state for the mappings
   of the LISP site (e.g., weights for the same priority don't sum 100).
   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 today's DNS.

   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 correctly on encapsulated packets.

   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



Jakab, et al.            Expires April 28, 2011                 [Page 6]


Internet-Draft               LISP Deployment                October 2010


   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 both entities can 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 turn,
   ETRs can be deployed at the border routers of the network, and
   packets are decapsulated as soon as possible.  Again, once
   decapsulated packets are routed according to the EID, and can follow
   the best path.

   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  In LISP, ITRs set the reachability bits when encapsulating data
      packets.  Hence, ITRs need a mechanism to be aware of the liveness
      of ETRs.



Jakab, et al.            Expires April 28, 2011                 [Page 7]


Internet-Draft               LISP Deployment                October 2010


   o  ITRs encapsulate packets and in order to achieve efficient
      communications, the MTU of the site must be large enough to
      accommodate this extra header.

   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 will transmit a higher amount
      of Map-Requests, increasing the load on the distributed mapping
      database.  This could be solved by synchronizing ITR caches, via
      IGP or multicast.

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, ISP_B only has the current tools (such as BGP
   prefix deaggregation) to control on which of his own upstream or
   peering links should packets enter.  This is either not feasible (if
   fine-grained per-customer control is required, the very specific
   prefixes may not be propagated) or increases DFZ table size.

                                  _.--.
    Stub1 ...   +-------+      ,-''     `--.      +-------+   ... Stub3
             \  |   R_A1|----,'             `. ---|R_B1   |  /
              --|   R_A2|---(     Transit     )   |       |--
    Stub2 .../  |   R_A3|-----.             ,' ---|R_B2   |  \... Stub4
                +-------+      `--.     _.-'      +-------+
          ...     ISP_A            `--''            ISP_B     ...

               Figure 4: Inter-Service provider TE scenario

   A solution for this is to apply LISP recursively.  ISP_A and ISP_B
   may reach a bilateral agreement to deploy their own private mapping
   system.  ISP_A then encapsulates packets destined for the prefixes of



Jakab, et al.            Expires April 28, 2011                 [Page 8]


Internet-Draft               LISP Deployment                October 2010


   ISP_B, which are listed in the shared mapping system.  Note that in
   this case the packet is double-encapsulated.  ISP_B's ETR removes the
   outer, second layer of LISP encapsulation from the incoming packet,
   and routes it towards the original RLOC, the ETR of Stub4, which does
   the final decapsulation.

   If ISP_A and ISP_B agree to share a private distributed mapping
   database, both can control their ingress TE without the need of
   disaggregating prefixes.  In this scenario the private database
   contains RLOC-to-RLOC bindings.  The convergence time on the TE
   policies updates is fast, since ISPs only have to update/query a
   mapping to/from the database.

   The main disadvantages of this deployment case are:

   1.  Extra LISP header is needed.  This increases the packet size and,
       for efficient communications, it requires that the MTU between
       both ISPs can accomodate double-encapsulated packets.

   2.  The ISP ITR must encapsulate packets and therefore must know the
       RLOC-to-RLOC binding.  These bindings are stored in a mapping
       database and may be cached in the ITR's mapping cache.  Cache
       misses lead to an extra lookup latency, unless NERD
       [I-D.lear-lisp-nerd] is used for the lookups.

   3.  The operational overhead of maintaining the shared mapping
       database.

2.5.  Tunnel Routers behind NAT

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:

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



Jakab, et al.            Expires April 28, 2011                 [Page 9]


Internet-Draft               LISP Deployment                October 2010


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

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 the Map-Replies.  Thus support for dynamic locators for the
   mapping database is needed in LISP equipment.  Existing mechanisms
   used for updating dynamic DNS can be used to automate the process.

2.6.  Summary and Feature Matrix

          Feature                         CE    PE    Split   Rec.
          --------------------------------------------------------
          Control of ingress TE            x     -      x      x
          No modifications to existing
             int. network infrastructure   x     x      -      -
          Loc-Status-Bits sync             x     -      x      x
          MTU/PMTUD issues minimized       -     x      -      x


3.  Proxy Tunnel Routers

3.1.  P-ITR

   Proxy Ingress Tunnel Routers (P-ITRs) are part of the LISP/non-LISP
   transition mechanism, allowing non-LISP sites to reach LISP sites.
   They announce certain aggregated EID prefixes into the global BGP
   routing tables 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 [I-D.ietf-lisp-interworking] for a
   detailed description of P-ITR functionality.

   A LISP site needs an interworking mechanism to communicate with non-
   LISP sites.  A P-ITR can fulfill this role, enabling early adopters
   to see the benefits of LISP.

3.1.1.  EID registrar P-ITR services

   EID registrars are in a good position to offer P-ITR services when
   allocating EID prefixes, unless the registrant wants to deploy it's
   own P-ITR infrastructure.  Since the registrar is already providing
   Map-Server services, publishing registered prefixes into the mapping
   system, they can announce an aggregate of their allocated EID range



Jakab, et al.            Expires April 28, 2011                [Page 10]


Internet-Draft               LISP Deployment                October 2010


   into the DFZ.  This way the P-ITR function can be colocated with the
   MS and the number of prefixes advertized to the DFZ reduced.  On the
   other hand, at the early stages of the transition this may imply a
   significant portion of a LISP site's traffic always going through the
   P-ITR, which may not be acceptable for the registrar.

3.1.2.  LISP+BGP

   At the other extreme exists the possibility to colocate the P-ITR
   function with the site's tunnel router(s).  This would effectively
   keep today's funcionality for communications with legacy sites, and
   adding the benefits of LISP for communications with other early
   adopters.  The downside is no decrease in global DFZ state.

   However, in this case the P-ITR is not strictly necessary, since
   packets reaching the site border need no encapsulation to reach the
   network.

3.1.3.  Content Delivery Network P-ITR services

   The main disadvantage of using P-ITRs is path stretch (unless
   colocated with the xTRs).  Packets from non-LISP sites going through
   the P-ITR may take a suboptimal route.  Because of this, large
   content providers may have the incentive to deploy geographically
   diverse P-ITRs, announcing their EID prefix with anycast.  Existing
   content delivery networks (CDNs) could leverage their existing
   infrastructure to add this service to their portfolio, so that
   independent content providers could also offer improved latencies to
   their users.  With this service in place a new LISP site need not
   deploy it's own P-ITR, but rather pay for the service and have low
   path stretch.

3.1.4.  Content Delivery Network load balancing

   In addition to providing P-ITR services to third parties, CDNs can
   leverage the improvement brought by LISP for their own advantage.  By
   deploying P-ITRs in strategic locations, traffic engineering could be
   improved beyond what is currently offered by DNS, by adjusting
   percentages of traffic flow to certain data centers, depending on
   their load.  This can be achieved by setting the appropriate
   priorities, weights and loc-status-bits in mappings.  And since the
   P-ITRs are controlled by the CDN operators, changes can take place
   instantaneously.

3.1.5.  ISP P-ITR services

   In all the above cases, the client for P-ITR services was a new LISP
   site, wishing to ensure global reachability of its allocated EID



Jakab, et al.            Expires April 28, 2011                [Page 11]


Internet-Draft               LISP Deployment                October 2010


   space from non-LISP networks.  On the flip side, ISPs can also
   provide P-ITR services to their non-LISP customers.  To do that they
   announce an aggregate of all known EID prefixes downstream to their
   customers.  When these announcements are sent only to edge networks
   not carrying full routes, this deployment scenario has no direct
   effect on the DFZ size.

   Additionally, they can select from these aggregates the EID prefixes
   of their LISP customers, and announce them upstream.

   Note that the above does not increase the traffic of the provider:
   customers using external P-ITRs would still use the ISP network for
   transit, and it doesn't attract non-customer traffic.  Traffic for
   their LISP customers has to traverse the provider as well.  On the
   other hand, by offering a P-ITR, the ISP ensures that all of its non-
   LISP customers can reach any LISP site, with minimal (if any) path
   strech, regardless of the quality of P-ITRs services contracted by
   destination sites.  Additionally, they ensure reachability for their
   LISP customers as well, potentially aggregating prefixes from several
   customers, and avoiding the LISP+BGP scenario.

   For performance reasons, and to simplify P-ITR management, it is
   desirable to minimize the number of non-aggregable EID prefixes.  In
   IPv6 this can be easily achieved if a large pblock is reserved as
   LISP EID space.

3.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  LISP sites without native IPv6 communicating with LISP nodes with
      IPv6-only locators.

   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 originated from the LISP site is advertized to the
   global routing tables by a P-ITR, and the PE router has a route
   towards it.  However, it will not be on the interface towards the CE
   router, so non-encapsulated packets will fail uRPF checks.




Jakab, et al.            Expires April 28, 2011                [Page 12]


Internet-Draft               LISP Deployment                October 2010


   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 [I-D.ietf-lisp-interworking]
   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.  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.  CDNs can also leverage their existing
   infrastructure, offering paid P-ETRs access.

   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 existance 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.  To enable
   autoconfiguration of the P-ETR locator, a DHCP option would be
   required.

   As a security measure, access to P-ETRs should be limited to
   legitimate users by enforcing ACLs.


4.  Map-Resolvers and Map-Servers







Jakab, et al.            Expires April 28, 2011                [Page 13]


Internet-Draft               LISP Deployment                October 2010


4.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 responsible for and then re-
   encapsulates and forwards it to a matching ETR.  Map-Server
   functionality is described in detail in [I-D.ietf-lisp-ms].

   The Map-Server is provided by Mapping Service Providers (MSPs).  EID
   assignment authorities can be MSPs themselves, or delegate this
   service to third parties.  For instance, a LISP site (i.e., ISP)
   requests a Provider Independent (PI) set of addresses from an EID
   registrar (i.e., RIPE).  This registrar (if it is an MSP as well) or
   an authorized third party MSP configures its Map-Server(s) to publish
   this prefix in the distributed mapping database and starts
   encapsulating and forwarding Map-Requests to the ETRs of the AS.
   These ETRs register this prefix at the Map-Server(s) through periodic
   authenticated Map-Register messages.  In this context there is a need
   for mechanisms to:

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

   o  Configure 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 ETRs
   authoritative for these prefixes.  Upon the failure of a Map-Server,
   ITRs communicating with the set of EID-prefixes will be unable to
   reach any of the affected EID-prefixes.  The only exception are the
   ITRs that contain in their map cache the EID-to-RLOC mappings.  In
   this case ITRs can reach ETRs until the entry expires (typically 24
   hours).  For this reason redundant Map-Server deployments are
   desirable and the LISP specification should describe appropriate
   mechanisms.

4.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 cache or by
   consulting the distributed mapping database.  Map-Resolver
   functionality is described in detail [I-D.ietf-lisp-ms].



Jakab, et al.            Expires April 28, 2011                [Page 14]


Internet-Draft               LISP Deployment                October 2010


   Anyone with access to the distributed mapping database can provide
   Map-Resolver service.  In the case of ALT, a BGP peering session with
   the ALT overlay is required.

   The MSP providing the Map-Server(s) for a LISP site should also
   provide access to Map-Resolver(s) for the use of that site, unless
   they prefer other alternatives.

   However, Map-Resolvers will be typically provided by ISPs because of
   performance reasons: they are topologically closer to the LISP site.
   The use of their resolver can be restricted to their clients, or they
   can adopt an "open to all" policy.

   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.


5.  Security Considerations

   Security implications of LISP deployments are to be discussed in a
   separate document.


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Acknowledgements

   This draft includes material inspired by previous work from Darrel
   Lewis and Margaret Wasserman, presented at IETF76.  The authors would
   like to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince
   Fuller, Dino Farinacci, and everyone else who provided input.


8.  References

8.1.  Normative References

   [I-D.ietf-lisp]
              Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
              "Locator/ID Separation Protocol (LISP)",
              draft-ietf-lisp-09 (work in progress), October 2010.

   [I-D.ietf-lisp-interworking]



Jakab, et al.            Expires April 28, 2011                [Page 15]


Internet-Draft               LISP Deployment                October 2010


              Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
              "Interworking LISP with IPv4 and IPv6",
              draft-ietf-lisp-interworking-01 (work in progress),
              August 2010.

   [I-D.ietf-lisp-ms]
              Fuller, V. and D. Farinacci, "LISP Map Server",
              draft-ietf-lisp-ms-06 (work in progress), October 2010.

8.2.  Informative References

   [I-D.lear-lisp-nerd]
              Lear, E., "NERD: A Not-so-novel EID to RLOC Database",
              draft-lear-lisp-nerd-08 (work in progress), March 2010.

   [cache]    Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS
              performance and the effectiveness of caching", 2002.


Authors' Addresses

   Lorand Jakab
   Technical University of Catalonia
   C/Jordi Girona, s/n
   BARCELONA  08034
   Spain

   Email: ljakab@ac.upc.edu


   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 April 28, 2011                [Page 16]


Internet-Draft               LISP Deployment                October 2010


   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 April 28, 2011                [Page 17]