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

Robert Raszuk <robert@raszuk.net> Thu, 08 April 2021 07:36 UTC

Return-Path: <robert@raszuk.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23F593A3E49 for <idr@ietfa.amsl.com>; Thu, 8 Apr 2021 00:36:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c1pDT4a1NQ6a for <idr@ietfa.amsl.com>; Thu, 8 Apr 2021 00:36:22 -0700 (PDT)
Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 376EE3A3E44 for <idr@ietf.org>; Thu, 8 Apr 2021 00:36:22 -0700 (PDT)
Received: by mail-lj1-x22e.google.com with SMTP id u9so1083442ljd.11 for <idr@ietf.org>; Thu, 08 Apr 2021 00:36:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; 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; d=1e100.net; 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$@ndzh.com> <CAOj+MMG0ONP5P4DxeaC4AEF8b_Ff43r5boQ6wL9EHHGAfVaK2w@mail.gmail.com> <20210407132506.GA7355@pfrc.org> <CAOj+MMFaJGk7-hif7Qm7Hp1=iThn5gyvmpp+UYY_q6PJEAVAPw@mail.gmail.com> <20210407223222.GD7355@pfrc.org> <CAOj+MMEmpMA9YOSU304mQed6o5gm1eUKbYNwyt88M5_E-7=woA@mail.gmail.com> <20210408004720.GF7355@pfrc.org>
In-Reply-To: <20210408004720.GF7355@pfrc.org>
From: Robert Raszuk <robert@raszuk.net>
Date: Thu, 8 Apr 2021 09:36:01 +0200
Message-ID: <CAOj+MMGukAL-fNpWh1yu=AHqnONPq9mCqqFGjK5pspFkHfn0UA@mail.gmail.com>
To: Jeffrey Haas <jhaas@pfrc.org>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf. org" <idr@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000004050a05bf711aaa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/mw9cHXMlHAU0S-NbSwohPWVKg7g>
Subject: Re: [Idr] WG adoption for draft-haas-flowspec-capability-bits - 3/30 to 4/13
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=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.

Cheers,
R.






On Thu, Apr 8, 2021 at 2:24 AM Jeffrey Haas <jhaas@pfrc.org> 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
>