[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
- [rrg] RG Last Call: ILNP document set RJ Atkinson
- Re: [rrg] RG Last Call: ILNP document set Robin Whittle
- Re: [rrg] RG Last Call: ILNP document set Eliot Lear
- Re: [rrg] RG Last Call: ILNP document set Tony Li
- Re: [rrg] RG Last Call: ILNP document set Eliot Lear
- Re: [rrg] RG Last Call: ILNP document set RJ Atkinson
- Re: [rrg] RG Last Call: ILNP document set Tony Li
- Re: [rrg] RG Last Call: ILNP document set Paul Jakma
- Re: [rrg] RG Last Call: ILNP document set Tony Li
- [rrg] The RRG's capacity to handle detail is not … Robin Whittle
- Re: [rrg] RG Last Call: ILNP document set Paul Jakma
- Re: [rrg] RG Last Call: ILNP document set Tony Li
- Re: [rrg] RG Last Call: ILNP document set t.petch
- Re: [rrg] RG Last Call: ILNP document set Tony Li
- Re: [rrg] The RRG's capacity to handle detail is … t.petch
- Re: [rrg] The RRG's capacity to handle detail is … Robin Whittle