draft-ietf-lisp-impact-02.txt   draft-ietf-lisp-impact-03.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: November 8, 2015 Telecom ParisTech Expires: December 12, 2015 Telecom ParisTech
A. Cabellos A. Cabellos
F. Coras F. Coras
Technical University of Technical University of
Catalonia Catalonia
May 7, 2015 June 10, 2015
LISP Impact LISP Impact
draft-ietf-lisp-impact-02.txt draft-ietf-lisp-impact-03.txt
Abstract Abstract
The Locator/Identifier Separation Protocol (LISP) aims at improving The Locator/Identifier Separation Protocol (LISP) aims at improving
the Internet scalability properties leveraging on three simple the Internet scalability properties leveraging on three simple
principles: address role separation, encapsulation, and mapping. In principles: address role separation, encapsulation, and mapping. In
this document, based on implementation work, deployment experiences, this document, based on implementation work, deployment experiences,
and theoretical studies, we discuss the impact that the deployment of and theoretical studies, we discuss the impact that the deployment of
LISP can have on both the Internet in general and the end-user in LISP can have on both the Internet in general and the end-user in
particular. particular.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 November 8, 2015. This Internet-Draft will expire on December 12, 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 3, line 24 skipping to change at page 3, line 24
instance, LISP provides a mean for a LISP site to precisely control instance, LISP provides a mean for a LISP site to precisely control
its inter-domain outgoing and incoming traffic, with the possibility its inter-domain outgoing and incoming traffic, with the possibility
to apply different policies to different domains exchanging traffic to apply different policies to different domains exchanging traffic
with it. LISP can also be used to ease the transition from IPv4 to with it. LISP can also be used to ease the transition from IPv4 to
IPv6 as it allows to transport IPv4 over IPv6 or IPv6 over IPv4. IPv6 as it allows to transport IPv4 over IPv6 or IPv6 over IPv4.
Furthermore, LISP also provides a solution to perform inter-domain Furthermore, LISP also provides a solution to perform inter-domain
multicast. multicast.
This document discusses the impact of LISP's deployment on the This document discusses the impact of LISP's deployment on the
Internet and on end-users and shows the consequences of the Internet and on end-users and shows the consequences of the
interworking infrastructure in terms of path-stretch. There still interworking infrastructure in terms of path-stretch. LISP comprises
are many, economical rather than technical, open questions related to both a tunnel-based data plane and a distributed control plane for
the deployment of such infrastructure. Moreover, encapsulation may the Internet, and requires some new functionalities, such as RLOC
reachability mechanisms. Being more than simple encapsulation
technology, there are remaining open questions related to the
deployment of LISP in the Internet. Moreover, encapsulation may
raise some issues (which have a limited impact in practice) because raise some issues (which have a limited impact in practice) because
it 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, encapsulation stresses resiliency as it makes Internet. Also, encapsulation stresses resiliency as it makes
failure detection and recovery slower than with hop-by-hop routing. failure detection and recovery slower than with hop-by-hop routing.
2. LISP in a nutshell 2. LISP in a nutshell
skipping to change at page 4, line 45 skipping to change at page 4, line 48
experience less churn). Furthermore, at the edge network, experience less churn). Furthermore, at the edge network,
information necessary to forward packets (i.e., the mappings) is information necessary to forward packets (i.e., the mappings) is
obtained on demand using a pull model (whereas the current Internet obtained on demand using a pull model (whereas the current Internet
uses a push model, instantiated by BGP). Therefore, scalability of uses a push model, instantiated by BGP). Therefore, scalability of
edge networks is now independent of the Internet's size and is now edge networks is now independent of the Internet's size and is now
related its traffic matrix. This scaling improvement is proven by related its traffic matrix. This scaling improvement is proven by
several works. The research work cited hereafter is based on the several works. The research work cited hereafter is based on the
following assumptions: 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; BGP routing infrastructure (current PI addresses only);
o EIDs are used only at the stub ASes, not in the transit ASes; o EIDs are used only at the stub ASes, not in the transit ASes;
o the RLOCs of an EID prefix are deployed at the edge between the o the RLOCs of an EID prefix are deployed at the edge between the
stubs owning the EID prefix and the providers, allocating the stubs owning the EID prefix and the providers, allocating the
RLOCs in a Provider Aggregetable (PA) mode. RLOCs in a Provider Aggregetable (PA) mode.
The above assumptions are inline with [RFC7215] and current LISP The above assumptions are inline with [RFC7215] and current LISP
deployments, however, such situation may change in the long term. deployments, however, such situation may change in the long term.
Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space Nevertheless, [KIF13] and [CDLC] explore different EDI prefix space
sizes, still showing results that are consitent and equivalent to the sizes, still showing results that are consitent and equivalent to the
above assumptions. above assumptions.
skipping to change at page 12, line 5 skipping to change at page 12, line 5
the migration to LISP-DDT [I-D.ietf-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 Iannone et al. [IL10] shown that there is However, even though Iannone et al. [IL10] shown that there is
economical incentives to migrate to LISP, some questions are on economical incentives to migrate to LISP, some questions are on
hold. For example, how will the EIDs be allocated to allow hold. For example, how will the EIDs be allocated to allow
aggregation and hence scalability of the mapping system? Who aggregation and hence scalability of the mapping system? Who
will operate the mapping system infrastructure and for what will operate the mapping system infrastructure and for what
benefit? benefit?
Reachability: The overhead related to RLOC rechability mechanisms is
not known.
6. IANA Considerations 6. IANA Considerations
This document makes no request to the IANA. This document makes no request to the IANA.
7. Security Considerations 7. Security Considerations
Security and threats analysis of the LISP protocol is out of the Security and threats analysis of the LISP protocol is out of the
scope of the present document. A thorough analysis of LISP security scope of the present document. A thorough analysis of LISP security
threats is detailed in [I-D.ietf-lisp-threats]. threats is detailed in [I-D.ietf-lisp-threats].
skipping to change at page 13, line 40 skipping to change at page 13, line 44
Engineering", draft-coras-lisp-re-07 (work in progress), Engineering", draft-coras-lisp-re-07 (work in progress),
April 2015. April 2015.
[I-D.farinacci-lisp-mr-signaling] [I-D.farinacci-lisp-mr-signaling]
Farinacci, D. and M. Napierala, "LISP Control-Plane Farinacci, D. and M. Napierala, "LISP Control-Plane
Multicast Signaling", draft-farinacci-lisp-mr-signaling-06 Multicast Signaling", draft-farinacci-lisp-mr-signaling-06
(work in progress), February 2015. (work in progress), February 2015.
[I-D.farinacci-lisp-signal-free-multicast] [I-D.farinacci-lisp-signal-free-multicast]
Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast", Moreno, V. and D. Farinacci, "Signal-Free LISP Multicast",
draft-farinacci-lisp-signal-free-multicast-02 (work in draft-farinacci-lisp-signal-free-multicast-03 (work in
progress), December 2014. progress), June 2015.
[I-D.farinacci-lisp-te] [I-D.farinacci-lisp-te]
Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic Farinacci, D., Kowal, M., and P. Lahiri, "LISP Traffic
Engineering Use-Cases", draft-farinacci-lisp-te-08 (work Engineering Use-Cases", draft-farinacci-lisp-te-08 (work
in progress), March 2015. in progress), March 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.
 End of changes. 9 change blocks. 
11 lines changed or deleted 16 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/