On Wed, Nov 15, 2000 at 12:02:59PM -0800, Kevin Oberman darkened my spool with the following:
First, it is not clear to me whether Juniper can prefix filter on a tier 1. Cisco can prefix filter on SOME NSPs that might be classed as tier 1. ESnet prefix filters on all peers that have fewer than about 10,000 prefixes.
i believe both juniper and cisco could, but i think you;re going to have unpleasantness wrt boot-time config loading, config commit time, size of the canonical config, slow boot-time/unstable-wire policy evaluation. ??? even with prefix filtering; if soft-reconfig is enabled, a peer could still DOS its peering router by consuming all its memory (eg: every /32 of /<some large prefix>).
As we are moving to Juniper at one peering point, we might try filtering come bigger peers. The Juniper folks say that they are still testing how extremely large policies effect performance. We will see.
Note: I am only talking about filtering BGP announcements, not packets!
Since Sprint and UUnet don't seem to be willing to provide information in the IRR to allow us to generate access-lists/policies, and not peering with these folks would be a Bad Idea(tm), so we can't quite filter everyone. (If I could figure out a way to get them to register, I'd have fun trying, though.)
so, the question is how to make registering irresistable? peering contract requirement? peer pressure? :)
The only downside to such filtering I have seen is that some folks (including some which use the router servers which mandate registration) are very lax about registration. It also makes for some rather long configuration files. Even with many large peers not being filtered, configurations at major meet points exceed a megabyte.
i believe this amounts to a fairly easy and doable solution. a 1 line configuration stmt and it can be automated....even some of the object registration could be automated. but, all the teir 1s have to play.