Network Working Group L. Jakab
Internet-Draft A. Cabellos-Aparicio
Intended status: Informational F. Coras
Expires: April 1, 2011 J. Domingo-Pascual
Technical University of Catalonia
D. Lewis
Cisco Systems
September 28, 2010
LISP Network Element Deployment Considerations
draft-jakab-lisp-deployment-00.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 1, 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 1, 2011 [Page 1]
Internet-Draft LISP Deployment September 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.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 13
4.1. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Jakab, et al. Expires April 1, 2011 [Page 2]
Internet-Draft LISP Deployment September 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 1, 2011 [Page 3]
Internet-Draft LISP Deployment September 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 1, 2011 [Page 4]
Internet-Draft LISP Deployment September 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 1, 2011 [Page 5]
Internet-Draft LISP Deployment September 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 1, 2011 [Page 6]
Internet-Draft LISP Deployment September 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_B--| 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 1, 2011 [Page 7]
Internet-Draft LISP Deployment September 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 1, 2011 [Page 8]
Internet-Draft LISP Deployment September 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 1, 2011 [Page 9]
Internet-Draft LISP Deployment September 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
No MTU/PMTUD issues - 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 1, 2011 [Page 10]
Internet-Draft LISP Deployment September 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.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
Jakab, et al. Expires April 1, 2011 [Page 11]
Internet-Draft LISP Deployment September 2010
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.
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,
Jakab, et al. Expires April 1, 2011 [Page 12]
Internet-Draft LISP Deployment September 2010
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
4.1. 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. The Map-Resolver is
defined in [I-D.ietf-lisp-ms].
Map-Resolvers will be typically provided by ISPs, which also define
the access policy the device. In medium or 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.
4.2. Map-Servers
The Map-Server learns EID-to-RLOC mapping entries from an
authoritative source and publishes them in the distributed mapping
database. The Map-Server learns these entries 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 which is announcing and then
re-encapsulates and forwards it to a matching ETR. The Map-Server is
defined in [I-D.ietf-lisp-ms].
The Map-Server can be provided by the EID registrar or third parties.
For instance, a LISP site (i.e., ISP) requests a Provider Independent
(PI) set of addresses to an EID-registrar (i.e., RIPE). This
registrar configures its own Map-Server 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 through periodic authenticated Map-Register
messages. In this context there is a need for mechanisms to:
Jakab, et al. Expires April 1, 2011 [Page 13]
Internet-Draft LISP Deployment September 2010
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 server are desirable
and the LISP specification should describe appropriate mechanisms.
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. Damien Saucez and
Luigi Iannone provided helpful comments.
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-07 (work in progress), April 2010.
[I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6",
Jakab, et al. Expires April 1, 2011 [Page 14]
Internet-Draft LISP Deployment September 2010
draft-ietf-lisp-interworking-00 (work in progress),
May 2009.
[I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server",
draft-ietf-lisp-ms-05 (work in progress), April 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 1, 2011 [Page 15]
Internet-Draft LISP Deployment September 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 1, 2011 [Page 16]