Re: v6ops-addcon and longer than 64 bit prefixes

Jari Arkko <jari.arkko@piuha.net> Tue, 07 October 2008 04:17 UTC

Return-Path: <ipv6-bounces@ietf.org>
X-Original-To: ipv6-archive@megatron.ietf.org
Delivered-To: ietfarch-ipv6-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB97C3A6859; Mon, 6 Oct 2008 21:17:15 -0700 (PDT)
X-Original-To: ipv6@core3.amsl.com
Delivered-To: ipv6@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53EF73A699E for <ipv6@core3.amsl.com>; Mon, 6 Oct 2008 21:17:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.309
X-Spam-Level:
X-Spam-Status: No, score=-2.309 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, J_CHICKENPOX_13=0.6]
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 Zl72EZRfH0Ak for <ipv6@core3.amsl.com>; Mon, 6 Oct 2008 21:17:13 -0700 (PDT)
Received: from smtp.piuha.net (p130.piuha.net [IPv6:2001:14b8:400::130]) by core3.amsl.com (Postfix) with ESMTP id 8F62D3A684D for <ipv6@ietf.org>; Mon, 6 Oct 2008 21:17:12 -0700 (PDT)
Received: from smtp.piuha.net (localhost [127.0.0.1]) by smtp.piuha.net (Postfix) with ESMTP id D44C2198772; Tue, 7 Oct 2008 07:17:49 +0300 (EEST)
Received: from [127.0.0.1] (unknown [IPv6:2001:14b8:400::130]) by smtp.piuha.net (Postfix) with ESMTP id 17DD2198661; Tue, 7 Oct 2008 07:17:46 +0300 (EEST)
Message-ID: <48EAB95A.6060307@piuha.net>
Date: Mon, 06 Oct 2008 18:20:26 -0700
From: Jari Arkko <jari.arkko@piuha.net>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Subject: Re: v6ops-addcon and longer than 64 bit prefixes
References: <48DB374B.1000308@piuha.net> <016e01c91f3f$b578bfc0$206a3f40$@net> <7988FFFC-E33E-4F16-9F37-551B47400403@cisco.com> <f1110c510809281355lc493589qdd9831b6ecb978a2@mail.gmail.com> <48DFF88E.9060006@gmail.com> <856B079E-5B60-4449-84D4-ED7DC4F30FDE@cisco.com> <2E2FECEBAE57CC4BAACDE67638305F1048122456B1@ROCH-EXCH1.corp.pvt> <48E288B3.8080700@gmail.com>
In-Reply-To: <48E288B3.8080700@gmail.com>
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: IETF IPv6 Mailing List <ipv6@ietf.org>, Ron Bonica <rbonica@juniper.net>, Pasi Eronen <Pasi.Eronen@nokia.com>, "draft-ietf-v6ops-addcon@tools.ietf.org" <draft-ietf-v6ops-addcon@tools.ietf.org>, Fred Baker <fred@cisco.com>, "alh-ietf@tndh.net" <alh-ietf@tndh.net>, V6ops Chairs <v6ops-chairs@tools.ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"
Sender: ipv6-bounces@ietf.org
Errors-To: ipv6-bounces@ietf.org

It is not a recommendation, as long as the "e.g." part is in the text. 
And it already is, so no problem. (But Tony's and Fred's suggested edits 
certainly deserve to be taken into account.)

Jari

Brian E Carpenter wrote:
> Marla,
>
> In what sense is "(e.g. on a basis of /48)" a recommendation?
>
>    Brian
>
> On 2008-10-01 04:09, Azinger, Marla wrote:
>   
>> My point with all of this is that I don't see it proper for IETF documents to reflect or suggest anything other than a technical boundary.  Neither /48 or /56 are technical boundaries and they shouldn't be put in an IETF document as a recommendation just because its the "flavor" of an RIR for the current year or because it just sounds good.
>>
>> I am asking all of you to stick to factual technical aspects.  The minute a subnet is written into an IETF document as a "recommendation" it limits RIR policy in the future due to ignorance.  RIR communities historically have taken the word "recommendation" as a warning sign that if you go more or less specific with a subnet you would venture into a technical issue.  And then it turns into a painful game of trying to change RIR policy or IETF documentation once reality hits that the "recommended" subnet had no technical significance, or more experience was gained and what was thought to be technically true turns out not to be.
>>
>> What the world needs are documents that point out factual boundaries.  And if there aren't any then point that out as well.  But the last thing we need is another IETF document that inserted selected subnet sizes without technical significance.  This very reason is why the ARIN RIR is messed up and has /32 as the Allocation size due to an IETF document that "recommended" /32 without any technical basis.
>>
>> I caution any use of a specific subnet size unless its pointing out a known technical barrier.
>>
>> Thank you
>> Marla Azinger
>> Frontier Communications
>> ARIN AC
>>
>> -----Original Message-----
>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Fred Baker
>> Sent: Tuesday, September 30, 2008 4:02 AM
>> To: Brian E Carpenter
>> Cc: IETF IPv6 Mailing List; Ron Bonica; Pasi Eronen; draft-ietf-v6ops-addcon@tools.ietf.org; alh-ietf@tndh.net; V6ops Chairs
>> Subject: Re: v6ops-addcon and longer than 64 bit prefixes
>>
>> If the registries are using /56, why recommend what they have tried and found wanting?
>>
>> On Sep 28, 2008, at 5:35 PM, Brian E Carpenter wrote:
>>
>>     
>>> /56 is a choice currently used by the registries. That doesn't
>>> invalidate using /48, if you consider that to be a more interesting
>>> allocation unit to consider. So I don't see a problem with "(e.g. on a
>>> basis of /48)".
>>>
>>>    Brian
>>>
>>> On 2008-09-29 09:55, Turchanyi Geza wrote:
>>>       
>>>> Colleagues,
>>>>
>>>> Ooops,
>>>>
>>>> HD is calculated for prefixes, but on the basis of /56
>>>>
>>>> (since November 2007)
>>>>
>>>> Please see
>>>>
>>>> http://www.ripe.net/ripe/docs/ripe-421.html#utilisation
>>>>
>>>> Best,
>>>>
>>>> Geza
>>>>
>>>>
>>>>
>>>> On Fri, Sep 26, 2008 at 8:21 AM, Fred Baker <fred@cisco.com> wrote:
>>>>         
>>>>> nit on the nit...
>>>>>
>>>>> HD is calculated for prefixes (e.g. on a basis of /48), instead of
>>>>> *being*
>>>>> based on endpoint addresses as IPv4 is.
>>>>>
>>>>> (the second part needed a verb)
>>>>>
>>>>> On Sep 25, 2008, at 12:51 PM, Tony Hain wrote:
>>>>>
>>>>>           
>>>>>> Wording nit in 2.4.2
>>>>>> Current:
>>>>>> HD is calculated for sites (e.g. on a basis of /48), instead of
>>>>>> based on addresses like with IPv4 should read:
>>>>>> HD is calculated for prefixes (e.g. on a basis of /48), instead of
>>>>>> based on endpoint addresses like with IPv4
>>>>>>
>>>>>>
>>>>>> It is not clear that the 6bone space discussion is appropriate for
>>>>>> this document, and restating what is effectively a policy will
>>>>>> cause a problem in the future. Removing the last sentence of 2. and
>>>>>> all of 2.3 will not impact the intent of this document. Given that
>>>>>> the stated target audience is network managers that have not
>>>>>> figured out an IPv6 addressing plan, confusing them with a
>>>>>> discussion about ancient history is not helpful.
>>>>>>
>>>>>> Tony
>>>>>>
>>>>>>
>>>>>>             
>>>>>>> -----Original Message-----
>>>>>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On
>>>>>>> Behalf Of Jari Arkko
>>>>>>> Sent: Thursday, September 25, 2008 12:02 AM
>>>>>>> To: IETF IPv6 Mailing List
>>>>>>> Cc: draft-ietf-v6ops-addcon@tools.ietf.org; V6ops Chairs; Pasi
>>>>>>> Eronen; Ron Bonica
>>>>>>> Subject: v6ops-addcon and longer than 64 bit prefixes
>>>>>>>
>>>>>>> Folks,
>>>>>>>
>>>>>>> Draft-ietf-v6ops-addcon was in IESG review and there was a lot of
>>>>>>> discussion about the recommendations an earlier version of the
>>>>>>> draft had about prefix lengths longer than 64 bits. The draft has
>>>>>>> now been revised to what we believe is reasonably consistent with
>>>>>>> reality and existing
>>>>>>> IPv6 address architecture RFCs. However, it would be good to give
>>>>>>> the 6MAN WG a chance to review the text.
>>>>>>>
>>>>>>> Please take a look at the document and the given two sections in
>>>>>>> particular:
>>>>>>>
>>>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10
>>>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10#section-3.1
>>>>>>> http://tools.ietf.org/html/draft-ietf-v6ops-addcon-10#appendix-B
>>>>>>>
>>>>>>> If there is no objection the draft will be approved. Please
>>>>>>> comment by September 30th.
>>>>>>>
>>>>>>> Jari
>>>>>>>
>>>>>>> ------------------------------------------------------------------
>>>>>>> -- IETF IPv6 working group mailing list ipv6@ietf.org
>>>>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/
>>>>>>> ipv6
>>>>>>> ------------------------------------------------------------------
>>>>>>> --
>>>>>>>               
>>>>>> -------------------------------------------------------------------
>>>>>> - IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>>> -------------------------------------------------------------------
>>>>>> -
>>>>>>             
>>>>> --------------------------------------------------------------------
>>>>> IETF IPv6 working group mailing list ipv6@ietf.org Administrative
>>>>> Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>>> --------------------------------------------------------------------
>>>>>
>>>>>           
>>>> --------------------------------------------------------------------
>>>> IETF IPv6 working group mailing list
>>>> ipv6@ietf.org
>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>>> --------------------------------------------------------------------
>>>>
>>>>         
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
>>
>>     
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>
>
>   


--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------