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

[Scott Brim <swb@employees.org>]

On 10 Oct 2007 at 21:46 -0400, Noel Chiappa allegedly wrote:
> E.g. assume that there are 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 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.  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.  You
aggregate how to find the aCARs (the CONS-internal routing
information), but you don't aggregate the mapping replies.

swb

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