> From: Sander Steffann <[email protected]>
> I think making sure that LISP is flexible enough to last a long time is
> a huge benefit.
I basically agree with that, but we don't have infinite code-writing cycles
available. (Remember, this is not an paper design exercise, this stuff is in
significant experimental use.)
I can dream up dozens of things that would help make LISP "flexible enough to
last a long time", but are we going to do them _all_ Right Now? Somehow I
don't think so.
Resources for writing code are limited. We have to pick what is most
important. The ability to support multiple dynamic EID blocks, without
changing config files - something we're unlikely to use for a long time, if
ever - is way less important than any number of more desirable upgrades.
That's really the bottom line here: saying 'we should do this' is equivalent
to saying 'this is more important than X, Y and Z'.
(Add to that the fact, as far as I know of, only one organization is even
putting energy into doing a commercial LISP implementation at the moment.)
> compare a few days/weeks of extra development work to years and years
> of everybody being limited by a bad decision now.
It seems to me entirely unlikely that changing from i) a single hard-coded
block to ii) multiple blocks allocated via some sort of dynamic mechanism is
something that would be _particularly_ hard to add later - as opposed to,
say, adding the ability to cache mappings in the MR (which requires changing
the format of the Map-Reply message).
Getting the correct balance between i) getting stuff up and running, and ii)
not handcuffing yourself in the long run, is a tricky problem. I lived through
one cycle of this (with the initial IPv4 stuff), and lived to see _just how
painful_ what one thinks is a 'quick hack to get us up and running' can be
(with the 32-bit addresses).
I am never going to make that mistake again.
This is not in that class.
Noel
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
