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

["Jakob Heitz (jheitz)" <[e-mail]>]

Regards,
Jakob.


On Apr 15, 2021, at 2:43 AM, Robert Raszuk <[e-mail]> wrote:


All,

Yes what Jakob and now Jeff are saying makes sense. If we are to introduce this capability it should be only about what BGP peer understands as part of the NLRI. Nothing to do with data plane and filtering. Just observe that even if data plane supports it and even of operator enables it filter may still fail to get installed due to no space. So we never know at BGP level what got installed and what not.

That's being just a little over dramatic. It's the case with all BGP. For any use case where it really matters and the originator must know exactly when and where its originated NLRI got installed, we don't use BGP.


Now - I am still seriously concerned to add this to v1. Well unless we also add the notion of optional types. That means that when setting up a filter (manually or programmatically) types have an "Optional" flag - which means that if a peer does not support this type it is ok to drop it and sent all remaining types in NLRI instead of not sending the entire NLRI at all.

That would provide some tools to make sure that v1 deployments are intact.

Thx,
R.





On Thu, Apr 15, 2021 at 5:37 AM Jakob Heitz (jheitz) <jheitz=[e-mail]<mailto:[e-mail]>> wrote:
I agree.
The capability is exchanged only with neighbors and thus is
not capable of informing the capabilities of all BGP speakers
in the network. A more capable network management method
is needed for that.

The BGP capability is only useful to avoid sending a flowspec
to a neighbor that it would consider as malformed.

Regards,
Jakob.

-----Original Message-----
From: Idr <[e-mail]<mailto:[e-mail]>> On Behalf Of Jeffrey Haas
Sent: Wednesday, April 14, 2021 5:43 PM
To: Dongjie (Jimmy) <[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>
Subject: Re: [Idr] [[e-mail]<mailto:[e-mail]>: I-D Action: draft-haas-flowspec-capability-bits-02.txt]

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

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr

_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr