> From: Robin Whittle <r...@firstpr.com.au>
Hi, one observation, and a few comments on your specific text.
The observation is that you seem to focus on the ALT, and indeed open with
detailed discussion of the ALT's problems.
LISP currently has a service interface to the mapping system specified
(the Map-Server/Map-Resolver interface), which hides the details of the
mapping system from the rest of the system (e.g. the xTRs). This interface
is intended, in part, to allow replacement of the mapping system with a
better one. There is at least one proposed replacement currently circulating
in the LISP community.
In light of that, you might want to move the ALT discussion to the end,
and clearly separate it from the discussion of LISP as a whole.
> ALT is a mapping distribution system with globally distributed query
> servers: ETRs and Map Servers.
Also Map-Resolvers, which are the places ITRs go to ask for mappings.
> ITRs drop the packet(s) they have no mapping for.
'currently drop'; obviously, it's easy enough to change this behaviour, one
xTR at a time, if it proves problematic in service.
> 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.
This is an assertion, not empirical data.
> No solution has been proposed for these problems
As mentioned, there is a proposal circulating in the LISP community for an
alternative mapping system which fixes many of the problems you mention (and
one I think you don't, the concentration of query traffic at the top-level
ALT nodes).
> with UDP and variable-length LISP headers in all traffic packets.
Ah, no - user-data packets have a fixed-length LISP header (currently 64
bits, IIRC).
> the MN cannot be behind NAT.
This is incorrect. A mechanism is of course needed to ascertain the
'external' address of the ETR, and a possible one has been coded and
field-tested, but an ETR can be behind a NAT (and IIRC there are current
test deployments of this).
> which LISP cannot achieve.
Also an assertion.
Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
