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