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