[RRG] Take 2: AA, BB, CC

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

It is hard to get consensus on anything longer than a sentence, but
for the sake of discussion, I think the following would be a good
thing for us to agree on.

Here are revised versions of Paragraphs A, B and C from "3 potential
consensus questions":

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

The original versions did not state time-frames for completing the
three threads of research.  Paragraph AA is more tentative about an
IPv6 solution.  My notes in [brackets] are explanatory, not part of
what I suggest we agree to.


AA:  We need to devise a solution for IPv6, or at least
     recommend directions for future research, unless we
     expect IPv6 adoption not to grow fast enough for there
     to be significant scaling problems to warrant a solution.



[So I think we would only decide not to work towards an IPv6
 solution if one of the following were true:

  1 - We fix the IPv4 solution and expect that fix, and IPv4
      in general, to last long enough for a clean-slate
      architecture to be developed and widely adopted.  Until
      then, we expect IPv4 to be usable enough to result in
      low enough levels of IPv6 adoption for any IPv6 scaling
      problems to be mild enough not to warrant a solution.

  2 - We do not fix IPv4 or IPv6.  We expect to be able to
      develop a clean-slate solution and have most end-users
      happily adopt it in a sufficiently  short period of time
      that the costs of the IPv4 scaling problem - and any IPv6
      scaling problem which results from partial or mass-adoption
      of IPv6 - will be sufficiently low as not to warrant an IPv4
      or IPv6 solution.

 I think any "IPv6 solution" should be some kind of addition to it -
 such as map-encap or perhaps Six/One Router - with minimal or no
 changes to host stacks, applications and the IPv6 BGP system.
 There has been suggestion of IPv6 with major changes to the
 addressing and routing structure, and therefore to host stacks and
 applications, such as (IPv6 + GSE).  I regard something like this
 to be as about as radical (hard to develop, deploy and have widely
 adopted) as any clean-slate design - so maybe we would be better
 with a really clean slate.]


BB:  We need to pursue a solution for IPv4, since we will probably
     decide we need one.  Alternatively, we expect the IETF and/or
     the rest of the world will insist there be one, and it would
     be best if we suggested such a solution.

     Reasons for this include that IPv4 is the Internet in current
     use - and that it is the only Internet with a routing scaling
     problem.  Also, we cannot be confident most end-users will want
     to adopt a scalable IPv6 or a clean-slate solution in
     sufficient time that the costs of the IPv4 routing scaling
     problem will remain acceptable.


CC:   There are three worthy avenues of investigation which we
      should pursue in parallel, with differing levels of urgency:

     1 - A solution which is optimal for IPv4 and which may be
         applicable to IPv6, but which may not be optimal for IPv6.

         For an IPv4 solution to be widely adopted, no host changes
         can be contemplated, except perhaps minor changes to help
         alleviate (necessarily minor) performance difficulties
         (not reachability or reliability limitations) inherent in
         the solution.

           [e.g.. host changes which make it more acceptable for
            TRRP's and LISP-ALT's delay of initial packets.]

         We should aim to specify this solution for IPv4 in 2009-03,
         since it needs to be developed to the RFC stage by about
         2011 or 2012, deployed soon after, and ideally be widely
         adopted by 2014 or so.

         [Of the current proposals, only the map-encap proposals
          might be feasible for IPv4.]


     2 - An IPv6 solution which may be one of:

         a - Conceptually compatible with the IPv4 solution, but
             potentially different in detail.

             [This means the same map-encap system as adopted for
              IPv4.]

         b - Fundamentally different from the IPv4 solution but,
             like the IPv4 solution, involves no host changes or at
             most minor changes.

             [Of the current proposals, only Six/One Router with
              multiple parallel PA prefixes for each PI prefix meets
              this criteria.]

         c - A radical revamp of IPv6 which involves major changes
             to host stacks and applications.

             [GSE has been mentioned, but not properly proposed.  I
              regard any such revamp as being about as difficult
              to get adopted as as a truly clean-slate proposal.]

         Since an IPv6 solution is not as urgent as an IPv4 solution
         and since we may not be able to research this field so
         well, or agree so much about it, our recommendation for
         this may be more tentative, concerning several options for
         future research.  The nature and urgency of the IPv6
         solution would depend in part on:

            How soon we think the IPv4 solution could be widely
            adopted.

            How the IPv4 address depletion problem develops - which
            will depend to some degree [opinions vary widely] on how
            an IPv4 solution [presumably map-encap] could enable
            more end-user networks to get the space they need,
            without significantly worsening the routing scaling
            problem and in ways which enable better utilization of
            IPv4 address space.

            How soon a clean-slate proposal could be deployed and
            how rapidly we think end-users would migrate to it.


     3 - A clean slate solution, unconstrained by the current
         state of IPv4 or IPv6.

         There is no way the RRG could reliably decide on the nature
         of this solution in the next 9 months.  We should
         recommend some lines of research and suggest some
         requirements and goals for the new architecture, including
         those concerning transition mechanisms from IPv4/6 and/or
         backwards compatibility with them.  As this architecture
         is to last forever, we should also consider how it may
         support goals beyond the challenges of the current scaling
         problem, such as how the architecture supports security
         (including spam reduction), mobility and global QoS.


  - 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