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

Rémi Després <remi.despres@free.fr> Thu, 02 September 2010 07:58 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 2CEB23A6A77 for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 2 Sep 2010 00:58:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.032
X-Spam-Level:
X-Spam-Status: No, score=-0.032 tagged_above=-999 required=5 tests=[AWL=-0.683, 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 v2z8XydiBq2q for <ietfarch-v6ops-archive@core3.amsl.com>; Thu, 2 Sep 2010 00:58:11 -0700 (PDT)
Received: from psg.com (psg.com [IPv6:2001:418:1::62]) by core3.amsl.com (Postfix) with ESMTP id 336E33A6908 for <v6ops-archive@lists.ietf.org>; Thu, 2 Sep 2010 00:58:11 -0700 (PDT)
Received: from majordom by psg.com with local (Exim 4.72 (FreeBSD)) (envelope-from <owner-v6ops@ops.ietf.org>) id 1Or4g4-000MrK-Ph for v6ops-data0@psg.com; Thu, 02 Sep 2010 07:57:44 +0000
Received: from smtp24.services.sfr.fr ([93.17.128.81]) by psg.com with esmtp (Exim 4.72 (FreeBSD)) (envelope-from <remi.despres@free.fr>) id 1Or4fy-000Mq7-BK for v6ops@ops.ietf.org; Thu, 02 Sep 2010 07:57:38 +0000
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
Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
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
Cc: Fred Baker <fred@cisco.com>, Eric Gray <eric.gray@ericsson.com>, IPv6 Operations <v6ops@ops.ietf.org>, "int-area@ietf.org" <int-area@ietf.org>
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)
Sender: owner-v6ops@ops.ietf.org
Precedence: bulk
List-ID: <v6ops.ops.ietf.org>

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