Subject: [rrg] LISP critique

From: Robin Whittle <[email-masked]>
Date: Wed, 20 Jan 2010 18:00:32 +1100

Hi Lixia and Tony,

Below is a 747 word critique of LISP.

I have attached a Word file with this text and another version
chopped back to 497 words.  An intermediate version shows what has
been lost - contextual and moderating material, not actual critical
material.

Given LISP-ALT's prominence in this field, it being the only RRG
proposal with an IETF WG, and given that its designers contributed
only twice to this critique phase (msg05685 and msg05700), I wonder
whether the RRG could be little more generous with the word limit for
the LISP critique.  The LISP summary used only 206 words.

  - Robin

This critique concerns LISP+ALT.  LISP+NERD could scale to ~10^7
EIDs, but its full-database ITRs would be more expensive and so less
numerous than the caching ITRs with local full-database query servers
which are used in APT and Ivip.

ALT is a mapping distribution system with globally distributed query
servers: ETRs and Map Servers. The ALT network is an overlay built
with existing tunnel and router elements.  A test network has been
built with relative ease and there are several efforts to write
interoperable implementations of ITRs, ETRs, Map Servers and Map
Resolvers.

A fundamental problem with any global query server network such as
ALT is that the delays inherent in this approach (with frequently
long paths and greater risk of lost queries or responses) mean that
ITRs will drop or significantly delay the initial packets of many new
sessions.  ITRs drop the packet(s) they have no mapping for.  After
the mapping arrives, the ITR waits for a resent packet (assuming the
sending host is not trying instead to contact another host in a
different EID prefix) and will then tunnel that packet correctly.
These "initial packet delays" reduce performance and so create a
major barrier to voluntary adoption on wide enough basis to solve the
routing scaling problem.

ALT’s delays are compounded by its structure being "aggressively
aggregated" according to address, without regard to the geographic or
topological location of the routers.  So the tunnels between ALT
routers will often span large geographic distances and traverse many
Internet routers.

Therefore, the many levels to which a query typically ascends in the
ALT hierarchy before descending towards its destination router will
too often involve very long geographic paths and so worsen delays and
packet loss rates.

No solution has been proposed for these problems or for the
contradiction between the need for high aggregation while making the
ALT structure robust against single points of failure.  Initial
packet delays can only be made insignificant with NERD or local
full-database query servers.

For LISP’s ITRs to perform multihoming service restoration, they must
determine reachability of end-user networks via two or more ETRs.
The individual efforts of large numbers of ITRs are inefficient and
potentially burdensome on the ETRs.

Testing reachability of the ETRs is complex and costly - and
insufficient.  ITRs cannot test network reachability via each ETR,
since the ITRs have no address of a device in that network.  So ETRs
must test network reachability and convey this to ITRs.

LISP involves complex communication between ITRs and ETRs, with UDP
and variable-length LISP headers in all traffic packets.  The ITR's
algorithm for solving the PMTUD problems caused by encapsulation is
incomplete and may be expensive to implement securely.

The advantage of LISP+ALT is that its ability to handle billions of
EIDs is not constrained by the need to transmit or store the mapping
to any one location.  Such numbers, beyond a few tens of millions of
EIDs, will only result if the system is used for Mobility.  Yet the
concerns just mentioned about ALT’s structure arise from the millions
of ETRs which would be needed just for non-mobile networks.  (Map
Servers may reduce total path lengths somewhat.)

In LISP’s mobility approach each MN needs an RLOC address to be its
own ETR, meaning the MN cannot be behind NAT.  This double address
use is unsuitable for IPv4. Lisp-mn requires instant mapping changes
being sent to all relevant ITRs every time the MN gets a new address
- which LISP cannot achieve.  However, LISP could support the TTR
Mobility architecture which does not require mapping changes to be
frequent or instantly achieved.

In order to enforce ISP filtering of incoming packets by source
address, LISP ITRs would have to implement the same filtering on each
decapsulated packet. This is extremely expensive at high data rates
for large numbers of prefixes - and is normally done with TCAM hardware.

LISP monolithically integrates multihoming failure detection and
restoration decision-making processes into the core-edge separation
scheme itself.  End-user networks must rely on the necessarily
limited capabilities which are built into every ITR.  These functions
could be externalised and made the responsibility of end-user
networks if LISP was able to distribute mapping in real-time to all
ITRs which need it.  However this is not practical without full
database local query servers.

LISP-ALT may be able to solve the routing scaling problem, but
alternative approaches would be superior because they eliminate the
initial packet delay problem and give end-user networks real-time
control over ITR tunneling.