Internet DRAFT - draft-saucez-lisp-iesg-statement
draft-saucez-lisp-iesg-statement
Network Working Group D. Saucez (Ed.)
Internet-Draft INRIA
Intended status: Informational October 14, 2012
Expires: April 17, 2013
LISP IESG Statement
draft-saucez-lisp-iesg-statement-00.txt
Abstract
The Locator/Identifier Separation Protocol (LISP) relies on three
simple principles to scale the Internet: address role separation,
encapsulation, and mapping. In this document, based on
implementation, deployment, and theoretical studies, we discuss the
impact that a LISP deployment would have on the Internet and for the
users.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 17, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
Saucez (Ed.) Expires April 17, 2013 [Page 1]
Internet-Draft LISP IESG Statement October 2012
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. LISP in a nutshell . . . . . . . . . . . . . . . . . . . . . . 3
3. LISP for scaling the Internet . . . . . . . . . . . . . . . . 4
4. Beyond scaling the Internet . . . . . . . . . . . . . . . . . 5
4.1. Traffic engineering . . . . . . . . . . . . . . . . . . . 5
4.2. IPv4/IPv6 Transition . . . . . . . . . . . . . . . . . . . 6
4.3. Inter-domain multicast . . . . . . . . . . . . . . . . . . 6
5. Impact of LISP on operations and business model . . . . . . . 7
5.1. Impact on non-LISP traffic and sites . . . . . . . . . . . 7
5.2. Impact on LISP traffic and sites . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9
9.1. Normative References . . . . . . . . . . . . . . . . . . . 9
9.2. Informative References . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
Saucez (Ed.) Expires April 17, 2013 [Page 2]
Internet-Draft LISP IESG Statement October 2012
1. Introduction
The Locator/Identifier Separation Protocol (LISP) relies on three
simple principles to scale the Internet: address role separation,
encapsulation, and mapping. The main target of LISP is to make the
Internet more scalable by reducing the number of routes in the DFZ as
well as the churn. As LISP relies on mapping and encapsulation, it
offers more than just scalability. For example, LISP provides a mean
for a LISP site to precisely control is inter-domain outgoing and
incoming traffic, with the possibility to apply different policies to
the different domains exchanging traffic with it. LISP can also be
used during the IPv/IPv6 transition phase as it allows to transport
IPv4 over IPv6 or IPv6 over IPv4. LISP also provides a solution to
perform inter-domain multicast.
In this document we discuss the impact a LISP deployment would have
on the Internet and for the users. We first show that interworking
results in path stretch and there is still open questions related to
the deployment model of such interworking (not technical but
economical). Afterward, we show that encapsulation causes issue (but
not in practice) because it reduces the MTU. An important impact of
LISP on operation is related to resiliency and troubleshooting.
Indeed, as LISP relies on mappings that are cached and on
encapsulation, troubleshooting is harder than in the traditional
Internet. Also, end-to-end encapsulation also stress resiliency as
it makes failure detection and recovery slower than with hop-by-hop
routing.
2. LISP in a nutshell
The Locator/Identifier Separation Protocol (LISP) relies on three
simple principles: address role separation, encapsulation, and
mapping.
Addresses are separated in two roles: the Routing Locators (RLOCs)
and the Endpoint Identifiers (EIDs). RLOCs are assigned from the
address space of the Internet service providers. The EIDs are
attributed by block extracted from the EID Space. To limit the
scalability problem of today's Internet, only the routes towards the
RLOCs are announced on the Internet while EIDs are also propagated
today.
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
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,
it sends it as in today's Internet. The packet eventually arrives at
Saucez (Ed.) Expires April 17, 2013 [Page 3]
Internet-Draft LISP IESG Statement October 2012
the border of its site at an ITR. Because EIDs are not routable on
the Internet, the packet is encapsulated with the source address set
to the ITR RLOC and the destination address set to the ETR RLOC. The
encapsulated packet is then forwarded in the Internet until it
reaches the selected ETR. The ETR decapsulates the packet and
forwards it to the destination. The acronym xTR for Ingress/Egress
tunnel router is used for a router playing these two roles.
The correspondence between EIDs and RLOCs is given by the mappings.
When an ITR needs to find ETR RLOCs that serve an EID it queries the
mapping system. It is worth noticing that LISP is not restricted to
the Internet Protocol for the EID addresses. Indeed, the LISP
Canonical Address Format (LCAF) allows encoding any kind of address
[I-D.farinacci-lisp-lcaf]. Therefore, any address type can be used
as EID (the address is the key for the mapping lookup) and LISP can
then transport, for example, Ethernet frames over the Internet.
A more throughout introduction to LISP can be found in
[I-D.chiappa-lisp-introduction] and a discussion around the
architecture in [I-D.chiappa-lisp-architecture]. The complete
specifications are given in [I-D.ietf-lisp], [I-D.ietf-lisp-ms],
[I-D.fuller-lisp-ddt], [I-D.ietf-lisp-interworking],
[I-D.ietf-lisp-map-versioning], and [I-D.ietf-lisp-sec].
3. LISP for scaling the Internet
The first goal of LISP is to scale the Internet. LISP improves the
Internet scalability because traffic engineering and stub do not
appear in the core anymore, so smaller and more stable tables in the
core. Also, at the edge, the routing tables scale with the edge, its
own, traffic pattern and not the size of the Internet. Scaling
improvement is proven by several works.
Quoitin et al. show in [QIdLB07] that the locator/identifier
separation improves the routing scalability by reducing the FIB size
and increases the path diversity and thus the traffic engineering
capabilities. In addition, Iannone and Bonaventure show in [IB07]
that the number of mapping entries that must be supported at an ITR
of a campus network is limited and does not represent more that 3 to
4 Megabytes of memory. Similarly, Juhoon 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 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
Saucez (Ed.) Expires April 17, 2013 [Page 4]
Internet-Draft LISP IESG Statement October 2012
locators per EID if LISP were deployed in today's Internet. The
assumptions in these studies are:
o contiguous addresses tend to be used similarly, EID prefixes
follow the current BGP prefixes decomposition;
o EIDs are used only at the stub ASes, not in the transit ASes;
o the RLOCs of an EID are deployed at the edge between the stubs
owning the EID and the providers and locator addresses are
allocated in a Provider Aggregetable (PA) mode.
4. Beyond scaling the Internet
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
traffic engineering [S11], can be used as an IPv6 transition at the
routing level, and inter-domain multicast [I-D.ietf-lisp-multicast],
[I-D.coras-lisp-re]. LISP has also proven to be a good protocol for
mobility of devices in the Internet [I-D.meyer-lisp-mn] or even
virtual machine mobility in data centers and multi-tenant VPN,
however, we will not discuss here these two last points as they are
out of the scope of the charter.
4.1. Traffic engineering
In today's Internet, stub networks are globally routable and the
routing system distributes the routes to reach these stubs. On the
contrary, the EID prefixes of a LISP site are not routable on the
Internet and mappings are needed to determine the list of LISP
routers to contact to send them packets. The difference is
significant for two reasons. First, packets are not sent to a site
but to a specific ingress router. Second, a site can control the
entry points for its traffic by controlling its mappings.
For traffic engineering purpose, a mapping associate an EID prefix to
a list of RLOCs. Each RLOC is annotated with a priority and a
weight. When there is several RLOCs, the ITR selects the one with
the lowest priority value and sends the encapsulated packet to this
RLOC. If several such RLOCs exist, then the traffic is balanced
proportionally to the weight among the different RLOC with the lowest
priority value. Traffic engineering in LISP thus allows the mapping
owner to have a fine-grained control on the primary and backup path
its incoming and outgoing packet use. In addition, it can share the
load among its links.
Traffic engineering in LISP goes one step further. Indeed, every
Saucez (Ed.) Expires April 17, 2013 [Page 5]
Internet-Draft LISP IESG Statement October 2012
Map-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 mapping owner to differentiate the answer (Map-Reply) it gives to
Map-Requests based on the requester. This functionality is not
possible today because a domain cannot control exactly the routes
that will be received by domains that are not in the direct
neighborhood.
4.2. IPv4/IPv6 Transition
The LISP encapsulation mechanism is designed to support any
combination of locators and identifiers address family. It is then
possible to bind IPv6 EIDs with IPv4 RLOCs and vice-versa. This
allows transporting IPv6 packets over an IPv4 network (or IPv4
packets over an IPv6 network), thus enabling the use of LISP as an
IPv6 transition mechanism.
A not so uncommon example is the case of the network infrastructure
of a datacenter being IPv4-only while dual-stack front-end load
balancers are used. In this scenario, LISP can be used to provide
IPv6 access to servers even though the network and the servers only
support IPv4. Indeed, assuming that the datacenter's ISP offers IPv6
connectivity, the datacenter only needs to deploy one (or more)
xTR(s) at its border with the ISP and one (or more) xTR(s) directly
connected to the load balancers. The xTR(s) at the ISP's border
tunnels IPv6 packets over IPv4 to the xTR(s) directly attached to the
load balancer. The load balancer's xTRs decapsulate the packets and
forward them to the load balancers, which act as proxies, translating
each IPv6 packet into an IPv4. IPv4 packets are then sent to the
appropriate servers. Similarly, when the server response arrives at
the load balancer, the packet is translated back into an IPv6 packet
and forwarded to its xTR(s), which in turn will tunnel it back, over
the IPv4-only infrastructure, to the xTR(s) connected to the ISP.
The packet is then decapsulated and forwarded to the ISP natively in
IPv6.
4.3. Inter-domain multicast
LISP naturally LISP supports multicast as a list of locators is
associated to the prefixes, it is thus just necessary to duplicate
the packets to multiple RLOCs instead of selecting only one
[I-D.ietf-lisp-multicast].
[I-D.coras-lisp-re] and [CDM+12] propose a technique to construct
multicast distribution tree and the test of three different
management strategies for low latency content delivery show that such
overlay can support thousands of members and hundreds of thousands of
clients. Interestingly, when constructed wisely, high client churn
Saucez (Ed.) Expires April 17, 2013 [Page 6]
Internet-Draft LISP IESG Statement October 2012
has a limited impact on the performance and management overhead.
5. Impact of LISP on operations and business model
Important implementation efforts (Cisco NXOS, Cisco IOS, FreeBSD
OpenLISP, Linux LISPMob, LISP-Click) have been made to assess the
specifications and interoperability tests [Was09] have been a
success. Large scale deployment in the international lisp4.net
testbed permit to learn operational matters related to LISP.
We have to distinguish the impact on LISP sites and traffic of the
impact on non-LISP site and traffic.
5.1. Impact on non-LISP traffic and sites
LISP has no impact on traffic which has neither LISP origin nor LISP
destination. However, LISP can have a significant impact on traffic
between a LISP site and a non-LISP site. Indeed, traffic between a
non-LISP site and a LISP site are subject to the same issues than
those observed for LISP-to-LISP traffic (cf supra) but also have
issues specific to the transition mechanism that allow LISP site to
exchange packets with non-LISP site ([I-D.ietf-lisp-interworking],
[I-D.ietf-lisp-deployment]).
Indeed, the transition requires proxies tunnel routers (PxTRs).
PxTRs do not cause particular technical issue. However, by
definition proxies cause path stretch and make troubleshooting
harder. There are still big questions related to PxTRs that have to
be answered:
o Where to deploy PxTRs? The placement in the topology has an
important impact on the path stretch.
o How many PxTRs? The number of PxTR has a direct impact on there
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
whole EID space or will it be segmented between different PxTRs?
o Who to operate PxTRs? The IETF does not aim at providing business
model hints, however, an important question to answer is related
to the entities that will deploy PxTRs, how they will earn money
and how the traffic will be carried with respect for the security
and privacy.
PxTR also normally have to advertise the EID prefix they are proxy
for in BGP. However, if proxies are managed by different entities,
Saucez (Ed.) Expires April 17, 2013 [Page 7]
Internet-Draft LISP IESG Statement October 2012
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
routing.
5.2. Impact on LISP traffic and sites
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,
by construction, LISP also have side impact on operations:
o MTU issue: as LISP uses encapsulation, the MTU is reduced (by 36
bytes in IPv4), this has implication on potentially all the
traffic. However, in practice, on the lisp4.net network, we have
not seen major issue due to the MTU. This is probably due to the
fact that current end-host stacks are well designed to deal with
the problem of MTU.
o Resiliency issue: the advantage of flexibility and control offered
by the loc/ID separation comes at the cost of increasing the
complexity of the reachability detection. Indeed, identifiers are
not directly routable and have to be mapped to locators. But a
locator may be unreachable while others are still reachable. This
is an important problem for any tunnel-based solution. In the
current Internet, packets are forwarded independently of the
border router of the network meaning that in case of the failure
of a border router, another one can be used. With LISP, the
destination RLOC specifically designate one particular ETR, hence
if this ETR fails, the traffic is dropped even though other ETRs
are available for the destination site. Another resiliency issue
is linked to the fact that mappings are learned on demand. When
an ITR fails, all its traffic is redirected to other ITRs that
might not have yet the mappings for the redirected traffic. The
study in [SKI+12] and [SD12] show, based on measurements and
traffic traces, that failure of ITRs and RLOC are seldom but that
when such failure happens, an important number of packet can be
dropped. Unfortunately, the current techniques for LISP
resiliency, based on monitoring or probing are not rapid enough
(failure recovery of the order of a few seconds). To tackle this
issue [I-D.bonaventure-lisp-preserve] and
[I-D.saucez-lisp-itr-graceful] propose techniques based on local
failure detection and recovery.
o Middle boxes/filters: because of encapsulation, the middle boxes
might not understand the traffic which can cause firewall to drop
legitimate packets. In addition, LISP allows triangular or even
rectangular routing, so it is hard to maintain a correct state
even if the middle box perfectly understands LISP. Finally,
filtering might also have problems because they might think only
Saucez (Ed.) Expires April 17, 2013 [Page 8]
Internet-Draft LISP IESG Statement October 2012
one host is generating the traffic (the ITR), as long as it is not
decapsulated.
o Troubleshooting/debugging: the major issue years of LISP
experimentation have shown is the difficulty of troubleshooting.
When there is a problem in the network, it is hard to pin-point
the reason as the operator only has an inconsistent view of the
network. He sees what is in its cache/database, he can try to see
what is potentially elsewhere by querying the MRs but the
knowledge is partial. On top of that, ICMP is too small, which
means that when an ICMP arrives the ITR, it might not contain
enough information to troubleshoot correctly. Furthermore,
deployment in the beta network has shown that LISP+ALT was not
easy to maintain and control, hence the migration to LISP-DDT.
o Business: the IETF is not aiming at providing business models.
However, even though [IL10] shown that there is economical
incentives to migrate to LISP, some questions are on hold. For
example, how will the EID be allocated to allow aggregation and
hence scalability of the mapping system? Who will operate the
mapping system infrastructure and for what benefit?
6. IANA Considerations
TBD
7. Security Considerations
As every protocol, LISP is subject to security issues. A detailed
analysis of LISP security threats is given in
[I-D.ietf-lisp-threats].
8. Acknowledgments
The people that contributed to this document are: Florin Coras, Vince
Fuller, Joel Halpern, Luigi Iannone, Terry Manderson, Fabio Maino,
and Gregg Schudel.
9. References
9.1. Normative References
[I-D.fuller-lisp-ddt]
Fuller, V., Lewis, D., Ermagan, V., and A. Jain, "LISP
Saucez (Ed.) Expires April 17, 2013 [Page 9]
Internet-Draft LISP IESG Statement October 2012
Delegated Database Tree", draft-fuller-lisp-ddt-04 (work
in progress), September 2012.
[I-D.ietf-lisp]
Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
"Locator/ID Separation Protocol (LISP)",
draft-ietf-lisp-23 (work in progress), May 2012.
[I-D.ietf-lisp-alt]
Fuller, V., Farinacci, D., Meyer, D., and D. Lewis, "LISP
Alternative Topology (LISP+ALT)", draft-ietf-lisp-alt-10
(work in progress), December 2011.
[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-04
(work in progress), September 2012.
[I-D.ietf-lisp-interworking]
Lewis, D., Meyer, D., Farinacci, D., and V. Fuller,
"Interworking LISP with IPv4 and IPv6",
draft-ietf-lisp-interworking-06 (work in progress),
March 2012.
[I-D.ietf-lisp-map-versioning]
Iannone, L., Saucez, D., and O. Bonaventure, "LISP Map-
Versioning", draft-ietf-lisp-map-versioning-09 (work in
progress), March 2012.
[I-D.ietf-lisp-ms]
Fuller, V. and D. Farinacci, "LISP Map Server Interface",
draft-ietf-lisp-ms-16 (work in progress), March 2012.
[I-D.ietf-lisp-multicast]
Farinacci, D., Meyer, D., Zwiebel, J., and S. Venaas,
"LISP for Multicast Environments",
draft-ietf-lisp-multicast-14 (work in progress),
February 2012.
[I-D.ietf-lisp-sec]
Maino, F., Ermagan, V., Cabellos-Aparicio, A., Saucez, D.,
and O. Bonaventure, "LISP-Security (LISP-SEC)",
draft-ietf-lisp-sec-04 (work in progress), October 2012.
Saucez (Ed.) Expires April 17, 2013 [Page 10]
Internet-Draft LISP IESG Statement October 2012
9.2. Informative References
[CDM+12] Coras, F., Domingo-Pascual, J., Maino, F., Farinacci, D.,
and A. Cabellos-Aparicio, "Lcast: Software-defined Inter-
Domain Multicast", Technical Report, Universitat
Politecnica de Catalunya, 2012.
[I-D.bonaventure-lisp-preserve]
Bonaventure, O., Francois, P., and D. Saucez, "Preserving
the reachability of LISP ETRs in case of failures",
draft-bonaventure-lisp-preserve-00 (work in progress),
July 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.chiappa-lisp-introduction]
Art, Y., "An Introduction to the LISP Location-Identity
Separation System", draft-chiappa-lisp-introduction-01
(work in progress), July 2012.
[I-D.coras-lisp-re]
Coras, F., Cabellos-Aparicio, A., Domingo-Pascual, J.,
Maino, F., and D. Farinacci, "LISP Replication
Engineering", draft-coras-lisp-re-00 (work in progress),
July 2012.
[I-D.farinacci-lisp-lcaf]
Farinacci, D., Meyer, D., and J. Snijders, "LISP Canonical
Address Format (LCAF)", draft-farinacci-lisp-lcaf-10 (work
in progress), July 2012.
[I-D.ietf-lisp-threats]
Saucez, D., Iannone, L., and O. Bonaventure, "LISP Threats
Analysis", draft-ietf-lisp-threats-02 (work in progress),
September 2012.
[I-D.meyer-lisp-mn]
Farinacci, D., Lewis, D., Meyer, D., and C. White, "LISP
Mobile Node", draft-meyer-lisp-mn-07 (work in progress),
April 2012.
[I-D.saucez-lisp-itr-graceful]
Saucez, D., Bonaventure, O., Iannone, L., and C. Filsfils,
"LISP ITR Graceful Restart",
Saucez (Ed.) Expires April 17, 2013 [Page 11]
Internet-Draft LISP IESG Statement October 2012
draft-saucez-lisp-itr-graceful-00 (work in progress),
July 2012.
[IB07] Iannone, L. and O. Bonaventure, "On the cost of caching
locator/id mappings", In Proc. ACM CoNEXT 2007.
[IL10] Iannone, L. and T. Leva, "Modeling the economics of Loc/ID
Separation for the Future Internet", Book Chapter,
Towards the Future Internet - Emerging Trends from the
European Research, IOS Press.
[KIF11] Kim, J., Iannone, L., and A. Feldmann, "Deep dive into the
lisp cache and what isps should know about it", In Proc.
IFIP Networking 2011.
[QIdLB07] Quoitin, B., Iannone, L., de Launois, C., and O.
Bonaventure, "Evaluating the benefits of the locator/
identifier separation", In Proc. ACM MobiArch 2007.
[S11] Saucez, D., "Mechanisms for Interdomain Traffic
Engineering with LISP", PhD Thesis, Universite catholique
de Louvain, 2011.
[SD12] Saucez, D. and B. Donnet, "On the Dynamics of Locators in
LISP", In Proc. IFIP Networking 2012.
[SKI+12] Saucez, D., Kim, J., Iannone, L., Bonaventure, O., and C.
Filsfils, "A Local Approach to Fast Failure Recovery of
LISP Ingress Tunnel Routers", In Proc. IFIP Networking
2012.
[Was09] Wasserman, M., "LISP Interoperability Testing", IETF 76,
LISP WG presentation, 2009.
Author's Address
Damien Saucez
INRIA
2004 route des Lucioles BP 93
06902 Sophia Antipolis Cedex
France
Email: damien.saucez@inria.fr
Saucez (Ed.) Expires April 17, 2013 [Page 12]
