...

...

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