Earlier, Robin wrote: % The problems with host upgrades include: % 1 - It is labour intensive, except perhaps if the upgrades are part % of an already existing OS (and perhaps application) automated % update system. However, only a subset of OSes and very few % applications have any such automated update system.
Windows has such an automated update system. Windows is over 75% of the installed host base. MacOS X also has such an automated update system, though it is a MUCH smaller percentage of the installed base. Numerous other OSs also have such automated update systems. % 2 - It is often impossible to upgrade some hosts, including for % instance DSL modems. Those might or might not need upgrading, depending on what has been proposed. Modern systems (e.g. those that have an IPv6 stack inside) generally ARE upgradable -- and need to be because around 2010 the last IPv6 block is likely to be allocated to the RIRs. If one reads the COMCAST presentations, this IPv6-only deployment for customers is an operational issue that ISPs have been and actively continue to plan for. % 3 - Host upgrades involve risk of misconfiguration, bugs, security % problems in a wide variety of systems. This is far more complex % than upgrading the network's routers, or installing new routers % - due to the larger number of hosts and their greater diversity. Router miconfiguration, bugs, and security concerns are quite common. Router configuration is often much more complex to get right, particularly the inter-domain routing configuration aspects, than host configuration (which is often achieved using DHCP). % 4 - In most end-user networks, not all hosts could be upgraded - so % the result would be a split system - a patchwork of upgraded and % non-upgraded devices. Therefore the benefits to the network % would not be complete, and the administrators and users would % be burdened by this extra complexity. The premise of this claim is not obviously true. Most end-user networks that I am familiar with, and I am familiary with many such networks due to by travels, consist entirely of Windows, Solaris, and/or MacOS X systems on the hosts and a single brand of switches/routers internally. % Another difficulty for host upgrades which are essential to the new % multihoming, TE and portability functionality is the fact that most % end-user networks require these functions to be centrally managed. Most end-user networks are telling me that they do NOT want to have to manage these things centrally. They want them to be native capabilities of the Internet Architecture, rather than bolt-on features that increase operating expenses. (OpEx is much more important than CapEx to most users.) % Any new system would need to include a secure way by which only the % system administrator could control these host upgrades. Exists today. See top. % Unless the host upgrade involved no configuration, no knowledge % of the currently used address space etc. then this would make % it much more difficult to develop and securely deploy the upgraded % functionality. This isn't obvious. I don't think there is consensus either way on the question of host upgrades. There *are* a bunch of issues with *any* change to *any* part of the system (host changes, tunnelling, or whatever else). This means that there are important architectural tradeoffs in various dimensions. My understanding is that the Routing RG is considering those various tradeoffs (for any proposed architectural approach) as part of the deliberations here. Yours, Ran [EMAIL PROTECTED] -- to unsubscribe send a message to [EMAIL PROTECTED] 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
