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

[Jeffrey Haas <[e-mail]>]

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