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

[Ron Bonica <[e-mail]>]

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) <[e-mail]> 
Sent: Tuesday, April 13, 2021 12:18 PM
To: Ron Bonica <[e-mail]>; Brian E Carpenter <[e-mail]>; [e-mail]; [e-mail]
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 <[e-mail]>
Date: Tuesday, 13 April 2021 at 15:25
To: ahabdels <[e-mail]>, Brian E Carpenter <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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) <[e-mail]>
    Sent: Tuesday, April 13, 2021 4:48 AM
    To: Brian E Carpenter <[e-mail]>; Ron Bonica <[e-mail]>; [e-mail]; [e-mail]
    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 <[e-mail]>
    Date: Monday, 12 April 2021 at 22:41
    To: ahabdels <[e-mail]>, Ron Bonica <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
    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