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

From: Robin Whittle <[email-masked]>
Date: Sun, 25 May 2008 19:47:39 +1000

I think the map-encap schemes (LISP, APT, Ivip and TRRP) were all
designed on the assumption that any solution to the routing and
addressing problem which required host upgrades would not be widely
enough adopted to make the required impact on the routing system.

I think there may be a role for host upgrades if they improve on a
slight performance problem which is inherent in the RRG-suggested
scheme - but that problem has to be slight, otherwise not enough
end-users will adopt the scheme in the first place for it to make a
sufficient difference to the routing scaling problem.

Below I am referring to host upgrades which are essential to the
operation of the RRG-suggested scheme.

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.

2 - It is often impossible to upgrade some hosts, including for
    instance DSL modems.

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.

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.

    This less than complete ability to upgrade hosts would be the
    typical experience of end-user networks and would prevent
    many of them from adopting the new system (as argued in another
    message).  Yet we need the great majority of end-user networks
    to adopt the new system if it is to solve the routing scaling
    problem.

If the host upgrade only concerns the operating system, then its
benefits in terms of routing scaling must arise without applications
seeing any changes.  Yet the multihoming, TE and portability which
the new system must provide needs to work the same for all
protocols, including those based on TCP, UDP, SCTP and ICMP.  So it
would not be good enough to have host upgrades which, for instance,
only change the way TCP is handled.

If the host upgrades also require new functionality in applications,
then this will never achieve even low levels of adoption, since
before any adoption could occur, there would have to be massive
investment by application writers, for the most common applications
at least.  Older and more obscure applications will not be upgraded
and therefore - could not partake of the new multihoming, TE and
portability benefits.  This raises the split-system, patchwork,
problem again.

If the benefits of the host upgrades only occur when the host is
communicating with another upgraded host, then the benefits to the
initial adoptors would be far too small to encourage most of them to
adopt it.  See the last part of:

   http://psg.com/lists/rrg/2008/msg01088.html

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.

Any new system would need to include a secure way by which only the
system administrator could control these host upgrades.  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.

There are no doubt other arguments against host upgrades, but these
look like more than sufficient to me.

  - Robin       http://www.firstpr.com.au/ip/ivip/

--
to unsubscribe send a message to [email-masked] 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

---

From: Randall Atkinson <[email-masked]>
Date: Sun, 25 May 2008 05:33:41 -0700

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

---

From: Robin Whittle <[email-masked]>
Date: Mon, 26 May 2008 01:21:05 +1000

Hi again Randall!

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

> 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

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

> host configuration (which is often achieved using DHCP).

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

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

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

> % system administrator could control these host upgrades.

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

> I don't think there is consensus either way on the question of host

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

> tradeoffs (for any proposed architectural approach) as part of the

Yes, which is why I am discussing it.

  - Robin

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 May 2008 14:38:50 +1200

> I don't think there is consensus either way on the question of host

+1. On this point, the devil is in the details. If a solution is
incrementally deployable with no loss of functionality for
non-upgraded hosts, I don't see how we can exclude it a priori.

    Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 26 May 2008 12:27:05 +0200

Ran,

I generally agree with your message.  And I agree with your factual 
assertion below.  However..
> tradeoffs (for any proposed architectural approach) as part of the

I remain very concerned about the lack of participation from those who 
develop applications.  Absent those individuals the weighing of such 
tradeoffs is likely skewed.

Eliot

---

From: "William Herrin" <[email-masked]>
Date: Mon, 26 May 2008 21:43:34 -0400

> enough adopted to make the required impact on the routing system.

Speaking for TRRP, that is correct and I consider the assumption to be valid.

> sufficient difference to the routing scaling problem.

I think the its permissible for the performance degradation on a
non-upgraded host to be serious so long as it isn't so serious as to
be "broken." If I can still telnet to and receive SNMP traps from my
Cisco 2511 over the new backbone then things are probably still OK. If
I need gateways and helpers and dual stacks then the deployment ain't
never gonna happen.

I think I'm saying essentially the same thing Brian Carpenter said:

>>If a solution is

With a sufficiently inclusive definition of "no loss of
functionality," and no dual-stack escapism, that's about right.

> The problems with host upgrades include:

#0. Way too many different people have to do too many things before
the system can be deployed as more than a toy.

Regards,
Bill Herrin

-- 
William D. Herrin ................ [email-masked] [email-masked]
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 27 May 2008 01:19:52 -0700

> non-upgraded hosts, I don't see how we can exclude it a priori.

I'd agree here, iif the solution can effectively reduce the global  
routing table size during the incremental deployment.

Lixia