"routing table slots" and the real problem
Yet again people keep talking about "the size of the routing tables" as being the deep problem, and this makes people say silly things like "FOO is protecting router memory". Thinking about it this way is funamentally and fatally incorrect. The REAL problem is the growing complexity of the ROUTING COMPUTATION, not the size of the resulting forwarding table. even if routers had infinite memory, we would still be crushed by the routing computation if allowed to grow unchecked. -mo
Mike O'Dell writes:
Yet again people keep talking about "the size of the routing tables" as being the deep problem, and this makes people say silly things like "FOO is protecting router memory".
Thinking about it this way is funamentally and fatally incorrect.
The REAL problem is the growing complexity of the ROUTING COMPUTATION, not the size of the resulting forwarding table. even if routers had infinite memory, we would still be crushed by the routing computation if allowed to grow unchecked.
True enough. Of course, this doesn't mean that we can't have routing table growth, as we will have processor capacity growth, but it does mean that the growth of the routing tables must be kept in line with what the router processors can do. Perry
processors can't be relied upon to solve the problem. the computational cost grows faster than Moore's law managing the complexity of the graph is the only alternative, and generally the only way to manage tne complexity is through aggregation. at the moment, the only way to manage aggregation is through address assignment. whether we have other alternatives over time is an open question. -mo
On Sun, 2 Mar 1997, Mike O'Dell wrote:
managing the complexity of the graph is the only alternative, and generally the only way to manage tne complexity is through aggregation.
In this case aggregation is a way of building a tree structure in the same way the Route reflectors are used to build a tree structure in the iBGP and route servers are used to build a tree structure in the eBGP. However, when you look at the details of actual route computations over time you should see a significant occurence of the identical calculation producing the identical results. In a reasonably stable network this should be amenable to some sort of caching system that can shortcut the route computations and provide a more linear characteristic as the route table grows. Is anyone doing any work on this whether in the vendor or the academic community?
whether we have other alternatives over time is an open question.
Time has a tendency to create alternatives; we should never discount the possibility even if we choose not to rely on it happening. Michael Dillon - Internet & ISP Consulting Memra Software Inc. - Fax: +1-250-546-3049 http://www.memra.com - E-mail: michael@memra.com
participants (4)
-
Michael Dillon -
Mike O'Dell -
mo＠UU.NET
-
Perry E. Metzger