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:
Sorry, I cannot parse your "For example" sentence. What is a "less
specific interface"?
- 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.
Yes.
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.
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.
We have been over this a number of times. The chairs believe the text
that is already in the spec is sufficient and leaves opportunities
open to experiment.
Dino
Ron
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
