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