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

["Ahmed Abdelsalam (ahabdels)" <[e-mail]>]

Hi Tom, 

Please my answers inline [AA]


-----Original Message-----
From: Tom Herbert <[e-mail]>
Date: Monday, 12 April 2021 at 18:32
To: ahabdels <[e-mail]>
Cc: 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 Mon, Apr 12, 2021 at 9:02 AM Ahmed Abdelsalam (ahabdels)
    <ahabdels=[e-mail]> 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.
    >
    Ahmed,

    I will point out that the draft steals 4 bits from the flow label as
    opposed to one bit. As for HopByHop extension header being inefficient
    that is in the eye of the beholder.

[AA] inefficient in the sense to have device parse/process full HBH header in fast path when what you need is one or couple of bits for packet marking. 

    > 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.

    That is currently just a proposal and not yet a WG item, and it
    wouldn't require that number of HBH options must be one.
[AA]  draft-hinden-6man-hbh-processing states there MUST only be one option. Text below from the draft: 

"The Hop-by-Hop Options Header as defined in [RFC8200] can contain one
   or more Hop-by-Hop options.  This document updates [RFC8200] such
   that there MUST only be one option contained in an Hop-by-Hop Options
   header in a single packet.  The motivation for this change is to
   simplify the processing of Hop-by-Hop options in the fast path."

    >
    > 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.
    >
    Sure, but again the bits in the flow label are not available for
    reassignement. IMO, the protocol being proposed is not robust.
    Furthermore, the fact that a protocol is targeted to a limited domain
    is not a valid raitionale to dismiss the established priniciples of
    robustness and interoperability, and note that "limited domain" has no
    normative defition so this draft probably should be Experimental as
    opposed to Standards Track.

    Tom

    > Cheers,
    > Ahmed
    >
    > -----Original Message-----
    > From: Ron Bonica <[e-mail]>
    > Date: Friday, 9 April 2021 at 00:13
    > To: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
    > Subject: RE: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
    > Resent from: <[e-mail]>
    > Resent to: <[e-mail]>, ahabdels <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
    > Resent date: Friday, 9 April 2021 at 00:13
    >
    >     Clarence,
    >
    >     Draft-filsfils-6man-structured-flow-label addresses a real problem. However, it may have issues with regard to backwards compatibility and IPv6 extensibility. Each is addressed below.
    >
    >     Backwards Compatibility
    >     ====================
    >     In the draft, you divide the flow label into 4 FLC bits and 16 FLE bits. The 4 FLC bits carry per-packet control information and are not used for ECMP load-balancing. The 16 FLE bits are as defined in RFC 6437.
    >
    >     This raises the issue of backwards compatibility. Many legacy devices IPv6 devices use all 20 bits of the flow label as defined in RFC 6437. As you say in  Section 4, this could cause packets belonging to a single flow to be distributed among multiple paths. So, the degree of packet reordering at the ultimate destination node will increase to an unacceptable level.
    >
    >     IPv6 Extensibility
    >     ==============
    >
    >     Over the past decade, there have been several proposals that take the following form:
    >
    >     - An IPv6 source node needs to convey some piece of information to every node along the packet's delivery path
    >     - Field X in the IPv6 header is longer than it needs to be
    >     - So, we can borrow a few bits from Field X to convey this information.
    >
    >     This approach is flawed for the following reasons:
    >
    >     - It can cause backwards compatibility issues, as described above
    >     - It only works a few times, until there are no more bits to be borrowed in the base IPv6 header
    >
    >     IPv6 includes a Hop-by-hop Options header. It's purpose is to convey information from the source node to every node along the packet's delivery path. Sadly, it was implemented badly so that it can be used as a DoS vector. Therefore, network operators generally filter it.
    >
    >     A better approach would be:
    >
    >     - to avoid borrowing bits from the IPv6 header
    >     - to use the HBH Option for its intended purpose
    >
    >     This will require rehabilitation of the HBH option. Bob Hinden and Gorry Fairhurst have made a good start towards this goal in draft-hinden-6man-hbh-processing. We vendors will also need to get behind the rehabilitation effort, revising our implementations so that it can no longer be used as a DoS vector. In turn, network operators will also need to get behind the rehabilitation effort.
    >
    >     While this may not be the path of least resistance, it will contribute to the future extensibility of IPv6. Let's do the right thing.
    >
    >                                                                                                        Ron
    >
    >
    >
    >
    >
    >     On 17-Mar-21 05:49, [e-mail] wrote:
    >     >
    >     > A New Internet-Draft is available from the on-line Internet-Drafts directories.
    >     >
    >     >
    >     >         Title           : Structured Flow Label
    >     >         Authors         : Clarence Filsfils
    >     >                           Ahmed Abdelsalam
    >     >                           Shay Zadok
    >     >                           Xiaohu Xu
    >     >                           Weiqiang Cheng
    >     >                           Daniel Voyer
    >     >                           Pablo Camarillo Garvia
    >     >       Filename        : draft-filsfils-6man-structured-flow-label-00.txt
    >     >       Pages           : 12
    >     >       Date            : 2021-03-16
    >     >
    >
    >
    >     Juniper Business Use Only
    >
    > --------------------------------------------------------------------
    > IETF IPv6 working group mailing list
    > [e-mail]
    > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
    > --------------------------------------------------------------------