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

Robert Raszuk <> Fri, 09 April 2021 15:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7067F3A25C9 for <>; Fri, 9 Apr 2021 08:59:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7Bjck4bpseJ8 for <>; Fri, 9 Apr 2021 08:59:15 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 65CFC3A25C3 for <>; Fri, 9 Apr 2021 08:59:14 -0700 (PDT)
Received: by with SMTP id g8so10440486lfv.12 for <>; Fri, 09 Apr 2021 08:59:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TrnDfe+/ECE9am4Ump/GEPF3fkfs0AzljhG9o1zq/9M=; b=S8V6lM6uTjOUz1rEsAjosKyYy/MMN3kj0ut3nJhRBtMViwFdqCEoMBgHEGTkb8LfAn qI2qaL5qjJJqQztGlDY73u8DSoA1aSCxqGtD97DPGn9HpVuR/9CshSpxjiUAZjN1GaA4 55c3PeOnvwE4JhNL8Ho4GTVCqqOeFumRJpBV2+ONxNKfVhqo9oxOavAHN0aGAg9LM60W czvlDc9mdcT3LFQU69yApo2DGcZBJFT69PkZqRIRkh1bf29jqSGVFFhjGw5htjd1duYL hyFbpLwxP15PrtYxzVwvDDVWF76spgLBf3lnqYc1pEUojV44jZziOvmYJjmykCsonfr0 H9zQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TrnDfe+/ECE9am4Ump/GEPF3fkfs0AzljhG9o1zq/9M=; b=lvKFDpXI0lY05LvgDThdLDPBLBFjoJp9wrfKfHnUymC+8rWjbJaT6LTqQnIn7jC89T amOEPX+aRA/z/fHxMTaSjtnJBOSe2/tsIaspEGc9ZTDZWCXilD0AbiU0dyghA4DF75ao Hd+GwhWD7Q/sF8RLJU1v/LvjdjttAmcY8gfLMcooFfGaxdeeQ/bUNXYcQpsEBLrCcg4V 09seQ/D7znMAglEt1pduTYUza2FtYjz6tZN6UCx6DgIqL0WbeRor3ptaHCKJkn5HYlPN ibbCxfvRoDlw060rNlwnEPkI2j+gOi7PTSi4frn1V39mIUi1ySPFd7m6nw/uw6XS48VE K9IA==
X-Gm-Message-State: AOAM53221cRQcNyYdhUCiMJ+5h8wu9wBUnhkBOwHCuvWuAkVZSj02QJY mug74KtYTIvxVTNR+WFEmurm+9bC3HUBmOSVInQaIg==
X-Google-Smtp-Source: ABdhPJxzhiPfNc0KDuHydnXI3pVJqKKBeGbnh67FBN7y1QgG0X88QN4RD6n9d8suBkT/ZibZC7oM+FxRiW6lceXFNkA=
X-Received: by 2002:a19:6f4d:: with SMTP id n13mr5039105lfk.591.1617983947548; Fri, 09 Apr 2021 08:59:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <005b01d72cf3$4f39c4a0$edad4de0$> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Fri, 9 Apr 2021 17:58:57 +0200
Message-ID: <>
To: Jeffrey Haas <>
Cc: "Jakob Heitz (jheitz)" <>, Aijun Wang <>, "Aseem Choudhary (asechoud)" <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="00000000000072405605bf8c3ebe"
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:59:19 -0000


Before answering first I wanted to get clarity on question #1. Now I have
it. Hence ready to answer the questions:

> 1) Is this document clear about the proposal?

No. Current text gives too much freedom to implementation in what they want
to signal in the capabilities (supported by platform filters, enabled by
platform filters, recognizable by BGP types).

> 2) Do you think we should do this with Flow Specification v2?
> Or should we do this instead of Flow Specification v2?

We should stop changing Flowspec v1 and shift all this new work to Flowspec
v2. It is just one new SAFI. We could perhaps also rename it to
Confspec instead of mixing it with Flowspec as number of requested new
changes or additions do not even describe the IP packet flows.

IMO there is no need to do interim solutions. For one we will never be done
with interim and it will be much harder to move to new clean solution.

> 3) Will this help operational networks?

It could help, but only in some deployment scenarios and with obvious
danger to break flowspec v1 original deployment use case.

Many thx,

On Fri, Apr 9, 2021 at 5:45 PM Jeffrey Haas <> wrote:

> Robert,
> On Fri, Apr 09, 2021 at 05:34:54PM +0200, Robert Raszuk wrote:
> > IDR WG and AD made a decision many months back that no new features you
> may
> > be referring to sitting in your backlog will be added to flowspec v1. Did
> > you miss that - I think so based on your replies.
> Considering that the recommendation was based in part on my commentary on
> the work for RFC 8955 and the problems with incremental deployment of new
> features... why yes, I'm familiar with the motivations for the current
> status quo.
> The motivation for this draft is to see if we have a way forward in the
> interim.
> > > The point of the proposal is to offer an option that addresses
> incremental
> > > deployment of new flowspec features without requiring a flowspec v2.
> >
> > And that is the key src of my objection as I see what is being cooked
> here.
> > It is against already reached WG consensus. New features should go to
> FSv2
> > leaving FSv1 to do its original job.
> I'd request you go back to Sue's simple 3 question adoption request and
> just
> answer the questions there.
> Thanks.
> -- Jeff