[c-nsp] BGP blackholling with communites

[Pete Templin]

David Freedman wrote:

> Saying that, I do not implement customer blackholing this way as it
> becomes complex to maintain seperate filters for both the customer's
> normal peering session (following their RIR assigned objects)
> and filters to allow the customer to inject /32s from their own space to
> be blackholed.

Complex from what standpoint?  Granted, I do my prefix lists manually, 
but my crew knows they need to update the "<customer>-pfx" list and the 
"<customer>-pfx-all" list if there are updates.

> We ask the customer to peer with a seperate "blackhole" device, which
> maintains a list of filters allowing the customer to announce /32s out
> of their own RIR assigned space (on which we explicitly set the
> "no-export" community).

Do you restrict customers to blackholing /32s?  We actually allow 
customers to blackhole all the way to their aggregate.  If they 
blackhole an aggregate (from the -pfx prefix list), we blackhole it 
internally and announce it out.  If they blackhole anything longer, we 
blackhole it internally.  That way, they can choose (if they're savvy) 
to implement a "blackhole-default" policy with overrides.  Granted, I 
don't think a single customer has ever used it, but the framework is 
already built.

I don't think any of our current upstreams have provided a community to 
be able to blackhole, but if they do, we'll likely rewrite our method so 
that customers can choose how to handle their aggregate, etc.

pt