Susan Hares <skh@merit.edu> writes: * * Do you have an estimate on the holes? * No - the way I do this estimation is purely on no holes. With holes needs a lot more work. I remeber Curtis had done something a long time ago with estimates with holes. Do you still have that stuff Curtis ?
--Tony.
That data was collected just after the Boston IETF. What the original data showed was the effects of "forwarding table compression" or combining adjacent routes who's next hop was the same to reduce the number of forwarding entries that needs to be placed on smart forwarding cards, regardless of CIDR savings or lack of CIDR savings. That technique may be of use to us if routing table growth continues (since our main processor can hold tons of RAM but our forwarding cards are our limiting factor). Shortly after that, I modified the program to consider full AS path and do the same mechanical operation with and without including holes. This was thought to be an upper and lower bounds on CIDR benefit in those pre-CIDR allocation days. The code is based on NSFNET modified AIX 3.1 netstat output (remember we used to have things called region routes which were like ISIS areas). The original code is still lying around, but it isn't of much use. It would need to be rewritten to use a gated dump or other input source and I don't think the excersize is particularly useful. What might be useful is running the forwarding table compression to see what gains we could get for things like NSS that are constrained by the forwarding card design but can take huge main memories. It might also be useful to run the "no holes" estimate based on full AS path since that would give us the _actual_ benefit of automated aggregation if we were to get rid of the longest match preference. I don't have the time to do these at the moment. I'm collecting the routing tables for the first on the hopes I'll find some time and anyone can do a gated dump or "sh ip bgp" and do the second to determine their own expected benefit. Curtis