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

Jeffrey Haas <jhaas@pfrc.org> Wed, 07 April 2021 22:10 UTC

Return-Path: <jhaas@slice.pfrc.org>
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 264D23A2BDF for <idr@ietfa.amsl.com>; Wed, 7 Apr 2021 15:10:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 VoV-WZLDXpfX for <idr@ietfa.amsl.com>; Wed, 7 Apr 2021 15:10:00 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 40DA43A2BCD for <idr@ietf.org>; Wed, 7 Apr 2021 15:10:00 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 4C4011E45A; Wed, 7 Apr 2021 18:32:23 -0400 (EDT)
Date: Wed, 7 Apr 2021 18:32:23 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: Robert Raszuk <robert@raszuk.net>
Cc: Susan Hares <shares@ndzh.com>, "idr@ietf. org" <idr@ietf.org>
Message-ID: <20210407223222.GD7355@pfrc.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOj+MMFaJGk7-hif7Qm7Hp1=iThn5gyvmpp+UYY_q6PJEAVAPw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/ae42amxAk7yUV4I00aCDlFu9i5I>
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: Wed, 07 Apr 2021 22:10:08 -0000

Robert,

On Wed, Apr 07, 2021 at 08:27:06PM +0200, Robert Raszuk wrote:
> > 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.

It's also not what the draft does.

:    A BGP Speaker that has received the BGP Flowspec Capability Bits
:    Capability MUST NOT transmit a BGP Flowspec encoded NLRI that
:    contains a component types that is not present in the received bit-
:    string.
: 
:    A BGP Speaker that has received a BGP Flowspec related AFI/SAFI
:    without this Capability MUST treat the absence as equivalent to
:    having received the Capability Bits covered by the base specification
:    for its defining RFC, [RFC8955] or [RFC8956].

So, it's a filter against NLRI that have unsupported component types.

It does not require that the capabilities are identical between two BGP
Speakers.

Nor does it require the capabilities to be symmetric between two BGP
Speakers.

> 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.

Section 4 already points out that understanding and willingness to use
a compoonent type are not identical.

> 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.

It's pre-broken, which is why we're having this discussion.

The two common deployment mechanisms are targeted BGP sessions to individual
routers - usually with NO_ADVERTISE, or distribution via standard BGP
propagation including route reflectors.

Presume a new filtering component, X, not in the set 1..14 of current
supported components.

A targeted session from a controller still needs to know whether it can send
X or not to a given router.  If you don't know this a priori, the first NLRI
with X contained in it will drop the session.

If a controller injects an NLRI containing X into a network that doesn't
understand it, it will propagate through the routers (e.g. route reflection)
that understand it. It will then hit the router that doesn't - and that
session drops.

There is no current way to safely do distribution of a new component X in a
hop by hop distributed domain without knowing the entire domain is safe.
This is just the recursive step of knowing that it's safe to one single
router.

Sure, you could know it via provisioning.  The penalty for guessing wrong or
mis-deployment is rough.

> 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).

I don't understand this point.

Consider contrasting it against the text in Section 5 which already talks
about the considerations for filtering.

-- Jeff

> 
> Now I wonder what is your take on this point ?
> 
> Thx,
> Robert.