OK, here is an alternative LISP critique.
It originally started with a short intro to LISP, and also included some
counter-points about some of the problems, etc, but the result was over the
500 word limit, so I have provided (first) a stripped-down one which meets the
500 limit - the counterpoints can be moved to the (eventual) rebuttal.
At the end I have appended the original, longer, version - feel free to mine
the first section of that for additional material for the LISP intro.
Noel
---------
Any list of LISP concerns is somewhat evanescent, as constant changes are
being made based on lessons learned in actual deployment. In particular,
potential problems for which there are local, incremental fixes (i.e. do not
need global coordination, such as protocol changes) are being by-passed until
operational experience shows that they actually need to be handled.
A good example is the handling of packets which arrive at a LISP device which
does not yet have an identity->location mapping for the destination; such
packets are currently discarded. If this proves to have a significant
performance impact (predictive opinions differ), it is easy to change this so
that such packets are buffered, waiting for a mapping to be returned. The
LISP team in fact has a moderately lengthy list of such items (roughly a
dozen), but since they are not significant they are not covered here.
This critique will therefore focus on i) fundamental architectural
limitations, and ii) potential problems where amelioration will require
co-ordinated change; they are listed in rough order of significance.
- LISP's most serious challenges are due to the fact that it is effectively a
new packet-switching layer, with all the challenges (neighbour liveness
detection, etc) that such layers bring - but with a much larger fan-out than
is typical in packet-switching systems, since any ITR might communicate with
any ETR.
There are three goals which are often in conflict: minimizing overhead,
minimizing complexity, and maximizing performance. Mechanisms which meet one
(e.g. performance) often fail another (e.g. overhead), due to the fan-out
issues.
- One important example of this is caching of mappings; this 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.
- 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.
- LISP cannot easily test reachability of ultimate destinations (e.g. behind
an ETR), only other LISP devices. It therefore is inevitably (and
unavoidably) dependent on the correct functioning of any network
infrastructure on the other side of a LISP device.
- 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.
- Identification namespace provider (EIDs) lock-in might result, due to the
need to be able to look up EIDs, unless some mechanism can be worked out to
allow multiple competing providers to provide resolutions for any given
segment of the identification name-space (perhaps as part of a new mapping
system).
- Systems which query for mappings will inevitably have some performance
impact. Even when all potential delay causes which can be handled are dealt
with (e.g. the packet drop example at the top), attempts to communicate with
a 'new' site will occasionally result in some unavoidable delay.
- The ALT mapping system has some potential performance and scaling issues
(e.g. concentration of request load at the top-level nodes), although an
interface is built into the system to allow replacement of the mapping
system.
--------
LISP is an architectural enhancement to the Internet; it provides an
identification/location separation scheme which is intended to meet the goals
of both i) practical short-term deployability and ii) long-term
growth/flexibility.
It is based on encapsulation, and is intended for deployment at the edges,
initially between sites and the core (to minimize required changes to
deployed base), although deployment at hosts (in particular, mobile hosts) is
also planned.
It currently consists of devices which wrap and unwrap user traffic (ITRs and
ETRs), devices which interface to a mapping system (Map-Resolvers and
Map-Servers), and a prototype mapping system, ALT, which re-uses existing
technology (BGP and tunnels) to allow mappings to be distributed.
It initially uses existing namespaces (IPv4 and IPv6) for both identity and
location; existing namespaces are chosen to reduce the initial deployment
difficulty, and both IP versions are supported to maximize the applicability
of LISP.
Any list of LISP concerns is somewhat evanescent, as constant changes are
being made based on lessons learned in actual deployment. In particular,
potential problems for which there are local, incremental fixes (i.e. no need
for global coordination, such as protocol changes) are being by-passed until
operational experience shows that they actually need to be handled.
A good example is the handling of packets which arrive at a LISP device which
does not yet have an identity->location mapping for the destination; such
packets are currently discarded. If this proves to have a significant
performance impact (predictive opinions differ), it is easy to change this so
that such packets are buffered, waiting for a mapping to be returned. The
LISP team in fact has a moderately lengthy list of such items (roughly a
dozen or so), but since they are not significant they are not covered here.
The protocols also have a great deal of flexibility built in, to allow
incremental changes guided by experience and changing circumstances. A good
example is the user-data headers, which constitute a low data-rate channel
piggy-backed on existing traffic between the ITRs and ETRs. The fields can be
shared between a number of uses - some as yet undefined, so that additional
low-data rate control functions can be added as their need becomes obvious.
This critique will therefore focus on i) fundamental architectural
limitations, and ii) potential problems where amelioration will require
co-ordinated change; they are listed in rough order of significance.
- LISP's most serious challenges are due to the fact that it is effectively a
new packet-switching layer, with all the challenges (neighbour liveness
detection, etc) that such layers bring - but with a much larger fan-out than
is typical in packet-switching systems, since any ITR might communicate with
any ETR.
There are three goals which are often in conflict: minimizing overhead,
minimizing complexity, and maximizing performance. Mechanisms which meet one
(e.g. performance) often fail another (e.g. overhead), due to the fan-out
issues. Clever engineering (e.g. the use of the piggy-backed control channel)
can handle many of these. Some of this is also under the control of users; if
they want higher performance, and are willing to pay the overhead costs, they
can change configuration to do so.
- One important example of this is caching of mappings; this improves the
performance, but introduces the problem of detecting, and replacing, outdated
mappings. This is a very lengthy topic, which cannot be covered here in any
detail.
- Although LISP does provide significant tools for multi-homing,
load-sharing, optimal-entry-selection, etc, these currently depend on correct
configuration; response to failures is also limited. It may be possible to
ameliorate this problem with automated configuration, although this has not
yet been examined.
- LISP cannot easily test reachability of ultimate destinations (e.g. behind
an ETR), only other LISP devices. It therefore is inevitably (and
unavoidably) dependent on the correct functioning of any network
infrastructure on the other side of a LISP device.
- 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
possible to support more than one ETR behind a NAT box. (Although since
multiple ETRs behind a single NAT box would present a single point of
failure, it is not clear that this is a problem.)
- Namespace provider lock-in might result, due to the need to be able to look
up identification (EIDs), unless some mechanism can be worked out to allow
multiple competing providers to provide resolutions for any given segment of
the identification name-space (perhaps as part of a new mapping system).
- Systems which query for mappings will inevitably have some performance
impact. Even when all potential delay causes which can be handled are dealt
with (e.g. the packet drop example at the top), attempts to communicate with
a 'new' site will occasionally result in some unavoidable delay. Since the
delay in those few cases will be of the same order as DNS delays, which are
currently acceptable, this is probably not a significant issue.
- The ALT mapping system has some potential performance and scaling issues
(e.g. concentration of request load at the top-level nodes), although an
interface is built into the system to allow replacement of the mapping
system. Since a superior mapping system based on DNS is already in design,
this is not felt to be a serious issue.
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
