The problem with this is that if you reject the routes initially and then later need them, then they're not in your incoming BRIB to reconsider. BGP is an incremental protocol. You can either save an update or you can ignore it, but if you ignore it, it's just plain gone.
If BGP is an incremental protocol (which of course, I know it is), why doesn't a certain vendor treat it that way? *cough* BGP Scanner *cough*. In any event, if the feature was implemented post-received routes (just like prefix-lists were with soft-reconfig), having a copy of the table that was sent to you by a peer, this would be trivial to do in code. Would it be CPU intensive? Perhaps, but so is having 225k routes and climbing. I'd submit that the CPU burned to do a route lookup on a BGP-RIB when a route is withdrawn or announced to see if something less specific exists would not in fact be that bad -- routing lookups, isn't that what a router is supposed to do? -- Alex Rubenstein, AR97, K2AHR, alex@nac.net, latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net