[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[RRG] 3 potential consensus questions



Before we can choose which parts of the solution space to consider,
or to consider whether a solution must involve portable PI-like
space, I think we need to think about time-frames and practical
matters.

As part of this, we need to decide whether we are trying to devise
one solution only, or several.


I think we already have consensus on:

A:   We need to devise a solution for IPv6.

However, I am not sure if there is consensus that this should be
IPv6 as we know it with an addition such as map-encap or Six/One
Router - or IPv6 with major changes to the addressing and routing
structure, and therefore to host stacks and applications (IPv6 + GSE).


I am not sure that there is consensus on:

B:   We need to pursue a potential solution for IPv4, since we may
     need one -  or at least the IETF and/or the rest of the world
     may insist there be one - and since we can't yet be sure that
     no worthwhile solution would emerge from further research.

Without consensus on B, I think it would be hard for the RRG to
proceed.  If we reach consensus that we don't need to devise an IPv4
solution, then I and maybe some others will lose confidence in the
RRG process and won't be able to contribute much.


I would be really happy if we could reach consensus on the above two
points and on this rewrite of something Bill Herrin wrote:

C:   There are three worthy avenues of investigation which we should
     pursue in parallel:

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

     2 - An IPv6 solution which may be one of:

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

         b - Fundamentally different from the IPv4 solution and
             which may or may not involve major changes to the IPv6
             routing and addressing system: involving changes to
             host stacks and applications.

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


I think this problem is too big and important, and the current state
of research too early, to pursue an ever-narrowing, track towards a
single solution in March 2009.

I think we need to have three inter-dependent discussions.

Short-cut 1:

    If we thought we could run forever on IPv4, we wouldn't need C2
    or C3.

       {I don't support think this is true, but I think that an IPv4
        solution would give us more time to pursue C2 or C3.  We
        or our successors will need a lot of time to develop these
        so they have a transition mechanism which most end-users
        find more attractive than continuing with IPv4 (or for C3,
        IPv6) with or without some scalable solution.}


Short-cut 2:

   If we are sure now that we could develop and IPv6 solution which
   would satisfy two conditions:

     a - We could reasonably expect most end-users find it
         preferable to continuing with IPv4 in 8 years or so.

     b - We thought it would be an excellent long-term solution.

   Then we wouldn't need C1 or C3.


Short-cut 3:

   If we were sure now that we could develop a clean-slate proposal
   which most end-users would happily adopt in 8 or maybe 10 years,
   that would probably make it unnecessary to pursue C1 and C2.


I believe that at the current, early, stage of research, we cannot
take any of these short-cuts - so we need to pursue C1, C2 and C3 in
parallel.


I think the idea of recommending a single solution in 2009-03 is a
worthy goal, but not an absolute requirement.  If we don't have
consensus on any single solution and therefore believe that further
research in two or more directions is needed, then that is what we
should recommend.


 - 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