Subject: Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

From: Warren Kumari <[email-masked]>
Date: Sun, 5 Jan 2020 15:04:08 -0500

On Thu, Dec 26, 2019 at 1:14 AM Tianran Zhou <[email-masked]> wrote:
>
> Working Group,
>
>
>
> Thank you for all of your emails related to draft-song-opsawg-ifit-framework.
>
> It seems there are a lot of interested people. I hope the authors will be encouraged by that.
>
> But there were also some strong concerns about the scope of the draft. What is it trying to achieve? How does that match the charter? Does it include material that is outside its scope? Thanks specially to Frank and Al for saying their concerns.
>
> We are going to extend the adoption call for another two weeks to Jan 8. And we encourage the inter-working group discussion.

<no hats>

I've just (re)read this, and have some concerns -- I found it somewhat
hard to dig into the actual technical "meat" of the document
(channeling Randy Bush "Where's the protein?") - it feels like it
describes a bunch of benefits and features of a solution, but without
actually describing the solution itself. The Abstract says that in the
document "a high-level framework, In-situ Flow Information Telemetry
(iFIT), is outlined.", but I couldn't really find it. Section 2 ("iFIT
Framework Overview") is so very level that it doesn't really seem to
say much at all.

I assumed that I'd just missed a bunch of other documents which
actually describe some of the details behind ifit, like what exactly
an iFIT node *does*, or what exactly an "On-demand Flow Sketch" is[0].
Basically, if I wanted to implement this myself, how would I do so?

The main thing I found was:
https://www-ctc.huawei.com/ke/press-events/news/2019/6/first-ifit-pilot-5g-transport-network-beijing-unicom-huawei
"In October 2018, Huawei submitted the draft of iFIT — "In-situ Flow
Information Telemetry Framework" — to the Internet Engineering Task
Force (IETF). Huawei's iFIT is the industry's first in-band flow
measurement solution to have been deployed commercially. In June 2019,
Huawei's iFIT solution won the Best of Show Award Special Prize at
Interop Tokyo 2019 — one of the most prestigious events in the
industry." and "Huawei's innovative iFIT solution takes a hardware
approach...", etc.

This, and the general tone of the document, feels like a marketing
driven exercise - the document describes a bunch of features and
benefits of a solution, but without the detail needed to implement it.

Without a full description of iFIT itself and a serious scrubbing of
the marketing tone, I do not think that the document should be
adopted.

W

[0]: "A flow sketch is a compact online data
      structure for approximate flow statistics which can be used to
      facilitate flow selection.  The aforementioned CountMin Sketch is
      such an example.  Since a sketch consumes data plane resources, it
      should only be deployed when needed." -- this doesn't really say
anything. Where is the format for the datastructure defined? How do I
write one, how do I deploy it?.

" iFIT Head Node:  A special iFIT node.  It is the entry node to an
      iFIT domain.  Usually the instruction header encapsulation, if
      needed, happens here." - this just names something, but does not
describe what it actually *is*, etc.

</no hats>

>
> Please continue to discuss on the mailing list.
>
>
>
> Merry Christmas!
>
> Tianran
>
>
>
> From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
> Sent: Monday, December 9, 2019 1:27 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09
>
>
>
> 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://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Alan DeKok <[email-masked]>
Date: Sun, 5 Jan 2020 15:47:11 -0500

On Jan 5, 2020, at 3:04 PM, Warren Kumari <[email-masked]> wrote:
> actually describing the solution itself.

  The document appears to be largely philosophic, not practical.  At no point does the document describe how anyone can implement anything.

  From the abstract:

   iFIT
   provides several essential components that can be assembled to
   achieve a complete and efficient solution for on-path telemetry.

  The components described in the document cannot be described as "complete", or "efficient", or a "solution".

> The Abstract says that in the

  The abstract is surprisingly long, while saying surprisingly little.

> benefits of a solution, but without the detail needed to implement it.

  It is impossible to implement anything based on this document.

  As an example of odd text:

   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.

  That statement is simply content-free.  It might as well say "nodes are capable of communicating via a variety of communications methods".

  To me, the document reads largely likely a patent application, but with no supporting details.  It claims the widest possible applicability for the "solution".  While at the same time giving next to no information about the solution.

  IMHO the WG should ignore this document entirely.

  Alan DeKok.

---

From: Haoyu Song <[email-masked]>
Date: Mon, 6 Jan 2020 18:31:08 +0000

Hi Warren,

Thanks for the review and comments. Please see my inline response. 

Haoyu

-----Original Message-----
From: OPSAWG <[email-masked]> On Behalf Of Warren Kumari
Sent: Sunday, January 05, 2020 12:04 PM
To: Tianran Zhou <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

<no hats>

I've just (re)read this, and have some concerns -- I found it somewhat hard to dig into the actual technical "meat" of the document (channeling Randy Bush "Where's the protein?") - it feels like it describes a bunch of benefits and features of a solution, but without actually describing the solution itself. The Abstract says that in the document "a high-level framework, In-situ Flow Information Telemetry (iFIT), is outlined.", but I couldn't really find it. Section 2 ("iFIT Framework Overview") is so very level that it doesn't really seem to say much at all.

I assumed that I'd just missed a bunch of other documents which actually describe some of the details behind ifit, like what exactly an iFIT node *does*, or what exactly an "On-demand Flow Sketch" is[0].
Basically, if I wanted to implement this myself, how would I do so?

[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. 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. 

The main thing I found was:
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%7Cb89e7d80cf84400ac8d308d7921a9334%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637138515165652629&amp;sdata=5MK%2BVY7QAyPZupkYMYLDijyLAqSxQhbG%2FUPVVq6mkTI%3D&amp;reserved=0
"In October 2018, Huawei submitted the draft of iFIT — "In-situ Flow Information Telemetry Framework" — to the Internet Engineering Task Force (IETF). Huawei's iFIT is the industry's first in-band flow measurement solution to have been deployed commercially. In June 2019, Huawei's iFIT solution won the Best of Show Award Special Prize at Interop Tokyo 2019 — one of the most prestigious events in the industry." and "Huawei's innovative iFIT solution takes a hardware approach...", etc.

This, and the general tone of the document, feels like a marketing driven exercise - the document describes a bunch of features and benefits of a solution, but without the detail needed to implement it.

Without a full description of iFIT itself and a serious scrubbing of the marketing tone, I do not think that the document should be adopted.

[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. 

W

      should only be deployed when needed." -- this doesn't really say anything. Where is the format for the datastructure defined? How do I write one, how do I deploy it?.

[HS] The reference [CMSketch]  Cormode, G. and S. Muthukrishnan, "An improved data stream summary: the count-min sketch and its applications", 2005,
<http://dx.doi.org/10.1016/j.jalgor.2003.12.001> provides a good overview on sketch. In the next revision, I'll add some more description to help understand it. 

" iFIT Head Node:  A special iFIT node.  It is the entry node to an
      iFIT domain.  Usually the instruction header encapsulation, if
      needed, happens here." - this just names something, but does not describe what it actually *is*, etc.

[HS] If only read this one item, it might be confusing. The definition of this term depends on the definition of iFIT Node and iFIT domain, which depends on the definition of iFIT, iFIT application, and iFIT framework.

</no hats>

> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdata
> tracker.ietf.org%2Fdoc%2Fdraft-song-opsawg-ifit-framework%2F&amp;data=
> 02%7C01%7Chaoyu.song%40futurewei.com%7Cb89e7d80cf84400ac8d308d7921a933
> 4%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637138515165652629&amp;
> sdata=aVDfz5wun4SlNiCw9An6I03P3OLk%2FnNhZ1t1w0WOLd8%3D&amp;reserved=0
>
>
>
> https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=02%7C01%7Chaoyu.song%4
> 0futurewei.com%7Cb89e7d80cf84400ac8d308d7921a9334%7C0fee8ff2a3b240189c
> 753a1d5591fedc%7C1%7C0%7C637138515165652629&amp;sdata=ufpb86jAbJmOmncs
> HRNcmugluTUIsKIUF1JfFX%2Bu4cg%3D&amp;reserved=0

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants.
   ---maf

_______________________________________________
OPSAWG mailing list
[email-masked]
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fopsawg&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7Cb89e7d80cf84400ac8d308d7921a9334%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637138515165662626&amp;sdata=JNYRjj5yA87LHAAqI9qwns8kqXyXFc0BYQ%2FoSr9yF0Q%3D&amp;reserved=0

---

From: "Joe Clarke (jclarke)" <[email-masked]>
Date: Mon, 6 Jan 2020 23:31:44 +0000

On Dec 30, 2019, at 19:32, Haoyu Song <[email-masked]<mailto:[email-masked]>> wrote:

OPSAWG,

Based on the feedbacks from Frank, Al, Adrian, Alex, and others,  I have updated the draft with modifications and new text/figures. The major modifications are summarized as follows.  Please let me know if these addressed your concerns.

  1.  Add a Scope subsection to clarify the scope of the draft.  Basically, the proposed informational framework is nonmandatory. It suggests a high-level framework to address some practical deployment challenges for a class of on-path telemetry techniques. It doesn’t define the component and interface specifications and implementation details.
  2.  Categorize the on-path telemetry techniques discussed in the draft as Hybrid Type I, conforming to RFC7799.
  3.  Detail the description of the framework with clearer term definitions and block diagrams. Add a framework architecture figure. A block diagram is added for each component. Match each component to the corresponding component in Network Telemetry Framework.
  4.  Clarify this work doesn’t conflict or overlap with existing works in other WGs such as IPPM.
  5.  Remove the references to some premature or expired drafts.
  6.  Some document structure adjustments and numerous other modification in response to the detail comments.

Happy new year, Haoyu.  I am still catching up after being away on work and personal travel.  I appreciate your refinement of the draft based on comments.

<hat off>

Rev -10 still wants to straddle this notion of a generic framework and an architecture.  I think you are missing Frank and Alan’s points about the definition of iFIT nodes and applications being unimplementable.  For example, an iFIT application is a network monitoring application that conforms to the iFIT framework.  But how can an app conform to a framework when you’ve stated that this isn’t a strict structure that one can conform to?

In short, why does any of this need special names?  If you’re trying to write a document on how existing elements of OAM fit together, talk about those elements and discuss the implementation challenges of them.  I just don’t see how describing esoteric, unimplementable things helps anyone.

That said, I don’t want to put words into Frank or Alan’s mouths.  I would appreciate their feedback on -10 as well as others that have commented on the list.  I would also like to hear from operators that support this draft on how they are incorporating this work to make their OAM deployments more robust.

Joe

  1.
Happy New Year!

Best,
Haoyu

From: OPSAWG <[email-masked]<mailto:[email-masked]>> On Behalf Of Tianran Zhou
Sent: Wednesday, December 25, 2019 10:14 PM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

Working Group,

Merry Christmas!
Tianran

From: OPSAWG [mailto:[email-masked]] On Behalf Of Tianran Zhou
Sent: Monday, December 9, 2019 1:27 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [OPSAWG] WG adoption call for draft-song-opsawg-ifit-framework-09

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://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/<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%7C82e864f485004d8bd61c08d789caeb47%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637129376973095264&sdata=8F%2BqeDNMM3VOrDhvoSZO39rc8U66Rvh94KEgSvMfYz8%3D&reserved=0>

Thanks,
Tianran as co-chair

---

From: Alan DeKok <[email-masked]>
Date: Mon, 6 Jan 2020 20:44:12 -0500

On Jan 6, 2020, at 1:31 PM, Haoyu Song <[email-masked]> 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.

  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.

  Further, the "programmable data plane" has been standardized extensively in the ForCES working group since at least 2003:

https://datatracker.ietf.org/wg/forces/documents/

 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.

  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.

  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.

---

From: Haoyu Song <[email-masked]>
Date: Tue, 7 Jan 2020 02:29:44 +0000

Hi Alan,

Thanks for the response. Please see inline. 

Haoyu

-----Original Message-----
From: Alan DeKok <[email-masked]> 
Sent: Monday, January 06, 2020 5:44 PM
To: Haoyu Song <[email-masked]>
Cc: Warren Kumari <[email-masked]>; Tianran Zhou <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [OPSAWG] extend the call//RE: WG adoption call for draft-song-opsawg-ifit-framework-09

[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. 

  From the abstract:

   With the advent of

[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. 

https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fwg%2Fforces%2Fdocuments%2F&amp;data=02%7C01%7Chaoyu.song%40futurewei.com%7C90ac59d12b5041fc5ba108d793131d9d%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C1%7C637139582662175583&amp;sdata=%2FDgnRZ7FEukQMj9YGJD9NroNUu7jv0I8cZRAkc4k55g%3D&amp;reserved=0

[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.  

   iFIT includes several

  Quoting again:

[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.  

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 6 Jan 2020 21:59:39 -0500

> [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 its…

  Then this document describes an architecture, not a solution.  Which is fine.  There are many IETF architecture documents.  But they are rather less enthusiastic.

> [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 improp…

  Then say "no existing technology solves this problem".  That is a statement of fact.  Engineering is done on facts, not on enthusiasm,

> [HS] I'm fully aware of the existence of ForCES, I just didn't see its wide application in real products.

  Irrelevant.  The programmable data plane was being standardized going back to 2000.  So this document is entirely wrong when it says "with the advent of the programmable data plane".

  What would be factual would be to say "existing technologies do not fix this problem".

> [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 prac…

  I reiterate my objection that this draft says essentially nothing.  And as such, does not belong in the IETF.

  Alan DeKok.