Eliot Lear wrote:
For a number of these approaches, reverse mapping is all but
impossible for the simple reason that there could be ambiguity when a
particular end point in the DFZ represents connectivity for more than
one "client" network. Put in terms of LISP: the ambiguity hits when
an ETR represents more than one EID prefix.
This ambiguity would only be the case if the ETR has only one RLOC.
(Hint - this is a "design implementation" detail that differentiates
different LISP proposals, either formally documented or under discussion
on the list.)
If a single ETR has multiple EID prefixes, *and* multiple RLOC addresses
(possibly RLOC *block* addresses) assigned to it, then it *may* be
feasible to have an unambiguous (and possibly even completely
deterministic) reverse mapping.
Brian Dickson
Eliot
Christian Vogt wrote:
Tony and Noel -
So except for the Googles of the world, maybe caching will work?
Yes, I have to agree. In fact, if you can make the system carry the
reverse mappings (do they need to be secured?) you might even make
the Googles work.
Two thoughts regarding the benefit of carrying reverse mappings in-band:
(1) Does it really matter whether the cache is populated from a mapping
table look-up or from mapping info carried in packets? In the end,
reverse and forward mappings consume the same cache resources.
(2) You already hinted it: Reverse mappings need to be secured.
Verification will likely cause the same overhead at a packet
receiver as a mapping table look-up.
- Christian
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
--
to unsubscribe send a message to [EMAIL PROTECTED] with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
