you can achieve this goal from a /32. what you're seeking to avoid is having to re-map the magic prefix if the experiment is a success: this I understand. But the cost of wiring a prefix is a very high cost: code should be written to be agile and be able to be TOLD what prefix is the magic prefix. Nobody should be reifying prefixes into anything, experiment or otherwise.
Make it a parameter of prefix/len. And work the experiment in a /32 On Thu, Oct 31, 2013 at 7:54 PM, Noel Chiappa <[email protected]>wrote: > > From: Roger Jorgensen <[email protected]> > > > The _big_ difference between EID's out there today, and the one from > > this new netblock are that any system should _know_ by matching the > IP > > that this is EID space, and by that know how to handle it. > > If traffic grow as everyone predict, and continue todo so, optimizing > > the handling of LISP EID's is probably a very good idea. > > Sure, but realize that there are limits on the improvement of basic LISP > handling. > > E.g. if we allocate a large number of PI blocks from a large EID block, an > ITR will likely _still_ have to do a mapping lookup cycle in order to be > able > to forward traffic to an PI EID block's ETR. (Since there would be many > different PI blocks allocated from that large PI block, scattered all over > the Internet.) > > Yes, the 'interoperation with legacy hosts' part would be better, since > there > would only need to be a single large advertisement into the legacy DFZ (as > someone else pointed out). > > And who knows, maybe someone will develop a use-case in which 'facial' EIDs > bring more significant benefits. But I think Darrel's point is very > accurate: > "we should keep our expectations for the benefits of this block modest". > > Noel > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp >
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
