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
