Re: draft-azinger-cidrv6-00

Tony Li <tony.li@tony.li> Thu, 22 July 2010 08:20 UTC

Return-Path: <owner-v6ops@ops.ietf.org>
X-Original-To: ietfarch-v6ops-archive@core3.amsl.com
Delivered-To: ietfarch-v6ops-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872353A69DD for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 22 Jul 2010 01:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.097
X-Spam-Level:
X-Spam-Status: No, score=-1.097 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
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 s8SjBUs3yJlx for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 22 Jul 2010 01:20:13 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 07B503A69D1 for <v6ops-archive@lists.ietf.org>; Thu, 22 Jul 2010 01:20:12 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Obqqv-0001FF-4w for v6ops-data0@psg.com; Thu, 22 Jul 2010 08:10:01 +0000
Received: from [76.96.27.228] (helo=qmta15.emeryville.ca.mail.comcast.net) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <tony.li@tony.li>) id 1Obqqs-0001Ef-Ok for v6ops@ops.ietf.org; Thu, 22 Jul 2010 08:09:58 +0000
Received: from omta07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by qmta15.emeryville.ca.mail.comcast.net with comcast id kw9W1e0021GXsucAFw9wB5; Thu, 22 Jul 2010 08:09:56 +0000
Received: from sjc-vpn7-614.cisco.com ([128.107.239.233]) by omta07.emeryville.ca.mail.comcast.net with comcast id kw9h1e00152qHCY8Uw9kkd; Thu, 22 Jul 2010 08:09:54 +0000
Subject: Re: draft-azinger-cidrv6-00
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Tony Li <tony.li@tony.li>
In-Reply-To: <4C477CC7.3040604@inex.ie>
Date: Thu, 22 Jul 2010 10:09:40 +0200
Cc: Leo Vegoda <leo.vegoda@icann.org>, IPv6 Operations <v6ops@ops.ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <E1626B04-D81C-466C-9D18-AC1690FADB1C@tony.li>
References: <564F70D7-8290-4E93-BD57-1AB577329CAF@icann.org> <4C477CC7.3040604@inex.ie>
To: Nick Hilliard <nick@inex.ie>
X-Mailer: Apple Mail (2.1081)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

Hi Nick,

>> Also, in section 10 it is recommended that "Internet Registries
>> should severely limit or eliminate [...] PI assignments".
> 
> RIRs carry out the policies set by their constituents, and cannot arbitrarily limit assignments unless there is scope within their policies to do so


The whole point is to give the RIRs the technical requirements so that they can set effective policies.


> In addition, until such time as there is a viable alternative for end-user multi-homing in ipv6, I'm not sure if making a recommendation like section 10 is actually going to achieve anything - other than raising eyebrows.


As you may know, there are several proposals being discussed.  Our point is to raise the issue with RIRs and ensure that they understand that this technology is becoming available.


> Section 5.2: Projections.
> 
> Um, I don't believe that a projection for 2040 adds anything here.  As the authors note, an S curve seems more likely at this stage, so adding an arbitrary number which is a similar order of magnitude to the population of the earth doesn't really lend credibility to the table :-)


Again, we are not claiming that this will be the growth rate.  We are simply pointing out the mathematical implications of a sustained 54% rate.  The number is not arbitrary in the least, it simply shows the implications of where we might be in 30 years.


> Section 5.1: Analysis.
> 
>>   Thus, the bulk of the routing table growth appears to be due to PI
>>   prefix injection.
> 
> No doubt it is.  Provider level aggregation will ensure that the N provider associated prefixes that most providers have been allocated today will be be reduced to 1.  Would it be useful to adopt a potential modeling premise that posits that most PI ipv4 holders today will take out an ipv6 block in the future, and see where that leads?


Obviously, that leads us to a baseline of 350K routes.  If done quickly, that would accelerate the growth rate.


> Section 5:  it may be useful to flesh out traffic engineering issues here.  This has the potential to increase prefix numbers from 1 back to N, and my gut feeling is that this is going be the #2 prefix source after PI.


I concur that it will be a contributor.  TE is already discussed in the problem statement (draft-narten-radir-problem-statement-05).

Tony