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) <[email protected]> Sent: Thursday, December 19, 2019 6:23 AM To: Haoyu Song <[email protected]>; opsawg <[email protected]>; draft-song-opsawg-ifit-framework.authors <[email protected]> Cc: opsawg-chairs <[email protected]> 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&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&sdata=vlsft6Tj%2BuI2rH6NCdZO0qf2O7%2BR9KSI0b%2FF0bjEkoY%3D&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 <[email protected]> Sent: Donnerstag, 19. Dezember 2019 02:09 To: Frank Brockners (fbrockne) <[email protected]>; opsawg <[email protected]>; draft-song-opsawg-ifit-framework.authors <[email protected]> Cc: opsawg-chairs <[email protected]> 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&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&sdata=JL2%2BLWYc04fnRBAOUcsUByjP6eUFmD8KW6XbYiDGd0s%3D&reserved=0 ________________________________________ 发件人: Frank Brockners (fbrockne) <mailto:[email protected]> 发送时间: 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%2Fdatatracker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fminutes-106-opsawg-01&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&sdata=1GNq52BxnTLejtyH17quH%2FaNHPodQS4YukznPvQZq6w%3D&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.be%2FrY-u8177wpU%3Ft%3D3785&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&sdata=X%2Fj2PSaoQSNFy1xTFNjfhUwt4KXjJY8ol3oKYVG2UH8%3D&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.be%2FrY-u8177wpU%3Ft%3D3867&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155305143&sdata=A2UP99wRCzNTk9OPci0%2FLE3KvzQQD%2FBJJHPmfhVqh8c%3D&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&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155315140&sdata=btJwYOUGtJnA8RKntlXXV5F0Xsu4H7rVO5gacId%2FgYg%3D&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:[email protected]> On Behalf Of Benoit Claise Sent: Dienstag, 17. Dezember 2019 14:43 To: Tianran Zhou <mailto:[email protected]>; opsawg <mailto:[email protected]>; draft-song-opsawg-ifit-framework.authors <mailto:[email protected]> Cc: opsawg-chairs <mailto:[email protected]> 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:[email protected]> 收件人： Tianran Zhou<mailto:[email protected]>;opsawg<mailto:[email protected]>;draft-song-opsawg-ifit-framework.authors<mailto:[email protected]> 抄送： opsawg-chairs<mailto:[email protected]> 主题： 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.youtube.com%2Fwatch%3Fv%3DrY-u8177wpU&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155315140&sdata=qfSNeIXLJRJo1WRh40SUF0K76wU8pi%2B5O1kIanyXXj8%3D&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%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155315140&sdata=K5azjOJhUbN3NDUhuwbV92cxcDKCPO9%2FubsdFBAObdY%3D&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:[email protected] https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637123622155315140&sdata=GOk5SIXxkgomuo7yxv1p9Qs4%2BcfgRjEGN13j8q40zjo%3D&reserved=0 _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
