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

[Jeffrey Haas <[e-mail]>]

Jie,

On Wed, Apr 14, 2021 at 03:21:54PM +0000, Dongjie (Jimmy) wrote:
> > 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?
> 
> The assumption here is that not all the nodes are required to implement
> the filters (or some just don't want to), while they may be on the path of
> the flowspec rule propagation. If this is true, it may be useful for the
> operator to know the set of nodes with the first capability and the set of
> nodes with the second capability, although the capability of parsing and
> propagating is more relevant to this document. These two capabilities may
> be advertised using different mechanisms, as the first capability may be
> needed by nodes not directly peered. 

Understood.  My question is what should a BGP Speaker that has been told
that the adjacent BGP Speaker can parse a certain set of Flowspec components
but not use some of them do about it?  Is it strictly advisory?

If it's strictly advisory, I would advocate that we not worry about
publishing that part in BGP.  One motivation is that capability space is
still at somewhat of a premium without extended optional parameters.

A second motivation is there may be better mechanisms to publish the network
wide capabilities for using the filters.  I'll likely share a proposal in
the upcoming weeks.

> > 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.
> 
> I understand the problems with the "opaque" NLRI, while if the rule
> specified in the NLRI is not required (or not capable) to be implemented
> in data plane on a transit node, will it cause less harm to the network? 

My draft tries to make clear that any device that filters a rule, either
because it doesn't receive it because of lack of capability of an upstream
node, or lack of local ability, can have potential to result in
mis-forwarding.  Whether it does so or not will depend on the independence
of the rules.

If my use of "independence" is unclear, I'll share an example next round.

> > 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.
> 
> Agree flowspec v2 can help with the syntax validation to some extent.
> While if the NLRI is considered malformed, the "treat as withdraw" error
> handling may not always work. 

I think lengths in structured BGP NLRI will likely give us a hybrid
situation.  

Consider an NLRI that has a known prefix length.
Consider that it has components that have individual sub-lengths that are
clear in the protocol.

It is possible that the length of the individual components summed together
are still a valid "length" from the top level (the prefix-length) from a
high level syntactic level, but individual components may be of invalid
length or syntax.  This is similar to the situation for path attributes.

In such a case, the NLRI is malformed, but may be of enough integrity to
properly handle as an ignore/discard.

The BGP-CAR proposal and perhaps some of the evpn NLRI error handling cases have
some similar overlap to this case.  (RFC 7606 tries to be too generic about
"typed NLRI" and I think got it somewhat wrong.)

-- Jeff