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

Aijun Wang <> Fri, 09 April 2021 03:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE4F23A2A0B for <>; Thu, 8 Apr 2021 20:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id geoMZ2c4PewC for <>; Thu, 8 Apr 2021 20:49:25 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D7CFA3A2A06 for <>; Thu, 8 Apr 2021 20:49:22 -0700 (PDT)
Received: from DESKTOP2IOH5QC (unknown []) by (Hmail) with ESMTPA id F2DB91C0108; Fri, 9 Apr 2021 11:49:14 +0800 (CST)
From: "Aijun Wang" <>
To: "'Aseem Choudhary \(asechoud\)'" <>, "'Jeffrey Haas'" <>
Cc: "'idr@ietf. org'" <>
References: <000001d72569$3eace130$bc06a390$> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Date: Fri, 9 Apr 2021 11:49:14 +0800
Message-ID: <005b01d72cf3$4f39c4a0$edad4de0$>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_005C_01D72D36.5D612350"
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQIqapUVSityAkuEw+t6JlAqFbED8gGNn27YAgp9UJ8CD+enJgH4N46UAlpBbagB6cI1CgJnp2s+AfutW2gB6qCgAAIVQ1QIAadLmjepVZdK0A==
Content-Language: zh-cn
X-HM-Tid: 0a78b4bf8ad3d993kuwsf2db91c0108
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: Fri, 09 Apr 2021 03:49:31 -0000

And, how to express the IPv4 filter(parsing) capabilities and IPv6 filter(parsing) capabilities individually?


Based on the discussion, how about change the capabilities name from “BGP Flowspec Capability Bits” to “BGP Flowspec Parsing Capability Bits”?

Then the BGP neighbor will not send the un-recognized component type. For the recognized component type, the routers within the domain will propagate the flowspec NLRI regardless of their actions on these rules.



Best Regards


Aijun Wang

China Telecom


From: <> On Behalf Of Aseem Choudhary (asechoud)
Sent: Friday, April 9, 2021 11:08 AM
To: Jeffrey Haas <>
Cc: idr@ietf. org <>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13


Hi Jeff,


I have couple of questions/clarification, maybe I am missing something:


1.       In Section 2 of the draft, there is an example of IPv6 and below text:



Bit 0 set to 0, bits 1..14 set to 1 showing support for all

      capabilities for IPv6 Flowspec, bit 15 is set to 0.



Reference has been given for RFC 8955 and in section 3, reference has been given for Section 8 (IANA Consideration).
Both these documents describe IPv6 having 13 components. I am missing where the 14th component in IPv6 defined and if so, can it be referred accordingly. 
2.       To me, this document describes a capability for each filter parameter (component type). So, looking from that way, I see few more parameters defined in component type 12 for LF, FF, IsF for IPv6 (section 3.6 rfc 8955) and LF,FF,IsF, DF for IPv4 ( rrfc 8956).
My question is: why not also define the capability of these parameters as well separately. To me these are different filter parameters like any other even though defined as single component type and can’t be compared with separate flag bits in TCP (component 8). This way, capability may be defined more granular.

From: Idr < <> > on behalf of Gyan Mishra < <> >
Date: Thursday, April 8, 2021 at 6:11 PM
To: "Jakob Heitz (jheitz)" < <> >
Cc: "idr@ietf. org <mailto:idr@ietf.%20org> " < <> >
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13



Agreed.   +1


On Thu, Apr 8, 2021 at 8:36 PM Jakob Heitz (jheitz) < <> > wrote:

This makes sense.

You should probably modify or delete section 4.

A BGP speaker has basically 2 jobs. 1. to propagate a received route to other neighbors and 2. to act on the route (install the filter). A BGP capability advertised by a router is only known to the neighbor of that router, not necessarily to the originator of a route. Therefore, BGP capabilities are an insufficient means to discover the capabilities of all routers in a network. All that BGP capabilities can really do is to prevent a neighbor from tearing down a BGP session when you send it a route it does not recognize (by enabling you to not send the unrecognized route in the first place). To find out how many routers in your network will install a given flowspec requires more capable network management techniques.


-----Original Message-----
From: Idr < <> > On Behalf Of Jeffrey Haas
Sent: Thursday, April 8, 2021 3:43 AM
To: Robert Raszuk < <> >
Cc: idr@ietf. org < <> >; Susan Hares < <> >
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13

On Thu, Apr 08, 2021 at 09:36:01AM +0200, Robert Raszuk wrote:
> Hi Jeff,
> Looks like we have converged.
> Would it be possible to include your below sentence explicitly/verbatim in
> the draft:
> "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. "
> With that I am happy as that was my point. And of course anyone is free to
> do what they like (both implementation and operation wise). The draft/rfc
> will only provide options.

I'm happy to add some text to this effect.

-- Jeff

Idr mailing list <>

Idr mailing list <>



Gyan Mishra

Network Solutions Architect 

Email <> 

M 301 502-1347