Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

["Frank Brockners (fbrockne)" <[e-mail]>]

Haoyu,

Thanks. Reading through your response below, you still don't seem to follow what I say. The document in its current form isn't appropriate as a standards document. That is why I suggested a couple of options to make it one - which you seem to ignore. The fact that several people find it useful does make it an appropriate standards document. E.g. a Huawei whitepaper might also be considered useful by several people, still a whitepaper is not a standards document. 

And per what I said earlier, if you decide to evolve your document towards a properly scoped specification, make sure that you choose a proper and non-confusing name. If your IFIT is really different from Huawei's IFIT, then just call it something else. Even your co-worker Alex Clemm was suggesting a name change.

Happy holidays.

Frank

> -----Original Message-----
> From: Haoyu Song <[e-mail]>
> Sent: Donnerstag, 19. Dezember 2019 19:01
> To: Frank Brockners (fbrockne) <[e-mail]>; opsawg
> <[e-mail]>; draft-song-opsawg-ifit-framework.authors <draft-song-
> [e-mail]>
> Cc: opsawg-chairs <[e-mail]>
> Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-
> 09
> 
> Hi Frank,
> 
> Thank you very much for the feedback. However I want to clarify a few things.
> 
> The core of the draft is a framework for data plane on-path telemetry. It's not a
> dedicated requirement document, neither a survey. The challenges we described
> are just used to motivate the framework. The standard gap analysis is also
> necessary to show how this framework can be implemented in the future.  While
> I agree the document is not perfect and still need to improve, I think the main
> information and logic flow are clear. I also think the document is self-sufficient.
> It's just a high level guide for future development but doesn't intend to put any
> constraints.
> 
> I said “Other documents might also be needed but they are out of scope of this
> one”, not to reference some non-existing document, but to respond to your
> previous email in which you suggest other documents like survey and
> deployment experience etc.  This document does not server those purpose.
> 
> While you ask for detailed specification (up to the level about how the controller
> to configure the nodes and what data to export, etc.) , you may still think from a
> perspective that this document is a solution specification, but it's not. I'm very
> sorry for that impression. We already emphasized in the document that we don’t
> intend to specify any interface and implementation details, but to describe high
> level functions. To server that purpose, a loose definition for the terms is
> enough and proper.
> 
> For example, we define iFIT Node as "a network node that is in an iFIT domain
> and is capable of iFIT-specific functions." So yes it forwards and processes
> traffic. I don't think anybody will misunderstand this. You ask how,  for which we
> can only provide high level function descriptions but won't specify any detail
> because we have made it very clear that's not the intention of this document.
> 
> So let's just focus on the current scope and content of the document, to see if
> it's useful and valuable to the community as a whole. From the majority
> responses, mostly from real network operators, the feedbacks are so far very
> positive and they all support the adoption of this document. I think that says
> something.
> 
> Best regards,
> Haoyu
> 
> 
> 
> -----Original Message-----
> From: Frank Brockners (fbrockne) <[e-mail]>
> Sent: Thursday, December 19, 2019 6:23 AM
> To: Haoyu Song <[e-mail]>; opsawg <[e-mail]>;
> draft-song-opsawg-ifit-framework.authors <draft-song-opsawg-ifit-
> [e-mail]>
> Cc: opsawg-chairs <[e-mail]>
> Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-
> 09
> 
> Haoyu,
> 
> you and your co-authors need to decide what the document is intended to be: A
> requirements document, an industry implementation survey, or a specification?
> Right now the document is a bit of everything – with nothing is appropriately
> spelled out and detailed for a standards document.
> 
> Depending on that decision, here is how you could evolve the document:
> If the document is intended as a requirements document:
>  - expand the requirements part of section 1
>  - remove all references to iFIT and similar – none of this is needed to articulate
> requirements If the document is intended as an industry survey:
>  - provide comprehensive inventory of available implementation
>  - focus on what is available / deployed and discuss experiences
>  - remove all references to iFIT and similar that try to specify things – none of
> this is needed to for an industry survey If the document is intended as a
> specification or case study
>  - provide technical specifications for IFIT node, IFIT application, IFIT Head
> Node, IFIT End Node, etc. I.e. explain how these “things” work and operate.
> What is their control plane, what is their data plane, etc.? Make sure that you’re
> not creating “empty shells” that are to be defined at a later stage. An approach
> to create forward references to currently non existing documents like “Other
> documents might also be needed but they are out of scope of this one” (see
> your message below) are not appropriate for a specification.
>  - if you believe that your IFIT specification has nothing to do with Huawei’s IFIT
> proprietary implementation (i.e.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-
> ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-
> pilot-5g-transport-network-beijing-unicom-
> huawei&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c
> 2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
> %7C637123622155305143&amp;sdata=vlsft6Tj%2BuI2rH6NCdZO0qf2O7%2BR9
> KSI0b%2FF0bjEkoY%3D&amp;reserved=0) then I strongly suggest that you
> choose a different name for your implementation.
> 
> Just to highlight that different from what you say, the specification of IFIT
> elements neither helps in articulating requirements nor does it support different
> industry solutions: If you take the example of an “IFIT Node” – there is a total of
> 8 occurrences in the document, with 5 of them in the main part of the
> document. The document defines “iFIT Node” as “a network node that is in an
> iFIT domain and is capable of iFIT-specific functions”. None of the 5 occurrences
> in the document is used for comparison or requirements definition, neither do
> they detail what IFIT specific functions are carried out by an IFIT node. Reading
> through the 5 occurrences,  one learns that iFIT nodes seem to be configured by
> a controller (what is a controller?), they seem to be able to do some form of
> data collection (how?, what data?), they seem to be able to export data using
> IPFIX and protobuf (what data is exported?), they seem to be able to cache data,
> and they seem to contain DNP. Reading through this, I still don’t know what IFIT
> Nodes are… Do they forward traffic? Do they process traffic? If so how? ...
> 
> Just for reference, here are the 5 occurrences of “IFIT Node” I found in the main
> part of the document:
> - An iFIT application uses a controller to configure the iFIT nodes.
> - After the telemetry data processing and analyzing, the iFIT application may
> instruct the controller to modify the iFIT node configuration and affect the
> future telemetry data collection.
> - In addition to efficient export data encoding (e.g., IPFIX [RFC7011] or protobuf
> [1]), iFIT nodes have several other ways to reduce the export data by taking
> advantage of network device's capability and programmability.
> - iFIT nodes can cache the data and send the accumulated data in batch if the
> data is not time sensitive.
> - The controller translates an intent and configure the corresponding DNPs in
> iFIT nodes which collect necessary network information.
> 
> Frank
> 
> From: Haoyu Song <[e-mail]>
> Sent: Donnerstag, 19. Dezember 2019 02:09
> To: Frank Brockners (fbrockne) <[e-mail]>; opsawg
> <[e-mail]>; draft-song-opsawg-ifit-framework.authors <draft-song-
> [e-mail]>
> Cc: opsawg-chairs <[e-mail]>
> Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-
> 09
> 
> Again, I need to point out the fact that I have listed all the questions raised
> during the meeting (including Frank's and Joe's) and I asked if I missed anything
> or misunderstood anything in an email to the list. But I didn't got any feedback
> from the queationers, so I believed  I had correctly understood the questions
> and then made updates accordingly. So, I don't understand why Frank still use
> the meeting video to question the draft. Please read and answer my email and
> draft, and let me know what you are not agree with based on that.
> 
> Alos, we have specified all the terms we used in the draft. Please take time to
> read it.
> 
> IFIT is NOT a proprietary solution.  Period.  I  don't think anybody can gain such a
> feeling from reading it.   There's no solution but requirement, challenges, a high
> level framework, examples, and standard gap analysis. How can it be a solution?
> 
> 
> Other documents might also be needed but they are out of scope of this one.  I
> firmly believe this one is also needed for the reason we clearly stated in the
> draft.
> 
> Thanks!
> 
> Haoyu
> 
> 
> 获取
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Faka.ms
> %2Fghei36&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6
> a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
> 7C0%7C637123622155305143&amp;sdata=JL2%2BLWYc04fnRBAOUcsUByjP6e
> UFmD8KW6XbYiDGd0s%3D&amp;reserved=0
> 
> ________________________________________
> 发件人: Frank Brockners (fbrockne) <mailto:[e-mail]>
> 发送时间: 2019年12月18日星期三 下午1:01
> 收件人: opsawg; draft-song-opsawg-ifit-framework.authors
> 抄送: opsawg-chairs
> 主题: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09
> 
> 
> Are we following our practices and procedures properly? For the record, in case
> others are equally puzzled about this call for adoption:
> 
> * Different from what the co-chair states in his WG adoption call below (“The
> authors then resolved all the open issues”), draft-song-opsawg-ifit-framework-
> 09 does NOT resolve all open issues nor does the document reflect all the WG
> feedback received at IETF 106.
> 
> * The WG minutes
> (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fminutes-106-opsawg-
> 01&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f
> 90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6
> 37123622155305143&amp;sdata=1GNq52BxnTLejtyH17quH%2FaNHPodQS4Yuk
> znPvQZq6w%3D&amp;reserved=0) miss a significant portion of comments and
> feedback as Benoit rightly points out below. E.g. Joe Clarke’s (as individual)
> comments are NOT mentioned at all, my comments are misrepresented.
> 
> * The authors did NOT reflect any of the comments made by myself (see
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.b
> e%2FrY-
> u8177wpU%3Ft%3D3785&amp;data=02%7C01%7Chaoyu.song%40futurewei.co
> m%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d55
> 91fedc%7C1%7C0%7C637123622155305143&amp;sdata=X%2Fj2PSaoQSNFy1xT
> FNjfhUwt4KXjJY8ol3oKYVG2UH8%3D&amp;reserved=0) or by Joe Clarke. IMHO
> this is NOT appropriate for editors of a “soon to be” WG document.
> 
> * draft-song-opsawg-ifit-framework-09 introduces a lot of new entities, e.g.
> IFIT Applications, IFIT Domain, IFIT Node, IFIT End-Node, etc. None of these
> entities are specified in the document, which means that the IETF would endorse
> a framework without even understanding the components/entities of the
> framework. The presenter responded
> (https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.b
> e%2FrY-
> u8177wpU%3Ft%3D3867&amp;data=02%7C01%7Chaoyu.song%40futurewei.co
> m%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d55
> 91fedc%7C1%7C0%7C637123622155305143&amp;sdata=A2UP99wRCzNTk9OP
> ci0%2FLE3KvzQQD%2FBJJHPmfhVqh8c%3D&amp;reserved=0 ) that it would be
> just a “very high level framework” that should fit any existing solution. If
> everything fits, i.e. “I FIT”, “You FIT”, “We all Fit”, … then why do we even need
> the definition of new entities? There is NO need to define “empty shells” for a
> lot of new entities, if all what the authors intend to do is compare different
> solutions.
> 
> * Different from what the presenter claimed, IFIT is NOT just “a high-level
> framework”, but IFIT is a proprietary Huawei technology, see e.g.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww-
> ctc.huawei.com%2Fke%2Fpress-events%2Fnews%2F2019%2F6%2Ffirst-ifit-
> pilot-5g-transport-network-beijing-unicom-
> huawei&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c
> 2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0
> %7C637123622155315140&amp;sdata=btJwYOUGtJnA8RKntlXXV5F0Xsu4H7rVO
> 5gacId%2FgYg%3D&amp;reserved=0. Public specifications for IFIT don’t seem to
> be available, with the exception of draft-li-6man-ipv6-sfc-ifit-02 which
> introduces new encapsulations. I.e. IFIT-Nodes, IFIT-End-Nodes etc. do exist –
> we just don’t know what they do. Looking at the people who responded to the
> adoption thread so far, one could also read the responses as a desire for a
> detailed documentation of the specification and lessons learned from
> deployments of Huawei’s IFIT.
> 
> Different from draft-song-opsawg-ifit-framework-09, which I do NOT support
> the adoption of, the following documents might be worthwhile documents
> (especially given the broad interest) to create/share:
> - requirements
> - comprehensive industry technology survey
> - specification and deployment experiences of Huawei’s IFIT I already made this
> suggestion back in the WG meeting at IETF 106 – but per the above it was
> ignored at multiple levels.
> 
> Regards, Frank
> 
> From: OPSAWG <mailto:[e-mail]> On Behalf Of Benoit Claise
> Sent: Dienstag, 17. Dezember 2019 14:43
> To: Tianran Zhou <mailto:[e-mail]>; opsawg
> <mailto:[e-mail]>; draft-song-opsawg-ifit-framework.authors
> <mailto:[e-mail]>
> Cc: opsawg-chairs <mailto:[e-mail]>
> Subject: Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-
> 09
> 
> Hi Tianran,
> Hi Benoit,
> 
> My last question was only to check if there is enough interest on this work, not
> an adoption call. There was q&a after the presentation. And Joe cut the line
> because of the time.
> 
> Now this is an adoption call. You are free to suggest or object.
> I just did :-)
> 
> Regards, B.
> 
> And we believe debate is really helpful.
> 
> Cheers,
> Tianran
> 
> ________________________________________
> Sent from WeLink
> 发件人： Benoit Claise<mailto:[e-mail]>
> 收件人： Tianran
> Zhou<mailto:[e-mail]>;opsawg<mailto:[e-mail]>;dra
> ft-song-opsawg-ifit-framework.authors<mailto:draft-song-opsawg-ifit-
> [e-mail]>
> 抄送： opsawg-chairs<mailto:[e-mail]>
> 主题： Re: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-
> 09
> 时间： 2019-12-17 20:56:58
> 
> Dear all,
> 
> After reviewing thehttps://datatracker.ietf.org/doc/minutes-106-opsawg/, I
> was a little bit puzzled. From my recollection, Joe and Frank had some good
> feedback on the draft.
> Also, in the minutes, I did not see any mention of Joe's feedback. And Frank's
> feedback on the draft is summarized as 4 words: "the scope is large"
> So I went back and reviewed the
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.y
> outube.com%2Fwatch%3Fv%3DrY-
> u8177wpU&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6
> a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%
> 7C0%7C637123622155315140&amp;sdata=qfSNeIXLJRJo1WRh40SUF0K76wU8p
> i%2B5O1kIanyXXj8%3D&amp;reserved=0.
> 
> I support Frank's feedback that this document scope is too large: a mix of an
> inventory of what exists, a set of requirements, and specifications/framework.
> I'm wondering: what is the scope of this document? Before we clarify this, I
> don't think we should adopt this document.
> 
> The OPSAWG chair questions at the end of the presentation were:
>         Chair: How many of you have read this document? quite a lot.
>         Chair: How many of you think this is a useful work and the working group
> could
>         work on it? still many, 20+.
> I was waiting for the negative question but to my surprise, it never came...
>         Chair: How many of you don't think ...
> If that question would have been asked, I would have come to mic. or at least
> raised my hand.
> 
> It's important to make a distinction between the interest to solve those
> problems (I believe we have full agreement) and whether this document is a
> good starting point. I object to the latter, with the document in the current
> form.
> Regards, Benoit
> 
> Hi WG,
> 
> On IETF 106 meeting, we saw predominant interest and support to this draft,
> especially from operators. The authors then resolved all the open issues.
> As requested by the authors, this email starts a 2 weeks working group adoption
> call for draft-song-opsawg-ifit-framework-09.
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatra
> cker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-
> framework%2F&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C524
> 7a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7
> C1%7C0%7C637123622155315140&amp;sdata=K5azjOJhUbN3NDUhuwbV92cxc
> DKCPO9%2FubsdFBAObdY%3D&amp;reserved=0
> 
> If you support adopting this document please say so, and please give an
> indication of why you think it is important. Also please say if you will be willing
> to review and help the draft.
> If you do not support adopting this document as a starting point to work on,
> please say why.
> This poll will run until Dec 23..
> 
> Thanks,
> Tianran as co-chair
> 
> 
> _______________________________________________
> OPSAWG mailing list
> mailto:[e-mail]
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ie
> tf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=02%7C01%7Chaoyu.song
> %40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b2
> 40189c753a1d5591fedc%7C1%7C0%7C637123622155315140&amp;sdata=GOk
> 5SIXxkgomuo7yxv1p9Qs4%2BcfgRjEGN13j8q40zjo%3D&amp;reserved=0
>