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

Jeffrey Haas <jhaas@pfrc.org> Fri, 09 April 2021 14:49 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 64F4A3A23A0 for <idr@ietfa.amsl.com>; Fri, 9 Apr 2021 07:49:10 -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 GBgRJ30fiBqZ for <idr@ietfa.amsl.com>; Fri, 9 Apr 2021 07:49:08 -0700 (PDT)
Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id B52733A239B for <idr@ietf.org>; Fri, 9 Apr 2021 07:49:08 -0700 (PDT)
Received: by slice.pfrc.org (Postfix, from userid 1001) id 127E61E459; Fri, 9 Apr 2021 11:11:36 -0400 (EDT)
Date: Fri, 9 Apr 2021 11:11:35 -0400
From: Jeffrey Haas <jhaas@pfrc.org>
To: "Aseem Choudhary (asechoud)" <asechoud@cisco.com>
Cc: "idr@ietf. org" <idr@ietf.org>
Message-ID: <20210409151135.GA29502@pfrc.org>
References: <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> <CAOj+MMGukAL-fNpWh1yu=AHqnONPq9mCqqFGjK5pspFkHfn0UA@mail.gmail.com> <20210408104259.GH7355@pfrc.org> <BYAPR11MB3207F949DD2C8ECA0465CD1EC0739@BYAPR11MB3207.namprd11.prod.outlook.com> <CABNhwV1fxAXHjy7=bc5QGWi0Jt89330U93tp8Hs0wvj3wdy6og@mail.gmail.com> <8B262FE8-EEFB-44E4-8AD0-2EBD3348DEF2@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8B262FE8-EEFB-44E4-8AD0-2EBD3348DEF2@cisco.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/l7srlthb_yDEfs1JZRxT64Q_erc>
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: Fri, 09 Apr 2021 14:49:10 -0000

Aseem,

On Fri, Apr 09, 2021 at 03:08:26AM +0000, Aseem Choudhary (asechoud) wrote:
> Hi Jeff,
> 
> I have couple of questions/clarification, maybe I am missing something:
> 
> 
>   1.  In Section 2 of the draft, there is an example of IPv6 and below text:
> 
> “
> Bit 0 set to 0, bits 1..14 set to 1 showing support for all
>       capabilities for IPv6 Flowspec, bit 15 is set to 0.
> “
> 
> 
> Reference has been given for RFC 8955 and in section 3, reference has been given for Section 8 (IANA Consideration).
> 
> Both these documents describe IPv6 having 13 components. I am missing where the 14th component in IPv6 defined and if so, can it be referred accordingly.

That's an outright error.  It'll be corrected in next version.

> 2.       To me, this document describes a capability for each filter parameter (component type). So, looking from that way, I see few more parameters defined in component type 12 for LF, FF, IsF for IPv6 (section 3.6 rfc 8955) and LF,FF,IsF, DF for IPv4 (4.2.2.12 rrfc 8956).
> 
> 
> My question is: why not also define the capability of these parameters as well separately. To me these are different filter parameters like any other even though defined as single component type and can’t be compared with separate flag bits in TCP (component 8). This way, capability may be defined more granular.

This was a question I was expecting to pop up and I was curious how it'd
manifest from independent thinking rather than my text.  Thanks for going
there.

I completely agree that the types, especially vs. different AFI/SAFI, may
end up varying.  But that's not the direction the specifications went.  We
have a single registry for component types today.

This has overlap at least in Juniper's implementation: The different
AFI/SAFI combinations have a single parsing library to build the data
structure that represents a validated flowspec NLRI.  I'm curious how it
shows up in other people's implementations.

This point can move a few different directions, and will require some
consensus among the Working Group.
1. It's a single registry, and stays so for the protocol.  Thus, the
   capability is about how well the NLRI components may be understood. 
2. We can have some drift on a per AFI/SAFI basis.  An example of this was
   the discussion point I'd had with Donald Eastlake about the nvo3 spec.
   This may imply a need for this bit string to be per-AFI/SAFI.

Your broader point also touches on the one Robert and Jakob have raised
about filtering capabilities vs. carrying the signaling information.
Broadly, "What do you do when an implementation can't support a certain
filtering capability but may wish to accept - and perhaps propagate - NLRI
that contains such filtering?"

My original leaning was toward the first option.  However, the thinking
about the nvo3 use case has me leaning a bit toward the second option now.
I'm hoping to see further thinking from the working group before making
the next set of changes.

-- Jeff