Re: [Idr] [[e-mail]: I-D Action: draft-haas-flowspec-capability-bits-02.txt]

[Jeffrey Haas <[e-mail]>]

Jie,

Thanks for your feedback.

On Mon, Apr 12, 2021 at 05:04:32PM +0000, Dongjie (Jimmy) wrote:
> Hi Jeff, all, 
> 
> I've read the recent discussion and the updated version of this draft, here are some thoughts and comments: 
> 
> I fully agree that incremental deployment of new flowspec components is important, and it does not need to wait for Flowspec 2.0.
> 
> Regarding a BGP flowspec component, there could be three different capabilities: 
> 
> 1.	The capability of parsing and implementing the component as a filter
> 
> 2.	The capability of parsing and propagating the component, but not for local use
> 
> 3.	The capability of propagating the component further even it is not parsed
> 
> The first two capabilities are discussed in this thread and the updated draft, and to me it makes sense to distinguish these two capabilities. 

Operationally, how would you expect a BGP Speaker to differentiate these two cases?  

> As sometimes a flowspec rule only needs to be installed on a subset of nodes, a node which is not required to install it or even support it may be on the propagation path of the flowspec rule. If there is some mechanism to limit the propagation scope or indicate the target nodes of the flowspec, the third capability may further help the incremental deployment of new flowspec components.

The third case is unfortunately problematic right now.  Deployment
experience has shown implementations aren't willing to deal with fully
"opaque" NLRI.  We've had a number of outages resulting from parsing bugs as
it is.

With flowspec v2, the primary obstacle toward opaque but still able to be
checked for NLRI high level syntactic correctness can be done.  We know this
is still problematic once you hit a node where the inner contents are
validated and found to be problematic, but at least in this case "treat as
withdraw" procedures are capable of being done.

The underlying behavior you're discussing is the scope discussion that I
think we're in general need of, and a separate thread was forked for.
Perhaps once that's been discussed in more detail it makes sense to come
back to this third point?

> Then back to the encoding of the flowspec capability bits, if we want to consider the case that a node can propagate unknown flowspec components, one reserved bit in the bit-string may be used to indicate such capability, other mechanism is also possible. 

The encoding is the less exciting bit of the discussion. :-)  Let's revisit
this after you've clarified your first two points.

-- Jeff