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

[Robert Raszuk <[e-mail]>]

Jakob,

Pls see my last msg. It is not about originator assurance that something
got installed. It is about operator basic understanding on what is going on
in his network from BGP distribution point of view.

Also pls observe that capabilities today require session reset. Dynamic
capabilities is not there. So if I enable some filtering type on PE I need
to reset my session to RR. If more SAFIs travel over this session this will
get pretty ugly.

Perhaps we should instead define FlowSpec ORF and single new capability
"Wait for FS-ORF". FS ORF would signal to peer what types it supports.
Simple, easy and non disruptive with pretty much the same end effect.

Cheers,
R.

On Thu, Apr 15, 2021 at 3:24 PM Jakob Heitz (jheitz) <[e-mail]>
wrote:

>
>
> 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]> 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]> On Behalf Of Jeffrey Haas
>> Sent: Wednesday, April 14, 2021 5:43 PM
>> To: Dongjie (Jimmy) <[e-mail]>
>> Cc: [e-mail]
>> Subject: Re: [Idr] [[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]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>