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

Eric Gray <eric.gray@ericsson.com> Fri, 20 August 2010 20:46 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 8483E3A697B for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 13:46:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.576
X-Spam-Level:
X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 0vvSMYccBKBG for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 13:46:46 -0700 (PDT)
Received: from imr4.ericy.com (imr4.ericy.com [198.24.6.8]) by core3.amsl.com (Postfix) with ESMTP id 466C53A6955 for <int-area@ietf.org>; Fri, 20 Aug 2010 13:46:46 -0700 (PDT)
Received: from eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) by imr4.ericy.com (8.14.3/8.14.3/Debian-9.1ubuntu1) with ESMTP id o7KKpk9R014618; Fri, 20 Aug 2010 15:51:52 -0500
Received: from EUSAACMS0701.eamcs.ericsson.se ([169.254.1.39]) by eusaamw0711.eamcs.ericsson.se ([147.117.20.178]) with mapi; Fri, 20 Aug 2010 16:46:52 -0400
From: Eric Gray <eric.gray@ericsson.com>
To: Fred Baker <fred@cisco.com>
Date: Fri, 20 Aug 2010 16:46:50 -0400
Thread-Topic: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
Thread-Index: ActApaKXZXf6Nl75R6S7kan3D7rc1gAAjlyQ
Message-ID: <C0AC8FAB6849AB4FADACCC70A949E2F1058062E6B0@EUSAACMS0701.eamcs.ericsson.se>
References: <D74F3837-E115-49FB-A9AB-5E0C53406621@tony.li> <C0AC8FAB6849AB4FADACCC70A949E2F1058062E62F@EUSAACMS0701.eamcs.ericsson.se> <188C11C5-CDBA-4213-83AC-453AE06ADAD5@cisco.com>
In-Reply-To: <188C11C5-CDBA-4213-83AC-453AE06ADAD5@cisco.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 20:46:47 -0000

Fred,

	I see what you mean, but I had the impression that I would not
(as a home-owner, at least) be getting my allocation from a top level
address space.  But I think I see the point of your argument now.

	Thanks for the clarification.

--
Eric 

-----Original Message-----
From: Fred Baker [mailto:fred@cisco.com] 
Sent: Friday, August 20, 2010 4:24 PM
To: Eric Gray
Cc: Tony Li; IPv6 Operations; int-area@ietf.org
Subject: Re: [Int-area] Review of draft-narten-ipv6-3177bis-48boundary-05
Importance: High


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.