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

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



Hi Dino,

 > And, by the way, you still did not answer my original question.
 > Namely, what were the problems that motivated development of CEF,
 > and how these problems would be solved in the context of LISP ?

I did answer it. It was software switching based population of the hardware or faster path forwarding cache.

One huge benefit CEF brings is the ability to resolve not only an active path to it's adj but also the backup paths. So during the failure of an active path you have immediate candidate already pre-resolved as backup.

Perhaps this entire discussion mixes the terminology ?

Isn't it possible for ITR to do both ? To cache mapping entires (to eliminate the amount of them on the ITR) which would contain multiple ETR locators and then pre-resolve all such locator candidates in CEF ?

So forwarding will be still cef based ... not cache based. Caching would be only related to keeping mapping entires in the control plane to eliminate the need for storing them all on all ITRs ?

Cheers,
R.




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