draft-ietf-lisp-impact-01.txt   draft-ietf-lisp-impact-02.txt 
Network Working Group D. Saucez Network Working Group D. Saucez
Internet-Draft INRIA Internet-Draft INRIA
Intended status: Informational L. Iannone Intended status: Informational L. Iannone
Expires: September 7, 2015 Telecom ParisTech Expires: November 8, 2015 Telecom ParisTech
A. Cabellos A. Cabellos
F. Coras F. Coras
Technical University of Catalonia Technical University of
March 6, 2015 Catalonia
May 7, 2015
LISP Impact LISP Impact
draft-ietf-lisp-impact-01.txt draft-ietf-lisp-impact-02.txt
Abstract Abstract
The Locator/Identifier Separation Protocol (LISP) aims at improving The Locator/Identifier Separation Protocol (LISP) aims at improving
the Internet scalability properties leveraging on three simple the Internet scalability properties leveraging on three simple
principles: address role separation, encapsulation, and mapping. In principles: address role separation, encapsulation, and mapping. In
this document, based on implementation work, deployment experiences, this document, based on implementation work, deployment experiences,
and theoretical studies, we discuss the impact that the deployment of and theoretical studies, we discuss the impact that the deployment of
LISP can have on both the Internet in general and the end-user in LISP can have on both the Internet in general and the end-user in
particular. particular.
Status of This Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 7, 2015. This Internet-Draft will expire on November 8, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LISP in a nutshell . . . . . . . . . . . . . . . . . . . . . 3 2. LISP in a nutshell . . . . . . . . . . . . . . . . . . . . . . 3
3. LISP for scaling the Internet . . . . . . . . . . . . . . . . 4 3. LISP for scaling the Internet . . . . . . . . . . . . . . . . 4
4. Beyond scaling the Internet . . . . . . . . . . . . . . . . . 6 4. Beyond scaling the Internet . . . . . . . . . . . . . . . . . 6
4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 7 4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 7
4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 7 4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . . 8
4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . 8 4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . . 8
5. Impact of LISP on operations and business model . . . . . . . 9 5. Impact of LISP on operations and business model . . . . . . . 9
5.1. Impact on non-LISP traffic and sites . . . . . . . . . . 9 5.1. Impact on non-LISP traffic and sites . . . . . . . . . . . 9
5.2. Impact on LISP traffic and sites . . . . . . . . . . . . 10 5.2. Impact on LISP traffic and sites . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
The Locator/Identifier Separation Protocol (LISP) relies on three The Locator/Identifier Separation Protocol (LISP) relies on three
simple principles to improve the scalability properties of the simple principles to improve the scalability properties of the
Internet: address role separation, encapsulation, and mapping. The Internet: address role separation, encapsulation, and mapping. The
main goal of LISP is to make the Internet more scalable by reducing 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 the number of prefixes announced in the Default Free Zone (DFZ). As
LISP relies on mapping and encapsulation, it turns out that it LISP relies on mapping and encapsulation, it turns out that it
provides more benefits than just increased scalability. For provides more benefits than just increased scalability. For
skipping to change at page 4, line 21 skipping to change at page 4, line 41
The original goal of LISP is to improve the scalability properties of The original goal of LISP is to improve the scalability properties of
the Internet architecture. LISP achieves such a target thanks to the Internet architecture. LISP achieves such a target thanks to
traffic engineering and stub AS prefixes not announced anymore in the traffic engineering and stub AS prefixes not announced anymore in the
DFZ, so that routing tables are smaller and more stable (i.e., they DFZ, so that routing tables are smaller and more stable (i.e., they
experience less churn). Furthermore, at the edge network, experience less churn). Furthermore, at the edge network,
information necessary to forward packets (i.e., the mappings) is information necessary to forward packets (i.e., the mappings) is
obtained on demand using a pull model (whereas the current Internet obtained on demand using a pull model (whereas the current Internet
uses a push model, instantiated by BGP). Therefore, scalability of uses a push model, instantiated by BGP). Therefore, scalability of
edge networks is now independent of the Internet's size and is now edge networks is now independent of the Internet's size and is now
related its traffic matrix. This scaling improvement is proven by related its traffic matrix. This scaling improvement is proven by
several works. several works. The research work cited hereafter is based on the
following assumptions:
Quoitin et al. [QIdLB07] show that the separation between locator
and identifier roles at the network level improves the routing
scalability by reducing the Routing Information Base (RIB) size (up
to one order of magnitude) and increases path diversity and thus the
traffic engineering capabilities. For instance, at the time of
writting, [CAIDA] list 49,757 ASes among which 85% are stub which
means that with LISP the number of ASes advertising prefixes could be
reduced by 85%.
In addition, Iannone and Bonaventure [IB07] show that the number of
mapping entries that must be handled by an ITR of a campus network
with 10,000 users is limited to few tens of thousands, and does not
represent more than 3 to 4 Megabytes of memory. Furthermore, they
show that the signaling traffic (i.e., Map-Request/Map-Reply packets)
is in the same order of magnitude like DNS requests/reply traffic and
that the encapsulation overhead, while not negligible, is very
limited (in the order of few percentage points of the total traffic
volume). Similarly, Kim et al. [KIF11] show that the EID-to-RLOC
cache size of an ITR responsible of more than 20,000 residential ADSL
users of a large ISP is still in the order of few tens of thousands
entries and should not exceed 14 Megabytes. These two studies rely
on BGP and traffic traces to determine the number of entries to keep
in the EID-to-RLOC 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. Saucez [S11] confirms these
results by looking at the distribution of the number of locators per
EID if LISP were deployed in the 2010's Internet. The assumptions in
these studies are:
o contiguous addresses tend to be used similarly and EID prefixes o EID-to-RLOC mappings follow the same prefix size as the current
follow the current BGP prefixes decomposition; BGP routing infrastructure;
o EIDs are used only at the stub ASes, not in the transit ASes; o EIDs are used only at the stub ASes, not in the transit ASes;
o the RLOCs of an EID prefix are deployed at the edge between the o the RLOCs of an EID prefix are deployed at the edge between the
stubs owning the EID prefix and the providers, allocating the stubs owning the EID prefix and the providers, allocating the
RLOCs in a Provider Aggregetable (PA) mode. RLOCs in a Provider Aggregetable (PA) mode.
While all previous studies consider the case of a timer-based cache The above assumptions are inline with [RFC7215] and current LISP
eviction policy (i.e., mappings are deleted from the cache upon deployments, however, such situation may change in the long term.
timeout), Coras et al. [CCD12] have a more general approach for the Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space
Least Recently Used (LRU) eviction policy, proposing an analytic sizes, still showing results that are consitent and equivalent to the
model for the EID-to-RLOC cache size when prefix-level traffic has a above assumptions.
stationary generating process. The model shows that miss rate can be
accurately predicted from the EID-to-RLOC cache size and a small set Quoitin et al. [QIdLB07] show that the separation between locator
of easily measurable traffic parameters. The model was validated and identifier roles at the network level improves the routing
using four one-day-long packet traces collected at egress points of a scalability by reducing the Routing Information Base (RIB) size (up
campus network and an academic exchange point considering EID- to one order of magnitude) and increases path diversity and thus the
prefixes as being of BGP-prefix granularity. Consequently, operators traffic engineering capabilities. [IB07] and [KIF13] show, based on
can provision the EID-to-RLOC cache of their ITRs according to the real Internet traffic traces that the number of mapping entries that
miss rate they want to achieve for their given traffic. must be handled by an ITR of a network with up to 20,000 users is
limited to few tens of thousands; that the signaling traffic (i.e.,
Map-Request/Map-Reply packets) is in the same order of magnitude like
DNS requests/reply traffic; that the encapsulation overhead, while
not negligible, is very limited (in the order of few percentage
points of the total traffic volume).
Previous studies consider the case of a timer-based cache eviction
policy (i.e., mappings are deleted from the cache upon timeout),
while [CDLC] has a more general approach based on the Least Recently
Used (LRU) eviction policy, proposing 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 EID-to-RLOC cache size and a small set of easily
measurable traffic parameters. The model was validated using four
one-day-long packet traces collected at egress points of a campus
network and an academic exchange point considering EID-prefixes as
being of the same size as BGP prefixes. Consequently, operators can
provision the EID-to-RLOC cache of their ITRs according to the miss
rate they want to achieve for their given traffic.
Results indicate that for a given target miss-ratio, the size of the Results indicate that for a given target miss-ratio, the size of the
cache depends only on the parameters of the popularity distribution, cache depends only on the parameters of the popularity distribution,
being independent of the number of users (the size of the LISP site) being independent of the number of users (the size of the LISP site)
and the number of destinations (the size of the EID-prefix space). and the number of destinations (the size of the EID-prefix space).
Assuming that the popularity distribution remains constant, this Assuming that the popularity distribution remains constant, this
means that as the number of users and the number of destinations means that as the number of users and the number of destinations
grow, the cache size needed to obtain a given miss rate remains grow, the cache size needed to obtain a given miss rate remains
constant O(1). constant O(1).
Under normal user traffic, miss-ratio decreases at an accelerated LISP usually populates its EID-to-RLOC cache in a pull mode which
pace with cache size and finally settles to a power-law decrease. means that mappings are retrieved on demand by the ITR. The main
However, Coras et al. [CDLC] extends the previous model to account advantage is that the EID-to-RLOC cache size only depens on the
for scanning attacks, whereby attackers generate a constant flow of traffic characteristics at the ITR and is independent of the size of
packets according to random scans of the destination prefix space and the Internet. This benefit comes at the cost of some delay to
shows that miss-ratios are very high and independent of the cache transmit the packets that do not hit an entry in the cache, for which
size. In fact, if the attack is merely 1% of the legitimate traffic, a mapping has to be learned. This delay is bound by the time
the miss rate does not drop under 1% as long as the cache cannot necessary to retrieve the mapping from the mapping system. Moreover,
accommodate the whole prefix space. Locality measurements also similarly to a push model (e.g., BGP), the pull model induces
suggested that LRU eviction policy should be close to optimal. signaling messages that correspond to the retrieval of mappings upon
cache miss. The difference being that the signaling load only
TBD: add a paragraph to explain the operational difference while depends on the traffic at the ITR and is not triggered by external
dealing with a pull model instead of a push. events such as in BGP. [CDLC] shows that the miss rate is a function
of the EID-to-RLOC cache size and traffic generation process and
[CDLC], [SDIB08], and [SDIB08] show from traffic traces that in
practice the cache miss rate, and thus the signaling rate, remain
low.
4. Beyond scaling the Internet 4. Beyond scaling the Internet
Even though it is its main goal, LISP is more than just a scalability 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 solution, it is also a tool to provide both incoming and outgoing
traffic engineering ([S11], [I-D.farinacci-lisp-te]) can be used as traffic engineering ([S11], [I-D.farinacci-lisp-te]) can be used as
an IPv6 transition at the routing level, and for inter-domain an IPv6 transition at the routing level, and for inter-domain
multicast ([RFC6831], [I-D.coras-lisp-re]). LISP has also proven to multicast ([RFC6831], [I-D.coras-lisp-re]). LISP has also proven to
be a good protocol for devices' Internet mobility be a good protocol for devices' Internet mobility
([I-D.meyer-lisp-mn]) or even virtual machines' mobility in data ([I-D.meyer-lisp-mn]) or even virtual machines' mobility in data
skipping to change at page 12, line 8 skipping to change at page 12, line 18
7. Security Considerations 7. Security Considerations
Security and threats analysis of the LISP protocol is out of the Security and threats analysis of the LISP protocol is out of the
scope of the present document. A thorough analysis of LISP security scope of the present document. A thorough analysis of LISP security
threats is detailed in [I-D.ietf-lisp-threats]. threats is detailed in [I-D.ietf-lisp-threats].
8. Acknowledgments 8. Acknowledgments
The people that contributed to this document are Sharon Barkai, Vince The people that contributed to this document are Sharon Barkai, Vince
Fuller, Joel Halpern, Terry Manderson, and Gregg Schudel. Fuller, Joel Halpern, Terry Manderson, Gregg Schudel, Ron Bonica,
Ross Callon.
The work of Luigi Iannone has been partially supported by the ANR- The work of Luigi Iannone has been partially supported by the ANR-13-
13-INFR-0009 LISP-Lab Project (www.lisp-lab.org). INFR-0009 LISP-Lab Project (www.lisp-lab.org).
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
progress), October 2014.
[RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The
Locator/ID Separation Protocol (LISP)", RFC 6830, January Locator/ID Separation Protocol (LISP)", RFC 6830,
2013. January 2013.
[RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The [RFC6831] Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas, "The
Locator/ID Separation Protocol (LISP) for Multicast Locator/ID Separation Protocol (LISP) for Multicast
Environments", RFC 6831, January 2013. Environments", RFC 6831, January 2013.
[RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, [RFC6832] Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking between Locator/ID Separation Protocol "Interworking between Locator/ID Separation Protocol
(LISP) and Non-LISP Sites", RFC 6832, January 2013. (LISP) and Non-LISP Sites", RFC 6832, January 2013.
[RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation [RFC6833] Fuller, V. and D. Farinacci, "Locator/ID Separation
Protocol (LISP) Map-Server Interface", RFC 6833, January Protocol (LISP) Map-Server Interface", RFC 6833,
2013. January 2013.
[RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID [RFC6834] Iannone, L., Saucez, D., and O. Bonaventure, "Locator/ID
Separation Protocol (LISP) Map-Versioning", RFC 6834, Separation Protocol (LISP) Map-Versioning", RFC 6834,
January 2013. January 2013.
[RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, [RFC6836] Fuller, V., Farinacci, D., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol Alternative Logical "Locator/ID Separation Protocol Alternative Logical
Topology (LISP+ALT)", RFC 6836, January 2013. Topology (LISP+ALT)", RFC 6836, January 2013.
[RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- [RFC7215] Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
Pascual, J., and D. Lewis, "Locator/Identifier Separation Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment Protocol (LISP) Network Element Deployment
Considerations", RFC 7215, April 2014. Considerations", RFC 7215, April 2014.
9.2. Informative References 9.2. Informative References
[CAIDA] "AS Relationships",
http://data.caida.org/datasets/as-relationships/, 2015.
[CCD12] Coras, F., Cabellos-Aparicio, A., and J. Domingo-Pascual,
"An Analytical Model for the LISP Cache Size", In Proc.
IFIP Networking 2012, May 2012.
[CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An [CDLC] Coras, F., Domingo, J., Lewis, D., and A. Cabellos, "An
Analytical Model for Loc/ID Mappings Caches", IEEE Analytical Model for Loc/ID Mappings Caches", IEEE
Transactions on Networking, 2014. Transactions on Networking, 2014.
[CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D., [CDM12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D.,
and A. Cabellos-Aparicio, "Lcast: Software-defined Inter- and A. Cabellos-Aparicio, "Lcast: Software-defined Inter-
Domain Multicast", Elsevier Computer Networks, July 2014. Domain Multicast", Elsevier Computer Networks, July 2014.
[I-D.bonaventure-lisp-preserve] [I-D.bonaventure-lisp-preserve]
Bonaventure, O., Francois, P., and D. Saucez, "Preserving Bonaventure, O., Francois, P., and D. Saucez, "Preserving
the reachability of LISP ETRs in case of failures", draft- the reachability of LISP ETRs in case of failures",
bonaventure-lisp-preserve-00 (work in progress), July draft-bonaventure-lisp-preserve-00 (work in progress),
2009. July 2009.
[I-D.coras-lisp-re] [I-D.coras-lisp-re]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-06 (work in progress), Engineering", draft-coras-lisp-re-07 (work in progress),
October 2014. April 2015.
[I-D.farinacci-lisp-mr-signaling] [I-D.farinacci-lisp-mr-signaling]
Farinacci, D. and M. Napierala, "LISP Control-Plane Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06
(work in progress), February 2015. (work in progress), February 2015.
[I-D.farinacci-lisp-signal-free-multicast] [I-D.farinacci-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-farinacci-lisp-signal-free-multicast-02 (work in draft-farinacci-lisp-signal-free-multicast-02 (work in
progress), December 2014. progress), December 2014.
[I-D.farinacci-lisp-te] [I-D.farinacci-lisp-te]
Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic
Engineering Use-Cases", draft-farinacci-lisp-te-07 (work Engineering Use-Cases", draft-farinacci-lisp-te-08 (work
in progress), September 2014. in progress), March 2015.
[I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in
progress), April 2015.
[I-D.ietf-lisp-lcaf] [I-D.ietf-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-ietf-lisp-lcaf-07 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-08 (work in
progress), December 2014. progress), April 2015.
[I-D.ietf-lisp-threats] [I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-12 (work in progress), Analysis", draft-ietf-lisp-threats-12 (work in progress),
March 2015. March 2015.
[I-D.meyer-lisp-mn] [I-D.meyer-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-meyer-lisp-mn-12 (work in progress), Mobile Node", draft-meyer-lisp-mn-12 (work in progress),
January 2015. January 2015.
[I-D.saucez-lisp-itr-graceful] [I-D.saucez-lisp-itr-graceful]
Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils, Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils,
"LISP ITR Graceful Restart", draft-saucez-lisp-itr- "LISP ITR Graceful Restart",
graceful-03 (work in progress), December 2013. draft-saucez-lisp-itr-graceful-03 (work in progress),
December 2013.
[IB07] Iannone, L. and O. Bonaventure, "On the cost of caching [IB07] Iannone, L. and O. Bonaventure, "On the cost of caching
locator/id mappings", In Proc. ACM CoNEXT 2007, December locator/id mappings", In Proc. ACM CoNEXT 2007,
2007. December 2007.
[IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID [IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID
Separation for the Future Internet", Book Chapter, Towards Separation for the Future Internet", Book Chapter,
the Future Internet - Emerging Trends from the European Towards the Future Internet - Emerging Trends from the
Research, IOS Press, May 2010. European Research, IOS Press, May 2010.
[IOSNXOS] Cisco Systems Inc., , "Locator/ID Separation Protocol [IOSNXOS] Cisco Systems Inc., "Locator/ID Separation Protocol
(LISP)", http://lisp4.cisco.com, 2013. (LISP)", http://lisp4.cisco.com, 2013.
[KIF11] Kim, J., Iannone, L., and A. Feldmann, "Deep dive into the [KIF13] Kim, J., Iannone, L., and A. Feldmann, "Caching Locator/ID
lisp cache and what isps should know about it", In Proc. Mappings: Scalability Analysis and Implications",
IFIP Networking 2011, May 2011. Elsevier Computer Networks Journal, March 2013.
[LISPClick] [LISPClick]
Saucez, D. and V. Nguyen, "LISP-Click: A Click Saucez, D. and V. Nguyen, "LISP-Click: A Click
implementation of the Locator/ID Separation Protocol", 1st implementation of the Locator/ID Separation Protocol",
Symposium on Click Modular Router, 2009, November 2009. 1st Symposium on Click Modular Router, 2009,
November 2009.
[LISPcp] "The lip6-lisp Project", https://github.com/lip6-lisp/, [LISPcp] "The lip6-lisp Project", https://github.com/lip6-lisp/,
2014. 2014.
[LISPfritz] [LISPfritz]
"Unsere FRITZ!Box-Produkte", "Unsere FRITZ!Box-Produkte",
http://avm.de/produkte/fritzbox/, 2014. http://avm.de/produkte/fritzbox/, 2014.
[LISPmob] "LISP Mobile Node for Linux", http://lispmob.org, 2013. [LISPmob] "An open-source LISP implementation for Linux, Android and
OpenWRT", http://lispmob.org, 2015.
[OpenLISP] [OpenLISP]
"The OpenLISP Project", http://www.openlisp.org, 2013. "The OpenLISP Project", http://www.openlisp.org, 2013.
[QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. [QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O.
Bonaventure, "Evaluating the benefits of the locator/ Bonaventure, "Evaluating the benefits of the locator/
identifier separation", In Proc. ACM MobiArch 2007, May identifier separation", In Proc. ACM MobiArch 2007,
2007. May 2007.
[S11] Saucez, D., "Mechanisms for Interdomain Traffic [S11] Saucez, D., "Mechanisms for Interdomain Traffic
Engineering with LISP", PhD Thesis, Universite catholique Engineering with LISP", PhD Thesis, Universite catholique
de Louvain, 2011, October 2011. de Louvain, 2011, October 2011.
[SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in [SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in
LISP", In Proc. IFIP Networking 2012, May 2012. LISP", In Proc. IFIP Networking 2012, May 2012.
[SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, [SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure,
"Interdomain Traffic Engineering in a Locator/Identifier "Interdomain Traffic Engineering in a Locator/Identifier
Separation Context", In Proc. of Internet Network Separation Context", In Proc. of Internet Network
Management Workshop, 2008, October 2008. Management Workshop, 2008, October 2008.
[SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C. [SKI12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C.
Filsfils, "A Local Approach to Fast Failure Recovery of Filsfils, "A Local Approach to Fast Failure Recovery of
LISP Ingress Tunnel Routers", In Proc. IFIP Networking LISP Ingress Tunnel Routers", In Proc. IFIP Networking
2012, May 2012. 2012, May 2012.
[Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76, [Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76,
LISP WG presentation, 2009., November 2009. LISP WG presentation, 2009., November 2009.
[lispfirewall] [lispfirewall]
"LISP and Zone-Based Firewalls Integration and "LISP and Zone-Based Firewalls Integration and
Interoperability", http://www.cisco.com/c/en/us/td/docs/ Interoperability", http://www.cisco.com/c/en/us/td/docs/
ios-xml/ios/sec_data_zbf/configuration/xe-3s/ ios-xml/ios/sec_data_zbf/configuration/xe-3s/
sec-data-zbf-xe-book/sec-zbf-lisp-inner-pac-insp.html, sec-data-zbf-xe-book/sec-zbf-lisp-inner-pac-insp.html,
2014. 2014.
Authors' Addresses Authors' Addresses
Damien Saucez Damien Saucez
INRIA INRIA
2004 route des Lucioles BP 93 2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex 06902 Sophia Antipolis Cedex
skipping to change at page 16, line 4 skipping to change at page 16, line 14
Authors' Addresses Authors' Addresses
Damien Saucez Damien Saucez
INRIA INRIA
2004 route des Lucioles BP 93 2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex 06902 Sophia Antipolis Cedex
France France
Email: damien.saucez@inria.fr Email: damien.saucez@inria.fr
Luigi Iannone Luigi Iannone
Telecom ParisTech Telecom ParisTech
23, Avenue d'Italie, CS 51327 23, Avenue d'Italie, CS 51327
75214 PARIS Cedex 13 75214 PARIS Cedex 13
France France
Email: luigi.iannone@telecom-paristech.fr Email: ggx@gigix.net
Albert Cabellos Albert Cabellos
Technical University of Catalonia Technical University of Catalonia
C/Jordi Girona, s/n C/Jordi Girona, s/n
08034 Barcelona 08034 Barcelona
Spain Spain
Email: fcoras@ac.upc.edu Email: fcoras@ac.upc.edu
Florin Coras Florin Coras
 End of changes. 41 change blocks. 
138 lines changed or deleted 132 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/