That was one of our biggest worries.... people make mistakes and route leaks happen.....
They do. And it's not just mom+pop providers who occasionally leak an entire table. Big operators do it too.
The unfortunate part we're faced with now is that we have several downstream customers who are multihomed. Because we're filtering out some of the prefixes that are not in an IRR, those routes are not nearly as attractive downstream giving the other carrier involved an advantage..... I can see this is where convenience/economics start to kick in ;(
One way or another, if you're providing transit, you absolutely need some means of filtering your downstreams using prefix filtering, and also preferable ASN filtering. Otherwise, your downstreams can inject any sort of crap into your table and you're opening yourself up to I-can't-believe-it's-not-youtube-hijacking-again situations. This is really bad and harmful for the internet. Max-prefixes are fine for peering exchanges, where you can just depeer if there's a problem, but they will not protect you against customers doing stupid stuff. The only issue for customers is not whether you do prefix filtering but whether you use IRR information or maintain your own internal database. The latter is re-inventing the wheel, imo. But lots of companies do it anyway. If your peering exchange doesn't provide multilateral peering, ask them to do so. This provides a natural platform for using route server client IRR prefix filtering, and route servers (despite a lot of well known and understood problems associated with them) can be very useful in this regard. Nick