draft-ietf-lisp-impact-04.txt   draft-ietf-lisp-impact-05.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: April 7, 2016 Telecom ParisTech Expires: May 23, 2016 Telecom ParisTech
A. Cabellos A. Cabellos
F. Coras F. Coras
Technical University of Technical University of
Catalonia Catalonia
October 5, 2015 November 20, 2015
LISP Impact LISP Impact
draft-ietf-lisp-impact-04.txt draft-ietf-lisp-impact-05.txt
Abstract Abstract
The Locator/Identifier Separation Protocol (LISP) aims at improving The Locator/Identifier Separation Protocol (LISP) aims at improving
the Internet routing scalability properties by leveraging on three 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 routing infrastructure and the end-user. LISP can have on both the routing infrastructure and the end-user.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 7, 2016. This Internet-Draft will expire on May 23, 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
skipping to change at page 2, line 19 skipping to change at page 2, line 19
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 Routing Architecture . . . . . . 4 3. LISP for scaling the Internet Routing Architecture . . . . . . 4
4. Beyond scaling the Internet Routing Architecture . . . . . . . 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 . . . . . . . . . . . . . . . . . . 9
5. Impact of LISP on operations and business models . . . . . . . 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 . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
The Locator/Identifier Separation Protocol (LISP) relies on three The Locator/Identifier Separation Protocol (LISP) relies on three
principles to improve the scalability properties of Internet routing: principles to improve the scalability properties of Internet routing:
address role separation, encapsulation, and mapping. The main goal address role separation, encapsulation, and mapping. When invented,
of LISP is to make the routing infrastructure more scalable by LISP was targeted at solving the Internet routing scaling problem
reducing the number of prefixes announced in the Default Free Zone ([RFC4984]). There have now been years of implementations and
(DFZ). As LISP utilizes mapping and encapsulation technologies, it experiments examining the impact and open questions of using LISP to
provides additional benefits beyond routing scalability. For improve inter-domain routing scalability. Experience has shown that
example, LISP provides a mean for a LISP site to precisely control because LISP utilizes mapping and encapsulation technologies, it can
its inter-domain outgoing and incoming traffic, with the possibility be deployed and used for purposes that go beyond routing scalability.
to apply different policies to different domains exchanging traffic For example, LISP provides a mean for a LISP site to precisely
with it. LISP can also be used to ease the transition from IPv4 to control its inter-domain outgoing and incoming traffic, with the
IPv6 as it allows the transport of IPv4 over IPv6 or IPv6 over IPv4. possibility to apply different policies to different domains
Furthermore, LISP also supports inter-domain multicast. exchanging traffic with it. LISP can also be used to ease the
transition from IPv4 to IPv6 as it allows the transport of IPv4 over
IPv6 or IPv6 over IPv4. Furthermore, LISP also supports inter-domain
multicast.
This document discusses the impact of LISP's deployment on the Leveraging on implementation and deployment experience, as well as
Internet routing infrastructure and on end-users. LISP utilizes a research work, this document describes, at a high level, the impacts
tunnel-based data plane and a distributed control plane. LISP and open questions still seen in LISP. This information is
requires some new functionalities, such as RLOC reachability particularly useful for considering future approaches and to support
mechanisms. Being more than a simple encapsulation technology and as further experimentation to clarify some large open questions (e.g.
a new technology, until more deployment experience is gained, there around the operations). LISP utilizes a tunnel-based data plane and
will remain open questions related to LISP deployment and operations. a distributed control plane. LISP requires some new functionalities,
As an encapsulation technology, there may be concerns on reduced such as reachability mechanisms. Being more than a simple
Maximum Transmission Unit (MTU) size in some deployments. An encapsulation technology and as a new technology, until even more
important impact of LISP is on network operations related to deployment experience is gained, some open questions, related to LISP
resiliency and troubleshooting. As LISP relies on cached mappings deployment and operations, remain. As an encapsulation technology,
and on encapsulation, resiliency during failures and troubleshooting there may be concerns on reduced Maximum Transmission Unit (MTU) size
may be more difficult. Also, the use of encapsulation may make in some deployments. An important impact of LISP is on network
failure detection and recovery slower and it will require more operations related to resiliency and troubleshooting. As LISP relies
coordination than with a single, non-encapsulated, routing domain on cached mappings and on encapsulation, resiliency during failures
solution. and troubleshooting may be more difficult. Also, the use of
encapsulation may make failure detection and recovery slower and it
will require more 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
principles: address role separation, encapsulation, and mapping. principles: address role separation, encapsulation, and mapping.
Addresses are semantically separated in two: the Routing Locators The address space is divided into two sets that have different
(RLOCs) and the Endpoint Identifiers (EIDs). RLOCs are addresses semantic meanings: the Routing Locators (RLOCs) and the Endpoint
typically assigned from the Provider (interdomain) Aggregatable (PA) Identifiers (EIDs). RLOCs are addresses typically assigned from the
address space. The EIDs are attributed to the nodes in the edge Provider Aggregatable (PA) address space. The EIDs are attributed to
networks, by a block of contiguous addresses, which are typically the nodes in the edge networks, by a block of contiguous addresses,
Provider Independent (PI). To limit the scalability problem, LISP which are typically Provider Independent (PI). To limit the
only requires the PA routes towards the RLOCs to be announced in the scalability problem, LISP only requires the PA routes towards the
Provider infrastructure. Whereas, for non-LISP deployments the EIDs RLOCs to be announced in the Provider infrastructure. Whereas, for
need as well to be propagated. 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 (towards the Provider spaces. Routers used to exit the EID space (towards the Provider
domain) are called Ingress Tunnel Router (ITRs) and those used to domain) are called Ingress Tunnel Router (ITRs) and those used to
enter the EID space (from the Provider domain) are called the Egress enter the EID space (from the Provider domain) are called the Egress
Tunnel Routers (ETRs). When a host sends a packet to a remote Tunnel Routers (ETRs). When a host sends a packet to a remote
destination, it sends it as in the non-LISP Internet. The packet destination, it sends it as in the non-LISP Internet. The packet
arrives at the border of its site at an ITR. Because EIDs are not arrives at the border of its site at an ITR. Because EIDs are not
routable on the Internet, the packet is encapsulated with the source routable on the Internet, the packet is encapsulated with the source
address set to the ITR RLOC and the destination address set to the address set to the ITR RLOC and the destination address set to the
skipping to change at page 4, line 44 skipping to change at page 4, line 50
The original goal of LISP was to improve the scalability properties The original goal of LISP was to improve the scalability properties
of the Internet routing architecture. LISP utilizes traffic of the Internet routing architecture. LISP utilizes traffic
engineering and stub AS prefixes (not announced anymore in the DFZ), engineering and stub AS prefixes (not announced anymore in the 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 of the 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
BGP model uses a push model). Therefore, the scalability of edge BGP model uses a push model). Therefore, the scalability of edge
networks is less dependent on the Internet's size and more related to networks is less dependent on the Internet's size and more related to
its traffic matrix. This scaling improvement has been proven by its traffic matrix. This scaling improvement has been proven by
several studies. The research studies cited hereafter are based on several studies (see below). The research studies cited hereafter
the following assumptions: are based on 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. It is recognized these assumptions may change in the deployments. It is recognized these assumptions may change in the
longer term. [KIF13] and [CDLC] explore different EDI prefix space longer term. [KIF13] and [CDLC] explore different EDI prefix space
sizes, and still show results that are consistent and equivalent to sizes, and still show results that are consistent and equivalent to
the above assumptions. the above assumptions.
skipping to change at page 5, line 41 skipping to change at page 5, line 48
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
network and an academic exchange point considering EID-prefixes as network and an academic exchange point considering EID-prefixes as
being of the same size as BGP prefixes. Consequently, operators can being of the same size as BGP prefixes. Consequently, operators can
provision the EID-to-RLOC cache of their ITRs according to the miss provision the EID-to-RLOC cache of their ITRs according to the miss
rate they want to achieve for their given traffic. rate they want to achieve for their given traffic.
Results indicate that for a given target miss-ratio, the size of the Results in [CDLC] indicate that for a given target miss-ratio, the
cache depends only on the parameters of the popularity distribution, size of the cache depends only on the parameters of the popularity
being independent of the number of users (the size of the LISP site) distribution, being independent of the number of users (the size of
and the number of destinations (the size of the EID-prefix space). the LISP site) and the number of destinations (the size of the EID-
Assuming that the popularity distribution remains constant, this prefix space). Assuming that the popularity distribution remains
means that as the number of users and the number of destinations constant, this means that as the number of users and the number of
grow, the cache size needed to obtain a given miss rate remains destinations grow, the cache size needed to obtain a given miss rate
constant O(1). remains 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 of this mode is that the EID-to-RLOC cache size only advantage of this mode is that the EID-to-RLOC cache size only
depends on the traffic characteristics at the ITR and is independent depends on the traffic characteristics at the ITR and is independent
of the size of the Provider domain. This benefit comes at the cost of the size of the Provider domain. This benefit comes at the cost
of some delay to transmit the packets that do not hit an entry in the of some delay to transmit the packets that do not hit an entry in the
cache (for which a mapping has to be learned). This delay is bound cache (for which a mapping has to be learned). This delay is bound
by the time necessary to retrieve the mapping from the mapping by the time necessary to retrieve the mapping from the mapping
system. Moreover, similarly to a push model (e.g., BGP), the pull system. Moreover, similarly to a push model (e.g., BGP), the pull
skipping to change at page 6, line 43 skipping to change at page 7, line 4
routing in environments where there is little to no correlation routing in environments where there is little to no correlation
between network endpoints and topological location. In service between network endpoints and topological location. In service
provider environments, this application is needed in a range of provider environments, this application is needed in a range of
consumer use cases which require an inline anchor to deliver a consumer use cases which require an inline anchor to deliver a
service to a subscribers. Inline anchors provide one of three types service to a subscribers. Inline anchors provide one of three types
of capabilities: 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, the approach commonly used by operators is to aggregate
custom built boxes. This limits deployments as end-points only can service anchors in custom built boxes. This limits deployments as
move on the same mobile gateway, functions can be chained only if end-points only can move on the same mobile gateway, functions can be
traffic traverses the same wire or the same DPI box, and capacity can chained only if traffic traverses the same wire or the same DPI box,
scale out only if traffic fans out to/from a specific load balancer. and capacity can scale out only if traffic fans out 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 for 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), Virtualized Customer Premise Equipment or vCPE, Packet Core (vEPC), Virtualized Customer Premise Equipment or vCPE,
where functionality previously anchored at a customer premises is now where functionality previously anchored at a customer premises is now
dynamically allocated in-network, Virtualized SGi LAN, Virtual IMS dynamically allocated in-network, Virtualized SGi LAN, Virtual IMS
and Virtual SBC, etc. and Virtual SBC, etc.
Current deployments by ConteXtream, using a pre-standards (designed ConteXtream ([ConteXtream]) has been deploying map-assisted overlay
2006) LISP-based architecture, support a total of 100 million networks since 2006, first with a proprietary solution, then evolving
subscribers. And, a deployment at a tier-1 US Mobile operator with to standard LISP. The solution has been deployed in production in
over 50 million subscribers provides a 39% download rate improvement three tier-1 operators spanning hundreds of millions of subscribers.
over LTE. Map assisted overlays had been primarily used to map subscriber flows
to services resources dynamically based on profiles and conditions.
Specifically it has been used to map mobile subscribers to value-
added/optimization services, broadband subscribes to telephony
services, and fixed-mobile subscribers to BNG (Broadband Network
Gateway) functions and Internet access services. The LISP map-
assisted overlay architecture is used to optimally resolve subscriber
to services to functions to instances to IP overlay aggregation
locations, just in time, per flow.
4.1. Traffic engineering 4.1. Traffic engineering
In the current (non-LISP)routing infrastructure, addresses used by In the current (non-LISP)routing infrastructure, addresses used by
stub networks are globally routable and the routing system stub networks are globally routable and the routing system
distributes the routes to reach these stubs. With LISP, the EID distributes the routes to reach these stubs. With LISP, the EID
prefixes of a LISP site are not routable in the DFZ, mappings are prefixes of a LISP site are not routable in the DFZ, mappings are
needed in order to determine the list of LISP routers to contact to needed in order to determine the list of LISP routers to contact to
forward packets. This difference is significant for two reasons. forward packets. This difference is significant for two reasons.
First, packets are not forwarded to a site but to a specific router. First, packets are not forwarded to a site but to a specific router.
Second, a site can control the entry points for its traffic by Second, a site can control the entry points for its traffic by
controlling its mappings. controlling its mappings.
For traffic engineering purposes, 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
proportionally to their weight among the RLOCs with the lowest If several RLOCs with the highest priority exist, then the traffic is
priority value. Traffic engineering in LISP thus allows the mapping balanced proportionally to their weight among such RLOCs. Traffic
owner to have a fine-grained control on the primary and backup path engineering in LISP thus allows the mapping owner to have a fine-
for its incoming and outgoing packets use. In addition, it can share grained control on the primary and backup path for its incoming and
the load among its links. An example of the use of such a feature is outgoing packets use. In addition, it can share the load among its
described by Saucez et al. [SDIB08], showing how to use LISP to links. An example of the use of such a feature is described by
direct different types of traffic on different links having different Saucez et al. [SDIB08], showing how to use LISP to direct different
capacity. types of traffic on different links having different 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
neighborhood. neighborhood.
skipping to change at page 9, line 41 skipping to change at page 10, line 16
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 as those observed site and a LISP site are subject to the same issues as those observed
for LISP-to-LISP traffic but also have issues specific to the for LISP-to-LISP traffic but also have issues specific to the
transition mechanism that allows the LISP site to exchange packets transition mechanism that allows the LISP site to exchange packets
with a non-LISP site ([RFC6832], [RFC7215]). with a non-LISP site ([RFC6832], [RFC7215]).
The transition requires setup of proxy tunnel routers (PxTRs). The transition requires setup of proxy tunnel routers (PxTRs).
Proxies cause what is referred to as path stretch and make Proxies cause what is referred to as path stretch (i.e., a
troubleshooting harder. There are still questions related to PxTRs lengthening of the path compared to the topological shortest-path)
that need to be answered: and make troubleshooting harder. There are still questions related
to PxTRs that need to 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?
skipping to change at page 11, line 12 skipping to change at page 11, line 38
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, a critical number of but that when such failure happens, a critical number of
packets 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 on 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 may Middle boxes/filters: because of increasingly common use of
not understand the traffic, which can cause a firewall to drop encryption as a response to pervasive monitoring ([RFC7258]),
legitimate packets. In addition, LISP allows triangular or with LISP providing the option to encrypt traffic between xTRs
even rectangular routing, so it is difficult to maintain a ([I-D.ietf-lisp-crypto]), middle boxes are increasingly likely
correct state even if the middle box understands LISP. to be unable to understand encapsulated traffic, which can
Finally, filtering may also have problems because they may cause them to drop legitimate packets. In addition, LISP
think only one host is generating the traffic (the ITR), as allows triangular or even rectangular routing, so it is
long as it is not de-encapsulated. To deal with LISP difficult to maintain a correct state even if the middle box
encapsulation, LISP aware firewalls that inspect inner LISP understands LISP. Finally, filtering may also have problems
packets are proposed [lispfirewall]. because they may think only one host is generating the traffic
(the ITR), as long as it is not de-encapsulated. To deal with
LISP encapsulation, LISP aware firewalls that inspect inner
LISP packets are proposed [lispfirewall].
Troubleshooting/debugging: the major issue which LISP Troubleshooting/debugging: the major issue which LISP
experimentation has shown is the difficulty of troubleshooting. experimentation has shown is the difficulty of troubleshooting.
When there is a problem in the network, it is hard to pin-point When there is a problem in the network, it is hard to pin-point
the reason as the operator only has a partial view of the the reason as the operator only has a partial view of the
network. The operator can see what is in its EID-to-RLOC network. The operator can see what is in its EID-to-RLOC
cache/database, and can try to obtain what is potentially cache/database, and can try to obtain what is potentially
elsewhere by querying the Map Resolvers, but the knowledge elsewhere by querying the Map Resolvers, but the knowledge
remains partial. On top of that, ICMP packets only carry the remains partial. On top of that, ICMP packets only carry the
first few tens of bytes of the original packet, which means first few tens of bytes of the original packet, which means
that when an ICMP arrives at the ITR, it might not contain that when an ICMP arrives at the ITR, it might not contain
enough information to allow correct troubleshooting. enough information to allow correct troubleshooting.
Deployment in the beta network has shown that LISP+ALT Deployment in the beta network has shown that LISP+ALT
([RFC6836], [CCR13]) was not easy to maintain and control, ([RFC6836]) was not easy to maintain and control ([CCR13]),
which explains the migration to LISP-DDT [I-D.ietf-lisp-ddt]. which explains the migration to LISP-DDT ([I-D.ietf-lisp-ddt]),
based on a massively distributed and hierarchical approach
([CCR13]).
Business/Operational-related: Iannone et al. [IL10] have shown that Business/Operational-related: Iannone et al. [IL10] have shown that
there are economical incentives to migrate to LISP, however, there are economical incentives to migrate to LISP, however,
some questions remain. For example, how will the EIDs be some questions remain. For example, how will the EIDs be
allocated to allow aggregation and hence scalability of the allocated to allow aggregation and hence scalability of the
mapping system? Who will operate the mapping system mapping system? Who will operate the mapping system
infrastructure and for what benefits? infrastructure and for what benefits? What if several
operators run different mapping systems? How will they
interoperate or share mapping information?
Reachability: The overhead related to RLOC reachability mechanisms Reachability: The overhead related to RLOC reachability mechanisms
is 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 A thorough security and threats analysis of the LISP protocol is
scope of the present document. A thorough analysis of LISP security carried out in details in [I-D.ietf-lisp-threats]. Like for other
threats is detailed in [I-D.ietf-lisp-threats]. Internet technologies, also for LISP most of threats can be mitigated
using Best Current Practice, meaning with careful deployment an
configuration (e.g., filter) and also by activating only features
that are really necessary in the deployment and verifying all the
information obtained from third parties. Unless gleaning (Section 6
of [RFC6836] and Section3.1 of [I-D.ietf-lisp-threats]) features are
used, the LISP data-plane shows the same level of security as other
IP-over-IP technologies. From a security perspective, the control-
plane remains the critical part of the LISP architecture. To
mitigate the threats on the mapping system, authentication should be
used for all control plane messages. The current specification
([RFC6836], [I-D.ietf-lisp-sec]) defines security mechanisms which
can reduce threats in open network environments. The LISP
specification defines a generic authentication data field for control
plane messages ([RFC6836]) which could be used for a general
authentication mechanisms for the LISP control-plane while staying
backward compatible.
8. Acknowledgments 8. Acknowledgments
Thanks to Deborah Brungard and Wassim Haddad for their thorough Thanks to Deborah Brungard, Ben Campbell, Spencer Dawkins, Stephen
reviews, comments, and suggestions. Farrel, Kathleen Moriarty, Hilarie Orman, 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 Alia Atlas, Sharon
Fuller, Joel Halpern, Terry Manderson, Gregg Schudel, Ron Bonica, Barkai, Vince Fuller, Joel Halpern, Terry Manderson, Gregg Schudel,
Ross Callon. Ron Bonica, and 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
[I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-13 (work in progress),
August 2015.
[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,
DOI 10.17487/RFC6830, January 2013, DOI 10.17487/RFC6830, January 2013,
<http://www.rfc-editor.org/info/rfc6830>. <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, DOI 10.17487/RFC6831, Environments", RFC 6831, DOI 10.17487/RFC6831,
January 2013, <http://www.rfc-editor.org/info/rfc6831>. January 2013, <http://www.rfc-editor.org/info/rfc6831>.
skipping to change at page 13, line 37 skipping to change at page 14, line 41
Communication Review. Vol. 43, N. 2., April 2013. 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.
[ConteXtream]
ConteXtream Software Company, "SDN and NFV solutions for
carrier networks. (Further details on LISP only through
private inquiry.)", http://www.contextream.com.
[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", the reachability of LISP ETRs in case of failures",
draft-bonaventure-lisp-preserve-00 (work in progress), draft-bonaventure-lisp-preserve-00 (work in progress),
July 2009. July 2009.
[I-D.coras-lisp-re] [I-D.coras-lisp-re]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J., Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-07 (work in progress), Engineering", draft-coras-lisp-re-08 (work in progress),
April 2015. November 2015.
[I-D.farinacci-lisp-mr-signaling] [I-D.farinacci-lisp-mr-signaling]
Farinacci, D. and M. Napierala, "LISP Control-Plane Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06
(work in progress), February 2015. (work in progress), February 2015.
[I-D.farinacci-lisp-signal-free-multicast] [I-D.farinacci-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-farinacci-lisp-signal-free-multicast-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-09 (work Engineering Use-Cases", draft-farinacci-lisp-te-09 (work
in progress), September 2015. in progress), September 2015.
[I-D.ietf-lisp-crypto]
Farinacci, D. and B. Weis, "LISP Data-Plane
Confidentiality", draft-ietf-lisp-crypto-02 (work 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-11 (work in Address Format (LCAF)", draft-ietf-lisp-lcaf-11 (work in
progress), September 2015. progress), September 2015.
[I-D.ietf-lisp-threats] [I-D.ietf-lisp-sec]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats Maino, F., Ermagan, V., Cabellos-Aparicio, A., and D.
Analysis", draft-ietf-lisp-threats-13 (work in progress), Saucez, "LISP-Security (LISP-SEC)", draft-ietf-lisp-sec-09
August 2015. (work in progress), October 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-13 (work in progress), Mobile Node", draft-meyer-lisp-mn-13 (work in progress),
July 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),
skipping to change at page 15, line 34 skipping to change at page 16, line 47
OpenWRT", http://lispmob.org, 2015. OpenWRT", http://lispmob.org, 2015.
[OpenLISP] [OpenLISP]
"The OpenLISP Project", http://www.openlisp.org, 2013. "The OpenLISP Project", http://www.openlisp.org, 2013.
[QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O. [QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O.
Bonaventure, "Evaluating the benefits of the locator/ Bonaventure, "Evaluating the benefits of the locator/
identifier separation", In Proc. ACM MobiArch 2007, identifier separation", In Proc. ACM MobiArch 2007,
May 2007. May 2007.
[RFC4984] Meyer, D., Ed., Zhang, L., Ed., and K. Fall, Ed., "Report
from the IAB Workshop on Routing and Addressing",
RFC 4984, DOI 10.17487/RFC4984, September 2007,
<http://www.rfc-editor.org/info/rfc4984>.
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258,
May 2014, <http://www.rfc-editor.org/info/rfc7258>.
[S11] Saucez, D., "Mechanisms for Interdomain Traffic [S11] Saucez, D., "Mechanisms for Interdomain Traffic
Engineering with LISP", PhD Thesis, Universite catholique Engineering with LISP", PhD Thesis, Universite catholique
de Louvain, 2011, October 2011. de Louvain, 2011, October 2011.
[SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in [SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in
LISP", In Proc. IFIP Networking 2012, May 2012. LISP", In Proc. IFIP Networking 2012, May 2012.
[SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure, [SDIB08] Saucez, D., Donnet, B., Iannone, L., and O. Bonaventure,
"Interdomain Traffic Engineering in a Locator/Identifier "Interdomain Traffic Engineering in a Locator/Identifier
Separation Context", In Proc. of Internet Network Separation Context", In Proc. of Internet Network
 End of changes. 30 change blocks. 
107 lines changed or deleted 171 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/