Re: [RRG] Consensus? Solution cannot require host upgrades

[Robin Whittle <rw@firstpr.com.au>]

Hi again Randall!

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

Yes, it is not so bad for these mainstream desktop OSes.  What about
the various OSes of servers?  Ideally these are being updated, but
are they really?  My guess is that there are lots of servers sitting
out there with old versions of the OS, which no-one has had the time
to update, because the thing is running fine and a new OS would
involve taking the machine off-line for a day or two and
reinstalling and reconfiguring all the applications and their data.

I just upgraded my home-office server from an antiquated Red Hat 7.2
(2002 vintage) to CentOS 5.1.  It was running OK, but it took me two
weeks or so to install my various programs the way I wanted, so I
put it off for a long time!  The clincher was I needed a new
Spamassassin, which needed a new version of Perl, which couldn't
easily be installed on RH 7.2.

My guess is that the real details of what OSes people are running
are messier than what would be ideal - and that there are sufficient
machines out there with OSes not automatically updated to form a
significant impediment to any approach which required host upgrades.


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

DSL modems are cheap, but there would be disruption and immense
support costs in having people install and try to configure new ones.


> Modern systems (e.g. those that have an
> IPv6 stack inside) generally ARE upgradable -- 

Do you know of any IPv6 compatible DSL modems?  With a few minutes
searching, I couldn't find any.

DOCSIS 3.0 in 2006 apparently supports IPv6, but from :

http://www.engadget.com/2008/04/03/and-were-off-twin-cities-get-first-docsis-3-0-deployment/

I get the impression that it has only been deployed in recent months.


> and need to be because around 2010 the last IPv6 block is
> likely to be allocated to the RIRs.

I think you meant "IPv4 block".

I think this reflects the view that the sky is going to fall in
around 2010 and there will be no more seats on board the Good Ship
IPv4: All newly arriving passengers will kindly board the Good Ship
IPv6.

In the next decade, I am sure we will see better and better use made
of IPv4 address space.  Until 2015 or 2020 at least, I am sure it
will be easier and cheaper to do this and provide customers with a
fully globally connective IPv4 service than to try to get them to
pay for an IPv6 only service which does not allow direct
connectivity to some or most other end-user's hosts.


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

Comcast have been planning and doing presentations.  But where are
the results?  Where are their IPv6 services?


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

I agree, but there are far fewer routers than hosts.


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

OK, such networks probably could undergo a complete revision of
hosts and routers to make them IPv6 compatible, and/or to install
some new function in their IPv4 and IPv6 stacks.

I wonder how many end-user networks - both large scale sites such as
universities and large corporations, and small sites such as small
factories and offices - have sufficiently consistent and up-to-date
servers and desktop machines to make a full upgrade feasible.


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

I find this hard to understand.

Multihoming, TE etc. needs to be managed.  It would be great if it
didn't need any management, but that is not the case.  It needs to
be configured, debugged and monitored.

The most obvious options are for the network administrators to
manage it from some central point, or for them to fuss around with
individual hosts.  Central management is the natural outcome for a
router-based solution, but it is conceivable that a host-based
system could be centrally managed too.  That would involve some
fancy coordination and security arrangements, but it would surely be
preferable than having administrators manually interacting with
potentially thousands of individual hosts.


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

What I meant was not controlling the upgrade process, but
controlling how this upgraded host functionality actually provides
multihoming, TE, portability etc.


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

I don't think there is.  I hope my message leads to such a
consensus, or at least to some instructive discussions.


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

Yes, which is why I am discussing it.

  - Robin


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