draft-ietf-lisp-impact-03.txt   draft-ietf-lisp-impact-04.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: December 12, 2015 Telecom ParisTech Expires: April 7, 2016 Telecom ParisTech
A. Cabellos A. Cabellos
F. Coras F. Coras
Technical University of Technical University of
Catalonia Catalonia
June 10, 2015 October 5, 2015
LISP Impact LISP Impact
draft-ietf-lisp-impact-03.txt draft-ietf-lisp-impact-04.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 routing scalability properties by leveraging on three
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 routing infrastructure and the end-user.
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 December 12, 2015. This Internet-Draft will expire on April 7, 2016.
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 Routing Architecture . . . . . . 4
4. Beyond scaling the Internet . . . . . . . . . . . . . . . . . 6 4. Beyond scaling the Internet Routing Architecture . . . . . . . 6
4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 7 4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 7
4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . . 8 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 models . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . . . . . . . . . . . 16
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 principles to improve the scalability properties of Internet routing:
Internet: address role separation, encapsulation, and mapping. The address role separation, encapsulation, and mapping. The main goal
main goal of LISP is to make the Internet more scalable by reducing of LISP is to make the routing infrastructure more scalable by
the number of prefixes announced in the Default Free Zone (DFZ). As reducing the number of prefixes announced in the Default Free Zone
LISP relies on mapping and encapsulation, it turns out that it (DFZ). As LISP utilizes mapping and encapsulation technologies, it
provides more benefits than just increased scalability. For provides additional benefits beyond routing scalability. For
instance, LISP provides a mean for a LISP site to precisely control example, LISP provides a mean for a LISP site to precisely control
its inter-domain outgoing and incoming traffic, with the possibility its inter-domain outgoing and incoming traffic, with the possibility
to apply different policies to different domains exchanging traffic to apply different policies to different domains exchanging traffic
with it. LISP can also be used to ease the transition from IPv4 to with it. LISP can also be used to ease the transition from IPv4 to
IPv6 as it allows to transport IPv4 over IPv6 or IPv6 over IPv4. IPv6 as it allows the transport of IPv4 over IPv6 or IPv6 over IPv4.
Furthermore, LISP also provides a solution to perform inter-domain Furthermore, LISP also supports inter-domain multicast.
multicast.
This document discusses the impact of LISP's deployment on the This document discusses the impact of LISP's deployment on the
Internet and on end-users and shows the consequences of the Internet routing infrastructure and on end-users. LISP utilizes a
interworking infrastructure in terms of path-stretch. LISP comprises tunnel-based data plane and a distributed control plane. LISP
both a tunnel-based data plane and a distributed control plane for requires some new functionalities, such as RLOC reachability
the Internet, and requires some new functionalities, such as RLOC mechanisms. Being more than a simple encapsulation technology and as
reachability mechanisms. Being more than simple encapsulation a new technology, until more deployment experience is gained, there
technology, there are remaining open questions related to the will remain open questions related to LISP deployment and operations.
deployment of LISP in the Internet. Moreover, encapsulation may As an encapsulation technology, there may be concerns on reduced
raise some issues (which have a limited impact in practice) because Maximum Transmission Unit (MTU) size in some deployments. An
it reduces the Maximum Transmission Unit (MTU) size. An important important impact of LISP is on network operations related to
impact of LISP on network operations is related to resiliency and resiliency and troubleshooting. As LISP relies on cached mappings
troubleshooting. Indeed, as LISP relies on cached mappings and on and on encapsulation, resiliency during failures and troubleshooting
encapsulation, troubleshooting is harder than in the traditional may be more difficult. Also, the use of encapsulation may make
Internet. Also, encapsulation stresses resiliency as it makes failure detection and recovery slower and it will require more
failure detection and recovery slower than with hop-by-hop routing. coordination than with a single, non-encapsulated, routing domain
solution.
2. LISP in a nutshell 2. LISP in a nutshell
The Locator/Identifier Separation Protocol (LISP) relies on three The Locator/Identifier Separation Protocol (LISP) relies on three
simple principles: address role separation, encapsulation, and principles: address role separation, encapsulation, and mapping.
mapping.
Addresses are semantically separated in two: the Routing Locators Addresses are semantically separated in two: the Routing Locators
(RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are addresses (RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are addresses
typically assigned from the Provider Aggregatable (PA) address space. typically assigned from the Provider (interdomain) Aggregatable (PA)
The EIDs are attributed to the nodes in the edge networks, by block address space. The EIDs are attributed to the nodes in the edge
of contiguous addresses, which are typically Provider Independent networks, by a block of contiguous addresses, which are typically
(PI). To limit the scalability problem, only the routes towards the Provider Independent (PI). To limit the scalability problem, LISP
RLOCs are announced in the Internet routing infrastructure, whereas only requires the PA routes towards the RLOCs to be announced in the
currently EIDs are also propagated. Provider infrastructure. Whereas, for non-LISP deployments the EIDs
need as well to be propagated.
LISP routers are used at the boundary between the EID and the RLOC 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 spaces. Routers used to exit the EID space (towards the Provider
Router (ITRs) and those used to enter the EID space the Egress Tunnel domain) are called Ingress Tunnel Router (ITRs) and those used to
Routers (ETRs). When a host sends a packet to a remote destination, enter the EID space (from the Provider domain) are called the Egress
it sends it as in the current Internet (without LISP). The packet Tunnel Routers (ETRs). When a host sends a packet to a remote
eventually arrives at the border of its site at an ITR. Because EIDs destination, it sends it as in the non-LISP Internet. The packet
are not routable on the Internet, the packet is encapsulated with the arrives at the border of its site at an ITR. Because EIDs are not
source address set to the ITR RLOC and the destination address set to routable on the Internet, the packet is encapsulated with the source
the ETR RLOC. The encapsulated packet is then forwarded in the address set to the ITR RLOC and the destination address set to the
Internet until it reaches the selected ETR. The ETR decapsulates the ETR RLOC. The encapsulated packet is then forwarded in the Provider
packet and forwards it to its final destination. The acronym xTR for domain until it reaches the selected ETR. The ETR de-encapsulates
Ingress/Egress tunnel router is used for a router playing these two the packet and forwards it to its final destination. The acronym xTR
roles. 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. 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 a When an ITR needs to find ETR RLOCs that serve an EID, it queries a
mapping system. It is worth noticing that with the LISP Canonical mapping system. With the LISP Canonical Address Format (LCAF)
Address Format (LCAF) [I-D.ietf-lisp-lcaf], LISP is not restricted to [I-D.ietf-lisp-lcaf], LISP is not restricted to the Internet Protocol
the Internet Protocol for the EID addresses. With LCAF, any address for the EID addresses. With LCAF, any address type can be used as
type can be used as EID (the address is the key for the mapping EID (the address is only the key for the mapping lookup). LISP can
lookup) and LISP can then transport, for example, Ethernet frames transport, for example, Ethernet frames over the Internet.
over the Internet.
A more thorough introduction to LISP can be found in [RFC7215]. The An introduction to LISP can be found in [RFC7215]. The LISP
complete specifications are given in [RFC6830], [RFC6833], specifications are given in [RFC6830], [RFC6833],
[I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834]. [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834].
3. LISP for scaling the Internet 3. LISP for scaling the Internet Routing Architecture
The original goal of LISP is to improve the scalability properties of The original goal of LISP was to improve the scalability properties
the Internet architecture. LISP achieves such a target thanks to of the Internet routing architecture. LISP utilizes traffic
traffic engineering and stub AS prefixes not announced anymore in the engineering and stub AS prefixes (not announced anymore in the DFZ),
DFZ, so that routing tables are smaller and more stable (i.e., they 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 of the 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 BGP model uses a push model). Therefore, the scalability of edge
edge networks is now independent of the Internet's size and is now networks is less dependent on the Internet's size and more related to
related its traffic matrix. This scaling improvement is proven by its traffic matrix. This scaling improvement has been proven by
several works. The research work cited hereafter is based on the several studies. The research studies cited hereafter are based on
following assumptions: the following assumptions:
o EID-to-RLOC mappings follow the same prefix size as the current o EID-to-RLOC mappings follow the same prefix size as the current
BGP routing infrastructure (current PI addresses only); BGP routing infrastructure (current PI addresses only);
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.
The above assumptions are inline with [RFC7215] and current LISP The above assumptions are inline with [RFC7215] and current LISP
deployments, however, such situation may change in the long term. deployments. It is recognized these assumptions may change in the
Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space longer term. [KIF13] and [CDLC] explore different EDI prefix space
sizes, still showing results that are consitent and equivalent to the sizes, and still show results that are consistent and equivalent to
above assumptions. the above assumptions.
Quoitin et al. [QIdLB07] show that the separation between locator Quoitin et al. [QIdLB07] show that the separation between locator
and identifier roles at the network level improves the routing and identifier roles at the network level improves the routing
scalability by reducing the Routing Information Base (RIB) size (up scalability by reducing the Routing Information Base (RIB) size (up
to one order of magnitude) and increases path diversity and thus the to one order of magnitude) and increases path diversity and thus the
traffic engineering capabilities. [IB07] and [KIF13] show, based on traffic engineering capabilities. [IB07] and [KIF13] show, based on
real Internet traffic traces that the number of mapping entries that real Internet traffic traces, that the number of mapping entries that
must be handled by an ITR of a network with up to 20,000 users is 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., 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 Map-Request/Map-Reply packets) is in the same order of magnitude
DNS requests/reply traffic; that the encapsulation overhead, while similar to DNS requests/reply traffic; and that the encapsulation
not negligible, is very limited (in the order of few percentage overhead, while not negligible, is very limited (in the order of few
points of the total traffic volume). percentage points of the total traffic volume).
Previous studies consider the case of a timer-based cache eviction Previous studies consider the case of a timer-based cache eviction
policy (i.e., mappings are deleted from the cache upon timeout), policy (i.e., mappings are deleted from the cache upon timeout),
while [CDLC] has a more general approach based on the Least Recently while [CDLC] has a more general approach based on the Least Recently
Used (LRU) eviction policy, proposing an analytic model for the EID- Used (LRU) eviction policy, proposing an analytic model for the EID-
to-RLOC cache size when prefix-level traffic has a stationary to-RLOC cache size when prefix-level traffic has a stationary
generating process. The model shows that miss rate can be accurately 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 predicted from the EID-to-RLOC cache size and a small set of easily
measurable traffic parameters. The model was validated using four measurable traffic parameters. The model was validated using four
one-day-long packet traces collected at egress points of a campus one-day-long packet traces collected at egress points of a campus
skipping to change at page 6, line 4 skipping to change at page 6, line 4
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).
LISP usually populates its EID-to-RLOC cache in a pull mode which LISP usually populates its EID-to-RLOC cache in a pull mode which
means that mappings are retrieved on demand by the ITR. The main means that mappings are retrieved on demand by the ITR. The main
advantage is that the EID-to-RLOC cache size only depens on the advantage of this mode is that the EID-to-RLOC cache size only
traffic characteristics at the ITR and is independent of the size of depends on the traffic characteristics at the ITR and is independent
the Internet. This benefit comes at the cost of some delay to of the size of the Provider domain. This benefit comes at the cost
transmit the packets that do not hit an entry in the cache, for which of some delay to transmit the packets that do not hit an entry in the
a mapping has to be learned. This delay is bound by the time cache (for which a mapping has to be learned). This delay is bound
necessary to retrieve the mapping from the mapping system. Moreover, by the time necessary to retrieve the mapping from the mapping
similarly to a push model (e.g., BGP), the pull model induces system. Moreover, similarly to a push model (e.g., BGP), the pull
signaling messages that correspond to the retrieval of mappings upon model induces signaling messages that correspond to the retrieval of
cache miss. The difference being that the signaling load only mappings upon cache miss. The difference being that the signaling
depends on the traffic at the ITR and is not triggered by external load only depends on the traffic at the ITR and is not triggered by
events such as in BGP. [CDLC] shows that the miss rate is a function external events such as in BGP. [CDLC] shows that the miss rate is a
of the EID-to-RLOC cache size and traffic generation process and function of the EID-to-RLOC cache size and traffic generation process
[CDLC], [SDIB08], and [SDIB08] show from traffic traces that in and [CDLC], [SDIB08], and [SDIB08] show from traffic traces that, in
practice the cache miss rate, and thus the signaling rate, remain practice, the cache miss rate, and thus the signaling rate, remain
low. low.
4. Beyond scaling the Internet 4. Beyond scaling the Internet Routing Architecture
Even though it is its main goal, LISP is more than just a scalability LISP is more than just a scalability solution, it is also a tool to
solution, it is also a tool to provide both incoming and outgoing provide both incoming and outgoing traffic engineering ([S11],
traffic engineering ([S11], [I-D.farinacci-lisp-te]) can be used as [I-D.farinacci-lisp-te]), it can be used as an IPv6 transition at the
an IPv6 transition at the routing level, and for inter-domain routing level, and it can be used for inter-domain multicast
multicast ([RFC6831], [I-D.coras-lisp-re]). LISP has also proven to ([RFC6831], [I-D.coras-lisp-re]). Also, LISP has been identified for
be a good protocol for devices' Internet mobility use to support devices' Internet mobility ([I-D.meyer-lisp-mn]) and
([I-D.meyer-lisp-mn]) or even virtual machines' mobility in data to support virtual machines' mobility in data centers and multi-
centers and multi-tenant VPNs. Details of the last two points are tenant VPNs. These last two uses are not discussed further as they
not discussed further because out of the scope of the current LISP are out of the scope of the current LISP Working Group charter.
Working Group charter.
LISP architecture facilitates routing in environments where there is A key advantage of the LISP architecture is that it facilitates
little to no correlation between network endpoints and topological routing in environments where there is little to no correlation
location. In service provider environment this use is evident in a between network endpoints and topological location. In service
range of consumer use cases which require an inline anchor in-order provider environments, this application is needed in a range of
to deliver a service to a subscribers. Inline anchors provide one of consumer use cases which require an inline anchor to deliver a
three types of capabilities: service to a subscribers. Inline anchors provide one of three types
of capabilities:
o enable mobility of subscriber end points o enable mobility of subscriber end points
o enable chaining of middle-box functions and services o enable chaining of middle-box functions and services
o enable seamless scale-out of functions o enable seamless scale-out of functions
Without LISP operators are forced to centralize service anchors in Without LISP, operators are forced to centralize service anchors in
custom built special boxes. This means that end-points can move as custom built boxes. This limits deployments as end-points only can
long as their traffic ends up on the same mobile gateway, functions move on the same mobile gateway, functions can be chained only if
can be chained as long as all traffic traverses the same wire or the traffic traverses the same wire or the same DPI box, and capacity can
same DPI box, and capacity can scale out as long as traffic fans out scale out only if traffic fans out to/from a specific load balancer.
to/from a specific load balancer.
With LISP service providers are able to distribute, virtualize, and With LISP, service providers are able to distribute, virtualize, and
instantiate subscriber-service anchors anywhere in the network. instantiate subscriber-service anchors anywhere in the network.
Typical use cases that virtualized inline anchors and network Typical use cases for virtualized inline anchors and network
functions include: Distributed Mobility and Virtualized Evolved functions include: Distributed Mobility and Virtualized Evolved
Packet Core (vEPC), where centralization makes way to distributed and Packet Core (vEPC), Virtualized Customer Premise Equipment or vCPE,
virtualized inline anchoring of mobility, Virtualized Customer where functionality previously anchored at a customer premises is now
Premise Equipment or vCPE, where functionality previously anchored at dynamically allocated in-network, Virtualized SGi LAN, Virtual IMS
customer premises is now dynamically allocated in-network, and Virtual SBC, etc.
Virtualized SGi LAN, where value added mobile services previously
anchored inside full-stack boxes or anchored to physical wires with
permutation setups aka "Rails", Virtual IMS and Virtual SBC, etc.
Current deployments by ConteXtream, using a pre standards (designed Current deployments by ConteXtream, using a pre-standards (designed
2006) based architecture, support a total of 100 millions subscribers 2006) LISP-based architecture, support a total of 100 million
with such an architecture. A deployment at a tier-1 US Mobile subscribers. And, a deployment at a tier-1 US Mobile operator with
operator over 50 millions subscribers provides a 39% download rate over 50 million subscribers provides a 39% download rate improvement
improvement over LTE. over LTE.
4.1. Traffic engineering 4.1. Traffic engineering
In the current (non-LISP) Internet, addresses used by stub networks In the current (non-LISP)routing infrastructure, addresses used by
are globally routable and the routing system distributes the routes stub networks are globally routable and the routing system
to reach these stubs. On the contrary, the EID prefixes of a LISP distributes the routes to reach these stubs. With LISP, the EID
site are not routable in the DFZ, meaning that mappings are needed in prefixes of a LISP site are not routable in the DFZ, mappings are
order to determine the list of LISP routers to contact to send them needed in order to determine the list of LISP routers to contact to
packets. The difference is significant for two reasons. First, forward packets. This difference is significant for two reasons.
packets are not sent to a site but to a specific router. Second, a First, packets are not forwarded to a site but to a specific router.
site can control the entry points for its traffic by controlling its Second, a site can control the entry points for its traffic by
mappings. controlling its mappings.
For traffic engineering purpose, a mapping associates an EID prefix For traffic engineering purposes, a mapping associates an EID prefix
to a list of RLOCs. Each RLOC is annotated with a priority and a 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 weight. When there are several RLOCs, the ITR selects the one with
the highest priority and sends the encapsulated packet to this RLOC. the highest priority and sends the encapsulated packet to this RLOC.
If several such RLOCs exist, then the traffic is balanced If several such RLOCs exist, then the traffic is balanced
proportionally to their weight among the RLOCs with the lowest proportionally to their weight among the RLOCs with the lowest
priority value. Traffic engineering in LISP thus allows the mapping priority value. Traffic engineering in LISP thus allows the mapping
owner to have a fine-grained control on the primary and backup path 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 for its incoming and outgoing packets use. In addition, it can share
load among its links. An example of the use of such a feature is the load among its links. An example of the use of such a feature is
described by Saucez et al. [SDIB08], showing how to use LISP to described by Saucez et al. [SDIB08], showing how to use LISP to
direct different types of traffic on different links having different direct different types of traffic on different links having different
capacity. capacity.
Traffic engineering in LISP goes one step further. As every Map- Traffic engineering in LISP goes one step further. As every Map-
Request contains the Source EID Address of the packet that caused a 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 cache miss and triggered the Map-Request. It is thus possible for a
mapping owner to differentiate the answer (Map-Reply) it gives to mapping owner to differentiate the answer (Map-Reply) it gives to
Map-Requests based on the requester. This functionality is not Map-Requests based on the requester. This functionality is not
available today with BGP because a domain cannot control exactly the available today with BGP because a domain cannot control exactly the
skipping to change at page 8, line 20 skipping to change at page 8, line 15
4.2. LISP for IPv6 Co-existence 4.2. LISP for IPv6 Co-existence
The LISP encapsulation mechanism is designed to support any The LISP encapsulation mechanism is designed to support any
combination of locators and identifiers address family. It is then combination of locators and identifiers address family. It is then
possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa. This possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa. This
allows transporting IPv6 packets over an IPv4 network (or IPv4 allows transporting IPv6 packets over an IPv4 network (or IPv4
packets over an IPv6 network), making LISP a valuable mechanism to packets over an IPv6 network), making LISP a valuable mechanism to
ease the transition to IPv6. ease the transition to IPv6.
A not so uncommon example is the case of the network infrastructure An example is the case of the network infrastructure of a datacenter
of a datacenter being IPv4-only while dual-stack front-end load being IPv4-only while dual-stack front-end load balancers are used.
balancers are used. In this scenario, LISP can be used to provide In this scenario, LISP can be used to provide IPv6 access to servers
IPv6 access to servers even though the network and the servers only even though the network and the servers only support IPv4. Assuming
support IPv4. Assuming that the datacenter's ISP offers IPv6 that the datacenter's ISP offers IPv6 connectivity, the datacenter
connectivity, the datacenter only needs to deploy one (or more) only needs to deploy one (or more) xTR(s) at its border with the ISP
xTR(s) at its border with the ISP and one (or more) xTR(s) directly and one (or more) xTR(s) directly connected to the load balancers.
connected to the load balancers. The xTR(s) at the ISP's border The xTR(s) at the ISP's border tunnels IPv6 packets over IPv4 to the
tunnels IPv6 packets over IPv4 to the xTR(s) directly attached to the xTR(s) directly attached to the load balancer. The load balancer's
load balancer. The load balancer's xTR decapsulates the packets and xTR de-encapsulates the packets and forwards them to the load
forward them to the load balancer, which act as proxies, translating balancer, which act as proxies, translating each IPv6 packet into an
each IPv6 packet into an IPv4. IPv4 packets are then sent to the IPv4. IPv4 packets are then sent to the appropriate servers.
appropriate servers. Similarly, when the server's response arrives Similarly, when the server's response arrives at the load balancer,
at the load balancer, the packet is translated back into an IPv6 the packet is translated back into an IPv6 packet and forwarded to
packet and forwarded to its xTR(s), which in turn will tunnel it its xTR(s), which in turn will tunnel it back, over the IPv4-only
back, over the IPv4-only infrastructure, to an xTR connected to the infrastructure, to an xTR connected to the ISP. The packet is then
ISP. The packet is then decapsulated and forwarded to the ISP de-encapsulated and forwarded to the ISP natively in IPv6.
natively in IPv6.
4.3. Inter-domain multicast 4.3. Inter-domain multicast
LISP has native support for multicast [RFC6831]. From the data-plane LISP has native support for multicast [RFC6831]. From the data-plane
perspective, at a multicast enabled xTR, an EID sourced multicast perspective, at a multicast enabled xTR, an EID sourced multicast
packet is encapsulated in another multicast packet and subsequently packet is encapsulated in another multicast packet and subsequently
forwarded in a RLOC-level distribution tree. Therefore, xTRs must forwarded in a RLOC-level distribution tree. Therefore, xTRs must
participate in both EID and RLOC level distribution trees. Control- participate in both EID and RLOC level distribution trees. Control-
plane wise, since group addresses have no topological significance plane wise, since group addresses have no topological significance
they need not to be mapped. It is worth noting that, to properly they need not to be mapped. It is worth noting that, to properly
skipping to change at page 9, line 23 skipping to change at page 9, line 17
Similarly to LISP-RE, Signal-Free LISP Multicast Similarly to LISP-RE, Signal-Free LISP Multicast
([I-D.farinacci-lisp-signal-free-multicast]) can be used when the ([I-D.farinacci-lisp-signal-free-multicast]) can be used when the
core network does not provide multicast support. But instead of core network does not provide multicast support. But instead of
using signaling to build inter-domain multicast trees, signal-free using signaling to build inter-domain multicast trees, signal-free
exclusively leverages the map-server for multicast state storage and exclusively leverages the map-server for multicast state storage and
distribution. As a result, the source ITR generally performs head- distribution. As a result, the source ITR generally performs head-
end replication but it might be also used to emulate LISP-RE end replication but it might be also used to emulate LISP-RE
distribution trees. distribution trees.
5. Impact of LISP on operations and business model 5. Impact of LISP on operations and business models
Important implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], Numerous implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob],
[LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the [LISPClick], [LISPcp], and [LISPfritz]) have been made to assess the
specifications and interoperability tests ([Was09]) have been a specifications and, additionally, interoperability tests ([Was09])
success. World-wide large deployment in the international lisp4.net have been successful. A world-wide large deployment in the
testbed, which is currently composed of nodes running at least three international lisp4.net testbed, which is currently composed of nodes
different implementations, allows to learn operational matters running at least three different implementations, will allow us to
related to LISP. learn further operational aspects related to LISP.
We have to distinguish the impact of LISP on LISP sites from the The following sections distinguish the impact of LISP on LISP sites
impact on non-LISP sites. from the impact on non-LISP sites.
5.1. Impact on non-LISP traffic and sites 5.1. Impact on non-LISP traffic and sites
LISP has no impact on traffic which has neither LISP origin nor LISP LISP has no impact on traffic which has neither LISP origin nor LISP
destination. However, LISP can have a significant impact on traffic destination. However, LISP can have a significant impact on traffic
between a LISP site and a non-LISP site. Traffic between a non-LISP 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 site and a LISP site are subject to the same issues as those observed
observed for LISP-to-LISP traffic but also have issues specific to for LISP-to-LISP traffic but also have issues specific to the
the transition mechanism that allow LISP site to exchange packets transition mechanism that allows the LISP site to exchange packets
with non-LISP site ([RFC6832], [RFC7215]). with a non-LISP site ([RFC6832], [RFC7215]).
Indeed, the transition requires to setup proxy tunnel routers The transition requires setup of proxy tunnel routers (PxTRs).
(PxTRs). PxTRs do not cause particular technical issue. However, by Proxies cause what is referred to as path stretch and make
definition proxies cause path stretch and make troubleshooting troubleshooting harder. There are still questions related to PxTRs
harder. There are still big questions related to PxTRs that have to that need to be answered:
be answered:
o Where to deploy PxTRs? The placement in the topology has an o Where to deploy PxTRs? The placement in the topology has an
important impact on the path stretch. important impact on the path stretch.
o How many PxTRs? The number of PxTR has a direct impact on the 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. 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 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? whole EID space or will it be segmented between different PxTRs?
o Who operates PxTRs? The IETF does not aim at providing business o Who operates PxTRs? An important question to answer is related to
model hints, however, an important question to answer is related the entities that will deploy PxTRs, how will they manage their
to the entities that will deploy PxTRs, how they will manage their additional CAPEX/OPEX costs associated with PxTRs? How will the
CAPEX/OPEX and how the traffic will be carried with respect for traffic be carried with respect to security and privacy?
the security and privacy.
PxTR also normally have to advertise in BGP the EID prefix they are A PxTR will also normally advertise in BGP the EID prefix for which
proxy for. However, if proxies are managed by different entities, they are proxy. However, if proxies are managed by different
they will belong to different ASes. In this case, we have to be sure entities, they will belong to different ASes. In this case, we need
that it will not cause MOAS (Multi-Origina AS) issues that could to be sure that this will not cause MOAS (Multi-Origin AS) issues
negatively influence routing. Moreover, it is important to ensure that could negatively influence routing. Moreover, it is important
that the way EID prefixes will be deaggregated by the proxies will to ensure that the way EID prefixes will be de-aggregated by the
remain reasonable to not take part in the BGP scalability issues. proxies will remain reasonable so as not to contribute to BGP
scalability issues.
5.2. Impact on LISP traffic and sites 5.2. Impact on LISP traffic and sites
LISP is a protocol based on the map-and-encap paradigm which has the 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, positive impacts that we have summarized in the above sections.
by design, LISP also has side impact on operations: However, LISP also has impacts on operations:
MTU issue: as LISP uses encapsulation, the MTU is reduced, this has MTU issue: as LISP uses encapsulation, the MTU is reduced, this has
implication on potentially all the traffic. However, in implications on potentially all of the traffic. However, in
practice, on the lisp4.net network, no major issue due to the practice, on the lisp4.net network, no major issue due to the
MTU has been observed. This is probably due to the fact that MTU has been observed. This is probably due to the fact that
current end-host stacks are well designed to deal with the current end-host stacks are well designed to deal with the
problem of MTU. problem of MTU.
Resiliency issue: the advantage of flexibility and control offered Resiliency issue: the advantage of flexibility and control offered
by the Locator/ID separation comes at the cost of increasing by the Locator/ID separation comes at the cost of increasing
the complexity of the reachability detection. Indeed, the complexity of the reachability detection. Indeed,
identifiers are not directly routable and have to be mapped to identifiers are not directly routable and have to be mapped to
locators but a locator may be unreachable while others are locators but a locator may be unreachable while others are
still reachable. This is an important problem for any tunnel- still reachable. This is an important problem for any tunnel-
based solution. In the current Internet, packets are forwarded based solution. In the current Internet, packets are forwarded
independently of the border router of the network meaning that independently of the border router of the network meaning that,
in case of the failure of a border router, another one can be in case of the failure of a border router, another one can be
used. With LISP, the destination RLOC specifically designate used. With LISP, the destination RLOC specifically designates
one particular ETR, hence if this ETR fails, the traffic is one particular ETR, hence if this ETR fails, the traffic is
dropped even though other ETRs are available for the dropped, even though other ETRs are available for the
destination site. Another resiliency issue is linked to the destination site. Another resiliency issue is linked to the
fact that mappings are learned on demand. When an ITR fails, fact that mappings are learned on demand. When an ITR fails,
all its traffic is redirected to other ITRs that might not have all its traffic is redirected to other ITRs that might not have
the mappings requested by the redirected traffic. Existing the mappings requested by the redirected traffic. Existing
studies ([SKI12], [SD12]) show, based on measurements and studies ([SKI12], [SD12]) show, based on measurements and
traffic traces, that failure of ITRs and RLOC are infrequent traffic traces, that failure of ITRs and RLOC are infrequent
but that when such failure happens, an important number of but that when such failure happens, a critical number of
packet can be dropped. Unfortunately, the current techniques packets can be dropped. Unfortunately, the current techniques
for LISP resiliency, based on monitoring or probing are not for LISP resiliency, based on monitoring or probing are not
rapid enough (failure recovery of the order of a few seconds). rapid enough (failure recovery on the order of a few seconds).
To tackle this issue [I-D.bonaventure-lisp-preserve] and To tackle this issue [I-D.bonaventure-lisp-preserve] and
[I-D.saucez-lisp-itr-graceful] propose techniques based on [I-D.saucez-lisp-itr-graceful] propose techniques based on
local failure detection and recovery. local failure detection and recovery.
Middle boxes/filters: because of encapsulation, the middle boxes Middle boxes/filters: because of encapsulation, the middle boxes may
might not understand the traffic which can cause firewall to not understand the traffic, which can cause a firewall to drop
drop legitimate packets. In addition, LISP allows triangular legitimate packets. In addition, LISP allows triangular or
or even rectangular routing, so it is hard to maintain a even rectangular routing, so it is difficult to maintain a
correct state even if the middle box perfectly understands correct state even if the middle box understands LISP.
LISP. Finally, filtering might also have problems because they Finally, filtering may also have problems because they may
might think only one host is generating the traffic (the ITR), think only one host is generating the traffic (the ITR), as
as long as it is not decapsulated. To deal with LISP long as it is not de-encapsulated. To deal with LISP
encapsulation, LISP aware firewalls that inspect inner LISP encapsulation, LISP aware firewalls that inspect inner LISP
packets are proposed [lispfirewall]. packets are proposed [lispfirewall].
Troubleshooting/debugging: the major issue that years of LISP Troubleshooting/debugging: the major issue which LISP
experimentation have shown is the difficulty of experimentation has shown is the difficulty of troubleshooting.
troubleshooting. When there is a problem in the network, it is When there is a problem in the network, it is hard to pin-point
hard to pin-point the reason as the operator only has a partial the reason as the operator only has a partial view of the
view of the network. The operator can see what is in its EID- network. The operator can see what is in its EID-to-RLOC
to-RLOC cache/database, and can try to obtain what is cache/database, and can try to obtain what is potentially
potentially elsewhere by querying the Map Resolvers but the elsewhere by querying the Map Resolvers, but the knowledge
knowledge remains partial. On top of that, ICMP packets only remains partial. On top of that, ICMP packets only carry the
carry the first few tens of bytes of the original packet, which first few tens of bytes of the original packet, which means
means that when an ICMP arrives at the ITR, it might not that when an ICMP arrives at the ITR, it might not contain
contain enough information to make correct troubleshooting. enough information to allow correct troubleshooting.
Interestingly, deployment in the beta network has shown that Deployment in the beta network has shown that LISP+ALT
LISP+ALT was not easy to maintain and control, which explains ([RFC6836], [CCR13]) was not easy to maintain and control,
the migration to LISP-DDT [I-D.ietf-lisp-ddt]. which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt].
Business: the IETF is not aiming at providing business models. Business/Operational-related: Iannone et al. [IL10] have shown that
However, even though Iannone et al. [IL10] shown that there is there are economical incentives to migrate to LISP, however,
economical incentives to migrate to LISP, some questions are on some questions remain. For example, how will the EIDs be
hold. For example, how will the EIDs be allocated to allow allocated to allow aggregation and hence scalability of the
aggregation and hence scalability of the mapping system? Who mapping system? Who will operate the mapping system
will operate the mapping system infrastructure and for what infrastructure and for what benefits?
benefit?
Reachability: The overhead related to RLOC rechability mechanisms is Reachability: The overhead related to RLOC reachability mechanisms
not known. is not known.
6. IANA Considerations 6. IANA Considerations
This document makes no request to the IANA. This document makes no request to the IANA.
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
Thanks to Deborah Brungard and Wassim Haddad for their thorough
reviews, comments, and suggestions.
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, Gregg Schudel, Ron Bonica, Fuller, Joel Halpern, Terry Manderson, Gregg Schudel, Ron Bonica,
Ross Callon. Ross Callon.
The work of Luigi Iannone has been partially supported by the ANR-13- The work of Luigi Iannone has been partially supported by the ANR-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
[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, Locator/ID Separation Protocol (LISP)", RFC 6830,
January 2013. DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>.
[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, DOI 10.17487/RFC6831,
January 2013, <http://www.rfc-editor.org/info/rfc6831>.
[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, DOI 10.17487/
RFC6832, January 2013,
<http://www.rfc-editor.org/info/rfc6832>.
[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, Protocol (LISP) Map-Server Interface", RFC 6833,
January 2013. DOI 10.17487/RFC6833, January 2013,
<http://www.rfc-editor.org/info/rfc6833>.
[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. DOI 10.17487/RFC6834, January 2013,
<http://www.rfc-editor.org/info/rfc6834>.
[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, DOI 10.17487/RFC6836,
January 2013, <http://www.rfc-editor.org/info/rfc6836>.
[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, DOI 10.17487/RFC7215,
April 2014, <http://www.rfc-editor.org/info/rfc7215>.
9.2. Informative References 9.2. Informative References
[CCR13] Saucez, D., Iannone, L., and B. Donnet, "A First
Measurement Look at the Deployment and Evolution of the
Locator/ID Separation Protocol", ACM SIGCOMM Computer
Communication Review. Vol. 43, N. 2., April 2013.
[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
skipping to change at page 13, line 49 skipping to change at page 14, line 13
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-03 (work in draft-farinacci-lisp-signal-free-multicast-03 (work in
progress), June 2015. progress), June 2015.
[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-08 (work Engineering Use-Cases", draft-farinacci-lisp-te-09 (work
in progress), March 2015. in progress), September 2015.
[I-D.ietf-lisp-ddt] [I-D.ietf-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in Delegated Database Tree", draft-ietf-lisp-ddt-03 (work in
progress), April 2015. 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-08 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in
progress), April 2015. progress), September 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-13 (work in progress),
March 2015. August 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-13 (work in progress),
January 2015. July 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", "LISP ITR Graceful Restart",
draft-saucez-lisp-itr-graceful-03 (work in progress), draft-saucez-lisp-itr-graceful-03 (work in progress),
December 2013. 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, locator/id mappings", In Proc. ACM CoNEXT 2007,
December 2007. December 2007.
skipping to change at page 16, line 29 skipping to change at page 16, line 37
France France
Email: ggx@gigix.net 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: acabello@ac.upc.edu
Florin Coras Florin Coras
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
 End of changes. 69 change blocks. 
251 lines changed or deleted 259 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/