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

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

On 22 sep 2008, at 9:34, Robin Whittle wrote:


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.
Yes, but it's unimportant whether this control is an inherent part of a centralized design or is simply added to a decentralized design because it's an additional requirement. There is nothing stopping you from coming up with a shim6 control protocol. 


For instance, each SHIM6 host does its own reachability testing and
multihoming service restoration decisions.  This is extraordinarily
messy
It's also extremely effective, because this actually tells you whether you have connectivity, while the presence of a prefix in BGP doesn't tell you much because the unreachability will usually be aggregated away, and it's scalable. It also avoids the need for continuous keepalives that is present in many protocols. 


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.


Anarchy!  :-)


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.
Yes, but our architecture is such that it's impossible to communicate this type of information between the network and the hosts, so a lot of information is lost if you take this functionality out of the host. We do congestion control in hosts for a reason. 


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.
shim6 just negotiates extra addresses and switches to a different one when necessary. If you can boot strap the address negotiation without requiring an initially working address pair then you could simply use ULAs or some such as the identifiers. However, this would require an id->loc lookup of some sort, which is something we were reluctant to include in shim6. 


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.
Sure, and it's perfectly reasonable to go live in the desert and pump up water from deep beneath the surface to water your lawn and run an air conditioner 24/7 to keep cool. 

Some things just don't work in the long run.


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.
Well, if we accept that then basically a loc/id separation is a way to avoid renumbering. Renumbering is only painful when you're actually doing it. Loc/id is painful for every packet and for every session... 


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


Sorry, that doesn't make any sense to me.


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.


True.


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.
There will be if everyone updates... The disruption will come to IPv4 as it runs out of addresses. At that point there will be people who are on v4 and not of v6 and people who are on v6 but not on v4. That's not good. People who add v6 today can keep running v4 so there is no disruption. 


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.
Right. But we should expect users to make _some_ changes to their routine if this is really necessary to make our efforts succesful. Maybe renumbering once a month is asking too much, but rejecting a solution just because it does some stuff in a decentralized manner is the other extreme. (I'm not arguing that shim6 solves everything for everyone, though, just that IPv6 PI was adopted way too easily.) 


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