Subject: Re: [lisp] Design discussion -06-(3) -> return all overlapping prefixes

From: [email-masked] (Noel Chiappa)
Date: Thu, 7 Jan 2010 10:46:58 -0500 (EST)

> From: "Joel M. Halpern" <[email-masked]>

Been meaning to say something on this topic for a while (I've been
thinking about it since I first heard about it a while back), but I've
been having a hard time wrapping my mind around it all, getting my
thoughts well-organized. Anyway, time to jump into the cold water, maybe
it will warm up if I swim around some... :-)

    > [For clarity, this is all personal. As chair, I just have to wait
    > and see what folks think..]

Understood. But the personal input is highly valued too... :-)

    > We are talking about overlapping EIDs, not overlapping locators.
    > There are LOTs of overlapping addresses in the current tables.
    > There are multiple reasons for these.
    > It is not clear to me that any of them apply to EIDs.

Good point. A list of uses for overlapping EIDs would be a good input to
the decision below, but...

    > an interesting idea for how one might use overlapping EIDs if they
    > are allowed. That usage clearly has value. Is that value more than
    > the complexity required for allowing overlapping EIDs?

This is one facet of the nub of the problem.

Allowing overlapping mappings (i.e. not just one mapping with multiple
outputs, or even partner-specific mappings - i.e. different mappings
returned to different enquirers) is an _architectural_ change, not just an
engineering one.

Since it is an architectural change, my favourite dictum ("The test of
great architecture is not how well it does things it was designed to do,
but how well it does things it was never expected to handle.") applies;
or rather, it does so in a corollary form, which is that 'You cannot make
architectural decisions based on a pure low-level cost/benefit analysis,
since you'll never be able to completely enumerate them all'.

But I agree, understanding the complexity _is_ a key input to that
decision.

    > Particularly if, as appears to be the case, we would need to
    > indicate that any request for a block that has nested EIDs needs to
    > return all those nested EID mappings as well?

This is the other main facet, a thorough understanding of the engineering
implications (and choices) - and it's the one I most don't understand well
yet.

I think what I need to do is sit down and compose an extended 'meditation'
on the implications of overlapping mappings, and list all the engineering
approaches to handling the engineering issues that come from allowing
overlapping mappings. I'll do that now (warning: lengthy message is likely
to result....)

    > I would be interested in hearing from other folks who have looked at
    > this as to where the value is.

Yes, this would be useful. Darrel has mentioned one good one. If people
can brainstorm, to see how broadly useful this proposed feature is, that
would give us a good sense of how much flexibility/adaptability (which is
really what you need to balance complexity against, when making an
architectural go/no-go decision) this proposed feature has.

I've heard another (having to do with controlling which xTR is used by
traffic entering a distributed site), but that one was hard to really
understand - in part since it also involved, IIRC, partner-specific
mappings, i.e. different mappings returned to different enquirers. (It was
trying to fully understand that one that caused my brain to seize up
the last time I thought about this... :-)

	Noel