Very true, but where is the core? I've setup many BGP peering sessions, and yes all of those direct edge connections into tier 1 providers is generally filtering prefixes longer than /24. These are where the big propagation problems happen. Whoops, I just advertised my internal network (including a bunch of /31 and /32s) to the Internet either clobbering route tables (capacity problem) or stomping routes.
This is why my comment posted in the recent CloudFlare post mortem talks about good network engineers and the misunderstanding of many 'technical savvy' folks that know enough to do some really dumb things architecturally.
This lends credence to the fact that, this is well understood if you've spun up peering sessions more than once. I find it slightly embarrassing most people don't realize how fragile a framework BGP really is. But it definitely comes to light reading through forums like HN that lean towards the developer side of readership.
It's not hard to "do things right". We filter our customers advertisements to us (requiring them to register their routes in a routing registry and then manually verifying them before allowing the prefixes to be accepted) as well as filtering what we advertise upstream (and our upstream performs filtering on our advertisements as well).
If you advertise /31s and /32s, well, you shouldn't be redistributing into BGP and, of course, your upstream should be filtering those prefixes and throwing them away. Problem solved.
Perhaps the majority of people here on HN don't understand BGP. Then again, most of them probably don't need to.
If the provider isn't filtering, sure.
> Most edge routes are configured to simply trust routes as they come in
Actually, edge routers are where your prefix filtering takes place. It's much more difficult to filter at the "core".