[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] How to avoid the side effect of cache in ITR
On 10 Oct 2007 at 21:46 -0400, Noel Chiappa allegedly wrote:
> E.g. assume that there are separate mapping entries for 188.8.131.52/24
> and 184.108.40.206/16, and the ITR looks up the mapping for 220.127.116.11, and
> that returns the 18.104.22.168/16 mapping, which it caches. Now assume the
> ITR needs to look up the mapping for 22.214.171.124; the 126.96.36.199/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 188.8.131.52/24 and 184.108.40.206/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 220.127.116.11/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.
to unsubscribe send a message to email@example.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