Re: [lisp] WG Last Call on draft-ietf-lisp-eid-block-mgmnt-02

Brian Haberman <brian@innovationslab.net> Wed, 08 October 2014 18:28 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79191ACE10 for <lisp@ietfa.amsl.com>; Wed, 8 Oct 2014 11:28:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEOQFOhkWsAO for <lisp@ietfa.amsl.com>; Wed, 8 Oct 2014 11:28:16 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D53201ACDF3 for <lisp@ietf.org>; Wed, 8 Oct 2014 11:28:15 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id AE85E880E2 for <lisp@ietf.org>; Wed, 8 Oct 2014 11:28:15 -0700 (PDT)
Received: from clemson.local (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 654451368186 for <lisp@ietf.org>; Wed, 8 Oct 2014 11:28:15 -0700 (PDT)
Message-ID: <54358237.5030405@innovationslab.net>
Date: Wed, 08 Oct 2014 14:28:07 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: lisp@ietf.org
References: <543538A8.30405@joelhalpern.com> <20141008111526504441.351ecc0f@sniff.de>
In-Reply-To: <20141008111526504441.351ecc0f@sniff.de>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="UUBP7O4QOh8juns4rw4U6MInfjBP8oxed"
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/RBovZqByUrdM7QrxnhCRkv_rSwM
Subject: Re: [lisp] WG Last Call on draft-ietf-lisp-eid-block-mgmnt-02
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Oct 2014 18:28:20 -0000

Hi Marc,

On 10/8/14 2:15 PM, Marc Binderberger wrote:
> Hello Joel, authors and lisp list,
> 
> while I think the document is overall reasonably written it has one problem: 
> it's bound to an proposed EID address block that has no guaranteed end of 
> life.
> 
> If this experiment would clearly terminate after 3+3 years then I would say 
> it's good to go. It's not the way the RIRs have written their documents but I 
> think that's okay for a experiment and a 6 year time frame. But the proposals 
> allow the requested /32 EID block to be turned into something permanently. 
> For a permanent EID block it's reasonable to assume the RIRs deal with the 
> allocation/assignment work ([1]) and then the document would need more 
> alignment with RIR policy documents. A simple example would be the language, 
> "allocation" is used throughout while "assignment" is only mentioned in the 
> Introduction. I checked both ARIN and RIPE and it's clearly defined there. 
> It's also going too far in telling IANA to not have a regional policy.
> 
> 
> So in short (and in all honesty): not feeling comfortable with the document 
> in the context of a potential permanent impact of the document.
> 

The eid-block draft (section 6,
https://tools.ietf.org/html/draft-ietf-lisp-eid-block-09#section-6)
discusses the transition to a degree if the allocation were to become
permanent.

The brief discussions I have had with RIR folks is that they would
expect allocations out of this address block to be managed by RIRs if it
were to become permanent.

Regards,
Brian

> 
> Regards, Marc
> 
> [1]: if the proposal is to have finally an additional authority beside the 
> RIRs for address allocation then I would reject the proposal. 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> On Wed, 08 Oct 2014 09:14:16 -0400, Joel M. Halpern wrote:
>> All,
>>
>> The work on the draft-ietf-lisp-eid-block-mgmnt-02 seems done and the 
>> authors requested a work group last call.
>>
>> This email starts a 14 day WG last call, to end CoB PDT October 22, 2014.
>>
>> You will find the document here:
>> http://www.ietf.org/id/draft-ietf-lisp-eid-block-mgmnt-02.txt
>>
>> Please review this WG document.  Let the working group know if you agree 
>> that it is ready for handing to the AD, or if you see issues with it. If 
>> you see issues, please be as specific as possible about the problems, and 
>> if possible suggest text to resolve them.
>>
>> Yours,
>> Joel
>>
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
>>
> 
> _______________________________________________
> lisp mailing list
> lisp@ietf.org
> https://www.ietf.org/mailman/listinfo/lisp
>