> From: Robin Whittle <r...@firstpr.com.au>
> Debating various aspects of LISP with Joel
Err, 'Noel'.
> As far as I know, no-one in the main LISP team has developed a better
> mapping system or suggested that one should or will be developed
> ...
> Please mention what this is, with references.
After a great deal of work (extensive detailed simulation, etc), a paper has
been written and submitted to a conference, but it's not public quite yet.
Hopefully it will be public Real Soon. (Sorry, but it's not a paper I had
anything to do with, so I don't feel I can say more than that - I merely
commented privately on a draft.) Work has started on a spec, but again it's
still not public, alas.
However, the Map-Resolver/Map-Server interface to the mapping system, which
allows use of different mapping system 'back-ends' is already fully public.
>> 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.
> Since I don't yet know what the alternative is, my critique is of LISP
> with ALT.
Understood, but that does not vitiate either half of the suggestion above.
After all, as I pointed out, the mapping service interface _is_ already
specified.
> I know there is a view that the delays which can easily be foreseen in
> LISP-ALT are not significant enough to prevent it being adopted widely
> enough to solve the routing scaling problem. I and some other people
> disagree with this viewpoint.
Pointing out the delays is fine. It's the flat assertion that this will
produce a certain result out in the world I'm questioning. E.g. have you gone
around to a significant subset of ISPs/large-content-providers, and asked
them if these delays are unsupportable? If not, then the statement is merely
your subjective, personal, opinion.
> With a global query server network, the delay in getting mapping will
> frequently be longer than this, since the answer has to come from the
> other side of the planet, which typically takes 350 to 400ms.
There have been discussions on caching mappings in the Map-Resolvers, which
will remove this delay for 'popular' destinations.
> I assert that any global query server system for mapping lookups will
> involve a significant performance degradation - sufficient to affect
> the experience of users. I also assert that even if the measured impact
> on end-users is minimal, the perception of this reduced performance
> will significantly reduce the chance of widespread voluntary adoption
> to a degree which threatens the ability of the system to solve the
> routing scaling problem.
And I assert the contrary. Arbitrary assertions, with no supporting evidence,
have no place in this document.
> Every time an LISP-MN gets a new RLOC address ... then all the ITRs in
> the world need to suddenly change their mapping to the new RLOC address.
No, only the ones the LISP-MN is currently communicating with. Why would some
ITR which has never communicated with the MN, and never will, need the updated
mapping?
Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
