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

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

    > From: Xu Xiaohu <xuxh@huawei.com>

    > The cache in ITR reduce the forwarding or querying pressure on some
    > mapping server, but it also results in the following side effects.
    > ...
    > it can result in black-hole or sub-optimal forwarding path in some
    > cases. For example, there are two prefixes in the mapping server,
    > 1.1.1.0/24 and 1.1.0.0/24.

I think you meant 1.1.1.0/24 and 1.1.0.0/16, right?

    > There are some approaches to avoid this: one is avoiding the EID
    > prefixes in mapping database overlapped, the other is replying with all
    > the specific EID-prefixes' mapping covered by the matching EID-prefix.
    > ...
    > for example, some enterprise has a /16 prefix, from which one /24
    > prefix is assigned to one site, while the remaining /24 prefixes are
    > assigned to another site
    > ... in current Internet, prefix overlapping is permitted.

Yesssss.... Even if you do longest match in the ITR when it looks through the
mappings that it has on hand, already cached (the way we do longest match now,
on routing table entries) that does not help.

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

I do not recall the specs well enough to know whether they already do that -
can anyone else confirm if they handle this problem, and if so, how?

	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