Hi Noel, >> 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.
I understand that. Auto-detection of those prefixes is a nice-to-have feature, but certainly not necessary for now. What if it's implemented as a configured prefix-list? > 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'. Not hard-coding some prefix in code certainly is as far as I am concerned. Making extensions to the DDT protocol to auto-configure the prefix list can wait. > (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.) Either you're talking about my company or you now know of two :-) I am now running on old c7200's for a proof-of-concept, but those will be replaced by (probably) ASR1k's as soon as I start to offer it as a commercial service. >> 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). I am very scared of hard-coded stuff :-) I would be very happy if it's not hard coded but just configurable in some way! I agree that changing existing message formats later would be so much worse. > 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. :-) Happy to hear that > This is not in that class. We might disagree a bit on that, but let's look for workable solution. From an operational point of view I really don't like hard-coded address blocks that have a special meaning, but I am also certainly not suggesting that you drop all other work! Would using a prefix-list to configure this be a good solution for now? (I suspect there must be existing code to check an address against a prefix-list somewhere ;-) Thanks! Sander _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
