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

Brian E Carpenter <brian.e.carpenter@gmail.com> Fri, 20 August 2010 20:56 UTC

Return-Path: <brian.e.carpenter@gmail.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 7EE303A6AEF for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 13:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.477
X-Spam-Level:
X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 PGGUoDFESSba for <int-area@core3.amsl.com>; Fri, 20 Aug 2010 13:56:55 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 59B583A697B for <int-area@ietf.org>; Fri, 20 Aug 2010 13:56:55 -0700 (PDT)
Received: by vws10 with SMTP id 10so3743321vws.31 for <int-area@ietf.org>; Fri, 20 Aug 2010 13:57:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=mSaayfSJ5vIcfv/FfdXfQYKV68PalXD/TBj5W6eERo8=; b=ou/rPQI++D8wiE+rw5WpC/HM8lzU5BrUEjP86sbsp4G71mGriVdil/t/Rq3qLGW153 Nebth0/Vpk/cCx0fec0hia2mnc4xVqzIVJzbZV/3FoNzukwR+o9OGPtWyryjoUCVxqXK hilMTSr2mUln4rog8Py4AFkZ60ZuFxaTT2iVE=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=FHlxNf97qx2OsNBH4n0AFbSziE4tDbOUwNRZ3EiBGqqCt7XN8GD6uNgoEd40y6aS7j hl16l0Zk7tT1SlqAYreaWsbJLzs57Is4xxfw0/JW5t/kRQBdLIs+Qd8LCD2KsUtiJ2z9 vgpw/wrQjCO3JwWTmx13i4ENfwceHbG3zccf8=
Received: by 10.220.61.199 with SMTP id u7mr1263948vch.0.1282337848960; Fri, 20 Aug 2010 13:57:28 -0700 (PDT)
Received: from [10.1.1.4] ([121.98.142.15]) by mx.google.com with ESMTPS id e18sm1281932vcm.31.2010.08.20.13.57.26 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 13:57:28 -0700 (PDT)
Message-ID: <4C6EEC30.5010409@gmail.com>
Date: Sat, 21 Aug 2010 08:57:20 +1200
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Organization: University of Auckland
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: "Joel M. Halpern" <jmh@joelhalpern.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> <4C6EE9D9.2090003@joelhalpern.com>
In-Reply-To: <4C6EE9D9.2090003@joelhalpern.com>
Content-Type: text/plain; charset="UTF-8"
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:56:56 -0000

On 2010-08-21 08:47, Joel M. Halpern wrote:
> 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.

Yes. That's why there is a strong recommendation to people
developing site addressing plans to use only the longest
possible sub-prefix of their PA prefix, in case they later
change to another ISP who gives them less PA 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.

There certainly should not be a MUST. In any case, the RIRs and ISPs would
ignore it. The /48 doctrine crashed and burned among the RIRs and ISPs
some years ago; 3177bis recognizes this reality.

    Brian

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