Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

"Joel M. Halpern" <jmh@joelhalpern.com> Fri, 20 August 2010 20:46 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: int-area@core3.amsl.com
Delivered-To: int-area@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D7F53A69ED for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 13:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.467
X-Spam-Level:
X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 5VklrthweqrG for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 13:46:49 -0700 (PDT)
Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 343513A6A06 for <int-area@ietf.org>; Fri, 20 Aug 2010 13:46:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 0553E3236DCA; Fri, 20 Aug 2010 13:47:24 -0700 (PDT)
X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net
Received: from [10.10.10.101] (pool-71-161-50-158.clppva.btas.verizon.net [71.161.50.158]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 1B9683236DC6; Fri, 20 Aug 2010 13:47:22 -0700 (PDT)
Message-ID: <4C6EE9D9.2090003@joelhalpern.com>
Date: Fri, 20 Aug 2010 16:47:21 -0400
From: "Joel M. Halpern" <jmh@joelhalpern.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
References: <D74F3837-E115-49FB-A9AB-5E0C53406621@tony.li> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E62F@EUSAACMS0701.eamcs.ericsson.se> <188C11C5-CDBA-4213-83AC-453AE06ADAD5@cisco.com> <4C6EE713.9080805@gmail.com>
In-Reply-To: <4C6EE713.9080805@gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: IPv6 Operations <v6ops@ops.ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/int-area>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Aug 2010 20:46:50 -0000

There does seem to be one significant benefit for being able to get the 
same size block from different providers.
If you have used one size, and change providers, if the prefix length 
gets longer, you have to rework your plan.  And if it gets shorter, but 
you don't rework your plan, you are wasting a LOT of space.

This does not mean that there should be one size for all cases.On the 
other hand, telling operators that they must offer four different sizes 
to all their customers (/48, /52, /56 and /60) makes the operator 
bookkeeping harder, at the very least.

Yours,
Joel

Brian E Carpenter wrote:
> On 2010-08-21 08:23, Fred Baker wrote:
>> On Aug 20, 2010, at 12:49 PM, Eric Gray wrote:
>>
>>> 	Having multiple chunk sizes seems to me to be a recipe for in-
>>> efficient use of address space in general.  
>> speaking for myself, I think a one-size-fits-all model has the same effect. In my home, today, I have two LANs; I could easily imagine expanding that to half a dozen or even a dozen in various scenarios. Giving me a /48 is a waste of address space - it's at least 4096 times as much as I need, and would give my upstream the ability to address 4095 more homes like mine if they were to allocate /60's. To the extent that they are paying their RIR for address space, er, membership, it wastes their money and increases my monthly payment. 
>>
>> I think there is a great reason to suggest that access and transit networks to offer their downstreams /48, /52, /56, and /60 options at various costs. It makes business sense for them, allows them to reasonably recover their costs without burdening the downstreams, allows for downstreams to number their networks in ways they like and reasonably move up to shorter prefixes when they need to, and (since I didn't mention /64) ensures that the smallest users - residential/SOHO - have options for routing within the home as appropriate.
> 
> Another +1 to Fred. I was originally a strong advocate of Eric's view,
> in fact I take credit/blame for a lot of RFC3177, but I believe that
> experience, especially the remarkable success of CIDR in controlling
> the growth of PA routes for IPv4, and the acquired wisdom of the RIRs
> in administering CIDR, have shown that there is no efficiency benefit
> in fixed chunks.
> 
>     Brian
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>