[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

On 17 sep 2008, at 8:40, Robin Whittle 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. 


They also need a solution which works for today's Internet - IPv4.


Which is orthogonal to the discussion at hand: PI in IPv6.


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 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.) 


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. Loc/id overload isn't so bad. 


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).
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). 


We just want the
Internet to keep working well with minimal disruption.


Then switch to IPv6 before we run out of IPv4 addresses...
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. 


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. :-) 


Elegance in keyboards would involve replacing the QWERTY keyboard
with something better.
Actually that's a myth. There was a lot of competition between various keyboard layouts in the early days of machine writing and QWERTY won for a reason. Talk that Dvorak is better comes from people with a financial interest and uncritical reporting. Of course it's possible to improve on QWERTY (or Dvorak) using more advanced systems where the system knows the language and multiple keys are pressed at the same time (velotype) but that's not a simple layout change. 


--
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