Re: [lisp] LISP EID Block Size

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
> 