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

Robert Raszuk <> Wed, 07 April 2021 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0E2CB3A23FD for <>; Wed, 7 Apr 2021 11:27:24 -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, 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 epUxOOGeT8js for <>; Wed, 7 Apr 2021 11:27:19 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C9C43A23F4 for <>; Wed, 7 Apr 2021 11:27:19 -0700 (PDT)
Received: by with SMTP id o126so30165350lfa.0 for <>; Wed, 07 Apr 2021 11:27:19 -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=1gbbfGwhcqEQ4YMEGifyOI5exQx66rLIgSRdumS4JBc=; b=PMN4EJhwa8xfpmpobuai+ct5iLeL6jK8vGox8lQHgR728VVZE04jzDRQCsOysPrN0E FgyTmAGruPEIvS2qFzDMuTtKIYpONDSuWVTXL0OIIY74YuPD9zSLs+2SbT/VJ3wvDQu2 XZs79R0nJb2XRDfvL4pvOu2EhuCNTytufIO3+BXD8GeogxAO2ENsUU+TYE6jHwsHfKm8 cBgJsouyIc2VbN3toz32KIhKGiBkJFWUPbvwYDoM8Xvx6QHyyRx3hpn4s34nAysL5F3R 1+//uGO11IX41xnDP3MrJRJA9iqfMZBx9ShftqGxmqDZ3ot65uxMqSHIr7dWNxq//P09 WxKA==
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=1gbbfGwhcqEQ4YMEGifyOI5exQx66rLIgSRdumS4JBc=; b=ckHPTtr1zGhcjaGowSb0ESelMAcY/bCZ/+wxxDiR4d46bEgrg8CAG4gIczyHLv1zZD y1dqinufbI33g/bAUu7dZj982qekTaBbOgHt8eunxQhcf+ZE3s3DTR9fOrVq1m7IZhrb 2hwU8ne+DIoG0SN1g5X6Ji3zrBxDB15p81saQcLN/otFlu7PvKpj4q+lPJRgEuDzeHMM 01kbgvS/2kHtmukp1ipjy2gDXPynD6WNn/iYUZfh7f39XPmS8rSOXntcawh7LjvFIaau s0W9xHMD8Ndep7QrOqh49SPXH+KKih54wnp/SJkIBvPty5U5ISSWZGZHTTLQv0d7np+F QOWQ==
X-Gm-Message-State: AOAM533Jnlz7sKw7KIUTCkkUVhDDi3nbXFoxU2aQRPyfKl0wgEq1IHz0 VYe+Dk8MZL+jHRYPljvaumZ3K6ws/1bCMMVobAgiTJXleps=
X-Google-Smtp-Source: ABdhPJwYx8XkX6Cy7SoA+yTZvYWmKkTAUE3GkDczHXBWYM7UhxnyZj+MPPD3EHASezEHSYuP/TLX/3Aw8Vu8oS5xcq0=
X-Received: by 2002:a19:651b:: with SMTP id z27mr3218241lfb.517.1617820035918; Wed, 07 Apr 2021 11:27:15 -0700 (PDT)
MIME-Version: 1.0
References: <000001d72569$3eace130$bc06a390$> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Wed, 7 Apr 2021 20:27:06 +0200
Message-ID: <>
To: Jeffrey Haas <>
Cc: Susan Hares <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="0000000000008d485d05bf66148a"
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 18:27:26 -0000

Hi Jeff,

I think you're mixing some of the points together.

I think actually I am not the one who is mixing it here.

Not a single BGP flowspec implementation implemented the "opaque" property
> in RFC 5575.  Not one.  And it was the strong motivation to remove that
> text
> in RFC 8955.

This is the crux.

The way I read the current draft is that you are putting an equal sign into
supported filtering and advertised capability.

That is not what I would do.

While subject to separate discussion perhaps it is ok to expect BGP to
parse NLRI and validate the types it carries. I am fine with that. But this
is a control plane. This has nothing to do with platform capabilities to
actually perform filtering on such types. That is also an easy software
upgrade across the network.

Even if platform does not support given filtering the bgp speaker will
accept the update and advertise it further. Mission accomplished. Flowspec
is not broken and has a chance to work downstream.

Contrary to the above what's being cooked here is severely breaking the
flowspec propagation chain to hardware capabilities (as most of the
filtering will likely occur in hardware at decent rates).

Now I wonder what is your take on this point ?