...

You can build your customer BGP filters off data in the IRR. Make it a requirement that BGP customers must keep that information up to date (or do it for them).

OK. So I apply an ingress filter (ideally built from the IRRs) to a customer peer. Then I have to add the cusomter's AS(s) prefixes to every eBGP peer's egress ACL (including customer peers) so that the networks will be permitted.

The customer begins advertising a newly allocated netblock. Now virtually *every* BGP peers ACL has to be modified & deployed and the source AS will need to either flap the route or reset the session.

If I had tagged the customer's prefixes with a BGP community when I picked up the routes ..and have filters in place that deny/permit predefined communities to all eBGP peers, all I would need to be concerned with is the customer's ingress ACL.

IMO, ACLs alone won't scale.

-danny

For any of this to scale it's got to be automated, so building and deploying the prefix filters on all external/customer peerings shouldn't be an issue. Scaling the size of the ACLs might be an issue though, I'm not sure about that. Won't setting soft state on customer peerings avoid the need to bounce routes after the ACL gets updated? I haven't actually done this yet - does anyone know how well it works/if it costs much memory/CPU? You'd need to make sure that external filters got updated before customer filters, but that shouldn't be too hard. The problem with tagging everything a BGP customer passes to you with the "export it" tag is that customers have been known to export routes they shouldn't. The ACL provides a sanity check without costing much (if you've already got the database/distribution tools built). -- -Chris (cgarner@sni.net)