> From: Robin Whittle <r...@firstpr.com.au>
> However there are no plans to allow an ITR function in hosts
In the LISP Mobility mechanism, mobile hosts are ETRs _and_ ITRs.
> ALT is indeed a prototype. I believe no-one should consider it scalable
> to very large numbers of end-user networks. So why do the LISP folks
> bother developing it?
Were you to try and actually deploy a proposed solution, I believe the answer
to your question would be clear to you. (And I say this not in snarkiness, but
seriously.) When starting a project to actually deploy something, there is
_never_ enough personpower. So some battles you juat put off fighting -
provided you have left yourself an escape path in the meantime.
(That was the mistake made in going from variable-length addresses in IPv3 to
fixed-length in IPv4 - a decision taken for reasons of practicality. We
didn't leave ourselves an escape path...)
The Map-Resolver/Map-Server interface is the escape path. Even if LISP-TREE
(the other resolution system) were fully spec'd at this point, it _still_
would not be considered for immediate deployment - because we have other
battles to fight right at the moment. That one can wait a couple of years,
until there's enough incoming fire from that particular problem.
> LISP for IPv4 always uses the one namespace
Syntax != semantics.
> for its host addresses
The EIDs of LISP MN's have no location information at all, they are pure
identifiers. _Some_ EIDs have some _local_-scope location information, but
not all EIDs do. So "address" is not an appropriate term to use of _all_
EIDs.
>> 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.
> the "operational experience" with a test network will not give rise to
> the scaling problems
The _cause_ of the problem (be it scaling, or whatever) is not important.
What is important is whether the _solution_ is local/incremental. Coding and
deploying actual solutions to all such problems (as opposed to an engineering
analysis verifying that such a solution exists) can be put off until practical
experience confirms that it's a problem that's bad enough in reality that it
has to be solved. See previous comments about battles.
> the end-user network is placing an unreasonable burden on all ITRs
> which are sending packets to their EID prefixes, and on .. the end-user
> network's ETR or Map Server.
> ...
> This is very similar to the problem we are trying to avoid - thousands
> or millions of uppity end-user networks adverting PI space in the DFZ
The two situations are not at all identical. In the DFZ case, the costs are
born by everyone in the DFZ, whether they are communicating with those
parties or not. In this case, only the parties communicating with each other
are paying. (And whether that cost is 'unreasonable' is a matter of opinion.)
> However DNS lookups may involve queries and responses with multiple
> servers, which likewise adds up to longer paths.
Modelling indicates the vast majority of cache misses in the DNS-based
system will involve only a single query/response.
> An advantage of ALT ... is that it would be possible, in principle, to
> send the initial data packet along it, so it is actually delivered to
> the ETR without the ITR having to know the mapping yet.
There might yet be some experimentation with that, to see how well it
works in practise.
> DNS has always been an obvious choice of looking up mapping.
The proposed DNS-based system does not (for a variety of reasons) actually
store the mappings themselves.
Noel
_______________________________________________
rrg mailing list
rrg@irtf.org
http://www.irtf.org/mailman/listinfo/rrg
