[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