> From: Margaret Wasserman <mrw at sandstorm.net>
> I'd prefer that we use short-enough TTLs to allow new mapping entries
> to be detected in a reasonably short period of time without an explicit
> signalling mechanism.
Well, it's certainly true that DNS seems to do OK without a mechanism for
detecting outdated mappings, so perhaps this is a non-issue. I'd be a bit
wary of craking the TTLs _way_ down, though - it could cause a rather large
traffic load.
> If there is concern that this would result in too much mapping
> traffic
Mindreader! :-)
> we could work on a mechanism to extend the TTL (and suppress subsequent
> mapping lookups) when there is ongoing successful communication.
Interesting idea. I thought about this for a while, and we can do something
(although I think it needs either a new control message, or some incredibly
hairy user traffic analysis), but there are fundamental limits on what we can
do via this path.
The thing is that just because an xTR is up and reachable - which is what all
the various existing mechanisms give us - that doesn't mean that a mapping
that uses it is correct, i.e. "ongoing successful communication". In other
words, even if you can successfully send a packet for EID D from ITR Is to
ETR Ed, and Ed is up and working, that doesn't mean that Ed is the right ETR.
To truly check for "ongoing successful communication", we'd need to be able
to ensure that traffic reaching Ed for D is actually getting to D, and that
implies either i) some sort of deep analysis of user-data traffic (e.g. to
watch for TCP ACKs), or ii) for Ed to tell Is that Ed is _not_ an ETR through
which D is reachable. (A NACK is preferred to an ACK, for obvious reasons.)
(OK, OK, so the latter is not actually making sure the traffic gets all the
way through to D - but to me it's not reasonable to expect LISP to verify
that, e.g. interior site routing is working; all it should be required to be
responsible for is making sure that the _LISP_ stuff is working OK.)
I'm not too big on the 'deep inspection' path, so that leaves the other; we'd
need to define a LISP error message (we don't seem to have one at the moment)
which says 'this is the wrong ETR for that EID'. Of course, that would be a
DoS attack vector, so the response at the ITR, on receiving it, would be just
to start a resolution cycle to refresh the mapping.
(BTW, what do ETRs do at the moment, if they get a packet which they are not
the correct ETR for? I assume they unwrap it, try and forward it, and
depending on how the code is written, it may either get re-wrapped and send
to an ETR, or forwarded to a PITR.)
Still, this whole approach has a limit though - which is that it can say
nothing about whether the _mapping_ is up-to-date, simply that Ed considers
itself a viable ETR for D. LISP contains a number of features for
load-sharing, for primary and backup ETRs, etc, and this method can't detect
any changes in the mapping as a whole (at least, not that I can see).
I think the only way to do that would be something like versioning; whether
that's done in a separate control-plane interaction, or piggy-backed on
user-data traffic, is a separate question.
(Note that it could also be either 'forward' or 'backward'; i.e. the ITR could
tell the ETR what mapping it's using for the destination EID, and the ETR
would notify the ITR if it's old; or the ETR could tell the ITR what the
latest mapping is for that EID, and the ITR would have to notice if its
mapping is outdated.)
But maybe I'm missing something?
Noel
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.