I was thinking about commenting on this point too, but Christian beat me to it.
We *can* propagate changes to the numerically significant host operating systems. It takes years, so any solution based on this must be one with a completely incremental deployment model. One view of the IPv6 deployment problem is that it depends on *both* incremental deployment to all hosts *and* centralised deployment by operators. That's the worst case, but seems inevitable for an actual change of the IP packet format. So, I think that tells us that a solution that requires host stack changes only, *or* infrastructure changes only, but not both, is deployable. Personally, I wouldn't expect something called "routing research group" to propose a strategy based 100% on host changes and 0% on changes to the routing system. But we could conceivably propose something based on changes to both, and that would surely be a big mistake. Brian On 2009-12-06 19:08, Christian Vogt wrote: > Branched from thread "moving towards recommendation: the current plan". > > > On Dec 1, 2009, Noel Chiappa wrote: > >> When it comes to preferring network-based or host-based solutions, when >> considering _architectural_ factors, I actually prefer the latter >> (because I want to move functionality out of the network, to maximize >> long-term flexibility). However, _engineering_ factors (e.g. the >> difficulty of changing hosts) has long led me to conclude that _initial_ >> deployment has to be network-based. > > We often take it that host changes are harder than network changes. But > is this assumption actually valid? There is, in fact, substantial > evidence that it is not. Consider IP version 6, which was deployed in > operating systems well before operators deployed it in their networks. > > Also from an economic standpoint, host changes appear easier than > network changes: Given the small number of operating systems used by > the majority of hosts, and given the highly automated methods to update > these operating systems, changes to one of the main operating systems > quickly affect a large number of hosts, hence at a small cost per host. > Network upgrades are slower and more expensive. > > Furthermore, for the same reason that network operators would tend to > defer changes, operating system vendors may be eager to adopt them. This > happens when the change must be bilateral to yield a benefit -- as is > the case with multi-homing support, which we are discussing here. > Network operators gain no immediate benefit by adopting a network-based > multi-homing mechanism early on, because the remote part of the > mechanism does not exist initially. Operating system vendors, on the > contrary, can distinguish their product from competition based on the > new multi-homing support, as the multi-homing support improves > communications between their operating system relative to the operating > systems without multi-homing support. > > Thus, in my personal opinion, host-based multi-homing support will have > a faster impact than any corresponding network-based support. > > - Christian > > > _______________________________________________ > rrg mailing list > [email protected] > http://www.irtf.org/mailman/listinfo/rrg > _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
