[c-nsp] FIB aggregation (was: Conditional advertise-map)

[Heath Jones]

> As I understand the problem, your interpretaion is correct. Only the
> worst case de-aggregation of /16 into 256 /24s would cause every
> even/odd /24 to find a new next-hop. Most cases would be somewhere
> between x0 (same next-hop) through x8 (your example) and up to x256
> (worst case).

Yes it is definately more of a concern with different next-hops for
prefixes within some aggregated space.
My gut feeling is that cam implementation is going to be an issue, as
I think ordering of aggregated prefixes in the cam and how to handle
non-matching prefixes in an aggregate is a problem for existing
implementations.

> Maybe someone could look at historic instability (from BGPmon?) the past
> couple of years and model how FIB aggregation would behave?

I've just finished the code for parsing mrt indextablev2 dumps. I have
to come up with some algorithm to choose the most affected ASs based
on prefixes and neighbor ASs. Any ideas appreciated!!
Once that is done and I have a few ASs to concentrate on, I was
planning to pump in real bgp update information (have to 'guesstimate'
how it will be seen by those ASs) from routeviews.
This should give a pretty good real-world answer to the question of
aggregation in tcam, for the worst case scenarios at the moment.