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

With the APN WG we are investigating a  similar stateful use of flow label
for APP ID signaling but then the problem exists with either  breaking
local ECMP hash or the APN ID field being reset by local stateless hash
function.

Let’s say all routers vendors are using the flow label for local stateless
ECMP hash, how does an app or Edge node connected to the application set
the APP ID as as soon as it hits a router doing local stateless the APP ID
set by application or by ingress leaf or TOR or CE would get reset by the
first node performing local stateless load balancing.

So the way RFC 6437 stands today the use of the flow label for stateful for
PM telemetry signaling or for APN ID or any other use case really would not
work.

Kind Regards

Gyan

On Sat, Apr 10, 2021 at 12:56 AM Gyan Mishra <hayabusagsm@gmail.com> wrote:

>
> RFC 6437 does talk about both stateless 5 tuple hash for uniform load
> balancing as well as stateless flow label for signaling.  The RFC says both
> can be used simultaneously but I don’t see how that’s possible.
>
> In theory if that were possible the flow label could be used for PM
> telemetry but that is not possible as the 20 bits have to be used for
> stateless or stateful but not both simultaneously.
>
> I believe this draft is an attempt to allow the flow label to serve two
> functions simultaneously both stateless ECMP load balancing FLE 16 bits and
> stateful 4 bits for PM signaling and monitoring.
>
> I understand the restructuring of the 20 bits but the major issue is
> backwards compatibility.
>
>
> Kind Regards
>
> Gyan
>
> On Sat, Apr 10, 2021 at 12:46 AM Gyan Mishra <hayabusagsm@gmail.com>
> wrote:
>
>>
>> +1 to Ron’s comment on backwards compatibility as the primary goal and
>> benefit of RFC 6437 is stateless locally significant uniform load balancing
>> with 5-tuple hash to generate the 20 bit flow label input key to a hash
>> function  and as Ron pointed out all 20 bits in the flow label are used for
>> the load balancing hash.
>>
>> RFC 6437 uniform per flow load balancing is one of the many benefits of
>> migration to IPv6 data plane IPv6 only - SRv6 or SR-MPLSv6 core for
>> operators.
>>
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Thu, Apr 8, 2021 at 6:13 PM Ron Bonica <rbonica=
>> 40juniper.net@dmarc.ietf.org> wrote:
>>
>>> 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, internet-drafts@ietf.org 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
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --
>
> <http://www.verizon.com/>
>
> *Gyan Mishra*
>
> *Network Solutions A**rchitect *
>
> *Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*
>
>
>
> *M 301 502-1347*
>
> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email gyan.s.mishra@verizon.com <gyan.s.mishra@verizon.com>*

*M 301 502-1347*