Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

Jeffrey Haas <> Thu, 08 April 2021 00:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B027B3A301D for <>; Wed, 7 Apr 2021 17:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id z3mjIEZGLKVx for <>; Wed, 7 Apr 2021 17:24:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 150963A3016 for <>; Wed, 7 Apr 2021 17:24:57 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 902271E45A; Wed, 7 Apr 2021 20:47:20 -0400 (EDT)
Date: Wed, 7 Apr 2021 20:47:20 -0400
From: Jeffrey Haas <>
To: Robert Raszuk <>
Cc: Susan Hares <>, "idr@ietf. org" <>
Message-ID: <>
References: <000001d72569$3eace130$bc06a390$> <> <> <> <> <>
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] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13
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, 08 Apr 2021 00:25:00 -0000

On Thu, Apr 08, 2021 at 12:30:18AM +0200, Robert Raszuk wrote:
> You say: "So, it's a filter against NLRI that have unsupported component
> types."
> I say: There is a significant difference between hardware support of a
> given filtering type and BGP ability to recognize it. And that is not
> reflected in the draft. Worse both are made equal.
> The deployment I am worried about is that lack of hardware support or
> perhaps even configuration protecting router to dynamically install some
> filters will trigger no capability to be sent hence in spite of software
> fully capable of parsing the entire "new" NLRI such BGP UPDATE will not be
> received. If not received it will not be propagated to peers (say EBGP
> peers) hence the end effect of flowspec will be broken.

Actually, it is reflected in the draft.

: 4.  Restricting BGP Flowspec Components in a Deployment
:    The filtering components specified in [RFC8955] are well supported in
:    implementations of the RFC.  However, as new platforms work to
:    support not only this existing RFC, but future features,
:    implementations may be unwilling or unable to support the packet
:    forwarding behaviors for a given component type.  The Flowspec
:    Capability Bits provides the ability for an implementation to limit
:    what forms of filtering are executed by the BGP Speaker.

It was also part of the presentation.

I acknowledge that you might not like that as a feature.

It is also an option for an implementation that understands a new component
that doesn't want to implement it in forwarding to advertise support for
that component and propagate it even if it doesn't locally use it.  

This is no worse than policy.

It's also not a detail I'm set on as a key feature of the draft.  The core
of the proposal is to deal with incremental deployment of new components.
And that said, even if you put into the draft, "If you don't want to use it
but understand it, advertise support for propagation purposes."

Someone will still use it for filtering.  I've at least noted that will
happen up front.

We can perhaps have the domain discussion this implies in the thread Jakob
has forked.

-- Jeff