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

Jeffrey Haas <> Fri, 09 April 2021 15:35 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 04A3D3A251D for <>; Fri, 9 Apr 2021 08:35:35 -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_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uGN_wbgr75t4 for <>; Fri, 9 Apr 2021 08:35:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id C95453A253E for <>; Fri, 9 Apr 2021 08:35:33 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 8635B1E459; Fri, 9 Apr 2021 11:58:01 -0400 (EDT)
Date: Fri, 9 Apr 2021 11:58:01 -0400
From: Jeffrey Haas <>
To: "Jakob Heitz (jheitz)" <>
Cc: "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: Fri, 09 Apr 2021 15:35:39 -0000

On Fri, Apr 09, 2021 at 12:36:01AM +0000, Jakob Heitz (jheitz) wrote:
> This makes sense.
> You should probably modify or delete section 4.

Certainly one of these.  The motivation of the document is to help with
incremental deployment primarily through noting what can be parsed.  The
procedure is "I don't know this component, don't send it to me".  I think
that aspect is clear.

Even if the section is completely deleted, it doesn't remove the implication
that a router may decide to limit what it advertises support for at the
discretion of the operator.  This is no different than policy.

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

I agree the capability isn't intended to address the network wide problem.
That work is deferred to a later time.

-- Jeff