Re: [rrg] draft-narten-radir-problem-statement-05.txt

Thomas Narten <narten@us.ibm.com> Wed, 24 February 2010 22:32 UTC

Return-Path: <narten@us.ibm.com>
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 112CD28C0DE for <rrg@core3.amsl.com>; Wed, 24 Feb 2010 14:32:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.942
X-Spam-Level:
X-Spam-Status: No, score=-5.942 tagged_above=-999 required=5 tests=[AWL=0.342, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315]
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 51V6YDb8mjrc for <rrg@core3.amsl.com>; Wed, 24 Feb 2010 14:32:53 -0800 (PST)
Received: from e31.co.us.ibm.com (e31.co.us.ibm.com [32.97.110.149]) by core3.amsl.com (Postfix) with ESMTP id 0532C3A85E6 for <rrg@irtf.org>; Wed, 24 Feb 2010 14:32:52 -0800 (PST)
Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e31.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o1OMQJWA032087 for <rrg@irtf.org>; Wed, 24 Feb 2010 15:26:19 -0700
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o1OMYn5v152670 for <rrg@irtf.org>; Wed, 24 Feb 2010 15:34:52 -0700
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o1OMYnJm002180 for <rrg@irtf.org>; Wed, 24 Feb 2010 15:34:49 -0700
Received: from cichlid.raleigh.ibm.com (sig-9-49-144-243.mts.ibm.com [9.49.144.243]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVin) with ESMTP id o1OMYmV2002116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Feb 2010 15:34:48 -0700
Received: from cichlid.raleigh.ibm.com (localhost [127.0.0.1]) by cichlid.raleigh.ibm.com (8.14.3/8.12.5) with ESMTP id o1OMYlJV031162; Wed, 24 Feb 2010 17:34:47 -0500
Message-Id: <201002242234.o1OMYlJV031162@cichlid.raleigh.ibm.com>
To: Robin Whittle <rw@firstpr.com.au>
In-reply-to: <4B837DB1.8050009@firstpr.com.au>
References: <201002180040.o1I0eAr0027055@cichlid.raleigh.ibm.com> <4B837DB1.8050009@firstpr.com.au>
Comments: In-reply-to Robin Whittle <rw@firstpr.com.au> message dated "Tue, 23 Feb 2010 18:03:13 +1100."
Date: Wed, 24 Feb 2010 17:34:47 -0500
From: Thomas Narten <narten@us.ibm.com>
Cc: RRG <rrg@irtf.org>
Subject: Re: [rrg] draft-narten-radir-problem-statement-05.txt
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: Wed, 24 Feb 2010 22:32:54 -0000

Hi Robin.

I've looked at some of the references and older messages, but it's not
clear to me what action item you want me to make. Do you have specific
concerns with the accuracy of our document? etc? It would be much more
helpful if you can point out specific wording or sections that you
feel are not right - and explain why.

> Section 3.3 states "there are millions of potential end sites which
> would benefit from being able to multihome".  Brian Carpenter and I
> recently, independently, nominated 10 million as a rough upper limit
> on the number of non-mobile network which want or need portability,
> multihoming and/or TE (though perhaps Brian didn't mention
> "portability".  My reasoning was roughly that with human population
> of 10 billion, there will probably be only one organisation per 1000
> people (mainly small companies, but also schools and other
> organisations) which have sufficient need of portability or
> multihoming to get "edge" space in a CES system and to get the two or
> more physical links from two or more ISP's services as needed for
> multihoming.

I don't know that I agree with this actually. In today's world of
DSL/Cable/soon-to-be ubiquitous wireless, I could imagine every home
using multiple ISPs. Won't those users want multihoming to work for
them?

But in any case, I don't know that  our document needs to take a stand
on any one particular number.

> I think the Problem Statement's references to "4.3. End Site
> Renumbering" and to certain extent to "4.4. Acquisitions and
> Mergers" could be improved by reference to address space
> "portability".  The word "portability" does not appear in the
> Statement, and while I think it makes some people's teeth itch, I
> think it should be mentioned.

IMO, there is an important and subtle difference between "portability"
and "renumbering hurts bad". They are not the same thing.

Portability is only wanted because that is the primary solution for
avoiding the pain of renumbering (other than NAT).

And portability also says (to me) something about individual prefixes
going into the DFZ, which is not really what people necessarily
actually care about (or want) when they want "portability". They want
to be able to switch providers without renumbering. So I think it is
more accurate to focus on that as being the true underlying issue.

> The problems mentioned in these sections arguably only exist because
> only PI space is "portable" and that when splitting even this
> portable space into two separately advertised PI prefixes is
> possible, this contributes to the routing scaling problem.

Section 4.2 on multihoming pretty clearly points out that PI vs. PA is
not the issue w.r.t. causing problems in the case of multihoming. You
can multihome with PA space, but you get the same bad properties.

> Core-Edge Separation architectures provide a new subset of the global
> unicast address space which is portable in a scalable manner, and
> which can be split up much more finely than the /24 limit which
> applies to conventional PI prefixes.

> So I think it would be reasonable to describe a key part of the
> routing scaling problem as being due to the lack of portability for
> any scalable form of address space in the current system.

I am not convinced that this is an accurate statement.

Thomas