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 <[email protected]> > Sent: Donnerstag, 19. Dezember 2019 19:01 > To: Frank Brockners (fbrockne) <[email protected]>; opsawg > <[email protected]>; draft-song-opsawg-ifit-framework.authors <draft-song- > [email protected]> > Cc: opsawg-chairs <[email protected]> > 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) <[email protected]> > Sent: Thursday, December 19, 2019 6:23 AM > To: Haoyu Song <[email protected]>; opsawg <[email protected]>; > draft-song-opsawg-ifit-framework.authors <draft-song-opsawg-ifit- > [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%7C5247a6a8c > 2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0 > %7C637123622155305143&sdata=vlsft6Tj%2BuI2rH6NCdZO0qf2O7%2BR9 > KSI0b%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 <draft-song- > [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%7C5247a6 > a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1% > 7C0%7C637123622155305143&sdata=JL2%2BLWYc04fnRBAOUcsUByjP6e > UFmD8KW6XbYiDGd0s%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%2Fdatatra > cker.ietf.org%2Fmeeting%2F106%2Fmaterials%2Fminutes-106-opsawg- > 01&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6a8c2934f > 90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C6 > 37123622155305143&sdata=1GNq52BxnTLejtyH17quH%2FaNHPodQS4Yuk > znPvQZq6w%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.b > e%2FrY- > u8177wpU%3Ft%3D3785&data=02%7C01%7Chaoyu.song%40futurewei.co > m%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d55 > 91fedc%7C1%7C0%7C637123622155305143&sdata=X%2Fj2PSaoQSNFy1xT > FNjfhUwt4KXjJY8ol3oKYVG2UH8%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.b > e%2FrY- > u8177wpU%3Ft%3D3867&data=02%7C01%7Chaoyu.song%40futurewei.co > m%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d55 > 91fedc%7C1%7C0%7C637123622155305143&sdata=A2UP99wRCzNTk9OP > ci0%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%7C5247a6a8c > 2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0 > %7C637123622155315140&sdata=btJwYOUGtJnA8RKntlXXV5F0Xsu4H7rVO > 5gacId%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]>;dra > ft-song-opsawg-ifit-framework.authors<mailto:draft-song-opsawg-ifit- > [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.y > outube.com%2Fwatch%3Fv%3DrY- > u8177wpU&data=02%7C01%7Chaoyu.song%40futurewei.com%7C5247a6 > a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7C1% > 7C0%7C637123622155315140&sdata=qfSNeIXLJRJo1WRh40SUF0K76wU8p > i%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%2Fdatatra > cker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit- > framework%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C524 > 7a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b240189c753a1d5591fedc%7 > C1%7C0%7C637123622155315140&sdata=K5azjOJhUbN3NDUhuwbV92cxc > DKCPO9%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.ie > tf.org%2Fmailman%2Flistinfo%2Fopsawg&data=02%7C01%7Chaoyu.song > %40futurewei.com%7C5247a6a8c2934f90f2e908d7848f0782%7C0fee8ff2a3b2 > 40189c753a1d5591fedc%7C1%7C0%7C637123622155315140&sdata=GOk > 5SIXxkgomuo7yxv1p9Qs4%2BcfgRjEGN13j8q40zjo%3D&reserved=0 > _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
