On 31 Oct 2013, at 11:57 pm, Dino Farinacci <[email protected]> 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 <[email protected]> wrote: > >> On 31 Oct 2013, at 2:44 am, Noel Chiappa <[email protected]> wrote: >> >>>> From: Luigi Iannone <[email protected]> >>> >>>> 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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/lisp > _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
