[v6ops] Re: [EXTERNAL] Re: Fwd: The V6OPS WG has placed draft-cc-v6ops-wlcg-flow-label-marking in state "Call For Adoption By WG Issued"

[Tim Chown <[e-mail]>]

Hi,

From: Brian E Carpenter <[e-mail]>
Date: Thursday, 15 August 2024 at 00:17
To: Tom Herbert <[e-mail]>
Cc: Tommy Jensen <[e-mail]>, IPv6 Operations <[e-mail]>
Subject: [v6ops] Re: [EXTERNAL] Re: Fwd: The V6OPS WG has placed draft-cc-v6ops-wlcg-flow-label-marking in state "Call For Adoption By WG Issued"
Tom,

On 15-Aug-24 10:56, Tom Herbert wrote:
> On Wed, Aug 14, 2024 at 3:25 PM Brian E Carpenter
> <[e-mail]> wrote:
>>
>> Hi,
>>
>> I am very strongly convinced that this draft should be published as an RFC. I am on the fence whether it should be published as an IETF stream Informational RFC or as an Independent stream Informational RFC. Since we know that most people don't read the boilerplate anyway, it hardly matters.
>>
>> Although this work bends the rules of RFC 6437, the implementers were (to my personal knowledge) aware of the issues from the start, allowed for some entropy bits, and most important have actually shown a use case for 20 largely underused bits in the IPv6 header. This is a use case that is worth publishing, and I can imagine it leading to reconsideration of some of the rules in RFC 6437. That's why it belongs in the RFC series.
>
> Hi Brian,
>
> I don't agree that the 20 bit flow label is underused. By default,
> Linux will set a flow label in a packet using the full twenty bits of
> entropy.

I'm aware of that and glad of it.

On the receive Linux path there are algorithms that assume
> that the full twenty bits of entropy are available. For instance,
> Receive Flow Steering (RFS) classifies packets by the hash that
> includes the flow label. Usually, we configure at least 1024 hash
> buckets (10 bits) so only getting five bits might create a bunch of
> hash collisions. Hosts might also be using the flow hash for other
> forms of filtering involving the flow label as well.

I'm not sure what the use cases are for more than a handful of hash
buckets.

IMHO, what matters in terms of the intended purpose of the RFC 6437
version of the flow label is whether routers, ECMP/LAG systems, and
load balancers are using it. That's where I have seen no indication
of widespread deployment.

>
> Also, pertaining to routers, the draft states "The 5 entropy bits are
> used to still support a level of conformance with the requirement
> stated in RFC 6437 to support traffic distribution in ECMP and LAG
> scenarios". I believe that is making an implicit assumption that we
> have no more than 32 ports for ECMP or LAG.

Yes.

> In short, I am very leary about publishing an RFC that essentially
> says that we really didn't need twenty bits of flow label, we just
> needed five bits after all. Five bits might be sufficient in a one
> limited domain, but maybe could cause problems in others. We really
> don't know at this point...

The WLCG really is a limited domain, even if it's world-wide. But you're
correct; the draft could use a short discussion of that.

Most of the WLCG operation spans private optical networks (LHCOPN, from CERN to the Tier 1s) or overlay networks (VRFs, the LHCONE), but an amount of the traffic just travels via the general R&E network infrastructure (over which LHCONE itself runs). In that sense it is a limited domain, and indeed the very large majority of research / science traffic is only routed over the NREN networks because they are optimised to carry it efficiently.  We can certainly make that clearer in the draft.

There’s more on this in the deck I used in Vancouver for the WLCG and IPv6 side meeting - https://docs.google.com/presentation/d/1riTdi7zgoJ3ig31Hp-gy4Z089PeKaoRJHALOcvjGn5E/edit#slide=id.p



     Brian

>
> Tom
>
>>
>> Note that RFC 6294 was published in the Independent Stream; that's a precedent. For more of the tortured history of the flow label, see RFC 6436.
>>
>> Regards
>>      Brian Carpenter
>>
>> On 15-Aug-24 06:05, Tommy Jensen wrote:
>>> +1, I oppose the WG adopting this.
>>>
>>> I do think having the I-D published individually would make for a nice reference for any standards updates ("this is an example of where this document's mechanism is needed and why"). The concrete numbers are especially insightful to justify design trade-offs and defaults values. That said, maybe it does not even need to make it to RFC publication if, as a draft, it can be used by the WG to motivate a standards-friendly solution that can be adopted and published by the WG instead.
>>>
>>> This seems like something we should discuss at 121 either way.
>>>
>>> Thanks,
>>> Tommy
>>> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>>> *From:* Tom Herbert <tom=[e-mail]>
>>> *Sent:* Tuesday, August 13, 2024 3:21 PM
>>> *To:* Mark Smith <[e-mail]>
>>> *Cc:* IPv6 Operations <[e-mail]>
>>> *Subject:* [EXTERNAL] [v6ops] Re: Fwd: The V6OPS WG has placed draft-cc-v6ops-wlcg-flow-label-marking in state "Call For Adoption By WG Issued"
>>> [You don't often get email from tom=[e-mail]. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification <https://aka.ms/LearnAboutSenderIdentification> ]
>>>
>>> On Tue, Aug 13, 2024 at 3:06 PM Mark Smith <[e-mail]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I don't support adoption for a number of reasons.
>>>>
>>>> Firstly, and the main reason, v6ops working group adoption means the
>>>> document becomes a product of the WG, rather than just the authors.
>>>>
>>>> As this ID is documenting violations of IETF Standard Track RFC 6437,
>>>> it becoming a v6ops WG document means that the v6ops WG is tacitly
>>>> endorsing RFC 6437 violation, even if published as Informational.
>>>>
>>>> It becoming a WG document also suggests there is further work to be
>>>> done on it by the WG, not just the authors. What further work on this
>>>> ID is there the v6ops WG to do?
>>>>
>>>> If the IETF is the best place to publish it, why can't it be published
>>>> as an Independent Submission, avoiding v6ops tacit endorsement and any
>>>> WG publication overheads.
>>>
>>> Mark,
>>>
>>> I tend to agree. The proposal is for a very limited use case, and the
>>> draft acknowledges that the correct mechanism to carry such data would
>>> be Destination Options. IMO, the community would be better served by
>>> the WG working on fixing the problems of extension header deployment
>>> instead of pursuing workarounds like this. Independent Submission
>>> seems appropriate.
>>>
>>> Tom
>>>
>>>>
>>>> Why can't it be published as an academic paper outside of the IETF,
>>>> further avoiding the IETF RFC publication costs?
>>>>
>>>> Regards,
>>>> Mark.
>>>>
>>>> On Wed, 14 Aug 2024 at 04:27, Nick Buraglio
>>>> <[e-mail]> wrote:
>>>>>
>>>>>
>>>>> This call for adoption is wrapping up. If anyone else would like to comment, please read the draft and provide feedback by tomorrow.
>>>>> Below is the current state:
>>>>>
>>>>> | [draft-cc-v6ops-wlcg-flow-label-marking](https://datatracker.ietf.org/doc/draft-cc-v6ops-wlcg-flow-label-marking/)  |             | Adoption Called 05-Aug-2024                        | Adoption Ending 19-August-2024 |
>>>>> | ------------------------------------------------------------------------------------------------------------------ | ----------- | -------------------------------------------------- | ------------------------------ |
>>>>> | Support                                                                                                            | Opposed     | Comments                                           | Comments Addressed             |
>>>>> | Brian Carpenter                                                                                                    |             | discussion of deviations from RFC 6437 is helpful. |                                |
>>>>> | Tim Winters                                                                                                        |             |                                                    |                                |
>>>>> | Nick Buraglio                                                                                                      |             |                                                    |                                |
>>>>> |                                                                                                                    | Tom Herbert | Feels is too specific                              | Yes                            |
>>>>> | David Farmer                                                                                                       |             |                                                    |
>>>>>
>>>>>
>>>>> I believe Tom had his concerns addressed but I never saw explicit support after.
>>>>> If anyone else would like to comment, please read the draft and provide feedback by tomorrow.
>>>>>
>>>>> nb
>>>>>
>>>>>
>>>>> On Mon, Aug 5, 2024 at 2:13 PM David Farmer <[e-mail]> wrote:
>>>>>>
>>>>>>
>>>>>> I support adoption.
>>>>>>
>>>>>> On Mon, Aug 5, 2024 at 13:35 Nick Buraglio <[e-mail]> wrote:
>>>>>>>
>>>>>>> All,
>>>>>>> We'd like to wrap this adoption call up. As of now we don't have a lot
>>>>>>> of input, but it is mostly positive. Please read and comment.  Current
>>>>>>> state:
>>>>>>>
>>>>>>> ### draft-cc-v6ops-wlcg-flow-label-marking
>>>>>>> #### Adoption Called 06-July-2024
>>>>>>> * Support - Comments - Comments Addressed
>>>>>>> Brian Carpenter - discussion of deviations from RFC 6437 is helpful.
>>>>>>> Tim Winters
>>>>>>> Nick Buraglio
>>>>>>>
>>>>>>>   * Opposed - Comments - Comments Addressed
>>>>>>> Tom Herbert - Feels is too specific - no
>>>>>>>
>>>>>>>
>>>>>>> ---------- Forwarded message ---------
>>>>>>> From: IETF Secretariat <[e-mail]>
>>>>>>> Date: Sat, Jul 6, 2024 at 5:09 PM
>>>>>>> Subject: The V6OPS WG has placed
>>>>>>> draft-cc-v6ops-wlcg-flow-label-marking in state "Call For Adoption By
>>>>>>> WG Issued"
>>>>>>> To: <[e-mail]>,
>>>>>>> <[e-mail]>, <[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The V6OPS WG has placed draft-cc-v6ops-wlcg-flow-label-marking in state
>>>>>>> Call For Adoption By WG Issued (entered by Nick Buraglio)
>>>>>>>
>>>>>>> The document is available at
>>>>>>> https://datatracker.ietf.org/doc/draft-cc-v6ops-wlcg-flow-label-marking/ <https://datatracker.ietf.org/doc/draft-cc-v6ops-wlcg-flow-label-marking/>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> v6ops mailing list -- [e-mail]
>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>
>>>>> _______________________________________________
>>>>> v6ops mailing list -- [e-mail]
>>>>> To unsubscribe send an email to [e-mail]
>>>>
>>>> _______________________________________________
>>>> v6ops mailing list -- [e-mail]
>>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> v6ops mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
>>>
>>> _______________________________________________
>>> v6ops mailing list -- [e-mail]
>>> To unsubscribe send an email to [e-mail]
_______________________________________________
v6ops mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]