There appear to be two related technical issues here.
The first one is on refreshing entries. A refresh of a less-
specific with overlapping more-specifics will inherently provide
refresh of the more-specifics. Even if an implementor does not
realize that, he will do the right thing. We can live with the text
asa is on that.
The second one deals with a different issue. In performing local
maintenance of a cache with overlapping entries, one could easily
get into a situation where the less-specific is being used (its use
time would be updated), but the more-specifics are not being used.
An LRU-based cache maintenance algorithm could, according to what is
written in the spec, remove these relatively-unused entries in teh
event of cache exhaustion.
HOWEVER, such removal would actually be wrong. It would break the
coherence requirement.
As far as I know, nothing in the spec says taht.
Yes, a sufficiently attentive reader could realize that one set of
protocol behavior could impact another. But we do NOT normally
expect readers to perform that level of inference. Specs are to be
implementable by folks who are not protocol designers.
Is there some place in the space where it says this? If not, could
we add a sentence or two in the text on local cache management.
Yes, I will make sure I mention how to time out entries when there are
overlapping EID-prefixes. Thanks a lot for clarifying things Joel.
Dino
Yours,
Joel
On 6/27/2011 12:34 PM, Dino Farinacci wrote:
This integrity rule is important because it drives the answer to
many
other questions. For example:
- If the ITR uses the less specific and updates its expiration time,
must it update the expiration time of all of the more specifics,
also?
The update of the expiration time is based on receiving a Map-Reply
and
in section 6.1.5, it is documented how to send and process Map-
Replies
when overlapping EID-prefixes are in use.
- If the EID-to-RLOC cache thrashes, and I am forced to delete
unexpired entries, must I delete the less specific before the more
specifics?
You could. But you could also use an LRU algorithm on EID-prefixes
which
are not overlapping.
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
