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

Robert Raszuk <> Wed, 07 April 2021 10:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFF093A164B for <>; Wed, 7 Apr 2021 03:29:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Status: No, score=-2.097 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_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6Zy9n7rtHrjF for <>; Wed, 7 Apr 2021 03:29:33 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4163A3A1644 for <>; Wed, 7 Apr 2021 03:29:33 -0700 (PDT)
Received: by with SMTP id g8so27625386lfv.12 for <>; Wed, 07 Apr 2021 03:29:32 -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=4TvZgVq5GBtTmH0eD6ri+MvIvhz9/EnSZn/s3dJhyGk=; b=Yd28QCcd+A/GK8c4Mhp9WjwtPuHBw+xbDJcAzcCRTGlEEMSUrXicRBtOLFATCT+49L xCw8uAdxzN+G/pUlPqJi86k02aFAjPGhRJZ+Q4cO0Lf4QcROTN3U63kgXlGFgEqRDLtV YS+Dx0u7HC2I3EYbnXz++dIJlrrPd+hIA+D0feN2zwGFj/xEdoRSYWYc7D6rKlQhqQXx vnqijtbSwfQHwuVBsvLcCcnD8afy+u7JVSlbJ+e+8NcKqdF4bXyn43H9jZewHTHNBwlh o/pjsydWI6RMdzr/+03LKSB0u5mqjGEtq0X75SmVyKWBZ8lpico96jScku8lFMIrgjOs JbEA==
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=4TvZgVq5GBtTmH0eD6ri+MvIvhz9/EnSZn/s3dJhyGk=; b=CEbZZimECoSyGkkPgJIJtJy8uNYwQT+JZyzFrK+8vLeeGlqA/+gVWTq4QGNmPd47Rf S476GGkLeQ8RqFTdq3zi5rM3u1YiePNq1JJPz8ykc41m1vsfafRVAKYRi+FlcY1W3ztJ D6tBAqVTUHtbrpuc2Ay/VQ9qBYDmYMAlTYxg/ddMQAo28bWr9iatBsE4A365QAbrCZfS 7aYPT6fk7vNrNBQirPEusAovEIALX2aKtf2gbvJwTX5gKN6epnhP5KNj9STxUQxizPax 0vW8xs4CEapi1Y/VFFGVcWCEky6DyZtR9fCmKCqd5CpHDctifpPQxHv9oiSxGvvIhrfn VQkw==
X-Gm-Message-State: AOAM531t/a9E2EB4eq5FyU17U4mN+2+2DRwFAENk+WqkJsMXixJeRdAT 3q14RnlsKdqldP8f8LS328Cq0LjE6Nfh7lyncGCK/5qAeTg=
X-Google-Smtp-Source: ABdhPJxbR7WAuLBP80DXJxq78I3JySEItWWkx16pLwC5WxZIiCYVikz+F/zXhKL/XqhJvVER71lufbBKWJkRU2TgBZc=
X-Received: by 2002:a19:651b:: with SMTP id z27mr1968303lfb.517.1617791370185; Wed, 07 Apr 2021 03:29:30 -0700 (PDT)
MIME-Version: 1.0
References: <000001d72569$3eace130$bc06a390$>
In-Reply-To: <000001d72569$3eace130$bc06a390$>
From: Robert Raszuk <>
Date: Wed, 07 Apr 2021 12:29:21 +0200
Message-ID: <>
To: Susan Hares <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000f0e1df05bf5f6797"
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: Wed, 07 Apr 2021 10:29:40 -0000


I have a question on how practical this proposal is.

Fundamental problem with today's BGP capabilities is that the information
is only known to the peer.

So if I inject flowspec rule from behind the RR the RR will suppress some
updates but:

* sender will have no clue about it
* any other flow spec BGP speaker which supports request filtering down the
BGP path will never get the chance to receive and apply the filter.

Both are IMHO bad. The latter is in fact directly against flowspec spirit
to apply filtering as close to the src even if hops on the way are not
capable of doing so.

So I am yet to be convinced this proposal is useful.

Today as a general rule if a router does not support an extension received
via flowspec it just does not apply it but still can happily propagate the
update down the road.

Even if one is to use flowspec for config distribution (aside the
discussion if this is a good or bad idea) the sender behind RR or in
different ASN under the same org will never be sure if some extensions are
supported or not by the intended receiver.

I think what we have here on the table is an illustration about the growing
need for domain wide (or set of domains under the same admin) capability
distribution such that all BGP speakers could advertise their
capabilities to interested parties. A bit broader than flowspec, but could
be useful here.


On Tue, Mar 30, 2021 at 3:33 PM Susan Hares <> wrote:

> This is a Working Group adoption call for
> The draft suggests a mechanism to address our incremental deployment issues
> for BGP Flowspec.
> As you discuss this mechanism, there are 3 questions to consider:
> 1) Is this document clear about the proposal?
> 2) Do you think we should do this with Flow Specification v2?
> Or should we do this instead of Flow Specification v2?
> 3) Will this help operational networks?
> Cheerily, Susan Hares
> _______________________________________________
> Idr mailing list