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

From: [email-masked] (Noel Chiappa)
Date: Wed, 21 Nov 2012 16:24:19 -0500 (EST)

> From: Sander Steffann <[email-masked]>

    > 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

---

From: Sander Steffann <[email-masked]>
Date: Wed, 21 Nov 2012 22:51:21 +0100

Hi Noel,

> 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?

> 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.

> 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.

> 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.

> 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