[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 Herbert <[e-mail]>]

On Fri, Aug 16, 2024 at 9:48 AM Tim Chown <[e-mail]> wrote:
>
> Hi,
>
>
>
> From: Tom Herbert <[e-mail]>
> Date: Friday, 16 August 2024 at 17:38
> To: Tim Chown <[e-mail]>
> Cc: Brian E Carpenter <[e-mail]>, Tommy Jensen <[e-mail]>, Mark Smith <[e-mail]>, IPv6 Operations <[e-mail]>
> Subject: Re: [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"
>
> On Fri, Aug 16, 2024 at 9:26 AM Tim Chown <[e-mail]> wrote:
> >
> > Hi Brian,
> >
> >
> >
> > From: Brian E Carpenter <[e-mail]>
> > Date: Wednesday, 14 August 2024 at 23:27
> > To: Tommy Jensen <[e-mail]>, Tom Herbert <[e-mail]>, Mark Smith <[e-mail]>
> > Cc: 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"
> >
> > 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.
> >
> >
> >
> > As an author, I really don’t mind via which route the document is published. It would be nice to have WG blessing, but if that’s controversial, we can go down the individual submission path.
> >
> >
> > 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.
> >
> >
> >
> > The general point of the document is to say “hey, we did this, for our case it works, others may find it interesting”.
> >
> >
> >
> > Work is continuing, albeit slowly, on using a HbH option alternative. The performance hit of doing so does not seem to be as bad as first expected, but hopefully we can report on that by or at IETF 121.  Eric Vyncke was involved in some similar tests recently, using the same approach, I think.
>
> Hi Tim,
>
> Just curious, why HbH instead of a Destination option? I believe the
> use case is E2E, so unless intermediate routers need to process the
> option, it seems like DstOpt might be a safer bet (has lower drop rate
> than HbH for instance).
>
>
>
> I believe that was down to the original use case of the marking, for the WLCG operators (the R&E NRENs mainly, i.e. those operating the R&E networks) to better understand which traffic is associated with which (CERN) experiments and which types of activity / application, and that implies inspecting (processing) the packet (and header) along the path. If that’s allowed with a DO, you may well be right.
>
>
>
> Of course once you have marking for accounting, others will come along and say “hey, we can use that to steer traffic too” (witness Brian’s old use cases RFC), and there’s been some testing of that using programmable P4 platforms.

Tim

I think we need to be careful here-- if we were using this information
for routing that's a whole 'nother ball of wax so to speak. There are
already proposals for that in FAST, SRv6, etc. IMO, it's going to be
better to keep the E2E accounting in routing separate, and if we're
going to have both I don't see how trying to put all of this into the
flow label is going to be feasible.

Tom

>
>
>
> Which reminds me the WLCG needs to run more EH tests over R&E infrastructure, which I suspect will likely be done with a plugin for the perfSONAR network monitoring toolkit that pretty much all WLCG sites have deployed (this also allows tests of different CCAs, jumbo, window sizes, etc).
>
>
>
> Tim
>
>
>
> 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.
> >
> >
> >
> > We don’t cite RFC 6294, we probably should, and maybe 6436 too, thanks for the history lesson :)
> >
> >
> >
> > Tim
> >
> >
> >
> > 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]