~
Network Working Group D. Saucez (Ed.)
Internet-Draft INRIA
Intended status: Informational L. Iannone
Expires: August 24, 2013 Telecom ParisTech
F. Coras
Technical University of
Catalonia
February 20, 2013
LISP Impact
draft-saucez-lisp-impact-01.txt
Abstract
The Locator/Identifier Separation Protocol (LISP) aims at improving
the Internet scalability properties leveraging on three simple
principles: address role separation, encapsulation, and mapping. In
this document, based on implementation, deployment, and theoretical
studies, we discuss the impact that deployment of LISP has on both
the Internet in general and for the end-users in particular.
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 August 24, 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
Saucez (Ed.), et al. Expires August 24, 2013 [Page 1]
Internet-Draft LISP Impact February 2013
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. LISP in a nutshell . . . . . . . . . . . . . . . . . . . . . . 3
3. LISP for scaling the Internet . . . . . . . . . . . . . . . . 4
4. Beyond scaling the Internet . . . . . . . . . . . . . . . . . 5
4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 5
4.2. IPv4/IPv6 Transition . . . . . . . . . . . . . . . . . . . 6
4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . . 7
5. Impact of LISP on operations and business model . . . . . . . 7
5.1. Impact on non-LISP traffic and sites . . . . . . . . . . . 7
5.2. Impact on LISP traffic and sites . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
9.1. Normative References . . . . . . . . . . . . . . . . . . . 10
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Saucez (Ed.), et al. Expires August 24, 2013 [Page 2]
Internet-Draft LISP Impact February 2013
1. Introduction
The Locator/Identifier Separation Protocol (LISP) relies on three
simple principles to scale the Internet: address role separation,
encapsulation, and mapping. The main goal of LISP is to make the
Internet more scalable by reducing the number of prefixes announced
in the Default Free Zone (DFZ) as well as its related churn. As LISP
relies on mapping and encapsulation, it turns out that it provides
more benefits than just scalability. For example, LISP provides a
mean for a LISP site to precisely control its inter-domain outgoing
and incoming traffic, with the possibility to apply different
policies to the different domains exchanging traffic with it. LISP
can also be used during the IPv4/IPv6 transition phase as it allows
to transport IPv4 over IPv6 or IPv6 over IPv4. LISP also provides a
solution to perform inter-domain multicast.
This document discusses the impact of LISP's deployment on the
Internet and on end-users. We first show that the use of an
interworking infrastructure results in path stretch and there still
are many, economical rather than technical, open questions related to
the deployment of such infrastructure. Moreover, encapsulation may
raise some issues (that do not have a real impact in practice)
because it reduces the Maximum Transmission Unit (MTU) size. An
important impact of LISP on network operations is related to
resiliency and troubleshooting. Indeed, as LISP relies on cached
mappings and on encapsulation, troubleshooting is harder than in the
traditional Internet. Also, end-to-end encapsulation stresses
resiliency as it makes failure detection and recovery slower than
with hop-by-hop routing.
2. LISP in a nutshell
The Locator/Identifier Separation Protocol (LISP) relies on three
simple principles: address role separation, encapsulation, and
mapping.
Semantics of address are separated in two: the Routing Locators
(RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are assigned from
the address space of the Internet service providers. The EIDs are
attributed by block of contiguous addresses extracted from the EID
Space. To limit the scalability problem of today's Internet, only
the routes towards the RLOCs are announced in the Internet while EIDs
are also propagated today.
LISP routers are used at the boundary between the EID and the RLOC
spaces. Routers used to exit the EID space are called Ingress Tunnel
Router (ITRs) and those used to enter the EID space the Egress Tunnel
Saucez (Ed.), et al. Expires August 24, 2013 [Page 3]
Internet-Draft LISP Impact February 2013
Routers (ETRs). When a host sends a packet to a remote destination,
it sends it as in today's Internet. The packet eventually arrives at
the border of its site at an ITR. Because EIDs are not routable on
the Internet, the packet is encapsulated with the source address set
to the ITR RLOC and the destination address set to the ETR RLOC. The
encapsulated packet is then forwarded in the Internet until it
reaches the selected ETR. The ETR decapsulates the packet and
forwards it to the destination. The acronym xTR for Ingress/Egress
tunnel router is used for a router playing these two roles.
The correspondence between EIDs and RLOCs is given by the mappings.
When an ITR needs to find ETR RLOCs that serve an EID it queries the
mapping system. It is worth noticing that LISP is not restricted to
the Internet Protocol for the EID addresses. The LISP Canonical
Address Format (LCAF) allows encoding any kind of address
[I-D.farinacci-lisp-lcaf]. Therefore, any address type can be used
as EID (the address is the key for the mapping lookup) and LISP can
then transport, for example, Ethernet frames over the Internet.
A more thorough introduction to LISP can be found in
[I-D.chiappa-lisp-introduction] and a discussion around the
architecture in [I-D.chiappa-lisp-architecture]. The complete
specifications are given in [RFC6830], [RFC6833],
[I-D.fuller-lisp-ddt], [RFC6836], [RFC6832], [RFC6834], and
[I-D.ietf-lisp-sec].
3. LISP for scaling the Internet
The first goal of LISP is to scale the Internet. LISP improves the
internet's scalability because traffic engineering and stub
announcements are not propagated in the core, so routing tables are
smaller and more stable (i.e., less affected by churn). Also, edge
network routing tables are populated on demanded therefore, for each
edge network they scale with the traffic matrix and independent of
the Internet's size. Scaling improvement is proven by several works.
Quoitin et al. show in [QIdLB07] that the locator/identifier
separation improves the routing scalability by reducing the RIB size
(up to one order of magnitude) and increases the path diversity and
thus the traffic engineering capabilities. In addition, Iannone and
Bonaventure show in [IB07] that the number of mapping entries that
must be supported at an ITR of a campus network is limited and does
not represent more that 3 to 4 Megabytes of memory. Furthermore,
they show that signaling traffic (i.e., Map-Request/Map-Reply
packets) is in the same order of magnitude like DNS requests traffic
and that encapsulation overhead, while not negligible, is very
limited (in the order of few percentage points of the total traffic
Saucez (Ed.), et al. Expires August 24, 2013 [Page 4]
Internet-Draft LISP Impact February 2013
volume). Similarly, Juhoon et al. show that the EID-to-RLOC Cache
size should not exceed 14 MB for an ITR responsible of more than
20,000 residential ADSL users at a large ISP [KIF11]. [IB07],
[KIF11] rely on BGP and traffic traces to determine the number of
entries to keep in the cache. In both papers, the size of the cache
is inferred from the number of entries by considering that every EID
is associated with two or three locators. [S11] confirms these
results by looking at the distribution of the number of locators per
EID if LISP were deployed in today's Internet. The assumptions in
these studies are:
o contiguous addresses tend to be used similarly, EID prefixes
follow the current BGP prefixes decomposition;
o EIDs are used only at the stub ASes, not in the transit ASes;
o the RLOCs of an EID are deployed at the edge between the stubs
owning the EID and the providers and locator addresses are
allocated in a Provider Aggregetable (PA) mode.
[CCD12] generalizes the caching discussion and proposes an analytic
model for the EID-to-RLOC cache size when prefix-level traffic has a
stationary generating process. The model shows that miss rate can be
accurately predicted from the cache size and a small set of easily
measurable traffic parameters, meaning that operators can provision
the EID-to-RLOC cache of their ITRs according to the miss rate they
want to achieve for their given traffic.
4. Beyond scaling the Internet
Even though it is its main goal, LISP is more than just a scalability
solution, it is also a tool to provide both incoming and outgoing
traffic engineering [S11], can be used as an IPv6 transition at the
routing level, and inter-domain multicast [RFC6831],
[I-D.coras-lisp-re]. LISP has also proven to be a good protocol for
mobility of devices in the Internet [I-D.meyer-lisp-mn] or even
virtual machine mobility in data centers and multi-tenant VPN,
however, we don't further discuss these two last points as they are
out of the scope of the charter.
4.1. Traffic engineering
In today's Internet, stub networks are globally routable and the
routing system distributes the routes to reach these stubs. On the
contrary, the EID prefixes of a LISP site are not routable on the
Internet and mappings are needed to determine the list of LISP
routers to contact to send them packets. The difference is
Saucez (Ed.), et al. Expires August 24, 2013 [Page 5]
Internet-Draft LISP Impact February 2013
significant for two reasons. First, packets are not sent to a site
but to a specific ingress router. Second, a site can control the
entry points for its traffic by controlling its mappings.
For traffic engineering purpose, a mapping associates an EID prefix
to a list of RLOCs. Each RLOC is annotated with a priority and a
weight. When there are several RLOCs, the ITR selects the one with
the lowest priority value and sends the encapsulated packet to this
RLOC. If several such RLOCs exist, then the traffic is balanced
proportionally to the weight among the RLOCs with the lowest priority
value. Traffic engineering in LISP thus allows the mapping owner to
have a fine-grained control on the primary and backup path its
incoming and outgoing packets use. In addition, it can share the
load among its links. An example of the use of such a feature is
described in [SDIB08], where Saucez et al. show how to use LISP to
direct different type of traffic (e.g., video vs. ftp) on different
links having different capacity.
Traffic engineering in LISP goes one step further. Indeed, every
Map-Request contains the Source EID Address of the packet that caused
a cache miss and triggered the Map-Request. It is thus possible for
a mapping owner to differentiate the answer (Map-Reply) it gives to
Map-Requests based on the requester. This functionality is not
available today because a domain cannot control exactly the routes
that will be received by domains that are not in the direct
neighborhood.
4.2. IPv4/IPv6 Transition
The LISP encapsulation mechanism is designed to support any
combination of locators and identifiers address family. It is then
possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa. This
allows transporting IPv6 packets over an IPv4 network (or IPv4
packets over an IPv6 network), thus enabling the use of LISP as an
IPv6 transition mechanism.
A not so uncommon example is the case of the network infrastructure
of a datacenter being IPv4-only while dual-stack front-end load
balancers are used. In this scenario, LISP can be used to provide
IPv6 access to servers even though the network and the servers only
support IPv4. Assuming that the datacenter's ISP offers IPv6
connectivity, the datacenter only needs to deploy one (or more)
xTR(s) at its border with the ISP and one (or more) xTR(s) directly
connected to the load balancers. The xTR(s) at the ISP's border
tunnels IPv6 packets over IPv4 to the xTR(s) directly attached to the
load balancer. The load balancer's xTR decapsulates the packets and
forward them to the load balancer, which act as proxies, translating
each IPv6 packet into an IPv4. IPv4 packets are then sent to the
Saucez (Ed.), et al. Expires August 24, 2013 [Page 6]
Internet-Draft LISP Impact February 2013
appropriate servers. Similarly, when the server's response arrives
at the load balancer, the packet is translated back into an IPv6
packet and forwarded to its xTR(s), which in turn will tunnel it
back, over the IPv4-only infrastructure, to an xTR connected to the
ISP. The packet is then decapsulated and forwarded to the ISP
natively in IPv6.
4.3. Inter-domain multicast
LISP has native support for multicast [RFC6831]. From the data-plane
perspective, at a multicast enabled xTR, an EID sourced multicast
packet is encapsulated in another multicast packet and subsequently
forwarded in a RLOC-level distribution tree. Therefore, xTRs must
participate in both EID and RLOC level distribution trees. Control-
plane wise, since group addresses have no topological significance
they need not be mapped. It is worth noting that, to properly
function inter-domain, LISP-Multicast requires that inter-domain
multicast be prior deployed.
[I-D.coras-lisp-re] and [CDM+12] propose a technique to construct xTR
based inter-domain multicast distribution trees. Simulations of
three different management strategies for low latency content
delivery show that such overlays can support thousands of member
xTRs, hundreds of thousands of end-hosts and deliver content at
latencies close to unicast ones [CDM+12]. It was also observed that
high client churn has a limited impact on performance and management
overhead.
5. Impact of LISP on operations and business model
Important implementation efforts ([IOS/NXOS], [OpenLISP], [LISPmob],
and [LISP+Click]) have been made to assess the specifications and
interoperability tests [Was09] have been a success. Large scale
deployment in the international lisp4.net testbed, which is currently
composed of nodes running at least three different implementations,
allows to learn operational matters related to LISP.
We have to distinguish the impact of LISP on LISP sites from the
impact on non-LISP sites.
5.1. Impact on non-LISP traffic and sites
LISP has no impact on traffic which has neither LISP origin nor LISP
destination. However, LISP can have a significant impact on traffic
between a LISP site and a non-LISP site. Traffic between a non-LISP
site and a LISP site are subject to the same issues than those
observed for LISP-to-LISP traffic (cf supra) but also have issues
Saucez (Ed.), et al. Expires August 24, 2013 [Page 7]
Internet-Draft LISP Impact February 2013
specific to the transition mechanism that allow LISP site to exchange
packets with non-LISP site ([RFC6832], [I-D.ietf-lisp-deployment]).
Indeed, the transition requires proxies tunnel routers (PxTRs).
PxTRs do not cause particular technical issue. However, by
definition proxies cause path stretch and make troubleshooting
harder. There are still big questions related to PxTRs that have to
be answered:
o Where to deploy PxTRs? The placement in the topology has an
important impact on the path stretch.
o How many PxTRs? The number of PxTR has a direct impact on the
load and the impact of the failure of a PxTR on the traffic.
o What part of the EID space? Will all the PxTRs be proxies for the
whole EID space or will it be segmented between different PxTRs?
o Who to operate PxTRs? The IETF does not aim at providing business
model hints, however, an important question to answer is related
to the entities that will deploy PxTRs, how they will earn money
and how the traffic will be carried with respect for the security
and privacy.
PxTR also normally have to advertise the EID prefix they are proxy
for in BGP. However, if proxies are managed by different entities,
they will belong to different ASes. In this case, we have to be sure
that it will not cause MOA issues that could negatively influence
routing.
5.2. Impact on LISP traffic and sites
LISP is a protocol based on the map-and-encap paradigm which has the
positive effects that we have given in the sections above. However,
by design, LISP also have side impact on operations:
MTU issue: as LISP uses encapsulation, the MTU is reduced (by 36
bytes in IPv4), this has implication on potentially all the
traffic. However, in practice, on the lisp4.net network, it
has not been seen major issue due to the MTU. This is probably
due to the fact that current end-host stacks are well designed
to deal with the problem of MTU.
Resiliency issue: the advantage of flexibility and control offered
by the Locator/ID separation comes at the cost of increasing
the complexity of the reachability detection. Indeed,
identifiers are not directly routable and have to be mapped to
locators. But a locator may be unreachable while others are
Saucez (Ed.), et al. Expires August 24, 2013 [Page 8]
Internet-Draft LISP Impact February 2013
still reachable. This is an important problem for any tunnel-
based solution. In the current Internet, packets are forwarded
independently of the border router of the network meaning that
in case of the failure of a border router, another one can be
used. With LISP, the destination RLOC specifically designate
one particular ETR, hence if this ETR fails, the traffic is
dropped even though other ETRs are available for the
destination site. Another resiliency issue is linked to the
fact that mappings are learned on demand. When an ITR fails,
all its traffic is redirected to other ITRs that might not have
yet the mappings for the redirected traffic. The study in
[SKI+12] and [SD12] show, based on measurements and traffic
traces, that failure of ITRs and RLOC are infrequent but that
when such failure happens, an important number of packet can be
dropped. Unfortunately, the current techniques for LISP
resiliency, based on monitoring or probing are not rapid enough
(failure recovery of the order of a few seconds). To tackle
this issue [I-D.bonaventure-lisp-preserve] and
[I-D.saucez-lisp-itr-graceful] propose techniques based on
local failure detection and recovery.
Middle boxes/filters: because of encapsulation, the middle boxes
might not understand the traffic which can cause firewall to
drop legitimate packets. In addition, LISP allows triangular
or even rectangular routing, so it is hard to maintain a
correct state even if the middle box perfectly understands
LISP. Finally, filtering might also have problems because they
might think only one host is generating the traffic (the ITR),
as long as it is not decapsulated.
Troubleshooting/debugging: the major issue years of LISP
experimentation have shown is the difficulty of
troubleshooting. When there is a problem in the network, it is
hard to pin-point the reason as the operator only has a partial
view of the network. The operator can see what is in its
cache/database, and can try to obtain what is potentially
elsewhere by querying the Map Resolvers but the knowledge
remains partial. On top of that, ICMP is too small, which
means that when an ICMP arrives at the ITR, it might not
contain enough information to troubleshoot correctly.
Furthermore, deployment in the beta network has shown that
LISP+ALT was not easy to maintain and control, hence the
migration to LISP-DDT.
Business: the IETF is not aiming at providing business models.
However, even though [IL10] shown that there is economical
incentives to migrate to LISP, some questions are on hold. For
example, how will the EIDs be allocated to allow aggregation
Saucez (Ed.), et al. Expires August 24, 2013 [Page 9]
Internet-Draft LISP Impact February 2013
and hence scalability of the mapping system? Who will operate
the mapping system infrastructure and for what benefit?
6. IANA Considerations
This document makes no request to the IANA.
7. Security Considerations
Security and threats analysis of the LISP protocol is out of the
scope of the present document. A thorough analysis of LISP security
threats is detailed in [I-D.ietf-lisp-threats].
8. Acknowledgments
The people that contributed to this document are: Florin Coras, Vince
Fuller, Joel Halpern, Terry Manderson, and Gregg Schudel.
9. References
9.1. Normative References
[I-D.fuller-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-fuller-lisp-ddt-04 (work
in progress), September 2012.
[I-D.ietf-lisp-deployment]
Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "LISP Network Element
Deployment Considerations", draft-ietf-lisp-deployment-06
(work in progress), January 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.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast
Saucez (Ed.), et al. Expires August 24, 2013 [Page 10]
Internet-Draft LISP Impact February 2013
Environments", RFC 6831, 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.
[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.
9.2. Informative References
[CCD12] Coras, F., Cabellos-Aparicio, A., and J. Domingo-Pascual,
"An Analytical Model for the LISP Cache Size", In Proc.
IFIP Networking 2011.
[CDM+12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D.,
and A. Cabellos-Aparicio, "Lcast: Software-defined Inter-
Domain Multicast", Technical Report, Universitat
Politecnica de Catalunya, 2012.
[I-D.bonaventure-lisp-preserve]
Bonaventure, O., Francois, P., and D. Saucez, "Preserving
the reachability of LISP ETRs in case of failures",
draft-bonaventure-lisp-preserve-00 (work in progress),
July 2009.
[I-D.chiappa-lisp-architecture]
Art, Y., "An Architectural Perspective on the LISP
Location-Identity Separation System",
draft-chiappa-lisp-architecture-01 (work in progress),
July 2012.
[I-D.chiappa-lisp-introduction]
Art, Y., "An Introduction to the LISP Location-Identity
Separation System", draft-chiappa-lisp-introduction-01
(work in progress), July 2012.
[I-D.coras-lisp-re]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Saucez (Ed.), et al. Expires August 24, 2013 [Page 11]
Internet-Draft LISP Impact February 2013
Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-01 (work in progress),
January 2013.
[I-D.farinacci-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-farinacci-lisp-lcaf-10 (work
in progress), July 2012.
[I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-03 (work in progress),
October 2012.
[I-D.meyer-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-meyer-lisp-mn-08 (work in progress),
October 2012.
[I-D.saucez-lisp-itr-graceful]
Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils,
"LISP ITR Graceful Restart",
draft-saucez-lisp-itr-graceful-01 (work in progress),
December 2012.
[IB07] Iannone, L. and O. Bonaventure, "On the cost of caching
locator/id mappings", In Proc. ACM CoNEXT 2007.
[IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID
Separation for the Future Internet", Book Chapter,
Towards the Future Internet - Emerging Trends from the
European Research, IOS Press.
[IOS/NXOS]
Cisco Systems Inc., "Locator/ID Separation Protocol
(LISP)", http://lisp4.cisco.com.
[KIF11] Kim, J., Iannone, L., and A. Feldmann, "Deep dive into the
lisp cache and what isps should know about it", In Proc.
IFIP Networking 2011.
[LISP+Click]
Saucez, D. and V. Nguyen, "LISP-Click: A Click
implementation of the Locator/ID Separation Protocol",
1st Symposium on Click Modular Router, 2009.
[LISPmob] "LISP Mobile Node for Linux", http://lispmob.org.
Saucez (Ed.), et al. Expires August 24, 2013 [Page 12]
Internet-Draft LISP Impact February 2013
[OpenLISP]
"The OpenLISP Project", http://www.openlisp.org.
[QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O.
Bonaventure, "Evaluating the benefits of the locator/
identifier separation", In Proc. ACM MobiArch 2007.
[S11] Saucez, D., "Mechanisms for Interdomain Traffic
Engineering with LISP", PhD Thesis, Universite catholique
de Louvain, 2011.
[SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in
LISP", In Proc. IFIP Networking 2012.
[SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure,
"Interdomain Traffic Engineering in a Locator/Identifier
Separation Context", In Proc. of Internet Network
Management Workshop, 2008.
[SKI+12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C.
Filsfils, "A Local Approach to Fast Failure Recovery of
LISP Ingress Tunnel Routers", In Proc. IFIP Networking
2012.
[Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76,
LISP WG presentation, 2009..
Authors' Addresses
Damien Saucez
INRIA
2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex
France
Email: damien.saucez@inria.fr
Luigi Iannone
Telecom ParisTech
23, Avenue d'Italie, CS 51327
75214 PARIS Cedex 13
France
Email: luigi.iannone@telecom-paristech.fr
Saucez (Ed.), et al. Expires August 24, 2013 [Page 13]
Internet-Draft LISP Impact February 2013
Florin Coras
Technical University of Catalonia
C/Jordi Girona, s/n
08034 Barcelona
Spain
Email: fcoras@ac.upc.edu
Saucez (Ed.), et al. Expires August 24, 2013 [Page 14]