Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

The normal way to interpret an IETF specification is that unless a behaviour is proscribed in the specification, it is allowed.

It is useful that Ron has noted the existence of routers that ECMP on those bits in the wild, but the only safe way to have proceeded would have been to assume that such routers existed since such behaviour was consistent with a reasonable interpretation of the standard.

- Stewart

> On 13 Apr 2021, at 19:23, Ron Bonica <rbonica=40juniper.net@dmarc.ietf.org> wrote:
> 
> Ahmed,
> 
> I know of at least three platforms that use these four bits in flow hash computation, as described in RFC 6437.
> 
>                                                                                                     Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -----Original Message-----
> From: Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com> 
> Sent: Tuesday, April 13, 2021 12:18 PM
> To: Ron Bonica <rbonica@juniper.net>; Brian E Carpenter <brian.e.carpenter@gmail.com>; 6man@ietf.org; draft-filsfils-6man-structured-flow-label@ietf.org
> Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
> 
> [External Email. Be cautious of content]
> 
> 
> Ron,
> 
> As reported in section 4, these 4-bits of Flow Label are not used for Flow hash computing. Also this makes FLE, used for load-balancing keys generation, to be byte aligned.
> 
> Cheers,
> Ahmed
> 
> -----Original Message-----
> From: Ron Bonica <rbonica@juniper.net>
> Date: Tuesday, 13 April 2021 at 15:25
> To: ahabdels <ahabdels@cisco.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "6man@ietf.org" <6man@ietf.org>, "draft-filsfils-6man-structured-flow-label@ietf.org" <draft-filsfils-6man-structured-flow-label@ietf.org>
> Subject: RE: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
> 
>    Ahmed,
> 
>    I understand that you need to convey four bits of additional information in basic IPv6 header. Why did you choose to encode this information in the high order bits of the flow label? Why did you not choose to encode this information in the low order bits if the IPv6 destination address?
> 
>                                                                                                                                                      Ron
> 
> 
>    Juniper Business Use Only
> 
>    -----Original Message-----
>    From: Ahmed Abdelsalam (ahabdels) <ahabdels@cisco.com>
>    Sent: Tuesday, April 13, 2021 4:48 AM
>    To: Brian E Carpenter <brian.e.carpenter@gmail.com>; Ron Bonica <rbonica@juniper.net>; 6man@ietf.org; draft-filsfils-6man-structured-flow-label@ietf.org
>    Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
> 
>    [External Email. Be cautious of content]
> 
> 
>    Inline [AA]
> 
>    -----Original Message-----
>    From: Brian E Carpenter <brian.e.carpenter@gmail.com>
>    Date: Monday, 12 April 2021 at 22:41
>    To: ahabdels <ahabdels@cisco.com>, Ron Bonica <rbonica@juniper.net>, "6man@ietf.org" <6man@ietf.org>, "draft-filsfils-6man-structured-flow-label@ietf.org" <draft-filsfils-6man-structured-flow-label@ietf.org>
>    Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
> 
>        On 13-Apr-21 04:01, Ahmed Abdelsalam (ahabdels) wrote:
>> Hi Ron,
>> 
>> Thanks for reading the draft. I think we agree on the problem statement
>> 
>> In our view using a 256-bit HopByHop extension header to encode a 1-bit flag, is far from efficient.
>> 
>> Also, as you point out, the proposed update in draft-hinden-6man-hbh-processing (which in my view is going in the right direction), limits HBH to one single header with one single option. If we encode the flag in a HbH option, we won’t be able to use HBH for anything else.
>> 
>> Structured FL can be used for packet marking while HBH can be used in many other use-cases that require more than simple packet marking.
> 
>        But there is no such thing as a structured flow label, because the standard specifies it as a 20-bit pseudo-random value. As my and other replies have shown, the proposal is not a backwards compatible change except possibly in limited domains. From a glance at my inbox, that has now become the main topic of discussion.
> 
>    [AA] Brain, Yes. This draft targets limited domain. We highlighted this in Recommended Design section and in next revision we are going to state this at the beginning of the draft.
> 
>           Brian
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------