[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] Tunnel fragmentation/reassembly for RRG map-and-encaps architectures



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 rrg-request@psg.com 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 rrg-request@psg.com 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