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

Jeffrey Haas <> Thu, 15 April 2021 00:20 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C75013A25F8 for <>; Wed, 14 Apr 2021 17:20:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Iwtuwbq-Mkgq for <>; Wed, 14 Apr 2021 17:20:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EF2333A25F7 for <>; Wed, 14 Apr 2021 17:20:29 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 36FAB1E459; Wed, 14 Apr 2021 20:43:11 -0400 (EDT)
Date: Wed, 14 Apr 2021 20:43:11 -0400
From: Jeffrey Haas <>
To: "Dongjie (Jimmy)" <>
Cc: "" <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <>
Subject: Re: [Idr] [ I-D Action: draft-haas-flowspec-capability-bits-02.txt]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Apr 2021 00:20:32 -0000


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

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