This is not our experience, and yes, we filter customers *and* peers. (We have a few peers we don't filter other than sanity-wise, but this is a limitation of config file size, not performance. Plus, a couple of Tier-1 networks don't register or don't publish as-sets.)
Configuration size is certainly one of the issues, yes. I guess some providers are more concerned with BGP convergence than others. I for one think 4-5 minutes to pickup a full BGP table from a single peer when doing nothing else -- and withOut any filter lookups, is a bit much.
We have been requiring customers to register, for BGP customers, since we started offering IP transit, and have built filters for customer from RADB and other public registries from day one.
Good practice. Unfortunately, it still doesn't provide safety when one of your peers advertises a network that they're not supposed to.
Obviously, when it comes to the data plane, filtering should be done at the edge, for scaling reasons.
Though this requires providers to rely on other providers to ensure their availability, something many providers would rather not do.
Filtering based on registries is a hack - the real issue of trust, of originators of routing information, is better managed through an end-to-end, top-to-bottom, but scalable, delegation and signature method, using such mechanisms as are under discussion in various IETF wg's on secure BGP.
SBGP. Ha. Did you perhaps consider the performance implications of this? And the requirement for de-aggregation or hierarchal signatures? And the fact that today it'd take pretty much an entire 24-hour period for one router to verify a full Internet routing table from a single peer? And that'll scale? I'd suggest we stick to some registry/pre-population of policies mechanisms. It's interesting that for quite a while nearly 30K PSTN 800 numbers were allocated nearly every week, with number portability and all. Perhaps we're simply missing something :-)
There is still the issue of the boot-strap route required for root name servers... :-)
Among those the requirement for routers to actually have cycles to populate forwarding tables and forward packets, something they probably wouldn't be doing if they were running SBGP.
In fact, the end result is non-propogation of bogus routing information. If only a few more big networks would do this, the risk to the net in general would be substantially reduced.
I'll again site the www.cisco.com incident from a few months back. The announcement was originated from a large provider that performs prefix-based filtering on all customers. I can speculate that your customers as well were affected by this. -danny