[RRG] Consensus? Solution cannot require host upgrades

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

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