Re: [Idr] flowspec enhancements

[Wesley Eddy <[e-mail]>]

Hi Jeff, I had a couple comments to your message inline below:


On 10/5/2015 3:11 PM, Jeffrey Haas wrote:
> 
> This I-D serves as an interesting melange of ideas.  I suspect at some later
> point you might find it useful to separate the individual changes into
> distinct I-Ds.
> 


Splitting out any good ideas, and leaving the bad or more difficult
ones behind, is definitely the plan.


>> Specifically, the suggested enhancements include:
>> - add packet rate limitations as an action (not just bitrate)
> 
> This one is generally useful and would be a pretty trivial extension.


Everyone that we've talked to has seemed to agree on this, so I think
it looks like we should pull it out into its own document.  We aren't
an equipment vendor with an implementation that could do packet rate
limiting, so I'd think it would be great if we could get a co-editor
from some vendor who could actually implement this ... if you or
someone else might be interested.


>> - add support for filtering of tunneled traffic (unencrypted)
> 
> This is problematic in several interesting ways, some of them implementation
> specific.  But perhaps that really suggests a widening of the deployment
> domain.
> 
> BGP Flowspec is typically deployed in scenarios to effectively program
> firewall filtering on BGP speakers.  Pragmatically, this has meant some
> level of restricting the operations to filters that can be applied at near
> wire-rate and thus we're not always getting a full set of potential
> filtering operations that may be available on devices that work at different
> scale.  
> 
> There's also the second issue in that such directly indexed forms of
> filtering may limit the deployment to cases where flowspec routes are
> directly advertised and not propagated to other BGP speakers.  This is likey
> because when tunneling technologies may change encap/decap on a hop-by-hop
> basis, it becomes difficult to adjust the filters to be fully generic using
> distribution via a Route Reflector - a common deployment scenario for
> Flowspec.  
> 
> Of course, these constraints become different once we're talking about
> non-traditional BGP speakers such as IPS systems, etc.


Agreed on all counts.  I think it motivates having a discussion "up one
level" first, to see what the community believe the future of flowspec
is, in terms of what types of devices in the near future are envisioned
to be utilizing flowspec routes, whether everyone only intends to use
them intra-domain or across one or more AS hops, etc.

Maybe everyone already implicitly agrees on these, and I just haven't
understood, but I think it would help to be explicit.


-- 
Wes Eddy
MTI Systems