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

Marc Binderberger <marc@sniff.de> Mon, 13 October 2014 20:30 UTC

Return-Path: <marc@sniff.de>
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 3A5DC1A0040 for <lisp@ietfa.amsl.com>; Mon, 13 Oct 2014 13:30:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.336
X-Spam-Level:
X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 JwrDLPr0NyBd for <lisp@ietfa.amsl.com>; Mon, 13 Oct 2014 13:30:51 -0700 (PDT)
Received: from door.sniff.de (door.sniff.de [IPv6:2001:6f8:94f:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id A1C5C1A001A for <lisp@ietf.org>; Mon, 13 Oct 2014 13:30:50 -0700 (PDT)
Received: from [IPv6:::1] (localhost.sniff.de [127.0.0.1]) by door.sniff.de (Postfix) with ESMTP id 190672AA0F; Mon, 13 Oct 2014 20:30:46 +0000 (GMT)
Date: Mon, 13 Oct 2014 13:31:08 -0700
From: Marc Binderberger <marc@sniff.de>
To: David Conrad <drc@virtualized.org>
Message-ID: <20141013133108150663.45ab5a31@sniff.de>
In-Reply-To: <5109D77D-96A0-4796-A646-7A11DC68CC24@virtualized.org>
References: <543538A8.30405@joelhalpern.com> <20141008111526504441.351ecc0f@sniff.de> <54358282.30905@joelhalpern.com> <20141008114923108851.765e002a@sniff.de> <5109D77D-96A0-4796-A646-7A11DC68CC24@virtualized.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: base64
X-Mailer: GyazMail version 1.5.15
Archived-At: http://mailarchive.ietf.org/arch/msg/lisp/On7Ax88xvF9zqP3XV51Xpwwn8L8
Cc: Roger Jorgensen <rogerj@gmail.com>, "lisp@ietf.org" <lisp@ietf.org>
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: Mon, 13 Oct 2014 20:30:58 -0000

Hello David,

> for hierarchy. The policies and processes appropriate for the allocation of 
> IP addresses do not appear to me to necessarily be applicable to the 
> allocation of LISP EIDs.

That's interesting - where do you see a problem?
There is no aggregation today beyond the "RA allocation block". Assignments 
within the RA block do not have to follow any additional aggregation scheme 
(to be fair, depends on the internal routing setup details).


> scalability of the routing system.  LISP EIDs do not have any requirement 
> for hierarchy.

I actually think this statement in it's generic form is wrong.  This may be 
related to the impression I have that people on the list think they know in 
principle how LISP can solve the scale problem - at least from the published 
documents I think a lot of aspects have not been discussed at all.


> allocation of LISP EIDs.  If LISP is successful, whether the RIRs choose to 
> become LISP EID allocators is likely a business decision they’ll need to 
> make.  I personally do not think it appropriate to assume they will make 
> that decision.

If the goal is to run a separate LISP Internet then you may have a point. But 
I think officially we still aim at a LISP deployment that blends into the 
existing Internet.


To summarize my points again: as long as we talk about prefixes being 
announces in today's global BGP table I expect a definite end of the test and 
it's rules and a complete cleanup at the end of the test. Both is "somehow" 
written in the document but not as simple, clean & crisp as it could be, 
IMHO. Thus my proposal for some re-wording.



Regards, Marc





On Wed, 8 Oct 2014 13:12:03 -0700, David Conrad wrote:
> Marc,
> 
> On Oct 8, 2014, at 11:49 AM, Marc Binderberger <marc@sniff.de> wrote:
>> Let me word it differently: the EID block as a sandbox for a large-scale, 
>> real-life experiment to learn how LISP becomes (or is already) 
>> production-ready for the Internet - great idea.
> 
> Sure.
> 
>> Beyond that I don't see a 
>> need for anything special or different for LISP and we have working 
>> procedures how to allocate/assign address space. This is also the promise, 
>> that LISP is blending in.
> 
> IP addresses allocated by the RIRs assume hierarchy to facilitate the 
> scalability of the routing system.  LISP EIDs do not have any requirement 
> for hierarchy. The policies and processes appropriate for the allocation of 
> IP addresses do not appear to me to necessarily be applicable to the 
> allocation of LISP EIDs.  If LISP is successful, whether the RIRs choose to 
> become LISP EID allocators is likely a business decision they’ll need to 
> make.  I personally do not think it appropriate to assume they will make 
> that decision.
> 
> Regards,
> -drc
>