draft-ietf-lisp-impact-00.txt   draft-ietf-lisp-impact-01.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: July 12, 2015 Telecom ParisTech Expires: September 7, 2015 Telecom ParisTech
A. Cabellos A. Cabellos
F. Coras F. Coras
Technical University of Catalonia Technical University of Catalonia
January 8, 2015 March 6, 2015
LISP Impact LISP Impact
draft-ietf-lisp-impact-00.txt draft-ietf-lisp-impact-01.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, deployment, and theoretical this document, based on implementation work, deployment experiences,
studies, we discuss the impact that deployment of LISP can have on and theoretical studies, we discuss the impact that the deployment of
both the Internet in general and for the end-users in particular. LISP can have on both the Internet in general and the end-user in
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 July 12, 2015. This Internet-Draft will expire on September 7, 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
skipping to change at page 2, line 15 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . . . . . 5 4. Beyond scaling the Internet . . . . . . . . . . . . . . . . . 6
4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 6 4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 7
4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 7 4.2. LISP for IPv6 Co-existence . . . . . . . . . . . . . . . 7
4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . 8 4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . 8
5. Impact of LISP on operations and business model . . . . . . . 8 5. Impact of LISP on operations and business model . . . . . . . 9
5.1. Impact on non-LISP traffic and sites . . . . . . . . . . 8 5.1. Impact on non-LISP traffic and sites . . . . . . . . . . 9
5.2. Impact on LISP traffic and sites . . . . . . . . . . . . 9 5.2. Impact on LISP traffic and sites . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 12
9.2. Informative References . . . . . . . . . . . . . . . . . 12 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 scale the Internet: address role separation, simple principles to improve the scalability properties of the
encapsulation, and mapping. The main goal of LISP is to make the Internet: address role separation, encapsulation, and mapping. The
Internet more scalable by reducing the number of prefixes announced main goal of LISP is to make the Internet more scalable by reducing
in the Default Free Zone (DFZ) as well as its related churn. As LISP the number of prefixes announced in the Default Free Zone (DFZ). As
relies on mapping and encapsulation, it turns out that it provides LISP relies on mapping and encapsulation, it turns out that it
more benefits than just scalability. For example, LISP provides a provides more benefits than just increased scalability. For
mean for a LISP site to precisely control its inter-domain outgoing instance, LISP provides a mean for a LISP site to precisely control
and incoming traffic, with the possibility to apply different its inter-domain outgoing and incoming traffic, with the possibility
policies to the different domains exchanging traffic with it. LISP to apply different policies to different domains exchanging traffic
can also be used to ease the transition from IPv4 to IPv6 as it with it. LISP can also be used to ease the transition from IPv4 to
allows to transport IPv4 over IPv6 or IPv6 over IPv4. Furthermore, IPv6 as it allows to transport IPv4 over IPv6 or IPv6 over IPv4.
LISP also provides a solution to perform inter-domain multicast. Furthermore, LISP also provides a solution to perform inter-domain
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 and on end-users and shows the consequences of the
interworking infrastructure in path stretch. There still are many, interworking infrastructure in terms of path-stretch. There still
economical rather than technical, open questions related to the are many, economical rather than technical, open questions related to
deployment of such infrastructure. Moreover, encapsulation may raise the deployment of such infrastructure. Moreover, encapsulation may
some issues (that do not have a real impact in practice) because it raise some issues (which have a limited impact in practice) because
reduces the Maximum Transmission Unit (MTU) size. An important it reduces the Maximum Transmission Unit (MTU) size. An important
impact of LISP on network operations is related to resiliency and impact of LISP on network operations is related to resiliency and
troubleshooting. Indeed, as LISP relies on cached mappings and on troubleshooting. Indeed, as LISP relies on cached mappings and on
encapsulation, troubleshooting is harder than in the traditional encapsulation, troubleshooting is harder than in the traditional
Internet. Also, end-to-end encapsulation stresses resiliency as it Internet. Also, encapsulation stresses resiliency as it makes
makes failure detection and recovery slower than with hop-by-hop failure detection and recovery slower than with hop-by-hop routing.
routing.
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 simple principles: address role separation, encapsulation, and
mapping. mapping.
Semantics of address are separated in two: the Routing Locators Addresses are semantically separated in two: the Routing Locators
(RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are assigned from (RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are addresses
the address space of the Internet service providers (PA). The EIDs typically assigned from the Provider Aggregatable (PA) address space.
are attributed, to the nodes in the edge network, by block of The EIDs are attributed to the nodes in the edge networks, by block
contiguous addresses extracted from the EID Space. To limit the of contiguous addresses, which are typically Provider Independent
scalability problem of today's Internet, only the routes towards the (PI). To limit the scalability problem, only the routes towards the
RLOCs are announced in the Internet while EIDs are also propagated RLOCs are announced in the Internet routing infrastructure, whereas
today. currently EIDs are also 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 are called Ingress Tunnel
Router (ITRs) and those used to enter the EID space the Egress Tunnel Router (ITRs) and those used to enter the EID space the Egress Tunnel
Routers (ETRs). When a host sends a packet to a remote destination, 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 it sends it as in the current Internet (without LISP). The packet
the border of its site at an ITR. Because EIDs are not routable on eventually arrives at the border of its site at an ITR. Because EIDs
the Internet, the packet is encapsulated with the source address set are not routable on the Internet, the packet is encapsulated with the
to the ITR RLOC and the destination address set to the ETR RLOC. The source address set to the ITR RLOC and the destination address set to
encapsulated packet is then forwarded in the Internet until it the ETR RLOC. The encapsulated packet is then forwarded in the
reaches the selected ETR. The ETR decapsulates the packet and Internet until it reaches the selected ETR. The ETR decapsulates the
forwards it to its final destination. The acronym xTR for Ingress/ packet and forwards it to its final destination. The acronym xTR for
Egress tunnel router is used for a router playing these two roles. 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 the 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. It is worth noticing that with the LISP Canonical
Address Format (LCAF) [I-D.ietf-lisp-lcaf], LISP is not restricted to Address Format (LCAF) [I-D.ietf-lisp-lcaf], LISP is not restricted to
the Internet Protocol for the EID addresses. With LCAF, any address the Internet Protocol for the EID addresses. With LCAF, any address
type can be used as EID (the address is the key for the mapping type can be used as EID (the address is the key for the mapping
lookup) and LISP can then transport, for example, Ethernet frames lookup) and LISP can then transport, for example, Ethernet frames
over the Internet. over the Internet.
A more thorough introduction to LISP can be found in A more thorough introduction to LISP can be found in [RFC7215]. The
[I-D.ietf-lisp-introduction]. The complete specifications are given complete specifications are given in [RFC6830], [RFC6833],
in [RFC6830], [RFC6833], [I-D.fuller-lisp-ddt], [RFC6836], [RFC6832], [I-D.ietf-lisp-ddt], [RFC6836], [RFC6832], [RFC6834].
[RFC6834], and [I-D.ietf-lisp-sec].
3. LISP for scaling the Internet 3. LISP for scaling the Internet
The first goal of LISP is to scale the Internet. LISP improves the The original goal of LISP is to improve the scalability properties of
Internet's scalability because traffic engineering and stub AS the Internet architecture. LISP achieves such a target thanks to
prefixes are not propagated in the DFZ, so routing tables are smaller traffic engineering and stub AS prefixes not announced anymore in the
and more stable (i.e., less affected by churn). Also, at the edge DFZ, so that routing tables are smaller and more stable (i.e., they
network, information necessary to forward packets (i.e., the experience less churn). Furthermore, at the edge network,
mappings) is usually obtained on demand using a pull model. information necessary to forward packets (i.e., the mappings) is
Therefore, for each edge network they scale with the traffic matrix obtained on demand using a pull model (whereas the current Internet
of the edge network and are independent of the Internet's size. This uses a push model, instantiated by BGP). Therefore, scalability of
scaling improvement is proven by several works. edge networks is now independent of the Internet's size and is now
related its traffic matrix. This scaling improvement is proven by
several works.
Quoitin et al. show in [QIdLB07] 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 RIB size (up to one order of magnitude) scalability by reducing the Routing Information Base (RIB) size (up
and increases the path diversity and thus the traffic engineering to one order of magnitude) and increases path diversity and thus the
capabilities. In addition, Iannone and Bonaventure show in [IB07] traffic engineering capabilities. For instance, at the time of
that the number of mapping entries that must be supported at an ITR writting, [CAIDA] list 49,757 ASes among which 85% are stub which
of a 10,000 users campus network is limited and does not represent means that with LISP the number of ASes advertising prefixes could be
more that 3 to 4 Megabytes of memory. Furthermore, they show that reduced by 85%.
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 volume).
Similarly, Kim 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 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. [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, EID prefixes 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
follow the current BGP prefixes decomposition; follow the current BGP prefixes decomposition;
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 and locator stubs owning the EID prefix and the providers, allocating the
addresses are allocated 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 While all previous studies consider the case of a timer-based cache
eviction policy (i.e., mappings are deleted from the cache upon eviction policy (i.e., mappings are deleted from the cache upon
timeout), [CCD12] generalizes the caching discussion for the Least timeout), Coras et al. [CCD12] have a more general approach for the
Recently Used (LRU) eviction policy and proposes an analytic model Least Recently Used (LRU) eviction policy, proposing an analytic
for the EID-to-RLOC cache size when prefix-level traffic has a 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 stationary generating process. The model shows that miss rate can be
accurately predicted from the EID-to-RLOC cache size and a small set accurately predicted from the EID-to-RLOC cache size and a small set
of easily measurable traffic parameters. The model was validated of easily measurable traffic parameters. The model was validated
using four one-day-long packet traces collected at egress points of a using four one-day-long packet traces collected at egress points of a
campus network and an academic exchange point considering EID- campus network and an academic exchange point considering EID-
prefixes as being of BGP-prefix granularity. Consequently, operators prefixes as being of BGP-prefix granularity. Consequently, operators
can provision the EID-to-RLOC cache of their ITRs according to the can provision the EID-to-RLOC cache of their ITRs according to the
miss rate they want to achieve for their given traffic. miss rate they want to achieve for their given traffic.
The results indicate that for a given miss ratio, cache size only Results indicate that for a given target miss-ratio, the size of the
depends on the parameters of the popularity distribution and is in cache depends only on the parameters of the popularity distribution,
fact 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 Under normal user traffic, miss-ratio decreases at an accelerated
pace with cache size and finally settles to a power-law decrease. pace with cache size and finally settles to a power-law decrease.
However, [CDLC] extends the model to account for scanning attacks, However, Coras et al. [CDLC] extends the previous model to account
whereby attackers generate a constant flux of packets according to for scanning attacks, whereby attackers generate a constant flow of
random scans of the destination prefix space and shows that miss- packets according to random scans of the destination prefix space and
ratios are be very high and independent of cache size. In fact, if shows that miss-ratios are very high and independent of the cache
the attack is merely 1% of the legitimate traffic, the miss rate does size. In fact, if the attack is merely 1% of the legitimate traffic,
not drop under 1% as long as the cache cannot accommodate the whole the miss rate does not drop under 1% as long as the cache cannot
prefix space. Locality measurements also suggested that LRU eviction accommodate the whole prefix space. Locality measurements also
policy should be close to optimal. suggested that LRU eviction policy should be close to optimal.
TBD: add a paragraph to explain thhe operational difference while TBD: add a paragraph to explain the operational difference while
dealing with a pull model instead of a push. dealing with a pull model instead of a push.
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], can be used as an IPv6 transition at the traffic engineering ([S11], [I-D.farinacci-lisp-te]) can be used as
routing level, and for inter-domain multicast [RFC6831], an IPv6 transition at the routing level, and for inter-domain
[I-D.coras-lisp-re]. LISP has also proven to be a good protocol for multicast ([RFC6831], [I-D.coras-lisp-re]). LISP has also proven to
mobility of devices in the Internet [I-D.meyer-lisp-mn] or even be a good protocol for devices' Internet mobility
virtual machine mobility in data centers and multi-tenant VPN, ([I-D.meyer-lisp-mn]) or even virtual machines' mobility in data
however, we don't further discuss in details the two last points as centers and multi-tenant VPNs. Details of the last two points are
they are out of the scope of the charter. not discussed further because out of the scope of the current LISP
Working Group charter.
Lisp architecture facilitates routing in environments where there is LISP architecture facilitates routing in environments where there is
little to no correlation between network endpoints and topological little to no correlation between network endpoints and topological
location. In service provider environment this use is evident in a location. In service provider environment this use is evident in a
range of consumer use cases which require an inline anchor in-order range of consumer use cases which require an inline anchor in-order
to deliver a service to a subscribers. Inline anchors provide one of to deliver a service to a subscribers. Inline anchors provide one of
three types of capabilities: 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 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 special boxes. This means that end-points can move as
long as their traffic ends up on the same mobile gateway, functions long as their traffic ends up on the same mobile gateway, functions
can be chained as long as all traffic traverses the same wire or the can be chained as long as all traffic traverses the same wire or the
same DPI box, and capacity can scale out as long as traffic fans out same DPI box, and capacity can scale out as long as traffic fans out
to and form 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
insatiate subscriber-service anchors anywhere in the network. instantiate subscriber-service anchors anywhere in the network.
Typical use cases that Virtualize inline anchors and network Typical use cases that 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), where centralization makes way to distributed and
virtualized inline anchoring of mobility, Virtualized Customer virtualized inline anchoring of mobility, Virtualized Customer
Premise Equipment or vCPE, where functionality previously anchored at Premise Equipment or vCPE, where functionality previously anchored at
customer prem is now dynamically allocated in-network, Virtualized customer premises is now dynamically allocated in-network,
SGi LAN, where value added mobile services previously anchored inside Virtualized SGi LAN, where value added mobile services previously
full-stack boxes or anchored to physical wires with permutation anchored inside full-stack boxes or anchored to physical wires with
setups aka "Rails", Virtual IMS and Virtual SBC, etc. 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) based architecture, support a total of 100 millions subscribers
with such an architecture. A deployment at a tier-1 US Mobile with such an architecture. A deployment at a tier-1 US Mobile
operator over 50 millions subscribers provides a 39% download rate operator over 50 millions subscribers provides a 39% download rate
improvement over LTE. improvement over LTE.
4.1. Traffic engineering 4.1. Traffic engineering
In today's Internet, stub networks are globally routable and the In the current (non-LISP) Internet, addresses used by stub networks
routing system distributes the routes to reach these stubs. On the are globally routable and the routing system distributes the routes
contrary, the EID prefixes of a LISP site are not routable on the to reach these stubs. On the contrary, the EID prefixes of a LISP
Internet and mappings are needed to determine the list of LISP site are not routable in the DFZ, meaning that mappings are needed in
routers to contact to send them packets. The difference is order to determine the list of LISP routers to contact to send them
significant for two reasons. First, packets are not sent to a site packets. The difference is significant for two reasons. First,
but to a specific ingress router. Second, a site can control the packets are not sent to a site but to a specific router. Second, a
entry points for its traffic by controlling its mappings. site can control the entry points for its traffic by controlling its
mappings.
For traffic engineering purpose, a mapping associates an EID prefix For traffic engineering purpose, 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 lowest priority value and sends the encapsulated packet to this the highest priority and sends the encapsulated packet to this RLOC.
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 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 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 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
routes that will be received by domains that are not in the direct routes that will be received by domains that are not in the direct
skipping to change at page 8, line 15 skipping to change at page 8, line 32
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 be mapped. It is worth noting that, to properly they need not to be mapped. It is worth noting that, to properly
function inter-domain, LISP-Multicast requires that inter-domain function, LISP-Multicast requires that inter-domain multicast be
multicast be prior deployed. available.
[I-D.coras-lisp-re] and [CDM12] propose a technique to construct xTR LISP Replication Engineering (RE) ([I-D.coras-lisp-re], [CDM12])
based inter-domain multicast distribution trees. Simulations of leverage LISP messages ([I-D.farinacci-lisp-mr-signaling]) for
three different management strategies for low latency content multicast state distribution to construct xTR based inter-domain
delivery show that such overlays can support thousands of member multicast distribution trees when inter-domain multicast support is
xTRs, hundreds of thousands of end-hosts and deliver content at not available. Simulations of three different management strategies
latencies close to unicast ones [CDM12]. It was also observed that for low latency content delivery show that such overlays can support
high client churn has a limited impact on performance and management thousands of member xTRs, hundreds of thousands of end-hosts and
overhead. deliver content at latencies close to unicast ones ([CDM12]). It was
also observed that high client churn has a limited impact on
performance and management overhead.
Similarly to LISP-RE, Signal-Free LISP Multicast
([I-D.farinacci-lisp-signal-free-multicast]) can be used when the
core network does not provide multicast support. But instead of
using signaling to build inter-domain multicast trees, signal-free
exclusively leverages the map-server for multicast state storage and
distribution. As a result, the source ITR generally performs head-
end replication but it might be also used to emulate LISP-RE
distribution trees.
5. Impact of LISP on operations and business model 5. Impact of LISP on operations and business model
Important implementation efforts ([IOSNXOS], [OpenLISP], [LISPmob], Important 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 interoperability tests ([Was09]) have been a
success. World-wide large deployment in the international lisp4.net success. World-wide large deployment in the international lisp4.net
testbed, which is currently composed of nodes running at least three testbed, which is currently composed of nodes running at least three
different implementations, allows to learn operational matters different implementations, allows to learn operational matters
related to LISP. related to LISP.
We have to distinguish the impact of LISP on LISP sites from the We have to distinguish the impact of LISP on LISP sites from the
impact on non-LISP sites. 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 than those
observed for LISP-to-LISP traffic (cf infra) but also have issues observed for LISP-to-LISP traffic but also have issues specific to
specific to the transition mechanism that allow LISP site to exchange the transition mechanism that allow LISP site to exchange packets
packets with non-LISP site ([RFC6832], [I-D.ietf-lisp-deployment]). with non-LISP site ([RFC6832], [RFC7215]).
Indeed, the transition requires to setup proxy tunnel routers Indeed, the transition requires to setup proxy tunnel routers
(PxTRs). PxTRs do not cause particular technical issue. However, by (PxTRs). PxTRs do not cause particular technical issue. However, by
definition proxies cause path stretch and make troubleshooting definition proxies cause path stretch and make troubleshooting
harder. There are still big questions related to PxTRs that have to harder. There are still big questions related to PxTRs that have 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 to operate PxTRs? The IETF does not aim at providing business o Who operates PxTRs? The IETF does not aim at providing business
model hints, however, an important question to answer is related model hints, however, an important question to answer is related
to the entities that will deploy PxTRs, how they will manage their to the entities that will deploy PxTRs, how they will manage their
CAPEX/OPEX and how the traffic will be carried with respect for CAPEX/OPEX and how the traffic will be carried with respect for
the security and privacy. the security and privacy.
PxTR also normally have to advertise in BGP the EID prefix they are PxTR also normally have to advertise in BGP the EID prefix they are
proxy for. However, if proxies are managed by different entities, proxy for. However, if proxies are managed by different entities,
they will belong to different ASes. In this case, we have to be sure 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 that it will not cause MOAS (Multi-Origina AS) issues that could
routing. Moreover, we have to be sure that the way EID prefixes will negatively influence routing. Moreover, it is important to ensure
be deaggregated by the proxies will remain reasonable to not take that the way EID prefixes will be deaggregated by the proxies will
part in the BGP scalability issues. remain reasonable to not take part in the 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 effects that we have given in the sections above. However,
by design, LISP also has side impact on operations: by design, LISP also has side impact 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 implication on potentially all 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
skipping to change at page 10, line 13 skipping to change at page 10, line 41
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 designate
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
yet the mappings for the redirected traffic. The study in the mappings requested by the redirected traffic. Existing
[SKI12] and [SD12] show, based on measurements and traffic studies ([SKI12], [SD12]) show, based on measurements and
traces, that failure of ITRs and RLOC are infrequent but that traffic traces, that failure of ITRs and RLOC are infrequent
when such failure happens, an important number of packet can be but that when such failure happens, an important number of
dropped. Unfortunately, the current techniques for LISP packet can be dropped. Unfortunately, the current techniques
resiliency, based on monitoring or probing are not rapid enough for LISP resiliency, based on monitoring or probing are not
(failure recovery of the order of a few seconds). To tackle rapid enough (failure recovery of the order of a few seconds).
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
might not understand the traffic which can cause firewall to might not understand the traffic which can cause firewall to
drop legitimate packets. In addition, LISP allows triangular drop legitimate packets. In addition, LISP allows triangular
or even rectangular routing, so it is hard to maintain a or even rectangular routing, so it is hard to maintain a
correct state even if the middle box perfectly understands correct state even if the middle box perfectly understands
LISP. Finally, filtering might also have problems because they LISP. Finally, filtering might also have problems because they
might think only one host is generating the traffic (the ITR), might think only one host is generating the traffic (the ITR),
as long as it is not decapsulated. To deal with LISP as long as it is not decapsulated. 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 years of LISP Troubleshooting/debugging: the major issue that years of LISP
experimentation have shown is the difficulty of experimentation have shown is the difficulty of
troubleshooting. When there is a problem in the network, it is troubleshooting. When there is a problem in the network, it is
hard to pin-point the reason as the operator only has a partial 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 EID- view of the network. The operator can see what is in its EID-
to-RLOC cache/database, and can try to obtain what is to-RLOC cache/database, and can try to obtain what is
potentially elsewhere by querying the Map Resolvers but the potentially elsewhere by querying the Map Resolvers but the
knowledge remains partial. On top of that, ICMP is too small, knowledge remains partial. On top of that, ICMP packets only
which means that when an ICMP arrives at the ITR, it might not carry the first few tens of bytes of the original packet, which
means that when an ICMP arrives at the ITR, it might not
contain enough information to make correct troubleshooting. contain enough information to make correct troubleshooting.
Interestingly, deployment in the beta network has shown that Interestingly, deployment in the beta network has shown that
LISP+ALT was not easy to maintain and control, which explains LISP+ALT was not easy to maintain and control, which explains
the migration to LISP-DDT [I-D.fuller-lisp-ddt]. the migration to LISP-DDT [I-D.ietf-lisp-ddt].
Business: the IETF is not aiming at providing business models. Business: the IETF is not aiming at providing business models.
However, even though [IL10] shown that there is economical However, even though Iannone et al. [IL10] shown that there is
incentives to migrate to LISP, some questions are on hold. For economical incentives to migrate to LISP, some questions are on
example, how will the EIDs be allocated to allow aggregation hold. For example, how will the EIDs be allocated to allow
and hence scalability of the mapping system? Who will operate aggregation and hence scalability of the mapping system? Who
the mapping system infrastructure and for what benefit? will operate the mapping system infrastructure and for what
benefit?
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
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, and Gregg Schudel.
The work of Luigi Iannone has been partially supported by the ANR-
13-INFR-0009 LISP-Lab Project (www.lisp-lab.org).
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.fuller-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-fuller-lisp-ddt-04 (work Delegated Database Tree", draft-ietf-lisp-ddt-02 (work in
in progress), September 2012. progress), October 2014.
[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-12
(work in progress), January 2014.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-07
(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, January
2013. 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,
skipping to change at page 12, line 21 skipping to change at page 12, line 46
2013. 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-
Pascual, J., and D. Lewis, "Locator/Identifier Separation
Protocol (LISP) Network Element Deployment
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, [CCD12] Coras, F., Cabellos-Aparicio, A., and J. Domingo-Pascual,
"An Analytical Model for the LISP Cache Size", In Proc. "An Analytical Model for the LISP Cache Size", In Proc.
IFIP Networking 2012, May 2012. 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", Technical Analytical Model for Loc/ID Mappings Caches", IEEE
Report http://arxiv.org/pdf/1312.1378v2.pdf, 2013. 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", Technical Report, Universitat Domain Multicast", Elsevier Computer Networks, July 2014.
Politecnica de Catalunya, 2012, July 2012.
[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", draft-
bonaventure-lisp-preserve-00 (work in progress), July bonaventure-lisp-preserve-00 (work in progress), July
2009. 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.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-06 (work in progress),
October 2014. October 2014.
[I-D.ietf-lisp-introduction] [I-D.farinacci-lisp-mr-signaling]
Cabellos-Aparicio, A. and D. Saucez, "An Architectural Farinacci, D. and M. Napierala, "LISP Control-Plane
Introduction to the Locator/ID Separation Protocol Multicast Signaling", draft-farinacci-lisp-mr-signaling-06
(LISP)", draft-ietf-lisp-introduction-09 (work in (work in progress), February 2015.
progress), November 2014.
[I-D.farinacci-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-farinacci-lisp-signal-free-multicast-02 (work in
progress), December 2014.
[I-D.farinacci-lisp-te]
Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic
Engineering Use-Cases", draft-farinacci-lisp-te-07 (work
in progress), September 2014.
[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-07 (work in
progress), December 2014. progress), December 2014.
[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-11 (work in progress), Analysis", draft-ietf-lisp-threats-12 (work in progress),
December 2014. 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-11 (work in progress), Mobile Node", draft-meyer-lisp-mn-12 (work in progress),
July 2014. 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", draft-saucez-lisp-itr-
graceful-03 (work in progress), December 2013. 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, December
2007. 2007.
 End of changes. 55 change blocks. 
201 lines changed or deleted 228 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/