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

"Dongjie (Jimmy)" <> Wed, 14 April 2021 15:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D37BA3A141B for <>; Wed, 14 Apr 2021 08:22:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=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 wsYI7CsFWeXi for <>; Wed, 14 Apr 2021 08:22:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C07063A1347 for <>; Wed, 14 Apr 2021 08:21:58 -0700 (PDT)
Received: from (unknown []) by (SkyGuard) with ESMTP id 4FL5cK3YwGz682ml for <>; Wed, 14 Apr 2021 23:14:41 +0800 (CST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.1.2106.2; Wed, 14 Apr 2021 17:21:56 +0200
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2106.2; Wed, 14 Apr 2021 23:21:54 +0800
Received: from ([]) by ([]) with mapi id 15.01.2106.013; Wed, 14 Apr 2021 23:21:54 +0800
From: "Dongjie (Jimmy)" <>
To: Jeffrey Haas <>
CC: "" <>
Thread-Topic: [Idr] [ I-D Action: draft-haas-flowspec-capability-bits-02.txt]
Thread-Index: AQHXLXlmAc8Q1Y7BnUGpbs2hLpyRdqqxHmrg//+Ja4CAA2/K0A==
Date: Wed, 14 Apr 2021 15:21:54 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US, zh-CN
Content-Language: zh-CN
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
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: Wed, 14 Apr 2021 15:22:13 -0000

Hi Jeff, 

Thanks for your reply, and please see some further discussion inline:

> -----Original Message-----
> From: Jeffrey Haas []
> Sent: Tuesday, April 13, 2021 1:51 AM
> To: Dongjie (Jimmy) <>
> Cc:
> Subject: Re: [Idr] [ I-D Action:
> draft-haas-flowspec-capability-bits-02.txt]
> 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?

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. 

> > 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.

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? 

> 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. 

> 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?

Sounds reasonable, will take a look at that thread. 

> > 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.


Best regards,

> -- Jeff