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

[Christoph Loibl <[e-mail]>]

Hi Benjamin,

Since I did not see any objections on the list I edited this as suggested into the document:

   This component uses the Numeric Operator (numeric_op) described in
   [I-D.ietf-idr-rfc5575bis] Section 4.2.1.1.  Type 13 component values
   SHOULD be encoded as 4-octet quantities (numeric_op len=10).

Cheers

Christoph

-- 
Christoph Loibl
[e-mail] | CL8-RIPE | PGP-Key-ID: 0x4B2C0055 | http://www.nextlayer.at



> On 09.11.2020, at 21:58, Benjamin Kaduk <[e-mail]> wrote:
> 
> 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