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) <[email protected]> Sent: Thursday, December 19, 2019 11:10 PM 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, 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%2Fdat > atra > 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%2Fyout > u.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%2Fyou > tu.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%2Fdata > tra > 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
