Subject: Re: [lisp] LISP EID Block Size

From: [email-masked] (Noel Chiappa)
Date: Wed, 30 Oct 2013 11:44:54 -0400 (EDT)

> From: Luigi Iannone <[email-masked]>

    > 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.

	Noel

---

From: Geoff Huston <[email-masked]>
Date: Thu, 31 Oct 2013 16:02:11 +1100

> 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

---

From: Sander Steffann <[email-masked]>
Date: Thu, 31 Oct 2013 13:41:19 +0100

Hi Geoff,

> experiment into the words in the two drafts relating to this proposed action

This pretty much sums up my feelings about those drafts as well.

Thanks :-)
Sander

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 31 Oct 2013 05:57:37 -0700

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. That part is the experiment, not whole of LISP proper.

Dino

On Oct 30, 2013, at 10:02 PM, Geoff Huston <[email-masked]> wrote:

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: Geoff Huston <[email-masked]>
Date: Fri, 1 Nov 2013 08:36:30 +1100

On 31 Oct 2013, at 11:57 pm, Dino Farinacci <[email-masked]> wrote:

> 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