Here is version 2 of my <=500 word critique of LISP. The message: http://www.ietf.org/mail-archive/web/rrg/current/msg05722.html
contains the original version, and a 747 word version which has more
contextual and moderating material.
There are two significant changes, both prompted by corrections
suggested by Noel Chiappa:
Mention of potentially caching Map Resolvers in the first
paragraph.
http://tools.ietf.org/html/draft-ietf-lisp-ms-04#section-5.4
Correction of "variable length" LISP header in data packets to
"64-bit".
The attached Word file contains the new version, without line breaks,
which should be easier to put into an ID, and a version showing
changes - including low-key changes to save words.
- Robin
(499 words)
LISP-ALT distributes mapping to ITRs via (optional, local,
potentially-caching) Map Resolvers and with globally distributed
query servers: ETRs and optional Map Servers.
A fundamental problem with any global query server network is that
the frequently long paths and greater risk of packet loss cause ITRs
to 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 and will
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", without regard to the geographic location of the
routers. Tunnels between ALT routers will often span
intercontinental distances and traverse many Internet routers.
The many levels to which a query typically ascends in the ALT
hierarchy before descending towards its destination will often
involve excessively long geographic paths and so worsen initial
packet delays.
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.
LISP’s ITRs multihoming service restoration depends on them
determining reachability of end-user networks via two or more ETRs.
Large numbers of ITRs doing this is inefficient and may overburden 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 report network un-reachability to ITRs.
LISP involves complex communication between ITRs and ETRs, with UDP
and 64-bit LISP headers in all traffic packets.
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.
In LISP’s mobility approach each MN needs an RLOC address to be its
own ETR, meaning the MN cannot be behind NAT. Mapping changes must be
sent instantly to all relevant ITRs every time the MN gets a new
address - which LISP cannot achieve.
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 may be prohibitively expensive.
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.
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.
LISP-critique-0.5kword-v2.doc
Description: MS-Word document
_______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
