Re: [Idr] Benjamin Kaduk's Discuss on draft-ietf-idr-flow-spec-v6-19: (with DISCUSS and COMMENT)

[Benjamin Kaduk <[e-mail]>]

On Mon, Nov 09, 2020 at 12:05:09PM +0100, Christoph Loibl wrote:
> Hi,
> 
> I am reading thru the discussion and trying to summarize + my comments:
> 
> > On 09.11.2020, at 05:35, Erik Kline <[e-mail]> wrote:
> > Whether randomized or not, I would imagine the use of flow label matching would be more the exception than the rule.
> 
> 
> ack.
> 
> > On 09.11.2020, at 05:32, Benjamin Kaduk <[e-mail]> wrote:
> > 
> >> On Sat, Nov 07, 2020 at 12:45:09PM +0100, Robert Raszuk wrote:
> >> Ok 3 octets to keep byte boundary sounds reasonable indeed.
> > 
> > Well, the
> > https://tools.ietf.org/html/draft-ietf-idr-rfc5575bis-27#section-4.2.1.1
> > 'len' encoding options don't give a 3-byte option for the value field.
> > Which is why I was assuming 4-bytes.
> > 
> > -Ben
> 
> Correct, if we want a 3 octets (or 20-bits) length we need to “re-invent the wheel” = we need to add a new “operator” that supports 3-byte length etc. Not only the document needs to extended, but also implementations need to take care of yet another operator encoding format. 

Exactly, and that is (IMO clearly) something for flowspec v2 if at all, not
this document.

> We can however easily require the length of the flow-label field to be 4-octets:
> 
> 	Type 13 component values MUST be encoded as 4-octet quantity 
>         (numeric_op len=10).
> 
> But this is an exception because we usually use SHOULD there in rfc5575bis (only because of historical incompatibilities that could not be changed in the -bis though), and I am not sure if adding this special case really makes it better (since it does not reduce complexity).

There do seem to be a couple "MUST"s as well (but maybe just for fields
that are smaller than 1 octet or flags, so the reasoning is a little
different than for the case we're looking at).  I don't think this issue is
significant enough that we need to diverge from 5575bis (and 5575 itself),
though, and I do see what you mean about "SHOULD" being most common.

> How can we continue?

I think it would be okay to just drop the specific mention of 1- and 2-byte
encoding for the flow label match, so we have "[t]ype 13 component values
SHOULD be encoded as 4-byte quantities (len=10)".

I'm of course happy to hear other suggestions as well!

Thanks,

Ben