Re: [lisp] LISP EID Block Size

Geoff Huston <> Thu, 31 October 2013 21:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE1D621E8063 for <>; Thu, 31 Oct 2013 14:36:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.443
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mq5Yho-0ed87 for <>; Thu, 31 Oct 2013 14:36:40 -0700 (PDT)
Received: from ( [IPv6:2001:dd8:a:3::230]) by (Postfix) with SMTP id C2D8E11E81BB for <>; Thu, 31 Oct 2013 14:36:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 (unknown []) by (Halon Mail Gateway) with ESMTP; Fri, 1 Nov 2013 07:36:31 +1000 (EST)
Received: from (2001:dd8:a:852::21) by (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 [] ( by ( 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 <>
In-Reply-To: <>
Date: Fri, 1 Nov 2013 08:36:30 +1100
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <> <> <>
To: Dino Farinacci <>
X-Mailer: Apple Mail (2.1816)
Cc: Noel Chiappa <>, LISP mailing list list <>
Subject: Re: [lisp] LISP EID Block Size
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 31 Oct 2013 21:36:46 -0000

On 31 Oct 2013, at 11:57 pm, Dino Farinacci <> 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.


> Dino
> On Oct 30, 2013, at 10:02 PM, Geoff Huston <> wrote:
>> On 31 Oct 2013, at 2:44 am, Noel Chiappa <> wrote:
>>>> From: Luigi Iannone <>
>>>> 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