|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: using IRR tools for BGP route filtering
> > I agree totally with prefix-list filtering customers and we have done so > from the very beginning. (Who wants to blemish the reputation of their > ASN as result of a customer being a bonehead and announcing default, etc?) > Provider<->Provider prefix-list filtering becomes much more involved > however. When a provider has 400+ bilateral peering relationships, the > time it takes to bring a new customer online who has their own address > space grows substantially. It is no different when a provider obtains > additional address space. If their peers are prefix-list filtering, they > have to contact every peer to have them blast a hole in the filters for > the new address block. If a provider performed prefix filtering on their peers, the policies would need to be auto-generated from some database, a la IRR or the like. This used to be a problem not long ago, when things such as sequenced prefix lists (with incremental update support), and BGP route refresh didn't exist. Today, however, they do. The problem is that the data in the IRRs is stale -- at best, the associated infrastructure isn't necessarily production quality, the routers can't store the policies, much less perform matches in a reasonable manner, and they certainly can't perform any type of forwarding plane functions such as SA verification. Of course, a bit of latency introduced would perhaps encourage correct aggregation and use of provider-allocated space, which, of course, is yet another rathole in and of itself. > In a perfect world, we would not need to filter, period. Filtering > customers has become necessary to survival. I see Provider<->Provider > filtering as a major hurdle to jump anytime your (or anyone elses) network > expands in relation to prefixes being legitimately announced. Though I'm certain you'll agree that hurdle isn't nearly as high as the one that providers must jump when another provider begins advertsing more-specifics of their customers address space. For example, I recall a provider announcing a /24 which contained www.cisco.com a few months back, and every peer gladly accepted the announcment .. including Cisco's service provider! As you can imagine, this caused a bit of a problem for a number of folks. Fortunately, Cisco doesn't rely wholly on web-generated revenue, as some folks do. The lobbying for this isn't simply because we think it's cool or that it would be trivial to accomplish .. it's because the lack of inter-provider filtering and SA verification mechanisms are by far one of the most vulnerable components of today's Internet. Support for these two components alone would clearly improve the Internet as a whole, significantly increasing reliability, while decreasing vulnerability to things such a DoS attacks. -danny
|