Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]

Brian E Carpenter <brc@zurich.ibm.com> Fri, 21 April 2006 13:47 UTC

Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvyg-0002LD-DH; Fri, 21 Apr 2006 09:47:18 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FWvyd-0002D4-9B for ietf@ietf.org; Fri, 21 Apr 2006 09:47:15 -0400
Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FWvyc-00005O-Pn for ietf@ietf.org; Fri, 21 Apr 2006 09:47:15 -0400
Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.6/8.13.6) with ESMTP id k3LDlDnR090156 for <ietf@ietf.org>; Fri, 21 Apr 2006 14:47:13 +0100
Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k3LDluuH039152 for <ietf@ietf.org>; Fri, 21 Apr 2006 14:47:56 +0100
Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.13.3) with ESMTP id k3LDlDHt020263 for <ietf@ietf.org>; Fri, 21 Apr 2006 14:47:13 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id k3LDlDnM020256; Fri, 21 Apr 2006 14:47:13 +0100
Received: from zurich.ibm.com (sig-9-145-130-122.de.ibm.com [9.145.130.122]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id PAA72332; Fri, 21 Apr 2006 15:47:12 +0200
Message-ID: <4448E25F.6010109@zurich.ibm.com>
Date: Fri, 21 Apr 2006 15:47:11 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: Tony Hain <alh-ietf@tndh.net>
References: <09a401c664a7$c7ce9b40$d447190a@tndh.net>
In-Reply-To: <09a401c664a7$c7ce9b40$d447190a@tndh.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976
Cc: 'IETF Discussion' <ietf@ietf.org>
Subject: Re: [narten@us.ibm.com: PI addressing in IPv6 advances in ARIN]
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.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://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Errors-To: ietf-bounces@ietf.org

Tony Hain wrote:
> Brian E Carpenter wrote:
> 
>>... 
>>Scott Leibrand wrote:
>>..
>> > I agree, especially in the near term.  Aggregation is not required
>>right
>> > now, but having the *ability* to aggregate later on is a prudent risk
>> > reduction strategy if today's cost to do so is minimal (as I think it
>>is).
>>
>>I think that's an understatement until we find an alternative to
>>BGP aggregation. That's why my challenge to Iljistsch was to simulate
>>10B nodes and 100M sites - if we can't converge a reasonable sized
>>table for that network, we *know* we have a big problem in our
>>future. Not a risk - a certainty.
>>
> 
> 
> The problem with your challenge is the lack of a defined topology. The
> reality is that there is no consistency for topology considerations, so the
> ability to construct a routing model is limited at best. 

Actually my challenge asked for an assumed geographical distribution
and an assumed set of ISPs and interconnects, I believe. Obviously
one needs to know how robust the result is under reasonable variations
of the assumed topology.

> 
> The other point is that the protocol is irrelevant. Whatever we do the
> architectural problem is finding an aggregation strategy that fits a routing
> system in hardware that we know how to build, at a price point that is
> economically deployable. 

Yes, but BGP4 is a surrogate for that.
> 
> As far as I am concerned BGP is not the limitation. The problem is the ego
> driven myth of a single dfz where all of the gory details have to be exposed
> globally. If we abolish that myth and look at the problem we are left with
> an answer where BGP passing regional aggregates is sufficient.

I'm sorry, I don't think I've ever seen a convincing argument how such
aggregates could come to pass in the real world where inter-regional
bandwidth is partitioned at link level or dark fibre level. There just
isn'tany forcing function by which mathematically close prefixes
will become topologically close, because there's nothing that
forces multiple providers to share long-distance routes.

> Yes there
> will be exception routes that individual ISPs carry, but that is their
> choice not a protocol requirement. Complaining that regional aggregates are
> sub-optimal is crying wolf when they know they will eventually loose to the
> money holding customer demanding non-PA space. The outcries about doom and
> gloom with PI are really about random assignments which would be even less
> optimal. 
> 
> The fundamental question needs to be if there is an approach to address
> allocation that can be made to scale under -any- known business model, not
> just the one in current practice. It is not the IETFs job to define business
> models, rather to define the technology approaches that might be used and
> see if the market picks up on them. Unfortunately over the last few years
> the process has evolved to excluding discussions that don't fit in the
> current business models, despite the continuing arguments about how those
> models are financial failures and need to change. The point that Scott was
> making is that there are proposals for non-random assignments which could be
> carried as explicit's now and aggregated later.

I understand his point very well and I'm even in favour of it, because
statistically it can only help aggregation and certainly not damage it.
But I think that without some radically new principle it will at best
very slightly reduce randomness.

     Brian

> What we lack is a forum to
> evaluate the trade-off's. 
> 
> Tony 
> 
> 

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf