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

Eric Gray <eric.gray@ericsson.com> Fri, 20 August 2010 21:55 UTC

Return-Path: <eric.gray@ericsson.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 5FA7F3A6867 for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 14:55:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.58
X-Spam-Level:
X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599]
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 08v4mxslKAkg for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 14:55:17 -0700 (PDT)
Received: from imr3.ericy.com (imr3.ericy.com [198.24.6.13]) by core3.amsl.com (Postfix) with ESMTP id 589BF3A67FB for <int-area@ietf.org>; Fri, 20 Aug 2010 14:55:17 -0700 (PDT)
Received: from eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) by imr3.ericy.com (8.13.8/8.13.8) with ESMTP id o7KLtojv004419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 20 Aug 2010 16:55:50 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.39]) by eusaamw0712.eamcs.ericsson.se ([147.117.20.181]) with mapi; Fri, 20 Aug 2010 17:55:49 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: Brian E Carpenter <brian.e.carpenter@gmail.com>, Fred Baker <fred@cisco.com>
Date: Fri, 20 Aug 2010 17:55:47 -0400
Thread-Topic: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
Thread-Index: ActAp1ivnJ6BtBjZTc6v5A4iXupRcgACn9lg
Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F1058062E716@EUSAACMS0701.eamcs.ericsson.se>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 21:55:18 -0000

Brian,

	Thanks for "dating" my opinion.  :-)

	CIDR would be a good model for this case - except that,
practically speaking CIDR with IPv4 really only left you with
something like 17 different sizes for address allocation, of 
which many were not very useful.

	Following the CIDR model for IPv6 seems to allow for as
many as (on the order of) 7-10 times as many possibly usable
address allocation sizes.

	That might suggest some weakness in the analogy...

--
Eric 

-----Original Message-----
From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] 
Sent: Friday, August 20, 2010 4:36 PM
To: Fred Baker
Cc: Eric Gray; IPv6 Operations; int-area@ietf.org
Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05

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