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

Yes, that is an implementation issue that provided a level of indirection. This helped the amount of data transmitted from the control-plane process to the line-card processors when an IGP path changed for an external prefix.

Perhaps this entire discussion mixes the terminology ?

Yes, I think it does. CEF was not created because caching failed. It was created because the way caching was implemented was not optimal.

It was not a question of having a partial table (i.e. cache) versus a full table (i.e. a RIB's worth of data), but how the forwarding table was populated.

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 ?

That is the way I have implemented it because when the locator priority and weights are the same, you want to hash at packet encapsulation time to select a locator address.

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 ?

I don't understand what is meant by "cached-based" versus "cef-based". An ITR can have this population rules:

1) Populate the mapping cache for active flows only.
2) Install a default mapping cache entry that points to an ETR that has more mapping
   entries.
3) Put all mapping entries from the Internet into the site ITR.

DNS does 1), CEF does 3), and 2) is done by doing a hybrid. We can swing on this pendulum based on traffic patterns. But here are the disadvantages of each:

1) Data-plane induced requests cause population. So latency is incurred. But latency
   is only for the first destination site request.
2) Stretch is increased to not require all ITRs must have a full table.
3) Requires lots of memory to store all mappings so latency can be eliminated. Solving
   this in one in scalable way will help scale xTRs in 2).

So choose your poison, you have to make a hard decision. So we start with caching and if the cache gets as large as full table, then we have moved the pendulum full swing.

Having said that, Eliot has mentioned with NERD, to start with a full table because it will begin small and then deal with the scaling as LISP or any other Loc/ID split solution becomes popular and ubiquitous.

Dino


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