[rrg] Wildly unrealistic Recommendation
Robin Whittle <rw@firstpr.com.au> Fri, 26 March 2010 18:09 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 DAA7C3A69F6 for <rrg@core3.amsl.com>; Fri, 26 Mar 2010 11:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.606
X-Spam-Level: **
X-Spam-Status: No, score=2.606 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, 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 DaakAcMmWzXu for <rrg@core3.amsl.com>; Fri, 26 Mar 2010 11:09:58 -0700 (PDT)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 2303F3A68FE for <rrg@irtf.org>; Fri, 26 Mar 2010 11:09:58 -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 E8A93175AEA; Sat, 27 Mar 2010 05:10:20 +1100 (EST)
Message-ID: <4BACF88D.50304@firstpr.com.au>
Date: Sat, 27 Mar 2010 05:10:21 +1100
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>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [rrg] Wildly unrealistic 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, 26 Mar 2010 18:09:59 -0000
Listening to the audio of the meeting, I understand Lixia and Tony have decided that the RRG Recommendation is for the Core-Edge Elimination (Locator / Identifier Separation) architecture ILNP to be further developed. Perhaps I missed something about the Recommendation also involving Aggregation with Increasing Scopes - but several people mentioned this was either a stop-gap, or involved such complexities as to give them a headache. ILNP can't work for IPv4 and can only deliver significant routing scalability benefits once all hosts: 1 - Adopt IPv6. 2 - Have their stacks upgraded to ILNP. There are various critiques of how well ILNP would work, but even if it worked as planned, it cannot be a solution to the only routing scaling problem currently in existence (IPv4 - see: msg05946). So I think this Recommendation is wildly unrealistic. There is nothing in the Charter to suggest that we don't need to worry about the IPv4 routing scaling problem. http://www.irtf.org/charter?gtype=rg&group=rrg The Charter mentions Mobility as part of the problem - but this has been sidelined for most of the RRG discussions. At the moment, the Internet routing and addressing architecture is facing challenges in scalability, mobility, multi-homing, and inter-domain traffic engineering. Thus the RRG proposes to focus its effort on designing an alternate architecture to meet these challenges. It is not clear that ILNP can handle mobility - yet I think it was Tony, earlier this morning, who stated that current IP Mobility arrangements are far from adequate. (I don't recall his words.) This Recommendation comes purely from the co-chairs. There has been no attempt to test or seek consensus on this. Nor has there been a serious attempt to develop a set of design goals, as was required by the Charter. The existing Design Goals ID was never developed any further after its current draft, very early in this phase of the RRG's work. There was no attempt to test consensus support for it. Discussion of "proposals" (AKA "candidate architectures") was banned or discouraged for much of the last three years. We were told to discuss "architectural" matters - but there was little or nothing from the co-chairs by example or by instruction on what this would involve. The co-chairs did not encourage serious work on a taxonomy or classification system for the various proposals/architectures. (I have no idea why, today, they classed GLI/Split - which is a CEE architecture - with the CES "map-encap" architectures.) No-one has argued the case for why it is better to burden all hosts with extra work (CEE = Locator / Identifier Separation) than to add some things to the routing system (CES) and leave the hosts alone, using the current, highly efficient, naming model in which the IP address plays both the Identifier and Locator roles. See the thread "Why won't supporters of Loc/ID Separation (CEE) argue their case?" - the first message links to messages arguing against CEE. It seems this Recommendation is unconcerned with practical matters such as efficiency, minimising delay in establishing communications, concern about the IPv4 scaling problem - or about the barriers imposed by the need for widespread voluntary adoption: http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/ CES architectures can meet these constraints. CEE architectures can't. For anyone who wants to read my idea of what the RRG should have recommended: http://www.ietf.org/mail-archive/web/rrg/current/msg06219.html No-one else wrote what they would like to see in the Recommendation. This includes a general critique of Core-Edge Elimination (Locator / Identifier Separation) architectures, including ILNP. I think Lixia mentioned that ILNP requires hosts to do "heavy lifting". Indeed it does - see msg06219 for why all CEE architectures require all hosts to do more work, send and receive more packets, and frequently suffer significant delays in establishing initial communications. These problems are worse for any host, such as a mobile host, which relies on slow, potentially congested, potentially unreliable links such as 3G wireless. - Robin
- [rrg] Wildly unrealistic Recommendation Robin Whittle
- Re: [rrg] Wildly unrealistic Recommendation John E Drake
- Re: [rrg] Wildly unrealistic Recommendation Noel Chiappa
- Re: [rrg] Wildly unrealistic Recommendation L.Wood
- Re: [rrg] Wildly unrealistic Recommendation Robin Whittle
- Re: [rrg] Wildly unrealistic Recommendation Noel Chiappa