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

[Dino Farinacci <dino@cisco.com>]

> 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