Comments welcome!
Comments inline.
Lixia
-----------
LISP Critique
LISP continues to go through changes based on lessons learned in
actual deployment. This critique is based on the (understanding of)
description at the time of this writing. This critique includes
LISP is going through engineering changes as a reflection of
deployment. There really aren't any architectural changes happening.
issues from fundamental architectural limitations, potential
problems that require co-ordinated change, and new issues as the
results of the design; in addition it also includes a clarification
of some basic definitions.
First, two basic terms in LISP needs clarification: as state in LISP
drafts:
"LISP specifies an architecture and mechanism for replacing the
addresses currently used by IP with two separate name spaces:
Endpoint IDS (EIDs), used within sites, and Routing Locators
(RLOCs),
used on the transit networks that make up the Internet
infrastructure."
Thus "EID" in LISP is not a host identifier, but IP addresses used
within a site for packet delivery. Furthermore, an RLOC is not
simply any IP address reachable in the global default free zone; it
is an special address that binds to an attachment point of a site.
A LISP EID is a host identifier. It is also a locally scoped locator
that does not require global routing knowledge from core routers.
Regarding the architecture, LISP's most serious challenges are due
to the fact that it effectively divides today's routed IP address
space into two, edges and the core, which comes with all the
challenges that such a grand division brings; the list below
attempts to capture the major ones that have been identified (not in
priority order).
The first question is whether, or how, one can draw a clear boundary
to sort existing networks into the core and edges. For example where
should one put those transit networks that do not provide global
connectivity (e.g. Internet2)? Do such networks belong to the core
or edges? Does the core represent a connected cloud (bar transient
failures)?
The second class of challenges arises from the fact that the
reachability to each edge destination is now a combined result of 3
major components: the mapping database that captures connectivity
between an edge site and its TRs, realtime status between an edge
site and its TRs, and the connectivity between ITR and ETR to
encapsulate packets over. In designing these components, three goals
are often in conflict: minimizing overhead, minimizing complexity,
and maximizing performance.
Because the mapping database will be very large in size, LISP lets
ITRs query mapping on demand, which brings up the question of how to
handle packets while ITR waiting for the mapping information. The
current decision (dropping packets) favors simplicity at the cost of
data performance. Would be feasible to buffer the packets? How deep
such a buffer could be? Such questions need future research.
An implementation *could* queue packets. This has the same
architectural tradeoffs that ARP and IPv6 Neighbor Discovery have. And
the architecture says data packets could be used as Map-Requests.
Another issue arises from caching the mapping information: caching
improves the performance, but introduces the problem of detecting,
and replacing, outdated mappings. This is a very lengthy topic with
many subtly different failure modes, which cannot be covered here in
any detail.
But you make is sound that LISP doesn't address this. There are
numerous solutions to this and several are implemented.
Because of this caching effect, and the fact that the ETR to a
multihomed destination site is chosen at ITR, LISP design also faces
challenges of response to component failures. LISP cannot easily
test reachability of ultimate destinations (e.g. behind an ETR).
Well it could. It could ping EIDs. Just like a BGP router could ping
an endpoint host. But it doesn't because it would not scale. It
doesn't mean that because a BGP route is in a routing table that the
destination is reachable.
So please compare apples and apples. That means compare what the new
LISP idea challenges are with the same challenges existing routing
architectures have.
Regarding the mapping system, the ALT design has potential
performance and scaling issues (e.g. concentration of request load
at the top-level nodes); an interface has been built to allow
If you say ALT doesn't scale, then you must say the BGP based Internet
doesn't scale. Are you willing to say that?
replacement of the mapping system. Another issue is potential
identification (EIDs) namespace provider lock-in, unless some
mechanism can be worked out to allow multiple competing providers to
provide resolutions from EIDs to ETRs (perhaps as part of a new
mapping system). This last point touches on an even more important
issue: an ISP's performance critically depends on the performance of
the mapping system, a single mapping system to serve all seems
problematic.
There are no address providers. It is a one time sale. You buy an
address block from a registry and the relationship is over.
If you want to bind it with locators and buy service from a Mapping
Service Provider (MSP), then you have choices because they all attach
at the ALT at the same aggregation layer.
We are modeling this in our 3rd generation of the LISP test network.
The only relationship a LISP site has with a service provider is the
link that attaches to it and the single address the SP assigns to the
CE side of the link. Once you disable the contract with the SP, the
link goes away and the address does. The EID-prefixs and other
locators do not change. The mapping entry for the site gets updated
dynamically in the Map-Server as well as existing caches and
communication continues. In fact, TCP connections stay up during this
change.
Another class of issues relates to network management and operations.
- Although LISP does provide significant tools for multi-homing,
load-sharing, optimal-entry-selection, etc, these currently depend
on correct
configuration; response to component failures is also limited.
Can you sight examples where this is true. Just making a claim doesn't
mean it is true.
- LISP is currently working through NAT boxes, but only in limited
configurations. In particular, due to the use of fixed UDP ports,
it is not
currently possible to support more than one ETR behind a NAT box.
This is easily fixed with a protocol change and not an architectural
change. And this is only the case when the NAT and LISP are not co-
located in the same box(es).
- Encapsulations of data packets increase the packet size and may
lead to PMTU problems.
Just like existing tunneling solutions that seem to work and generate
revenue in practice.
Last but not least: One would not be able to see global routing
table size reduction unless/until LISP has been adopted by
significant number of networks. On the other hand, LISP is
potentially a useful tool in data centers where its one-level of
indirection may help significantly simplify the support for virtual
servers.
This is simply not true. The more specifics from site advertisements
are withdrawn at the expense of coarse prefixes being injected by
PITRs. The difference in the number of 1 or 2 orders of magnitude.
And why is there two points in the same paragraph? The data center
comment came out of no where.
Dino
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
