[RRG] Consensus? Users will not adopt solutions which result in "split-system" functionality

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

I am perplexed by several things at this late stage in the RRG
discussion - 19 months after RAWS, 10 months before our deadline,
and after four or five map-encap proposals (LISP-NERD, LISP-ALT,
APT, Ivip and TRRP) have been described in sufficient detail for
there to be robust critiques made of their practicality.

1 - We have achieved consensus on very little:

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


2 - We are now being asked to decide whether or not certain
    parts of the design space might contain the preferred
    solution, such as Six/One Router as in the "Translation"
    part of the space, as opposed to LISP etc. in the
    map-encap part.  Yet we are being discouraged from discussing
    actual proposals:  http://psg.com/lists/rrg/2008/msg01285.html


3 - I think the five map-encap proposals were all predicated on the
    assumptions (which is reasonable to me, and presumably to
    the other developers) that host changes are not practical
    and that we must solve the IPv4 routing scaling problem
    directly - but now I find that these two assumptions are
    not agreed to by some folks, and they are not part of
    what we have "consensus" on.

So I feel the need to backtrack even further and suggest we achieve
consensus (actually, "rough consensus" I think) on some more
fundamental things before we can make decisions about which sectors
of the design space might contain the solution the RRG should recommend.

The first of these proposals is in this email.  Other messages deal
with other things which I thought we agreed on, and which I think we
must agree on, if we are to make much further progress towards
achieving consensus on where the best solution might lie.

First of all, I want to state some things I think we all agree on -
a series of limitations on "our" ability to encourage or force
anyone to adopt a solution to the routing scaling problem:

  1 - The IETF has little persuasive influence on the actions of
      of the end-user networks, ISPs etc. who must implement any
      technical solution to the routing scaling problem.

  2 - Likewise, the RIRs.  Likewise the RRG.  None of us have
      anything more than the ability to present some arguments and
      make a case to other parties - although the IETF can develop
      some protocols etc. and the RIRs could work together to
      administer address space to help facilitate adoption of
      the new technologies.

  3 - Since any solution which is widely enough deployed to solve
      the routing scaling problem must be deployed by end-users etc.
      acting in their own short to medium term interests, we need to
      devise a solution which will be enthusiastically adopted by
      many and later most end-users, ISPs etc.  In order for this
      to occur, they must gain genuine, direct, benefits over and
      above their costs, risks and disruption etc.  The fact that
      they would be reducing (or not expanding) the DFZ routing
      table is not such a benefit.

      (However, to the extent that end-users are able to use a new
      form of address space which does not contribute to the routing
      scaling problem, it is possible that ISPs, RIRs etc. may be
      able to supply this space at a lower cost than is currently
      possible.)


Based on the above, which I think we all agree on, here is the point
of this message:  Can we form consensus on the following?

Short version:

   ISPs, end-user networks and end-users will not adopt solutions
   which result in "split-system" functionality - at least not
   to the very high levels of adoption we need in order to solve
   the routing scaling problem.

   So any solution to the routing scaling problem must provide
   clear benefits to all of the network when it is adopted - not
   some complex to administer patchwork of benefit and no benefit.


Long version:

   In order for our solution to be attractive, it must result in
   immediate benefits.  This includes the requirement that the
   benefits be system-wide, clear and unambiguous - resulting in
   minimal extra complexity, and in significant immediate benefits
   which are measurable in ways which lead to greater reliability,
   better performance etc. - all "bankable" aspects of system
   performance.  (That is, direct, useful, benefits to those who
   adopt the new technology.)

   This would be impossible if the solution only provided a
   half-baked set of benefits.  For instance, if either or both
   of the points below were true, the new technology would
   introduce such complexities that it would never be widely
   adopted by most end-user networks, ISPs etc. acting in their
   own immediate interest:

   1 - The solution can only be applied to a subset of their
       network.  For instance, but not limited to:

           The solution involves host OS changes, but it is
           impossible, impractical or too costly to upgrade
           all hosts in this way.

           The solution involves changes to applications -
           and it will never be possible to upgrade all
           applications, because some are no longer maintained.

       Therefore, in adopting the solution, the end-user network
       ISP etc. would find their network to be only partially
       benefiting, and would be burdened with the added complexity
       of having to remember which parts of their system work with
       the new solution and which don't.

       For instance, if robust multihoming, portability of
       address space, TE etc. only works for some of their
       hosts, some parts of their network, some of their
       applications and not others, then this will be such an
       additional burden of complexity that far too few
       end-users etc. would actually adopt the solution in
       order for the solution to make a sufficiently big impact
       on the routing scalability problem.


   2 - Even if an entire network could be upgraded completely
       (including reliable, easy, secure, upgrades to all hosts)
       then if the benefits only arise when communicating with
       other upgraded networks, hosts, applications etc. then
       the solution will not produce sufficient benefits to
       "early" adoptors for it to be widely enough adopted
       to make the required impact on the routing scalability
       problem.

       "Early" means the first adoptor, the first thousand adoptors
       and in some senses every adopter as long as some potential
       adoptors have not yet done so.

       The reason for this is that as long as there is less than
       100% adoption, and as long as benefits only materialize when
       communicating with upgraded networks, hosts, applications
       etc. there will always be a "split-system" situation, in
       which the benefits are partial.

       Since the benefits concern reliability of reachability - in
       multihoming and portability (changing to another ISP)
       situations - very few end-users will invest in the costs and
       disruption in order to achieve benefits for only a subset
       of their traffic.  This is true if the subset is 90%, and
       even more true if it is 10%. 1% or 0.01%, which would be the
       case initially.


  - 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