It has been stated that if the granularity of prefixes in negative Map-
Replies are too specific, we can fill up a cache. There are two ways
to deal with this:
(1) Use some form of aggregation or table compression.
(2) Don't store negative prefixes.
Jeff mentioned for (1) to have the mapping system return a coarse
negative prefix with positive ones which punch holes in negative map-
replies. This will be quite hard since the sender of the negative Map-
Reply may not know all positive entries (since they are spread around
and stored in other map-servers). But the map-server could infer based
on looking at the ALT to find positive entries. So some research can
be done on this idea to see if is tractable.
Another way to tackle (1) is to have the ITR look at the more-specific
negative prefixes to see if they can be combined into a fewer number
of more coarse prefixes using localized prefix compression. If exact
compression can be done, then do it (meaning their are no positive
holes in the compressed aggregate). If there are holes created, they
*could be mitigated* if you already have a positive cache entry stored
because you previously have encapsulated to the site. But you can't
always depend on this ordering to make it reliable.
As for (2), we could say, we'll make a tradeoff by saving the cache at
the expense of more load on the mapping system. Well the mapping
system (like DNS) has to be provisioned and capacity planned to handle
load for scaling reasons. So it should also be able to handle DoS load
too. And if it can't, then the DoS load gets dropped (that is the good
news). But with every DoS load that gets dropped there is good load
that loses too. So take this with a grain of salt.
But if the ITRs only stored positive cache entries, one might think we
would not know when to forward natively to non-LISP sites. Well when
an ITR gets a cache miss, it could send the packet natively as well as
send a rate-limited Map-Request. We do implement very short-lived data-
caches so we can do aggressive rate-limiting. If a Map-Reply is
returned, you know the destination is a LISP site and you cache the
positive entry. If nothing comes back, you continue to forward
natively. As I said, this puts more Map-Request load on the mapping
system.
Or maybe a combination can be used. You store negative entries to a
threshold and when you need to store a positive, it is the negative
ones that are evicted first to make room for the positive ones. And
which negative ones you choose to evict can the most specific prefixes
because they represent a smaller set of destinations and the
probability of sending a Map-Request for them to find out if they are
LISP destinations or not is less likely then with larger blocks.
Note, it is easier to compress negative map-cache entries since their
locator-set is the same. That is it is empty with an action of "native-
forward" where as for positive map-cache entries you cannot compress
consecutive power-of-2 blocks if the locator-set is different (meaning
the EID-prefixes belong to different sites). Now, there is always the
option to take the compressed value and use a new locator, perhaps a
re-encapsulating router in the core, that can hold more prefixes. This
is related to my other email where a PETR can be used where it
decapsulates from the ITR and re-encapsulates directly to the site.
This will be at the expense of possible added data-plane stretch.
Dino
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
