[rrg] The RRG's capacity to handle detail is not up to the task of designing architectural enhancements for v4/v6 Internets

Robin Whittle <rw@firstpr.com.au> Sat, 26 June 2010 04:04 UTC

Return-Path: <rw@firstpr.com.au>
X-Original-To: rrg@core3.amsl.com
Delivered-To: rrg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31BC93A689C for <rrg@core3.amsl.com>; Fri, 25 Jun 2010 21:04:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.762
X-Spam-Level:
X-Spam-Status: No, score=0.762 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_50=0.001, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuGJYMR3bOYB for <rrg@core3.amsl.com>; Fri, 25 Jun 2010 21:04:48 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id E7CB53A681E for <rrg@irtf.org>; Fri, 25 Jun 2010 21:04:45 -0700 (PDT)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id 8EAF2175CD6; Sat, 26 Jun 2010 14:04:50 +1000 (EST)
Message-ID: <4C257C67.2000000@firstpr.com.au>
Date: Sat, 26 Jun 2010 14:04:55 +1000
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <96BB0246-5DED-48B4-833D-22272E37B522@gmail.com> <4C24C45E.9030707@firstpr.com.au> <4C24E1F0.1040509@cisco.com> <1207B0CA-CD33-44F7-84BC-AA64079F38D7@tony.li> <alpine.LFD.2.00.1006252151170.29897@stoner.jakma.org> <94AA0C0A-71FC-4CA2-BAAB-9F0BFC740162@tony.li>
In-Reply-To: <94AA0C0A-71FC-4CA2-BAAB-9F0BFC740162@tony.li>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] The RRG's capacity to handle detail is not up to the task of designing architectural enhancements for v4/v6 Internets
X-BeenThere: rrg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IRTF Routing Research Group <rrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/rrg>
List-Post: <mailto:rrg@irtf.org>
List-Help: <mailto:rrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/rrg>, <mailto:rrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 26 Jun 2010 04:04:50 -0000

Hi Tony,

In "Re: [rrg] RG Last Call: ILNP document set", thanks for pointing out:

  http://tools.ietf.org/html/rfc5743#section-2.1

Since I understand there is consensus support for publishing the ILNP
IDs as IRTF RFCs and since it is a formal requirement:

  There must be a statement in the abstract identifying it as the
  product of the RG.

I withdraw my request that the statement be removed.


> The constraints are pretty much set forth in RFC 5743. In
> addition, documents should reflect something that the group has
> already discussed.
> 
> Further, we strongly would like to get RG consensus that the
> document is in a state where it should be published.  Note that
> this is not an endorsement of the content, but consensus that
> the quality of the document is sufficient to be a product of
> the RG.

Given the evident constraints on RRG participants reading and
commenting meaningfully on anything with substantial detail, I think
the ILNP IDs are short and simple enough to achieve such consensus.

I would not attempt to write up Ivip as RRG RFCs, since there is no
evidence that sufficient RRG folk have the time or inclination to
read and comment on something of Ivip's length and detail.

You and many other regular RRG contributors have had three years to
read and comment on Ivip - and you have not done so.

Distributed Real Time Mapping has been perfectly well explained, with
nice diagrams:

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

for 3 months - and no-one has commented on it.

TTR Mobility was part of my initial Ivip message three years ago:

  http://www.ietf.org/mail-archive/web/ram/current/msg01518.html

yet no-one has commented on it.  It has been well documented, with
diagrams - with the help of Steve Russert:

  http://www.firstpr.com.au/ip/ivip/TTR-Mobility.pdf

since August 2008 and I have frequently mentioned and explained it on
the list.  Still, no-one has commented on it.


> The documents themselves are research contributions.  They are not
> expected to be engineering specifications and as such, can omit a
> great deal of detail if they so choose. Certainly thorny questions
> can be deferred to the IETF.

I completely disagree with this idea of separating "architecture"
from "engineering" - especially the idea of leaving "engineering" to
someone else to solve.

Can you point to any successful outcomes of this disdain for, or
deferment of interest in, "engineering"?  In any field whatsoever -
software development, IETF protocols, ship-building, aircraft design,
commercial buildings, dam, road or railway construction?

Except when doing the initial brainstorming, a designer of a new
architecture should be able to show it will work at all levels of the
design - irrespective of whether some people think of these levels as
"architecture" or "engineering".

The proposed architectural enhancements for IPv4 and IPv6 should also
have a clear set of goals and non-goals, and address the major
challenges of the need for widespread voluntary adoption.  It should
also go beyond scalable multihoming to achieve mobility on a massive
scale.

The RRG has not developed or achieved consensus on a set of goals, or
a problem statement.  ILNP has no list of goals or non-goals.

I have attempted to do this with Ivip, and I think I have generally
succeeded.  But it seems that the result far exceeds the attention
span or interest of most RRG members to read and comment about.  Even
my attempt at writing an RRG Recommendation:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html

seems to be too long (19 pages) and detailed for anyone to comment on.


ILNP is simple and short enough for you and many other RRG people to
read and comment upon.  However, it is completely inadequate as a
solution to the routing scaling problem - for reasons I mentioned in
msg06219.  It suits Ran's preference for remaining a the
"architectural" end of the design process, his lack of interest in
what he regards as "engineering" details - and his evident lack of
interest in questions of adoption:

  http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

Nor, it seems, do you or Ran have interest/time to comment on some
critiques of ILNP, such as what I just wrote about ILNP's approach to
mobility (msg07031).

Neither you or Ran have written anything to help Fred Templin refine
his IRON IDs, which I understand you also want to have published as
IRTF RFCs.


I am not suggesting that you or any other RRG folks should spend time
on Ivip or IRON or anything else.  We are all volunteers.

However, given the pervasive lack of interest in any proposal which
involves sufficient complexity to actually work, I don't think you
should claim the RRG has done its job properly.

Most active participants have failed to read and meaningfully discuss
significant contributions such as Ivip, or more recently, IRON.
There has been considerable RRG discussion of LISP, but the LISP
folks have generally been uninterested in discussing these
substantial critiques, either on the RRG list or in the LISP WG.


I know we are all short of time.  But with Ivip in general, and with
TTR Mobility, you have had 3 years.   To gain a good understanding of
the 3 month-old DRTM, you can read 6 pages of text and peruse three
diagrams.  That would take an hour or less.  This is a fraction of
the effort which you and many other people put into reading and
writing RRG messages every week, so as the months and years go by,
being short of time is clearly not the limiting factor.

I think you, Ran and some other folks are too focused on changing all
hosts to relieve the Network of some extra workload.  This is a very
pure, mathematical, approach by which you limit the functionality of
the network and its routers in order that they can scale very well.
You appear untroubled by the consequent requirement that hosts to do
extra work and use new, more complex, protocols.

As a result of your elevation of network simplicity to the primary
goal, you you quickly dismiss any Core-Edge Separation architecture
such as LISP, Ivip or IRON.

With ILNP, you are pursuing an architecture which changes all host
stacks (and for IPv4 requires upgrades to all DFZ and other routers),
because it suits your conviction that the Network can't or shouldn't
be called upon to be made more complex and do extra work, to support
current host protocols in the quest for scalable multihoming and
mobility.

Four days ago I argued:

  "Overloading" of Loc & ID functions is good for hosts and should be
  maintained
  http://www.ietf.org/mail-archive/web/rrg/current/msg07017.html

that the current host protocols and the division of labor between
routing system and hosts have profound advantages.  I have mentioned
this frequently in the past.  Yet no-one has commented.

ILNP will probably never be adopted even slightly by genuine users in
IPv6, where it has some technical elegance - due to:

  1 - The need for host stack changes.

  2 - Substantial benefits for adopters and for scalable routing only
      being delivered once almost every host and network adopts it.

  3 - Being unsuitable for mobility.

  4 - Burdening all hosts with extra packets or longer packets.

  5 - Introducing extra delays in the establishment of communication
      sessions.

ILNP has absolutely zero chance of helping with the IPv4 scaling /
multihoming / mobility problem for these reasons and because it
requires longer packets (with the IPv4 Option) and upgrades to all
DFZ and other routers in order to handle this Option.

These problems with any CEE (Loc/ID Separation) approach have been
obvious since before this recent 3 year phase of the RRG's work -
which is why people developed LISP, Ivip, IRON and TIDR.

So I think that in recommending ILNP, you are completely mistaken.

Hopefully in the future there will be a group of people with time and
interest to discuss and contribute to architectures which are
complete enough (and therefore more complex than ILNP and more
carefully designed than LISP) to actually achieve all the goals of
scalability, multihoming, mobility and widespread adoption by
voluntary means alone.

At future years I intend to write up Ivip and DRTM more thoroughly
and hopefully write some code for a test network.  Until then, please
see:

  http://www.ietf.org/mail-archive/web/rrg/current/msg06823.html

in response to Tom Petch (msg06831) regarding his suggestion I write
RFCs for the CES/CEE distinction and for DRTM.

 - Robin