Re: Route table growth and hardware limits...talk to the filter

[Randy Bush <randy () psg com>]

> > > If you do save it in your BRIB, then you can do this filtering between
> > > RIB and FIB.  That turns out to be a completely local feature, requiring
> > > no protocol changes or additions whatsoever, and thus does not even
> > > require an RFC or Internet draft.  This feature has been seen in some
> > > circles under the name "ORIB".  Ask YFRV's PM for it.  ;-)
> > >
> > > Note that this feature *is* CPU intensive.  This also does not decrease
> > > the RP RAM usage the way that update filtering would.  In fact, due to
> > > the overhead of tracking filtered and non-filtered prefixes, there is
> > > additional RP RAM usage.  YMMV.
> >
> > so, bottom line, no help other than reducing fib?
>
> Not unless you're actually willing to accept a real change in the results.

how about a filter between in-rib and what you actually crank through
the churning clothes washer?  pass on the in-rib, calc on the phyltered
data.  so when shorter prefix is withdrawn, you can look for next best
candidate.

note thatv my original proposal/case some years back allowed a number of
flavors of phylter, longer+same-next-hop, longer+same-as-path,
longer+same_origin-as.

randy