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

Re: [RRG] Opportunistic Topological Aggregation in the RIB->FIB Calculation?



Jari Arkko wrote:
I second what Lixia said.

In general, there are plenty of ways to optimize and compress FIB tables, some without changing the end result and some that do change the routing (Paul Francis' scheme, for instance). I have not reviewed your scheme in detail, but if you search you will find others. Some earlier discussion here: http://www.ietf.org/mail-archive/web/ram/current/msg00567.html

I view the former class (schemes that do not change forwarding decisions) as implementation techniques. On a given platform, you may decide that its reasonable to spend some central CPU time to reduce the amount of memory needed on the line cards. Of course, there are trade-offs, you cannot determine with certainty that compression will be effective on today's RIB even if it was very useful on yesterday's, etc. My personal opinion is that these techniques should belong to the toolkit for people building routers, perhaps more so than they are today. Of course there are many other things in the toolkit as well.

I view the latter (Francis-type) schemes as mostly operational techniques that can be useful if and when existing equipment on a given operator is otherwise unable to deal with the situation. Note that there is a trade-off between buying newer equipment vs. operational effort. I would like to see Paul's scheme or something else documented at least.

However, our task in the RRG is not really about these types of approaches. We should assume they are being applied (I certainly hope so) where needed, and it may be useful for the group to understand that such techniques exist. But our task should really be about architectural change, something that could yield 10x to 1000x difference in table sizes.

This is a cart-before-the-horse issue.

While the tools are potentially capable of significant degrees (or even orders-of-magnitude) reduction in FIB (and in many cases RIB) size, they are dependent on the data on which they operate.

Garbage (un-aggregateable prefix) in, garbage (bloated RIB and FIB) out.

So, even though the specific implementations *may* be out of scope, the notion that the prefix sets being suitable for such processing are needed, is definitely *in* scope.

The addressing (and address *allocation*) schemes are absolutely architectural in nature.

So, while the specific techniques may be very helpful in informing architectural models, even if the techniques themselves get removed at the end of the RRG process.

They are, in effect, like the pencil-lines used by artists doing realistic perspective work. The lines-to-infinity are needed to shape and size objects, but are not part of the finished artwork.

BTW - I'll be contributing more ideas on such aggregation techniques and ways to view "sets of things to aggregate" and such, over the next several weeks.

Brian Dickson

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