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

Jeffrey Haas <> Thu, 15 April 2021 12:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 86F123A1BEA for <>; Thu, 15 Apr 2021 05:24:02 -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=unavailable autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cbes4vd9jXsf for <>; Thu, 15 Apr 2021 05:23:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EC0E23A1BFD for <>; Thu, 15 Apr 2021 05:23:56 -0700 (PDT)
Received: by (Postfix, from userid 1001) id EC4071E44B; Thu, 15 Apr 2021 08:46:39 -0400 (EDT)
Date: Thu, 15 Apr 2021 08:46:39 -0400
From: Jeffrey Haas <>
To: Robert Raszuk <>
Cc: "Jakob Heitz (jheitz)" <>, "Dongjie (Jimmy)" <>, "" <>
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 12:24:03 -0000


On Thu, Apr 15, 2021 at 11:42:40AM +0200, Robert Raszuk wrote:
> Yes what Jakob and now Jeff are saying makes sense. If we are to introduce
> this capability it should be only about what BGP peer understands as part
> of the NLRI. Nothing to do with data plane and filtering. Just observe that
> even if data plane supports it and even of operator enables it filter may
> still fail to get installed due to no space. So we never know at BGP level
> what got installed and what not.
> Now - I am still seriously concerned to add this to v1. Well unless we also
> add the notion of optional types. That means that when setting up a filter
> (manually or programmatically) types have an "Optional" flag - which means
> that if a peer does not support this type it is ok to drop it and sent all
> remaining types in NLRI instead of not sending the entire NLRI at all.

If I'm understanding this correctly as "strip some parts of the match
components", I think we'll find that problematic.

A useful bit of this conversation is we're getting discussion about what
happens when you have inconsistent filtering behaviors in a flowspec domain.
This was going to be a problem regardless of how we pass around the state
for it; flowspec v1 with new fields, or flowspec v2.

I also suspect this is not as dire as people are fearing.  Even in the route
reflector dissemination model, it's fairly common for deployments to have a
distinct route reflector plane for flowspec.  This avoids the concern that
errors in a flowspec session may have collateral damage for other address
families carried on the same peering session.

What this tends to mean is that such deployments are mostly one step away
from the targeted session deployment that is the alternative option.  This
means that grouping devices into sets that can support common classes of
filtering isn't a massive operational challenge.

That said, it's understood that passing flowspec in-band with a normal
peering session can still happen.  This will still likely be the case for
the providers that accept flowspec from their customers.  (A small number
based on my experience.)  But it does have overlap with inter-domain
deployment for the same administrative group - multiple ASes for same

-- Jeff