[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
- [rrg] Form of the final recommendation? Robin Whittle
- Re: [rrg] Form of the final recommendation? Tony Li
- Re: [rrg] Form of the final recommendation? Robin Whittle
- Re: [rrg] Form of the final recommendation? Tony Li