[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