Re: The internet architecture - pointer to RRG discussion

Robin Whittle <rw@firstpr.com.au> Mon, 29 December 2008 23:21 UTC

Return-Path: <ietf-bounces@ietf.org>
X-Original-To: ietf-archive@megatron.ietf.org
Delivered-To: ietfarch-ietf-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 329703A69A9; Mon, 29 Dec 2008 15:21:12 -0800 (PST)
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997E53A69A9 for <ietf@core3.amsl.com>; Mon, 29 Dec 2008 15:21:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.562
X-Spam-Level:
X-Spam-Status: No, score=-1.562 tagged_above=-999 required=5 tests=[AWL=0.333, 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 wieTdc9tgtR5 for <ietf@core3.amsl.com>; Mon, 29 Dec 2008 15:21:09 -0800 (PST)
Received: from gair.firstpr.com.au (gair.firstpr.com.au [150.101.162.123]) by core3.amsl.com (Postfix) with ESMTP id 418A23A686A for <ietf@ietf.org>; Mon, 29 Dec 2008 15:21:09 -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 52ACF175F1C; Tue, 30 Dec 2008 10:20:57 +1100 (EST)
Message-ID: <49595B59.20605@firstpr.com.au>
Date: Tue, 30 Dec 2008 10:20:57 +1100
From: Robin Whittle <rw@firstpr.com.au>
Organization: First Principles
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
To: ietf@ietf.org
Subject: Re: The internet architecture - pointer to RRG discussion
References: <20081130151159.418826BE571@mercury.lcs.mit.edu> <676530.29665.qm@web31814. mail.mud.yahoo.com> <49494DC8.1020503@employees.org> <2093978A-667A-498B-BD6 9-B75ABC17E732@gmail.com> <2EB8416D-799A-4F17-AA19-412E0DD49010@let.de> <a06 24086cc5749d09f78c@[10.0.1.11]> <661D82BF-2C24-4152-B395-8793E57CD3C5@let.d e> <a0624087ac575815832f7@[10.0.1.11]> <BA04FE5C-3132-4D43-A3B8-A9330AAF53C5 @let.de> <a0624087fc5758c8ed3a7@[10.0.1.11]> <C7D1AECE-49DE-4B7D-98AD-FE95E7 ACB09A@let.de> <A1D3AAC4-7099-456C-AE52-8426F5EBF761@mpi-sws.org> <2788466ED3E31C418E9ACC5C316615572FFC36@mou1wnexmb09.vcorp.ad.vrsn.com> <a0624082fc57d9e05bf48@[10.0.1.42]> <3EFC6F1A8324616A9DE63869@p3.int.jck.com>
In-Reply-To: <3EFC6F1A8324616A9DE63869@p3.int.jck.com>
Cc: John C Klensin <john-ietf@jck.com>, Bryan Ford <baford@mpi-sws.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Short version:   Please contribute to the IRTF Routing Research Group
                 discussions on how to devise a new Internet
                 architecture (including by adding to the current
                 architecture) to solve the routing scaling problem.

Hi John and All,

This discussion includes debate about whether in a new Internet
architecture, the responsibility for handling network-centric
problems should in future be handled by hosts.  These network-centric
 real-time events, problems and responsibilities include:

 1 - Multihoming.

 2 - Traffic engineering.

 3 - Portability of address space - or some other, yet to be
     invented, approach which has the same effect of making it easy
     to choose another ISP without the disruption, cost etc.

Please take a look at the current discussions in the IRTF Routing
Research Group.  The RRG has been charged with the responsibility of
recommending to the IESG what sort of architectural changes should be
made to the Internet (really, the IPv4 Internet and the IPv6
Internet) to solve the routing scaling problem.  The deadline is
March 2009.

RRG mailing list archives, wiki and charter:

 http://www.irtf.org/pipermail/rrg/
 http://trac.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup
 http://www.irtf.org/charter?gtype=rg&group=rrg

The RAWS workshop (Amsterdam October 2006):

 http://tools.ietf.org/html/rfc4984
 http://www.iab.org/about/workshops/routingandaddressing/


I wrote a critique of any solution which pushes new responsibilities
onto hosts which concern things which occur in the network:

 Fundamental objections to a host-based scalable routing solution
 http://www.irtf.org/pipermail/rrg/2008-November/000271.html

Bill Herrin has a page which attempts to list the various approaches
to solving the routing scaling problem:

 http://bill.herrin.us/network/rrgarchitectures.html

I think the problem definition there is biased towards the notion
that the solution is to have hosts take on new functions, including
with changes to stacks, APIs and applications.  I wrote some
additional text which I think provides a more complete problem
description:

 http://www.irtf.org/pipermail/rrg/2008-December/000525.html

Also of interest is a recent paper contrasting network centric
core-edge separation schemes with host-centric "elimination" schemes:

  Towards a Future Internet Architecture: Arguments for Separating
  Edges from Transit Core

  Dan Jen (UCLA), Lixia Zhang (UCLA), Lan Wang (University of
  Memphis), Beichuan Zhang (University of Arizona)

  (HotNets-VII) Calgary, Alberta, Canada October 6-7, 2008
  http://conferences.sigcomm.org/hotnets/2008/papers/18.pdf

Bill is currently calling for RRG members to form strong consensus on
rejecting one or more solution strategies.  (Msg 000554.)  The types
of strategy are (with my descriptions for A, B and C):

Strategy A:

  Network-based core-edge separation schemes, including LISP, APT
  Ivip, TRRP and Six-One Router.  (See the RRG wiki page for links.)

Strategy B:

  Host-centric elimination schemes.  "Elimination" means all end-user
  network addresses are subsets of ISP prefixes.  Only ISP prefixes
  are advertised in the interdomain routing system.

  See Brian Carpenter's message on how this is "unworkable for IPv4
  and very close to the plan of record for IPv6" - except that
  IPv6 doesn't provide multihoming (session survival when the
  currently used ISP-provided address becomes unusable).

   http://www.irtf.org/pipermail/rrg/2008-December/000577.html

Strategy C:

  New interdomain routing system arrangements, including for
  instance: geographical aggregation or compact routing.
  (A critique of compact routing: http://arxiv.org/abs/0708.2309.)

Strategy D:

  "Use plain old BGP for the RIB. Algorithmically compress the FIB in
  each router."

Strategy E:

  "Make no routing architecture changes. Instead, create a billing
  system through which the folks running core routers are paid by the
  folks announcing each prefix to carry those prefixes. Let economics
  suppress growth to a survivable level."

Strategy F:

  "Do nothing. (RFC 1887 § 4.4.1)"


My message calling for strong consensus in rejecting Strategies B, C,
D, E and F:

  http://www.irtf.org/pipermail/rrg/2008-December/000565.html



  - Robin            http://www.firstpr.com.au/ip/ivip/
_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf