[RRG] Committees vs. small teams, IPv4 fix absolutely required

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

Hi James,

In the "Long term clean-slate only for the RRG?" thread, you wrote:

>> I don't support IETF/IRTF working on any long term, clean slate
>> solutions.

OK.  It is too big a job for the RRG in our time frame - March
2008 - but I think we should consider clean slate solutions which
are scalable, and which would solve other problems, to recommend to
whoever (perhaps the RRG in the future) carries on this work.  Maybe
there is a way that the IPv4 and IPv6 solutions which arise from the
RRG recommendations could be designed in a manner which supports
transition to a long-term "clean slate" architecture.  Also, ideas
about a clean-slate architecture may influence how long we plan the
IPv4 and IPv6 fixes to last.

>> I believe that the preliminary phases in which this work is
>> now require small teams of creative individuals with new and
>> quite radically different ideas.

I fully agree.  I think the best approach would be something like this:

  Various teams work on their own proposals and present them
  as clearly as possible, as their work develops.

  Then members of all teams, plus the RRG members who are not
  in any particular team, constructively criticise these
  proposals.

>> An environment of required consensus and "design by committee"
>> isn't conducive to the kind of creative thinking that is required
>> for such solutions.

I agree.  I wrote about this in March:

   Concerns about the RRG process ... & how not to design an
   airliner   http://psg.com/lists/rrg/2008/msg00971.html

The top-down approach doesn't work very well because there are
multiple fruitful directions which need to be developed into
detailed proposals before the benefits and problems become apparent.

Imagine a committee designing an airliner and first deciding whether
to use carbon fibre composites or not.  That is just one of many
major interdependent decisions a designer makes.  By choosing to go
only one way, or the other, before exploring all the possible
outcomes of each branch in the road, the committee is not able to
discover all the synergies and problems which make or break an
actual design.

I think the RRG could develop some principles for choosing a good
solution, for both IPv4 and IPv6 (there are some important technical
differences, and a lack of urgency with IPv6) and recommend one or
more of the proposals as worthy of further consideration and
development.

Perhaps the RRG might decide that none of the proposals are good
enough yet for development in the next year or two - but instead
recommend further research into or more short term (IPv4 and IPv6)
solutions and into a long-term, clean-slate architecture.

>> After all if Kleinrock, Cerf, and the rest had gone to ITU with
>> the Internet in the early phase, would it have ever happened?

I wasn't involved in those days, but I guess the ITU would be
wanting see how the billing for each Internet call was done.

It is hard to imagine a new architecture for the Internet developing
without having to be approved by a bunch of committees.

However perhaps an Ivip like map-encap scheme could be introduced by
one or more commercial operators, to provide portable multihomable
space - and with the TTR extensions, mobility.  That might be so
easy to adopt and useful for end-user networks, that it becomes
widely adopted in a few years.  Done properly, this would  solve the
routing scaling problem, making any alternative solution harder to
introduce.  This is not what I want to happen, but I could imagine
it happening - especially if we drift well into the next decade
without anything sufficiently attractive to end-users emerging from
the IRTF-IETF committee system.

I agree in the early days, multiple free-wheeling teams should work
on their own proposals - with the RRG or similar acting as a testing
ground for all the new proposals.  I think it is vital that the team
members constructively criticise the proposals of other teams.

As I understand it, the RRG plan is not to debate specific
proposals, but to develop an architectural specification from
high-level discussions, without reference to current proposals.
I think this is highly unlikely to produce a better proposal than
those already developed.

One aim of focussing on "high-level architectural" discussion of
the solution space is to find potential solutions which were missed
by the independent teams.  However, I think no such new direction
has been found so far, at least in terms of anything compatible with
IPv4 and IPv6 without host changes.

Ideally the small teams would have the resources to fully develop
their ideas, build prototypes etc.  So far, only the LISP team have
been able to prototype their system.

>> As for the other proposals, a solution for IPv4 is absolutely
>> required, since that is what industry and society depends on,
>> regardless of how much the IETF may desire that IPv6 become the
>> basis of people's day to day interaction with the Internet.

I agree entirely.


>> I'm not sure about having different solutions for IPv4 and IPv6.
>> I suspect that there would be a lot of pushback from vendors and
>> operators on this when it went to standardization, and I'm sure
>> there would be a draft that would pop up for
>> "IPv4-solution-on-IPv6" that would rapidly gain consensus and
>> overthrow any IPv6-only solution.

I tend to agree, but since I think it is still early days, since
IPv6 enables more technical methods to be use to solve the problem,
since it isn't so urgent and since the installed base is so much
smaller, I wanted to keep the path open for a different solution, if
it was sufficiently superior to the IPv4 solution to justify
whatever differences it entailed.


 - 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