Re: [RRG] How to avoid the side effect of cache in ITR

[jnc@mercury.lcs.mit.edu (Noel Chiappa)]

    > From: Scott Brim <swb@employees.org>

    >> On 10 Oct 2007 at 21:46 -0400, Noel Chiappa allegedly wrote:

    >> .. separate mapping entries for 1.1.1.0/24 and 1.1.0.0/16, and the ITR
    >> looks up the mapping for 1.1.2.17, and that returns the 1.1.0.0/16
    >> mapping, which it caches. Now assume the ITR needs to look up the
    >> mapping for 1.1.1.17; the 1.1.0.0/16 mapping which it already has
    >> cached will satisfy that request, even though it is not the right
    >> mapping.

    > I don't see why this would happen except by a configuration error. The
    > mapping replies have (EID prefix) -> (set of RLOCs to reach it). There
    > is no reason why these would be aggregated in flight unless the result
    > were known to be true.

??? I wasn't positing any mapping in flight; I was just positing that there
were two mappings configured:

    1.1/16 -> (RLocSet A)
    1.1.1/24 -> (RLocSet B)

I.e. the second entry is for a "punch-out" in the first entry.

Now, maybe you want to say that "punch-outs" should be illegal, i.e. that no
two EIDRange->RLocSet mappings can have overlapping EIDRange's, but like I
said, I don't recall recall whether that's currently allowed or not.

If it *is* allowed, then we have the problem I describe (at least in schemes
which do caching; more on this below).


If it is not allowed, then to configure something like the example above, one
would have to configure ~256 entries, one looking like the second one, and
the other ~255 all looking like

    1.1.X/24 -> (RLocSet A)

for all X other than 1.

Unless we do as I suggest below, which amounts to automatically 'converting'
things that look like the first, to the ~256 entry version I just described:

    >> I would say that the fix is to not allow a larger mapping to be
    >> returned if it 'covers' a smaller one. I.e. the entity which maintains
    >> the authoritative mappings would only have two entries, for 1.1.1.0/24
    >> and 1.1.0.0/16. However, whenever a request came in for any
    >> 1.1.<anything> which was not 1.1.1.N, it would have to reply with a
    >> 'made up' mapping entry of 1.1.<something>/24, to avoid 'covering up'
    >> the 1.1.1.0/24 mapping.

    > The authoritative source should only return what it is authoritative
    > for.

Well, but it's authoritative for both 1.1/16 and 1.1.1/24. The issue is the
punchout;


    > In CONS there are two different sorts of information flowing. First is
    > CONS-internal routing information to get to the authoritative source
    > (aCAR). Second is the mapping replies themselves.

Yes, in CONS there are two kinds of mappings/bindings (in the generic sense of
the word), the first being:

  EIDRange->CDR/aCAR

which allows you to find the second:

  EIDRange->RLocSet

which is what you actually want. (And I have proposed that we have different
terms for the two kinds of mapping, to prevent confusion - I forget now
exactly what terminology I suggested.)

However:

    > You aggregate how to find the aCARs (the CONS-internal routing
    > information), but you don't aggregate the mapping replies.

Right, but this problem has little to do with how EIDRange->RLocSet bindings
are distributed; rather, it's mostly a property of how we allowed EIDRange's
to be configured.

I say "little" above, not "nothing", because if you're using a full push
scheme (i.e. all ITR's have the *complete* table of EIDRange->RLocSet
bindings) we can fix this problem, whilst allowing punchout configurations,
simply by saying you have to do longest-match lookups in the table.

But as long as i) ITR's can have incomplete tables, and ii) punchout
configurations are allowed, we have this problem.

	Noel

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg