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

Robert Raszuk <> Thu, 08 April 2021 07:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 23F593A3E49 for <>; Thu, 8 Apr 2021 00:36:27 -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 c1pDT4a1NQ6a for <>; Thu, 8 Apr 2021 00:36:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 376EE3A3E44 for <>; Thu, 8 Apr 2021 00:36:22 -0700 (PDT)
Received: by with SMTP id u9so1083442ljd.11 for <>; Thu, 08 Apr 2021 00:36:21 -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=/TXF8fCvmiPtlgIubn+/KBVaVMOsH//e0xhiDsqLXeo=; b=B1j3JHJuPHEn5oYwuvmslJF1lg02suQL02RBDXsDBUnvr9MQkOsVqCfzqVA7bC/hUF T25lDEQgGc2YJ7potaBIYiTMTsxh2ge6Wm3daL+3dxSVtgqPvixKHagavZIKAj5V9wZM feK/iLa/dUH9ixVkm2ROVC4X8aVDw0VomONTegyrjdXe0REumdSBZT/hrBpoc9HyEfUS gfEddklv4GUTJ6pZH6bpcGpqSBJ9u/tGP6KYvwIjLLUBl204/juVluwy/EwgYcY8DNHQ EHXaUF9r8qZhD6L5RvHl3FXO7AFg2VgN1rRDqVqCh1MMvfBz4ZgngeY4E0BIlLpKwcRe 2DTA==
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=/TXF8fCvmiPtlgIubn+/KBVaVMOsH//e0xhiDsqLXeo=; b=O22MMHPSwczK4bfPP23QqfM/HRVu44Z5IkSbhiLn3TXpmnsXsc9Rv9Y2Xc1uzZ8vH6 n/xqW4nxxJAS5kQtBmDL1cx5Q9OyYE0H92PuUzXz7FID/HWl2l28TNtQtl5rgnQl4a5C 4Q6mB9pnjsUz/VPZJZOJkTzZ0LaQiN0AnwrQFPzjnhVH/wyc8pM6YlkmCI4POnVB0+r8 dSEqWnfB0QrjoNxH5Vq8UlRc7qeXzdcdjCWmca9xg4aAGo9q38lYJ8hpWO26NioXhtcn lgzjIxuckWAM3wXk6qwjRJ7MX12+QJT+AUx9T9ayqY8Z5RNidSzqQjQWJb/DZH+qJb2v HOwg==
X-Gm-Message-State: AOAM530iE1KBYetv8AkcyBPMKfcAADqpLSyiTsxlavAwwjste2tyq97O AbmNAARtlf0UR4+4MOfgjKuBEDy/eFNgvJCjx39F4Z0Loj6a2A==
X-Google-Smtp-Source: ABdhPJwoXrfPJZGp9U51Dv7hrgZKHbtijRjQDuXd561mBC/HcZTiEcDUHlZPeuK7ijSnQWYsGd16DbWFiT0I0iQU4v0=
X-Received: by 2002:a2e:5cc7:: with SMTP id q190mr4578464ljb.37.1617867372227; Thu, 08 Apr 2021 00:36:12 -0700 (PDT)
MIME-Version: 1.0
References: <000001d72569$3eace130$bc06a390$> <> <> <> <> <> <>
In-Reply-To: <>
From: Robert Raszuk <>
Date: Thu, 8 Apr 2021 09:36:01 +0200
Message-ID: <>
To: Jeffrey Haas <>
Cc: Susan Hares <>, "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="00000000000004050a05bf711aaa"
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: Thu, 08 Apr 2021 07:36:27 -0000

Hi Jeff,

Looks like we have converged.

Would it be possible to include your below sentence explicitly/verbatim in
the draft:

"It is also an option for an implementation that understands a new component
that doesn't want to implement it in forwarding to advertise support for
that component and propagate it even if it doesn't locally use it. "

With that I am happy as that was my point. And of course anyone is free to
do what they like (both implementation and operation wise). The draft/rfc
will only provide options.


On Thu, Apr 8, 2021 at 2:24 AM Jeffrey Haas <> wrote:

> On Thu, Apr 08, 2021 at 12:30:18AM +0200, Robert Raszuk wrote:
> > You say: "So, it's a filter against NLRI that have unsupported component
> > types."
> >
> > I say: There is a significant difference between hardware support of a
> > given filtering type and BGP ability to recognize it. And that is not
> > reflected in the draft. Worse both are made equal.
> >
> > The deployment I am worried about is that lack of hardware support or
> > perhaps even configuration protecting router to dynamically install some
> > filters will trigger no capability to be sent hence in spite of software
> > fully capable of parsing the entire "new" NLRI such BGP UPDATE will not
> be
> > received. If not received it will not be propagated to peers (say EBGP
> > peers) hence the end effect of flowspec will be broken.
> Actually, it is reflected in the draft.
> : 4.  Restricting BGP Flowspec Components in a Deployment
> :
> :    The filtering components specified in [RFC8955] are well supported in
> :    implementations of the RFC.  However, as new platforms work to
> :    support not only this existing RFC, but future features,
> :    implementations may be unwilling or unable to support the packet
> :    forwarding behaviors for a given component type.  The Flowspec
> :    Capability Bits provides the ability for an implementation to limit
> :    what forms of filtering are executed by the BGP Speaker.
> It was also part of the presentation.
> I acknowledge that you might not like that as a feature.
> It is also an option for an implementation that understands a new component
> that doesn't want to implement it in forwarding to advertise support for
> that component and propagate it even if it doesn't locally use it.
> This is no worse than policy.
> It's also not a detail I'm set on as a key feature of the draft.  The core
> of the proposal is to deal with incremental deployment of new components.
> And that said, even if you put into the draft, "If you don't want to use it
> but understand it, advertise support for propagation purposes."
> Someone will still use it for filtering.  I've at least noted that will
> happen up front.
> We can perhaps have the domain discussion this implies in the thread Jakob
> has forked.
> -- Jeff