Re: [RRG] Are host-stack modifications allowed or disallowed ?

[Robin Whittle <rw@firstpr.com.au>]

Hi Brian,

You wrote, in part:

> However, all hosts are not created equal. If a solution required 
> a specific type of host to be updated, that might be quite well 
> linked to economic incentives and therefore deployable. I'm
> thinking of a solution that needed host updates only in servers
> that are globally visible (typically those in DMZs), but not in
> client or generic p2p hosts. Since it is those globally visible
> servers that are the main customer base for PI multihoming, they
> might well be incented to update their stack to support some form
> of loc-id solution.


Assuming we are discussing only the goal of multihoming and TE for
hosts which are public servers (and therefore not concerned about
other goals related to routing-addressing, such as improving IPv4
address utilization), then for your suggestion to work, I think:

1 - You would need to show that the multihoming and TE could
    be achieved without changes to the client hosts or the
    networks those are located in.  Therefore you need to achieve
    multihoming and TE purely with new software in the server hosts,
    or together with some routing changes in their network.

    This has to be done in parallel with deploying a map-encap
    scheme, with its ITRs, ETRs and mapping database distribution
    system.


2 - To be incrementally deployable, the benefits would need to
    ensue pretty directly and immediately to the people who run
    these servers and/or the networks they are in.  Or do you mean
    some external incentive scheme to encourage server operators to
    change their operating system (and perhaps application?)
    software?

3 - Also, I think you would need to show that this subset of
    address usage being used in the new way would make a big
    enough impact on the routing scaling problem for it to be worth
    the trouble - ideally sufficient to solve the problem
    indefinitely without having to take other measures.

4 - I also think you would need to get consensus that the
    dichotomy you are implying about networks with public
    server hosts and networks without is valid and will
    remain valid for some decades to come.

Do you have any possible approaches which would pass all of these tests?

LISP-NERD, APT and Ivip don't need any host upgrades at all, since
there is no delay problem or any other difficulty which needs to be
solved at the hosts on either end of the communication.

I think the only reason people are thinking of host upgrades now is
to make hosts somehow cope better with the initial packet delays
which look like they will be inevitable often enough to be a problem
with LISP-ALT or TRRP - the two pure-pull systems currently under
discussion.  You could do this for servers, to help in some way with
the server-client response communication, but your proposal doesn't
allow for upgrading hosts which are clients, so they still suffer
delays and any host stack complications which result.

It is not clear to me how host changes could make these initial
packet delays much less of a problem, other than to tweak existing
protocols so they didn't make such a mess of themselves when such
delays occurred.  The delays will still add up and the end-users
will still be affected - making this form of address space suck, or
at least be widely regarded as being second-rate and best avoided.

The others tests look pretty challenging too.

 - Robin


--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg