Re: [lisp] Last Call: <draft-ietf-lisp-eid-block-03.txt> (LISP EID Block) to Informational RFC

[Sander Steffann <[e-mail]>]

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