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

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Apr 2021 14:18:37 +1200

Hi,

A few comments on this draft.

As background, there have been numerous past proposals for semantics in the flow label; all the ones we could find in 2011 are discussed in https://www.rfc-editor.org/rfc/rfc6294.html. The IETF has consistently declined to adopt any of them. There's also some rationale for the current standard in https://www.rfc-editor.org/rfc/rfc6436.html.

My first comment on the present draft is that it doesn't state its target scenario (which might be LAG, because LAG is mentioned a few times). It also ignores the fact that most current operating systems follow RFC6437 by setting a 20-bit pseudorandom label for all TCP sessions. Of course this must not be changed en route across the Internet. One usage scenario is described in RFC7098, but it's clear that the draft isn't compatible with any scenario in which sources somewhere on the Internet do what RFC6437 tells them to do and downstream routers or load balancers assume that is the case. 

So is it correct that the draft is aimed only at sources (and routers and destinations) within some sort of limited domain? If so, that needs to be clearly stated at the beginning.

There is a spec for using the flow label for ECMP/LAG tunnels in RFC6438. I'd be inclined to the view that 16 pseudorandom bits would be sufficient in that case. In any case, in that case the end-to-end flow label is not affected, just the tunnel, so the fact that four bits don't contribute to the hash is tolerable.

However, just to be clear, you *cannot* declare that in a packet that goes out on the Internet, where the downstream routers support RFC6437, that 4 bits in the flow label are not part of the flow label. Such a thing would in no way be "seamless migration from RFC6437".

Relying on specific statements by a couple of router vendors about what their current products do or don't do is invalid. Other vendors might be different, and as technology evolves those two vendors might change what they do. The argument in section 4 might work for an ECMP/LAG scenario but it *certainly* doesn't work for the server farm scenario (RFC7098), which it would simply break. So rather than "seamless migration" you get "broken user sessions".

Again, you might be able to fix this by positioning the proposal for an ECMP/LAG scenario within a limited domain or a provider tunnel. But as a generic update to RFC6437, absolutely positively not.

Nit:

I'm not sure why in figs 1 and 2 you use little-endian bit numbering. It's confusing. I thought the issue was settled by RFC 791.

Regards
   Brian Carpenter

On 17-Mar-21 05:49, [email-masked] 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
> 
> Abstract:
>    This document defines the IPv6 Structured Flow Label.  The seamless
>    nature of the change to [RFC6437] is demonstrated.  Benefits of the
>    solution are explained.  Use-cases are illustrated.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-filsfils-6man-structured-flow-label/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-filsfils-6man-structured-flow-label-00
> https://datatracker.ietf.org/doc/html/draft-filsfils-6man-structured-flow-label-00
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>

---

From: Ron Bonica <[email-masked]>
Date: Thu, 8 Apr 2021 22:12:55 +0000

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

>       Filename        : draft-filsfils-6man-structured-flow-label-00.txt

Juniper Business Use Only

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Apr 2021 15:38:47 +1200

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

And the use of the flow label for server-farm load balancing will be completely broken. That's why this idea is a non-starter outside a limited domain.

    Brian

> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 9 Apr 2021 21:22:16 -0700

To my memory, around 2015 Tom Herbert submitted a kernel patch that would change flow label based on RTO, and this has been successfully used for “self healing fabrics” in large DCs to rebalance flows. Since every piece of silicon in DC that takes flow label into consideration when hashing the  traffic uses full 20 bits - repurposing part of it would break it.
This and similar solutions would need to be addressed.

Regards,
Jeff

> On Apr 9, 2021, at 20:39, Brian E Carpenter <[email-masked]> wrote:
>

---

From: Tom Herbert <[email-masked]>
Date: Fri, 9 Apr 2021 21:38:01 -0700

> This and similar solutions would need to be addressed.

Jeff,

Yes, flow labels are commonly set by all the major OSes now, all
twenty bits are used, and there are deployed intermediate nodes that
act on those bts. The opportunity to repurpose flow label bits is long
gone, and it probably wouldn't even work in a limited domain. The best
direction is a HBH option.

Tom

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 10 Apr 2021 00:46:48 -0400

+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=
[email-masked]> 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
> ==============
>
> 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.
>
> 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
>
>
>
>
>
-- 

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

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [email-masked] <[email-masked]>*

*M 301 502-1347*

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 10 Apr 2021 00:56:27 -0400

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 <[email-masked]> wrote:

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

*Gyan Mishra*

*M 301 502-1347*

---

From: Jeff Tantsura <[email-masked]>
Date: Fri, 9 Apr 2021 22:05:30 -0700

Thanks Tom, exactly my point.

Regards,
Jeff

> On Apr 9, 2021, at 21:38, Tom Herbert <[email-masked]> wrote:
>

---

From: Gyan Mishra <[email-masked]>
Date: Sat, 10 Apr 2021 01:09:13 -0400

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 <[email-masked]> wrote:

>>> 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
>>>
>>>
>>>
>>>
>>>
>>> >       Filename        :
>>> draft-filsfils-6man-structured-flow-label-00.txt
>>> >       Pages           : 12
>>> >       Date            : 2021-03-16
>>> >
>>>
>>>

*Gyan Mishra*

*M 301 502-1347*

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 10 Apr 2021 17:21:03 +1200

On 10-Apr-21 16:56, Gyan Mishra 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.

If a particular subset of hosts run a protocol that pre-assigns flow labels in some *stateful* way among that set of hosts, they shouldn't disturb everybody else who follows the RFC. That was the theory, anyway. It's never been tested to my knowledge.

    Brian

> 
> 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 <[email-masked] <mailto:[email-masked]>> 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=[email-masked] <mailto:[email-masked]>> wrote:
> 
>         Clarence,
> 
>         On 17-Mar-21 05:49, [email-masked] <mailto:[email-masked]> wrote:
>         >
>         [email-masked] <mailto:[email-masked]>
>     /Network Solutions A//rchitect /
> 
>     /Email [email-masked] <mailto:[email-masked]>//
>     /
> 
>     /M 301 502-1347
> 
>     /
> 
> 
> -- 
> 
> /Network Solutions A//rchitect /
> 
> /Email [email-masked] <mailto:[email-masked]>//
> /
> 
> /M 301 502-1347
> 
> /
> 
> 
>

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Mon, 12 Apr 2021 16:01:17 +0000

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.

Cheers,
Ahmed 

-----Original Message-----
From: Ron Bonica <[email-masked]>
Date: Friday, 9 April 2021 at 00:13
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
Resent from: <[email-masked]>
Resent to: <[email-masked]>, ahabdels <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Friday, 9 April 2021 at 00:13

    Clarence,

    Backwards Compatibility
    ==================== 

    IPv6 Extensibility
    ============== 

                                                                                                       Ron

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Mon, 12 Apr 2021 16:01:31 +0000

Hi Brian,

Many thanks for your time.

Indeed, the scope of this draft is within a limited domain. The deployment scenario for this draft is documented in Section 3. In short: service provider network, whereas all IPv6 nodes are under the administrative control of the operator. The ingress PE receives traffic from customers (eth, ipv4, ipv6) and encapsulates it in a new IPv6 header. The source node of the IPv6 packet traversing the SP network is the ingress PE. We can clarify this further in the next revision of the draft. 

I believe this would address your point.

We will also fix the nit in the illustration.

Many thanks,
Ahmed.

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Thursday, 8 April 2021 at 04:19
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
Resent from: <[email-masked]>
Resent to: <[email-masked]>, ahabdels <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Thursday, 8 April 2021 at 04:18

    Hi,

    Nit:

    Regards
       Brian Carpenter

---

From: Tom Herbert <[email-masked]>
Date: Mon, 12 Apr 2021 09:32:00 -0700

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

> 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 enc…

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.

> 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

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 12 Apr 2021 17:38:50 +0100

Brian E Carpenter wrote on 08/04/2021 03:18:
> My first comment on the present draft is that it doesn't state its
> target scenario (which might be LAG, because LAG is mentioned a few
> times).
I was wondering the same myself.  It's difficult to assess the need for 
a non-backwards-compatible protocol change without a clear understanding 
of the end goal.

Maybe the authors would be able to clear things up on this front?

Nick

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Mon, 12 Apr 2021 17:16:12 +0000

Hi Nick 

We will clarify this in the next version of the document.

Thanks 
Ahmed
-----Original Message-----
From: Nick Hilliard <[email-masked]>
Date: Monday, 12 April 2021 at 18:39
To: Brian E Carpenter <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt
Resent from: <[email-masked]>
Resent to: <[email-masked]>, ahabdels <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Resent date: Monday, 12 April 2021 at 18:38

    Nick

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Mon, 12 Apr 2021 17:27:30 +0000

Hi Tom, 

Please my answers inline [AA]

-----Original Message-----
From: Tom Herbert <[email-masked]>
Date: Monday, 12 April 2021 at 18:32
To: ahabdels <[email-masked]>
Cc: Ron Bonica <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

    Ahmed,

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

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

    Tom

---

From: Ron Bonica <[email-masked]>
Date: Mon, 12 Apr 2021 17:37:51 +0000

Ahmed,

The strategy of borrowing bits from the base IPv6 header is not extensible. It only works until there are no more bits to borrow.

Draft-hinden doesn't have that problem. 

                                                                                                                                  Ron

-----Original Message-----
From: Ahmed Abdelsalam (ahabdels) <[email-masked]> 
Sent: Monday, April 12, 2021 1:28 PM
To: Tom Herbert <[email-masked]>
Cc: Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

[External Email. Be cautious of content]

Hi Tom,

-----Original Message-----
From: Tom Herbert <[email-masked]>
Date: Monday, 12 April 2021 at 18:32
To: ahabdels <[email-masked]>
Cc: Ron Bonica <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

    Ahmed,

    Tom

    > Administrative Requests: https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/ipv6__;!!NEt6yMaO-gk!RDpXauDLYV7wfgu_sy-tjtCvhKaoIR8WnNBQvpZlva0il-3NHCN6fLr_d-Dxyg6f$

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Apr 2021 08:41:32 +1200

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

   Brian

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Tue, 13 Apr 2021 08:47:30 +0000

Inline [AA]

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Monday, 12 April 2021 at 22:41
To: ahabdels <[email-masked]>, Ron Bonica <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

[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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 13 Apr 2021 09:03:57 -0400

This requires something more strict than a "limited domain".  It 
requires a limited domain with universal deployment.  Otherwise, very 
strange things are likely to happen.

More generally, it just seems a bad idea.  It is pretending that this 
particular extension is so special it should get a resource that does 
not even exist.

Please don't.
Joel

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Apr 2021 13:25:12 +0000

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

-----Original Message-----
From: Ahmed Abdelsalam (ahabdels) <[email-masked]> 
Sent: Tuesday, April 13, 2021 4:48 AM
To: Brian E Carpenter <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

Inline [AA]

-----Original Message-----
From: Brian E Carpenter <[email-masked]>
Date: Monday, 12 April 2021 at 22:41
To: ahabdels <[email-masked]>, Ron Bonica <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

       Brian

---

From: "Ahmed Abdelsalam (ahabdels)" <[email-masked]>
Date: Tue, 13 Apr 2021 16:17:57 +0000

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 <[email-masked]>
Date: Tuesday, 13 April 2021 at 15:25
To: ahabdels <[email-masked]>, Brian E Carpenter <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

    Ahmed,

                                                                                                                                                      Ron

    -----Original Message-----
    From: Ahmed Abdelsalam (ahabdels) <[email-masked]> 
    Sent: Tuesday, April 13, 2021 4:48 AM
    To: Brian E Carpenter <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

    Inline [AA]

    -----Original Message-----
    From: Brian E Carpenter <[email-masked]>
    Date: Monday, 12 April 2021 at 22:41
    To: ahabdels <[email-masked]>, Ron Bonica <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

           Brian

---

From: Ron Bonica <[email-masked]>
Date: Tue, 13 Apr 2021 18:23:36 +0000

Ahmed,

I know of at least three platforms that use these four bits in flow hash computation, as described in RFC 6437.

                                                                                                     Ron

-----Original Message-----
From: Ahmed Abdelsalam (ahabdels) <[email-masked]> 
Sent: Tuesday, April 13, 2021 12:18 PM
To: Ron Bonica <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

Ron,

Cheers,
Ahmed

-----Original Message-----
From: Ron Bonica <[email-masked]>
Date: Tuesday, 13 April 2021 at 15:25
To: ahabdels <[email-masked]>, Brian E Carpenter <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

    Ahmed,

                                                                                                                                                      Ron

    -----Original Message-----
    From: Ahmed Abdelsalam (ahabdels) <[email-masked]>
    Sent: Tuesday, April 13, 2021 4:48 AM
    To: Brian E Carpenter <[email-masked]>; Ron Bonica <[email-masked]>; [email-masked]; [email-masked]
    Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

    Inline [AA]

    -----Original Message-----
    From: Brian E Carpenter <[email-masked]>
    Date: Monday, 12 April 2021 at 22:41
    To: ahabdels <[email-masked]>, Ron Bonica <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
    Subject: Re: I-D Action: draft-filsfils-6man-structured-flow-label-00.txt

           Brian

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 14 Apr 2021 12:11:24 +0100

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=[email-masked]> wrote:
> 
> Ahmed,
>

---

From: Gyan Mishra <[email-masked]>
Date: Thu, 15 Apr 2021 01:30:37 -0400

+1

On Tue, Apr 13, 2021 at 9:04 AM Joel M. Halpern <[email-masked]> wrote:

> > To: ahabdels <[email-masked]>, Ron Bonica <[email-masked]>, "
> [email-masked]" <[email-masked]>, "
> [email-masked]" <
> [email-masked]>
> >      > 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
> >
> >
-- 

*Gyan Mishra*

*M 301 502-1347*