[rrg] Form of the final recommendation?

Robin Whittle <rw@firstpr.com.au> Fri, 25 December 2009 03:54 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 D3B2B3A683B for <rrg@core3.amsl.com>; Thu, 24 Dec 2009 19:54:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.522
X-Spam-Level:
X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[AWL=0.373, 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 EFG3rL8TScXo for <rrg@core3.amsl.com>; Thu, 24 Dec 2009 19:54:20 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id E46D43A6810 for <rrg@irtf.org>; Thu, 24 Dec 2009 19:54:19 -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 EAC0E175A8D; Fri, 25 Dec 2009 14:53:57 +1100 (EST)
Message-ID: <4B343754.1060004@firstpr.com.au>
Date: Fri, 25 Dec 2009 14:53:56 +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>, Lixia Zhang <lixia@cs.ucla.edu>, Tony Li <tony.li@tony.li>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] Form of the final recommendation?
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: Fri, 25 Dec 2009 03:54:21 -0000

Hi Lixia and Tony,

I don't have a clear idea of what documents the RRG will be producing
or how these will be debated, drafted and finalised.

Here's my current understanding and some questions.

I saw 14 proposals.  However, one is for archival purposes only:

   Enhanced Efficiency of Mapping Distribution Protocols in
   Map-and-Encap Schemes
     http://www.ietf.org/mail-archive/web/rrg/current/msg05540.html
     K. Sriram, Young-Tak Kim, and Doug Montgomery

and three, in my estimation, are only for mapping systems:

   2-phased mapping for Internet core/edge split schemes
     http://www.ietf.org/mail-archive/web/rrg/current/msg05536.html
     Wei Zhang

   Layered Mapping System
     http://www.ietf.org/mail-archive/web/rrg/current/msg05534.html
     http://www.ietf.org/mail-archive/web/rrg/current/msg05554.html
     Sun Letong, YinXia, Wang ZhiLiang, Wu Jianping

   Mapping system based on compact routing
     http://www.ietf.org/mail-archive/web/rrg/current/msg05519.html
     http://www.ietf.org/mail-archive/web/rrg/current/msg05531.html
     Hannu Flinck


Tony wrote:

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

     Mapping systems are obviously a component of a solution but are
     not by themselves a solution. To be considered seriously, they
     should be used in conjunction with some network layer solution.

Are the four proposals above going to be part of the final phase?

The archival one is not really meant to be a solution. The other
three could only be part of a solution, and I think they can't be
evaluated alongside the other 10 proposals because they do not
contain a proposal for a complete solution.   The first one is meant
to apply to various core-edge separation schemes.  The last two seem
to be attempts to improve on ALT, for the purposes of providing a
mapping system for LISP.  However, without the proponents of those
core-edge separation schemes adopting these mapping systems, there's
no way of evaluating how well the combination would work.


I understand from:

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

that you are compiling the summaries into an Internet Draft and that
in that ID each summary will be followed by a 500 word "analysis".

I understand the proponents are to find and choose one or more people
(ideally several: "collaboration of a number of people" to write the
"analysis" - but that the proponents can't write or contribute to
that analysis themselves.   So these analyses will presumably be
reasonably positive - or as positive as the proponents can persuade
anyone to write!

Then there will be a 500 word "rebuttal" of the proposal.  This will
be solicited by Lixia and yourself.  Is this to be written by one
person or more?  Will you ask particular people to write this - or
will you accept contributions from anyone?  How would you choose the
people or between contributed rebuttals?  Is anyone to contribute a
rebuttal to the RRG list, or should we do it in private to the co-chairs?

Is "rebuttal" too strong a term to use?  I guess a critique could
either be in terms that the proposal cannot possibly work - which is
a rebuttal - or that it could work, but not as well as some other
proposal.  That could be tricky to do respectfully (with sufficient
details, arguments and qualifications) in 500 words, since it also
involves evaluating at least one other proposal which would be argued
to work better.

Then you will solicit "another counterpoint".  "Solicit" indicates to
me that you won't simply ask the proponents for a "counterpoint" but
that you will ask someone to write something - or accept potentially
multiple counterpoints and either choose one, or encourage the
authors to work together to produce a single one.

Will people contribute counterpoints freely on the list, or directly
to you?  I guess the counterpoint is to the "rebuttal" - so it can
only be written after the rebuttals are finalised.

Are the proponents allowed to write a counterpoint?  What if the
proponents of the proposal don't like your choices about the
counterpoint?

While it looks tricky, I can see some value in this set of pieces of
writing.

But the resulting document doesn't seem to resemble a
"recommendation" to the IETF.


I guess there will be a lot of debate on the list about the merits of
the various proposals.  However, the remaining 10 proposals are not
all directly comparable.  I think they fit into three groups:

A - 3 core-edge separation proposals which would work for both IPv4
    and IPv6 and not require any host changes:

     Ivip
       http://www.ietf.org/mail-archive/web/rrg/current/msg05533.html
       Robin Whittle

     LISP
       http://www.ietf.org/mail-archive/web/rrg/current/msg05503.html
       Vince Fuller, Dino Farrinacci, David Meyer and Darrel Lewis.

     Tunneled Inter-domain Routing (TIDR)
       http://www.ietf.org/mail-archive/web/rrg/current/msg05538.html
       Juan Jose Adan

    These three seem to be in direct competition in that it would
    only make sense to adopt one, and because they seem to be based
    on broadly the same set of assumptions.  I think each could
    potentially be adopted widely, on a voluntary basis, in a
    not-too-distant time-frame (3 to 10 years), due to there being no
    need for host changes and no assumptions about widespread
    migration to IPv6 as providing relief from the IPv4 scaling
    problem.


B - 6 proposals which I think are all core-edge elimination schemes
    which I think are not suitable for widespread voluntary adoption
    in the near-term, due to the need for host-changes.  Some are
    IPv6-only.  One is IPv4-only - while I recall the RRG consensus
    is to definitely solve the IPv6 problem, and ideally the IPv4
    problem too.

    These seem to me to have different goals, different time-frames
    and very different ideas about adoption than the Group A
    proposals:

     Global Locator, Local Locator, and Identifier Split (GLI-Split)
       http://www.ietf.org/mail-archive/web/rrg/current/msg05537.html
       Michael Menth, Matthias Hartmann and Dominik Klein

     hIPv4
       http://www.ietf.org/mail-archive/web/rrg/current/msg05529.html
       Patrick Frejborg

     Identifier-Locator Network Protocol (ILNP)
       http://www.ietf.org/mail-archive/web/rrg/current/msg05539.html
       Ran Atkinson

     Name-Based Sockets
       http://www.ietf.org/mail-archive/web/rrg/current/msg05543.html
       Christian Vogt

     Name overlay (NOL) service for scalable Internet routing
       http://www.ietf.org/mail-archive/web/rrg/current/msg05532.html
       Yangyang Wang

     RANGI
       http://www.ietf.org/mail-archive/web/rrg/current/msg05505.html
       Xiaohu Xu


C - One proposal which could be adopted without any further IETF
    protocol development and would probably not preclude any other
    proposal.  At the same time, I think few people would see it as a
    full solution to the routing scaling problem - which is what the
    Group A and B proposals are attempting to be.

     Aggregation with Increasing Scopes: An Evolutionary Path Towards
     Global Routing Scalability
       http://www.ietf.org/mail-archive/web/rrg/current/msg05542.html
       Dan Jen, Dan Massey, Robert Raszuk, Lan Wang, Xiaohu Xu,
       Beichuan Zhang and Lixia Zhang.

    This proposal suggests it is near-term preliminary to a
    longer-term host-based solution - implicitly a core-edge
    elimination scheme.  Some of the proponents previously worked
    on a core-edge separation scheme (APT) but decided that this -
    and presumably other such schemes - are too difficult to
    introduce.


Is the RRG's final recommendation going to be in a separate ID from
the one with the summaries, analyses, rebuttals and counterpoints?

If so, what is the schedule for discussing and writing it?

Could the recommendation be split into sections according to
time-frame and/or for IPv4 and IPv6?

There are divergent viewpoints about how important it is to solve the
IPv4 scaling problem and how urgently we need to work on the IPv6
scaling problem.  Maybe the RRG will reach consensus on this and so
be able to recommend a single approach.

If there is no broad consensus or this on anything else, will the
final recommendation try to summarise the two or more major groups of
viewpoints?


Discussion of proposals has been banned or discouraged until now.
Only a subset of the proposals which were discussed on the RRG or the
RAM list are still alive.  Now there are a bunch of new ones - or at
least unfamiliar ones, since TIDR predates this incarnation of the
RRG and has barely been mentioned on the mailing list.

I hope you will be able to help me and others understand the form of
the final recommendation.

  - Robin