> I have to say I rather lik the iea of a query to the mapping system that asks > for a simple, small set of prefixes with the property that anything outside > of that set is by definition unknown to that mapping system. A mapping > system with no clue returns 0/0.
And is already implemented multiple times. ;-) Dino > > Yours, > Joel > > On 11/21/2012 3:03 PM, Sander Steffann wrote: >> Hi Noel, >> >>>> I don't think that expecting code to handle two blocks (the >>>> experimental one and the permanent one) is asking too much >>> >>> We disagree. For me, it's extra code/complexity, and it buys you absolutely >>> nothing at all. >> >> I don't agree. See below. >> >>>> If a single permanent allocation that never changes is truly necessary >>> >>> Allocation != reservation. Nobody is asking for the entire chunk to be >>> _allocated_ (i.e. given out), just that it be _reserved_ for this use. >> >> But if I understand correctly it's going to be hard-coded somewhere. That >> will mean that everything that is reserved now will be unusable for anything >> else ever. I'm not *that* worried about wasting IPv6 addresses, but I do >> worry about any hard-coding of prefixes. What for example if LISP is such a >> success that the block is too small? >> >> Wouldn't it be better to have a bootstrap method that is more flexible? The >> DDT root servers know which prefixes are delegated, so we might extend the >> DDT protocol to return that list of prefixes. I write code myself, so I know >> it's a lot more work to implement something like that properly. I'm worried >> about the consequences of making this hard-coded though. We can't foresee >> all the possibilities at this point in time (if ever). >> >> Another benefit of making this flexible is that multiple models of LISP >> deployment can be used. It doesn't matter anymore if IANA reserves a special >> block, RIRs assign from separate blocks, or even if ISPs offer LISP based >> solutions to their customers (which happens to be what I am doing). >> >> You get all that, but yes: it does make the code more complex. On the other >> hand: LISP implementations know how to talk to DDT servers and probably also >> have prefix-list-matching code already, so it shouldn't be too difficult to >> get a list of prefixes and match against it. >> >> - Sander >> >> > _______________________________________________ > lisp mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/lisp _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
