Hi Alan, Thanks for the response. Please see inline.
Haoyu -----Original Message----- From: Alan DeKok <[email protected]> Sent: Monday, January 06, 2020 5:44 PM To: Haoyu Song <[email protected]> Cc: Warren Kumari <[email protected]>; Tianran Zhou <[email protected]>; [email protected]; [email protected] Subject: Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09 On Jan 6, 2020, at 1:31 PM, Haoyu Song <[email protected]> wrote: > [HS] I've added more details in the latest version but as I said, this draft > is not a standard specification, so I just described the high level function > modules and how they can be assembled to form a complete solution. If the draft is a "solution", it should describe how to implement that solution. This draft does not do that. it describes *motivation* for a solution. > I've talked with many people and they told me they had no difficulty to > understand this and found many of the components are already common > practices. For the flow sketch, we provided a reference in the draft but we > didn't describe it extensively, because it's just used as an example in our > discussion and interested readers should directly read the reference for more > information. As for how to deploy such data structure, we actually consider > this as a standard gap. We briefly discussed it in the gap analysis and will > release several other drafts to cover those issues. Then this draft should be titled "architecture" or "motivation". And it should explicitly say that it does not describe a solution. Instead, it should describe a problem, and a proposed architecture. [HS] Indeed I tried to describe some practical problems on applying a specific set of techniques and then to propose an architecture (we call it a framework). A solution can be based on it, but itself cannot be used as a solution directly. > [HS] We write this draft from purely neutral and technical perspective. I > don't know from where you sense the marketing tone. If so, please kindly > point it out specifically so we can improve it. From the abstract: With the advent of programmable data-plane, emerging on-path telemetry techniques provide unprecedented flow insight and realtime notification of network issues. This is 100% marketing speak. IETF standards typically do not talk about how the technology is wonderful, or is "unprecedented". The documents instead describe a technical problem, followed by a technical solution. [HS] What I want to express here is that, as far as I know, no other OAM technique provides the same capability as this new type of technique such as IOAM. I can change the word if it sounds improper. Further, the "programmable data plane" has been standardized extensively in the ForCES working group since at least 2003: https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Fforces%2Fdocuments%2F&data=02%7C01%7Chaoyu.song%40futurewei.com%7C90ac59d12b5041fc5ba108d793131d9d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637139582662175583&sdata=%2FDgnRZ7FEukQMj9YGJD9NroNUu7jv0I8cZRAkc4k55g%3D&reserved=0 The first ForCES BoF was held at IETF 49, in December 2000. That work standardized prior discussions in CPIX / CSIX (then Network Processing Forum, now defunct). I was involved in that work for many years before moving on to other things. [HS] I'm fully aware of the existence of ForCES, I just didn't see its wide application in real products. Only recently, some programmable chips start to enable functions like INT which is basically an on-path telemetry technique we talked in this draft. Actually, I thought about using ForCES to implement the dynamic network probes discussed in this draft. I think it's a promising standard way to do that. Quoting further from the abstract of this document: iFIT includes several essential functional components that can be materialized and assembled to implement a complete solution for on-path telemetry. There is no need to say "materialized and assembled". It's fine to just say "used". The common practice in the IETF (and in other science and engineering disciplines) is to avoid "enthusiastic" words. Keep the words simple. i.e. "used" versus "materialized and assembled". The more complex the words, the less trustworthy the document appears. Quoting again: It also helps to inspire innovative network telemetry applications supporting advanced network operations. Words like "inspire" are again marketing excitement, and not boring technical engineering. [HS] Fair enough. I would use simple words instead. After reading the document, I hope the reader can recognize the issues and agree that our proposed framework or architecture makes sense for practical deployments, and start to think about how to fill the standard gaps to make it happen. I think this is the core value of this draft. My concern here is that I read the document, and I'm happy and enthusiastic. But I don't know what to *do*. As a result, this document is not appropriate for the IETF. Alan DeKok. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
