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

[Haoyu Song <[e-mail]>]

Frank,

This status of this document is "informational", not "standard". Please show me what's and what's not appropriate for an informational document. 

Haoyu
-----Original Message-----
From: Frank Brockners (fbrockne) <[e-mail]> 
Sent: Thursday, December 19, 2019 11:10 PM
To: Haoyu Song <[e-mail]>; opsawg <[e-mail]>; draft-song-opsawg-ifit-framework.authors <[e-mail]>
Cc: opsawg-chairs <[e-mail]>
Subject: RE: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

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%2Fdat
> atra
> 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%2Fyout
> u.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%2Fyou
> tu.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%2Fdata
> tra
> 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
>