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

Rémi Després <remi.despres@free.fr> Thu, 02 September 2010 07:57 UTC

Return-Path: <remi.despres@free.fr>
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 454ED3A6908 for <int-area@core3.amsl.com>; Thu, 2 Sep 2010 00:57:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.052
X-Spam-Level:
X-Spam-Status: No, score=-0.052 tagged_above=-999 required=5 tests=[AWL=-0.703, BAYES_50=0.001, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3]
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 i8KxrrmHkr-6 for <int-area@core3.amsl.com>; Thu, 2 Sep 2010 00:57:06 -0700 (PDT)
Received: from smtp24.services.sfr.fr (smtp24.services.sfr.fr [93.17.128.81]) by core3.amsl.com (Postfix) with ESMTP id 263C13A6A5D for <int-area@ietf.org>; Thu, 2 Sep 2010 00:57:06 -0700 (PDT)
Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 0D0F7700008F; Thu, 2 Sep 2010 09:57:36 +0200 (CEST)
Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2403.sfr.fr (SMTP Server) with ESMTP id 318A7700008E; Thu, 2 Sep 2010 09:57:35 +0200 (CEST)
X-SFR-UUID: 20100902075735203.318A7700008E@msfrf2403.sfr.fr
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Rémi Després <remi.despres@free.fr>
In-Reply-To: <4C6EE713.9080805@gmail.com>
Date: Thu, 02 Sep 2010 09:57:33 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <470D3DC2-1F9F-46D5-B73E-A12C48A82EA6@free.fr>
References: <D74F3837-E115-49FB-A9AB-5E0C53406621@tony.li> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E62F@EUSAACMS0701.eamcs.ericsson.se> <188C11C5-CDBA-4213-83AC-453AE06ADAD5@cisco.com> <4C6EE713.9080805@gmail.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
X-Mailer: Apple Mail (2.1081)
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: Thu, 02 Sep 2010 07:57:07 -0000

+1

Le 20 août 2010 à 22:35, Brian E Carpenter a écrit :

> 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
>