Re: [rrg] feature comparison chart, conscripted peer review ?

Robin Whittle <rw@firstpr.com.au> Mon, 15 February 2010 00:18 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 889073A7A7B for <rrg@core3.amsl.com>; Sun, 14 Feb 2010 16:18:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.725
X-Spam-Level:
X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, 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 syi2AMs14Qad for <rrg@core3.amsl.com>; Sun, 14 Feb 2010 16:18:43 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id C42E53A7A7C for <rrg@irtf.org>; Sun, 14 Feb 2010 16:18:40 -0800 (PST)
Received: from [10.0.0.6] (wira.firstpr.com.au [10.0.0.6]) by gair.firstpr.com.au (Postfix) with ESMTP id D0435175B0D; Mon, 15 Feb 2010 11:20:02 +1100 (EST)
Message-ID: <4B789339.1050306@firstpr.com.au>
Date: Mon, 15 Feb 2010 11:20:09 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: RRG <rrg@irtf.org>
References: <20100213055714.GA93359@rommie.caida.org> <20100214171903.GA9520@rommie.caida.org>
In-Reply-To: <20100214171903.GA9520@rommie.caida.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [rrg] feature comparison chart, conscripted peer review ?
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: Mon, 15 Feb 2010 00:18:48 -0000

Hi k,

Regarding systematic analysis of the proposals, I will soon be working
on two IDs for this purpose.  I hope people will support, constructively
criticise or contribute to these IDs as co-authors.

One will look at the Core-Edge Elimination (CEE) proposals:

  GLI-Split
  ILNP
  Name Based Sockets
  Name Overlay (NOL)
  RANGI

I haven't yet read the last two, but my impression is that they are CEE.
 I need to finish writing my understanding of GLI-Split and then read
these two before I can begin this ID.   This will include my
understanding of:

  What "CEE" and "CES" means.
  The history of the CEE and CES terms.
  The various naming models these proposals involve - all involve
  "Locator/Identifier Separation" - and how these differ from the
  current 2 level IP naming structure.
  My arguments about why it is best to retain the current naming model.
  I will probably mention GSE as well, although it is not an RRG
  proposal.

The other will look at the Core-Edge Separation (CES) proposals:

  IRON-RANGER
  Ivip
  LISP
  TIDR

I will probably mention APT as well.

A note below my signature explains on why I am concentrating on these
proposals.


Regarding:

   CES & CEE: GLI-Split; GSE, Six/One Router; 2008 sep./elim. paper
   http://www.ietf.org/mail-archive/web/rrg/current/msg06009.html

you wrote:

>   thanks for these "Comparison charts of:
>                      CES: LISP-ALT/NERD, APT, Ivip, TRRP, TIDR,
>                           IRON-RANGER and Six/One Router.
>                      CEE: GSE, GLI-Split, ILNP, Name-Based Sockets."
>   
>   two process questions:
>   (1) is there any plan for the RRG recommendation to include a more
>   complete version of such a matrix chart of proposals vs
>   rrg-documented design goals, with a pointer to enough explanation
>   of how well the proposal meets the design goal, or outstanding
>   complications?  your charts are the first step i've seen in
>   this direction, but a more comprehensive comparison chart
>   would be incredibly useful.  

I think the RRG Report should have systematic analysis like this.
Perhaps the co-chairs or multiple people in the RRG can write this, or
adapt something from the IDs I am about to write.


>   (2) i understand such a chart is likely blocked on more meat
>   filled in on critiques/rebuttal/counterpoints for each
>   proposal.  has the wg considered asking all proposal submitters
>   to submit critiques of at least three (or some N) other
>   proposals, including estimating the corresponding lines of
>   a feature comparison matrix?

I think this is the first such suggestion.  AFAIK there's no way the
co-chairs or the RRG itself can require anyone to do anything.

I entirely support your suggestion that anyone who submitted a proposal
should write critiques for multiple other proposals.


I know people are busy and all, but if someone puts a proposal to the
RRG, then it is because they believe it has merit above all other
proposals.  (There are exceptions, such as K. Sriram's and colleagues'
"Enhanced Efficiency" proposal, which was submitted for archival
purposes.  Also, some proponents have agreed with critiques that their
proposal can't be the best solution.)

As a service to others - including especially RRG members who the
proponents seek the support of - I think proponents should write
critiques of the prominent proposals which compete with their own.

For instance, why hasn't Ran Atkinson (or anyone else who supports ILNP
- such as Tony Li, I think) contributed to the list:

  1 - What is wrong with other CEE proposals: GLI-Split, Name Based
      Sockets, Name Overlay (NOL) and RANGI.

  2 - What is wrong with CES proposals in general, or in particular.

  3 - Why the ILNP naming model is superior to that of any other CEE
      architecture and to the current IP naming model, which is
      supported by all CES architectures.

Likewise, why haven't the GLI-Split people argued why their approach is
superior to all CES architectures and to the competing CEE architectures?

Why haven't the LISP folks written anything in detail about Ivip.  I
have written plenty of detailed, constructive, material about LISP.
Now's the time for them to return the favour.  It is a favour - am not
being at all ironic or facetious.

I think someone in the LISP team - and ideally Fred Templin (IRON
Ranger) should write to the list about why none of the CEE architectures
should be adopted.

Also, why don't the CEE proponents and supporters respond to this:

  Today's "IP addr. = ID = Loc" naming model should be retained
  http://www.ietf.org/mail-archive/web/rrg/current/msg05864.html

which is a fundamental critique of all CEE architectures and the widely
popular view (I think, within the RRG) that a "Locator/Identifier
Separation" naming model is superior to the current IPv4/6 model in
which the IP address plays both the Locator and Identifier roles.

Perhaps you could make a start by writing something about any of the above.


> this suggestion is based on the imbalance in the
> current draft between ideas-submitted and
> ideas-rigorously-evaluated. i suspect the IETF
> needs more of the latter, which it doesn't look
> like natural WG forces are going to produce.

I agree.

 - Robin


Here are the other proposals and why I am not concentrating on them.

  2 Phased Mapping
  Enhanced Efficiency
  LMS
  Mapping system based on compact routing

    These ones are only for mapping systems - and are not complete
    proposals.

Two other proposals which I think are neither CEE or CES architectures.

  AIS - Aggregation with Increasing Scopes

    If I have time and get answers to my questions (msg05862) I hope
    to understand this enough to write a critique.  But my current
    impression of this is that it could not be as good a solution
    as LISP or Ivip.

  hIPv4

    The original hIPv4 proposal is impractical.  I am discussing
    Patrick Frejborg's 04 revision at present.  I think this is
    interesting but at present I can't see how it could work.