Re: [RRG] Long term clean-slate only for the RRG?

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

I am replying to James Kempf, Scott Brim and Dino Farinacci.

My interpretation of your positions is that you do not support the
current rough consensus item, which may be up for further discussion
or a more formal vote (msg 1558).  I will call this "Paragraph T":

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

T:  Our recommendation should be applicable to IPv6.  It may or
    may not also apply to IPv4, but at the very least must
    provide a path forward for IPv6.

My impression is that you might favour my proposals A, B and C:

  3 potential consensus questions
  http://psg.com/lists/rrg/2008/msg01574.html

Paragraph C would commit the RRG to pursuing 3 parallel streams of
research, implicitly with three different time-frames:

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.

If the RRG achieves consensus on Paragraph C, and if we can handle
the whole discussion on the RRG list, then there is no need for my
suggestion for a separate list such as RRG-Sandbox.

However, even if we agree on Paragraph C or similar, if there are
other restrictions on the RRG list - such as not discussing
potential solutions, or deliberately avoiding technical details
(viewed by some as merely "engineering" and likely to distract from
"architecture") - then I would still suggest we have a another list.

If the RRG can't agree to C above, then I present some possible
alternatives, D, E and F - none of which I support - in:

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


James Kempf wrote:

> Robin,
>
> I haven't been following this discussion in detail, but I
> basically agree with your assessment.

OK.  Thanks.

> There are other folks working on clean slate architectures, GENI,
> etc.. The IETF (including IRTF which isn't that far removed)
> should "stick to the knitting" and work on stuff that keeps the
> current Internet running well.

I agree, but I think some folks on the RRG - including perhaps Lixia
and Tony - think our role should be focused on the long term and
that keeping the current (IPv4) Internet working is not our concern.

I think this position is partly based on the notion that the IPv4
Internet is working and will keep working sufficiently well that we
don't need to do much about it - and that a long-term solution can
be developed be widely adopted soon enough for the IPv4 (and perhaps
IPv6) pain to be acceptable.


**  I think we really need to decide for or against T, C or
**  alternatives such as D, E and F as soon as possible.


> And, as you mention below, fixing problems for IPv4 is much more
> important than for IPv6, because IPv4 is more widely deployed.

I agree entirely.

There are countless billions of dollars invested in IPv4 and there
is going to be massive investment keeping it going, since all the
alternative is (initially) a separate Internet with only limited
connection to the IPv4 Internet, and with very few people connected
to it.

The momentum of IT systems is immense, and I think it is hard to
think of a greater example than IPv4 (reachability of other hosts,
compatibility with host OSes and applications).

Most end-users don't care much about the long-term or the
architectural correctness of their IT systems.  They need works
today to keep working tomorrow.

However, some regard IPv4 as a dead-end, and who are confident of
widespread adoption of IPv6 (or whatever) in time that the IPv4
routing scaling problem wouldn't be too much of a concern.  For
them, perhaps the worsening costs, lack of space, lack of
multihoming and portability etc. of IPv4 is probably a good thing -
because they think it gives impetus to the world to kick the IPv4 habit.

I have some sympathy for this utopian view.  Likewise I wish the
world would standardise on one side of the road or the other for
driving - I am dreading trying to drive on the wrong side when I
travel to the USA!

http://en.wikipedia.org/wiki/Left_hand_drive
http://users.pandora.be/worldstandards/driving%20on%20the%20left.htm

If the RRG and therefore the IETF only pursue a long-term solution,
unconcerned about the growing trouble in today's Internet (IPv4), I
think a billion or so Internet users would feel this was a utopian
vision which was well intentioned, but did not give sufficient
priority to their actual needs.


> When and if a clean slate architecture gains traction, it is as
> likely to look like the current Internet as the circuit switched
> telephone network does.

Yes.

A clean slate design will require radically rewritten applications
as well as operating systems.  It will probably involve a completely
different routing system too, with the need for new routers, new
routing protocols etc.

Properly done, a clean-slate design would support mobility and
global end-to-end QoS with a financial settlement system so
end-users (or their ISPs) could pay for reserving bandwidth.  These
would make the Internet into a reliable, well funded, global data
network for everything from ping packets cell-phone calls to
multi-gigabyte streaming HDTV and massive, robust, VPNs.


> One thing that concerns me is the managability of any map and
> encap solution. I took a look at the LISP proposal a while back,
> and it struck me as raising some unique challenges for
> managability. That's not a reason not to do it, but I think that
> the RG should focus on "design for managability", i.e. that
> managability should be in the top ten goals for the design.

LISP isn't the only map-encap scheme - a list of distinctions and
commonalities with the others is here.

  http://www.firstpr.com.au/ip/ivip/comp/

Ivip involves simpler ITRs and modularly separates the multihoming
failure detection and decision system out of the map-encap scheme,
whereas the others integrate it monolithically.  Ivip has a business
case for the OITRDs (Open ITRs in the DFZ - which support packets
from networks without ITRs) whereas there is currently no business
case for the LISP equivalent: "Proxy Tunnel Routers".

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


Dino Farinacci wrote:

>> Robin,
>>
>> Yes !!! Be assured, myself, I am also and only focused on a long-term
>> solution, i.e. on a forever scaling solution.
>> At the same time I never was opposed to LISP or whichever map-encap
>> variant if considered to be a near-term interim solution.By other
>> words: map-encap is definitely not the longterm solution.
>> Instead I am convinced that topology aggregation will become the
>> longterm solution because it would scale even if the internet became
>> bigger than the network of our roads and streets.

The quote was from Heiner Hummel, not me.

> And to add to this, from the beginning, none of the LISP authors felt
> that LISP was the ultimate long-term solution.

Likewise with Ivip - the ultimate long-term solution involves
different protocols, as Bill Herrin wrote:

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


> So, should the short-term map-n-encap solution be for IPv4 and the
> long-term solution be for IPv6 only? That would depart from the thought
> of having one solution for both address-families.

That would involve the assumption that IPv6 could be used as a basis
for the long-term solution.  I suspect it would be better to start
afresh, which is why I proposed Paragraph C.


> Could we agree that one map-n-encap solution for both IPv4 and IPv6 be a
> short-term solution while we work on a long-term solution for IPv6-only?

I support this - if this turns out to be the best approach, then it
is covered by point 2 A of Paragraph C.

Assuming we fix IPv4 with a map-encap solution, and assuming that
the long-term solution needs to be clean-slate - not based at all on
IPv4 or IPv6 - then I think it would be good to decide:

   Although IPv6 could support a translation scheme such as
   was Six/One Router (which may have less PMTUD problems than
   map-encap, and involve less inefficiency with the overhead of
   long IPv6 encapsulating headers)  . . .

   Since IPv6 is not the long-term solution, and since we have
   figured out a fix for PMTUD already with the IPv4 map-encap
   system . . .

   Rather than have two architecturally different solutions for
   IPv4 and IPv6, we might as well use map-encap for IPv6.


Scott Brim wrote:

> I like to start with a clean slate set of _requirements_ (not
> design) and then work back to what is doable short term.

OK.  I understand from this that you support either:

  1 - Fixing IPv4 ASAP in order to give more time for IPv6 and a
      long-term solution.

  2 - Fixing IPv6 ASAP, with the intention that we can do this soon
      enough *and* make it favourable enough to get most people to
      adopt it, soon enough that the IPv4 swamp and scaling problem
      is somehow acceptable.

I support point 1 - and this is covered by Paragraph C.

I don't support point 2.  That is covered by Paragraph E:

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


> That way your immediate actions at least lead us in a good
> long-term direction.

Yes - probably involving one or perhaps two intermediate solutions
to give time for a proper long-term solution.

Perhaps there is a way of designing the IPv4 or IPv6 solutions so
that they in some way support migration to the long-term solution -
or perhaps without any changes to those designs, they might be
useful for this anyway.

I had a rough go at thinking about this recently (IPv99) - assuming
a good map-encap IPv4 system, what new system might we create which
would last for the long-term but have an agreeable migration path:

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

but that is far from "clean-slate" since the new system would retain
explicit support for IPv4 and has its overall address space largely
based on current IPv4 assignments.


Quoting Lixia:

>> I'll save the rest for later (as it's getting close to 3AM
>> local time). But I'd like to repeat myself one more time here:
>> - we are solving routing scalability problem here. we need to
>> "do it right"
>
> (1) We need to do it.
>
> (2) To the extent we can do it "right" and still satisfy (1) in
> useful time, we should.  See above as a way to do it.

I think this means you define a "short term" time-frame and figure
out what arguably needs to be done to protect current and
near-future (5 to 8 years maybe) end-users, and whether there is a
promising solution which would support in some way a long-term solution.

"Support" could be in the form of forming a technical basis for
migrating to the long term solution and/or by solving the near-term
problem (say 5 to 15 or whatever years) to give us more time to
concoct a genuine long-term solution with sufficient benefits and
with transition mechanisms which mean it is likely to be adopted in
the "long-term" - say 15+ years - early adoption in 2020 and
widespread by 2027 or whatever.

 - 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