Re: [lisp] LISP EID Block Size

Geoff Huston <gih@apnic.net> Thu, 31 October 2013 21:36 UTC

Return-Path: <gih@apnic.net>
X-Original-To: lisp@ietfa.amsl.com
Delivered-To: lisp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE1D621E8063 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 14:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.443
X-Spam-Level:
X-Spam-Status: No, score=-99.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mq5Yho-0ed87 for <lisp@ietfa.amsl.com>; Thu, 31 Oct 2013 14:36:40 -0700 (PDT)
Received: from so-mailgw.apnic.net (so-mailgw.apnic.net [IPv6:2001:dd8:a:3::230]) by ietfa.amsl.com (Postfix) with SMTP id C2D8E11E81BB for <lisp@ietf.org>; Thu, 31 Oct 2013 14:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apnic.net; s=c3po; h=received:received:received:content-type:mime-version:subject:from:in-reply-to: date:cc:content-transfer-encoding:message-id:references:to:x-mailer: return-path; bh=6MF7B0rLM6drLvkP2trehtgA/YvDC1J7Hb4a4KceAtM=; b=jcZhd/C3mzCNeRyb0ikhZ9aHqBUzsTi2HRf0d36jmONSyaYCbVDn1wotjK0+Ndfv0VDoR2KENvbHj vRHE9oy1edy5uOc7FpvyXZQmvBYaiL5Sq/Q/gjh7iuNKq0Ngx0Aea+vdWExWr6k5nycYq65fUQLS2m 2EPifMZ+4vOnzLEI=
Received: from IAMDA1.org.apnic.net (unknown [203.119.93.247]) by so-mailgw.apnic.net (Halon Mail Gateway) with ESMTP; Fri, 1 Nov 2013 07:36:31 +1000 (EST)
Received: from IAMDA2.org.apnic.net (2001:dd8:a:852::21) by IAMDA1.org.apnic.net (2001:dd8:a:852:f9ce:d66e:c64d:3db2) with Microsoft SMTP Server (TLS) id 14.1.421.2; Fri, 1 Nov 2013 07:36:31 +1000
Received: from [10.2.47.242] (203.119.101.249) by IAMDA2.org.apnic.net (203.119.111.21) with Microsoft SMTP Server (TLS) id 14.1.438.0; Fri, 1 Nov 2013 07:36:31 +1000
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Geoff Huston <gih@apnic.net>
In-Reply-To: <E6AD700C-DC48-48DB-9FF5-A24C6121834C@gmail.com>
Date: Fri, 1 Nov 2013 08:36:30 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <D68CD130-50BC-42AE-95E5-A4EBEEB20808@apnic.net>
References: <20131030154454.587D918C143@mercury.lcs.mit.edu> <15CC7F54-075E-4EB8-940B-8DCB198134A2@apnic.net> <E6AD700C-DC48-48DB-9FF5-A24C6121834C@gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
X-Mailer: Apple Mail (2.1816)
Cc: Noel Chiappa <jnc@mercury.lcs.mit.edu>, LISP mailing list list <lisp@ietf.org>
Subject: Re: [lisp] LISP EID Block Size
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 31 Oct 2013 21:36:46 -0000

On 31 Oct 2013, at 11:57 pm, Dino Farinacci <farinacci@gmail.com> wrote:

> Geoff, LISP can route the entire allocated address space (but just not requires it to be everywhere). So arguably, LISP can do this at much cheaper cost and complexity.
> 
> The reason for a dedicated block is similar to why we have an address block for IPv4 and IPv6 multicast. To experiment to see if a hard-coded block can provide any interesting ideas.


On the LISP page I already see LISP using IPv4 and IPv6 blocks for this experiment. So what have you found out already in terms of "interesting ideas"? What do you think that a larger block would inform you that is not possible with the existing block?

(using /56 end site prefixes a /32 can accommodate 16,777,216 end sites of course, and even at a 10% utilisation level thats 1.7 million end sites. So I;'m kinds mystified why a .32 can't tell you about scaling given that we are talking of the order of 10**6 end sites within such a block.)

> That part is the experiment, not whole of LISP proper.
> 

As I said already,  "Why do I feel that this experiment has not been well thought through?"

I would love to see a clear lucid description of the "experiment" in terms of the space to be investigated and the reasons why this form of investigation requires this kind of address allocation. So far I have seen nothing that talks to me in terms of a solid experiment proposal.

Geoff


> Dino
> 
> On Oct 30, 2013, at 10:02 PM, Geoff Huston <gih@apnic.net> wrote:
> 
>> On 31 Oct 2013, at 2:44 am, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>> 
>>>> From: Luigi Iannone <ggx@gigix.net>
>>> 
>>>> Yet, one of the main critics during the review was about the size of
>>>> the block which seems too large.
>>> 
>>> System Architecture Rule #1:
>>> 
>>> Any Fixed-Size Namespace Will Eventually Be Too Small
>>> 
>>> Given that a /12 represents .025% of the IPv6 namespace, _if_ LISP becomes a
>>> huge sucess, we're more likely to run into SAR #1; and if LISP does not
>>> become etc, are they really going to miss .025% of a namespace?
>>> 
>>>> Any thought about a change in the requested EID block size?
>>> 
>>> I think we got it right the first time.
>>> 
>> 
>> I don't understand this line of reasoning Noel. 
>> 
>> BGP is a huge success - it appears to route 100% of the address space. If LISP 
>> becomes a huge success then why wouldn't it route 100% of the address space, just
>> as BGP does today? And if it withers and dies then any dedicated address
>> allocation will be too much at that point in time. If this is all about an 
>> _experiment_ under some form of  experimental constraint then what are the
>> bounds of the experiment? What happens at the end of the experiment? Why would there 
>> be a continuing need to corral LISP into its own dedicated corner of the address
>> space? Is there something about scaling LISP to a full unicast routing scale that
>> simply does not work? Or is corralling of LISP into a dedicated block  of addresses
>> unnecessary? Why do I feel that this experiment has not been well thought through?
>> Or if it has, then it seems to me that the mapping of parameters of the proposed
>> experiment into the words in the two drafts relating to this proposed action
>> is still lacking.
>> 
>> regards,
>> 
>>   Geoff
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> lisp mailing list
>> lisp@ietf.org
>> https://www.ietf.org/mailman/listinfo/lisp
>