Re: [RRG] Elegance and the rejection of SHIM6 host-based multihoming

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

Short version:  Exploration of how SHIM6's host-based approach
                to multihoming failure detection and service
                restoration decision making is messier than
                LISP's, APT's and TRRP's approach.  Both
                approaches are inflexible and monolithically
                combined into their respective systems compared
                to Ivip's approach in which these functions are
                performed independently of the Ivip system, in
                any way the end-user network wishes to do so.


Hi Iljitsch,

You wrote:

>>> The shim6 effort was well under way at that point but not yet
>>> mature enough that it was possible to know whether it would
>>> solve the problem.
> 
>> The functional goals of SHIM6 are well known and have been for
>> a while: to provide host-based multihoming.
> 
> Well if all your hosts are multihomed your entire network is
> multihomed. End-users shouldn't concern themselves too much with
> the details of technology that aren't of immediate importance to
> them.

It is important to the administrator of an end-user network whether
portability and multihoming (TE too) can be controlled purely at a
router or some other central location, or whether every host in the
network needs to be coordinated in some way to achieve this.

For instance, each SHIM6 host does its own reachability testing and
multihoming service restoration decisions.  This is extraordinarily
messy compared to the Ivip approach of the administrator of the
network organising (typically via a company which specialises in
this) a single multihoming monitoring system for the entire network.
 That system uses whatever tests the administrator desires, and
makes decisions according to whatever criteria they require.  Then
that system changes the mapping, so the traffic flows to the new ETR
within a few seconds.

Ivip modularly separates the tasks of testing reachability and
deciding which ETR to use from the core-edge separation scheme
itself.  Ivip enables these functions to be performed however the
end-user wishes, including with as much or as little sophistication
and test packet overhead as they desire.  This will be a lot simpler
to debug and optimise for each multihoming situation than any system
such as LISP, APT, TRRP and I think Six/One Router - which integrate
these functions monolithically into the ITR (or translation router)
functions of the core-edge separation system itself.

SHIM6 is even worse - it builds these functions into the hosts.

With Ivip there is a single failure monitoring system and a single
decision process to handle the entire end-user network.

With LISP etc. these functions have to be done with very limited
flexibility by as many ITRs as are currently tunneling packets to
hosts in this end-user network.

If there were 100 such LISP etc. ITRs, this is 100 separate sets of
test packets to the ETR, with very limited decision flexibility, due
to the necessarily limited functionality these protocols can require
in all ITRs.  With Ivip, there need only be one set of test packets,
and one highly flexible, decision system - which can be constructed
in any manner at all, since it is not at all part of the Ivip system.

With SHIM6, the situation will often be worse than with LISP etc.
If there were 100 ITRs each handling packets from 10 hosts which are
sending packets to this one edge network, then this means there are
1000 hosts all doing their own reachability testing, making their
own decisions etc.


A system which completely isolates the hosts from multihoming,
portability etc. by providing them with a consistent IP address at
all times is arguably a lot simpler to run and debug than one which
pushes a lot of the complexity, responsibility and potential
problems into the host operating systems themselves.

>> They also need a solution which works for today's Internet -
>> IPv4.
> 
> Which is orthogonal to the discussion at hand: PI in IPv6.

OK.


>> Also, people want address space which is portable between ISPs
>> - so they don't have to renumber their network, DNS etc. when
>> selecting a new ISP.
> 
> Shim6 could have given them that and maybe still could in the
> future by using a separate ID space.

I don't see how SHIM6 could be used for providing portable address
space.


>> I believe these are perfectly reasonable desires and needs.
>> SHIM6 and IPv6's automated router and host renumbering just
>> doesn't do what most end-user networks need.
> 
> No, it doesn't do what they want. Like trained monkeys these
> users expect to be able to continue to do the same thing forever
> even though circumstances are changing. (Actually that's unfair
> to monkeys, humans and flies are pretty much the only creatures
> that keep doing the same thing expecting different results.)

I think that the administrators of end-user networks are perfectly
justified in seeking a solution which isolates hosts from any
effects of multihoming service restoration, moving to another ISP etc.


>> LISP, APT, Ivip, TRRP and Six/One Router are attempts at
>> providing end-user networks with what they want and need:
>> portability and network-based multihoming with PI space, but in
>> a scalable way.
> 
> At a high price of added complexity.
> 
> One or two of these solutions may be turned into something
> workable but that's not to say that that would be the best
> possible solution.
> 
> Mark my words: a loc/id split is going to open a big can of worms
> that will make life harder for a long time. 

Please document your concerns in detail.  Core-edge separation
schemes do involve extra complexity - but they do not require
changes to host operating systems or applications, and they have the
ongoing property of not involving hosts in portability, multihoming etc.


> Loc/id overload isn't so bad.

Do you mean the current situation where an IP address is arguably
used to define both the end-point device and how the packet needs to
be forwarded across the Internet to reach that endpoint?  If so, it
is bad because it leads to a scaling problem when more and more
end-user networks get what they need: PI space, in the only way
currently possible: via a BGP advertised prefix.


>> I think it would be an unjustifiable over-reaction to require
>> that all hosts change their stacks and applications just to
>> solve a scaling problem in the DFZ
> 
> There's no need to update applications for shim6 (IPv6
> applications are already expected to try all addresses, that's
> all that shim6 needs).

OK - has SHIM6 been extensively tested with a range of IPv6
applications?

Since reachability testing is built into the SHIM6 functionality of
each host, how are end-user network administrators going to be happy
with this, since they are likely to have a variety of desires about
what constitutes an "outage", what should cause packets to flow one
way or another etc.?


> There is ample precedent for this, like IPv6. Or if you prefer
> something that's in wider use: TCP congestion control. Hosts need
> to keep state anyway so solving the problem there is essentially
> free. It would be stupid to ignore that.
> 
> Host stack changes take a long time, but apart from that, they're
>  actually a fairly easy way to solve problems because only a
> handful of organizations need to make investments (the host OS
> vendors).

Yes, but there is a huge hurdle to overcome if the new system only
provided benefits when communicating with another upgraded system.
 SHIM6 still can't provide portable address space.  Nor could SHIM6
be the basis for a global approach to mobility such as this:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf


>> We just want the Internet to keep working well with minimal
>> disruption.
> 
> Then switch to IPv6 before we run out of IPv4 addresses...

That is rather disruptive, since there's almost no-one at home on
the IPv6 Internet.


> Oh wait, what you really want is to not have to deal with the
> problem. Fine. But then you pay the price in some other way.

We have to find a way of dealing with the scalability problem - and
then the shortage of address problem - which most people will want
to adopt due to the immediate benefits it brings.  IPv6 is currently
a non-starter because it does not provide connectivity to all hosts
(or at least all hosts used for any purpose important to Internet
users in general) - which IPv4 does.


>> Elegance in English would involve a radical revamp of the
>> language.
> 
> Which, of course, those of us who invested 10 years of our lives
> to learn how to spell it (most other languages take less than
> half that) wouldn't like.
> 
>> Elegance in driving would involve all countries agreeing to
>> either drive on the left or on the right.
> 
> Hey, I drive on the right, speak a language that's (arguably)
> more elegant than English, use tab notation rather than
> traditional notation and play a keyboardless instrument, use the
> metric system and run IPv6. I'm doing my part.  :-)

Very cool!  If the majority of Internet users were like you, they
would be keen to invest the time end effort into making a big switch
to another network such as IPv6 even when it is only partially
functional for a few years until everyone else gets around to using
it fully.

Our task is to come up with a system which solves the routing
scalability problem which ordinary folks will adopt for their own
immediate reasons - since most of them won't know or care about
routing scalability.

 - 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