Dino,
A few weeks ago, we went round and round over the question of cache integrity
and talked past one another. I think that I can formulate the question a little
better now.
In order for an ITR to function properly, the EID-to-RLOC cache must conform to
some integrity rules. These integrity rules are never stated explicitly in the
base document. The reader is left to infer them from selected LISP behaviors.
For example, you say that when the EID-to-RLOC database contains several more
specific prefixes (e.g., 10.1.1.0/24) and a single overlapping less specific
interface and the ITR sends a Map Request whose response is the less specific:
- the ETR must respond with the less specific and all of the more specifics
- the less specific must expire before the more specifics
This leads me to infer that if the ITR is to behave correctly and its cache
contains the less specific, it must also contain all of the more specifics. But
you never say this explicitly. I must infer it.
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?
- 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?
Also, I am left to wonder if there are any other cache integrity rules that I
have not gleaned from the text.
It would be good if you could add a section that explicitly states cache
integrity rules.
Ron
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
