Hi Alex, Thank you very much for your support and detailed review. We'll consider your suggestions in the next revision. They'll definitely help improve the quality of the draft.
Best regards, Haoyu -----Original Message----- From: Alexander L Clemm <[email protected]> Sent: Tuesday, December 10, 2019 9:42 AM To: [email protected] Cc: [email protected] Subject: Comments on draft-song-opsawg-ifit-framework-09 Hi Haoyu, Draft Authors, after reading draft-song-ifit-framework-09, whose adoption I support, FWIW I have a few comments that I think should be addressed in future revisions of the draft: Section 1, 2nd paragraph: line of argumentation why "radical rethinking of existing methods" needs to be strengthened. While reasoning is given that the importance of monitoring and troubleshooting continues to grow, I don't think there are convincing arguments given why rethinking and new methods would be required, and the framework itself does not really propose such methods. Section 1, C2: It should be mentioned that the growing OAM data can also negatively affect service levels. For example, if telemetry data keeps getting added at each hop, not only does the packet grow but also its serialization delay, which could be detrimental in some cases. (Possibly this could even be listed as additional challenge C.2.5) Section 3, in particular Figure 1: (I consider this my most important comment): I don't think the Figure and the introductory text that surrounds it does a framework justice. What is being depicted in the figure seems to be a fairly generic monitoring/telemetry collection architecture, not a new framework, and made me even question why we would produce a document just for that? Importantly, the key components of iFIT which are listed in section 4 are not depicted in the Figure, nor are they mentioned as part of the framework in section 3. I do think that those key components are important and their integration with the framework crucial. A framework that explains how things like smart data export, smart flow selection, a choice of different probing techniques, etc complement each other and work in concert makes a lot of sense. I think section 3 needs to be updated to make sure that it does not sell iFIT short. Section 4 (or 3?): The document should explain better why iFIT is called iFIT, not iPIT. In other words, that it does not limit itself to packet telemetry, but indeed flow telemetry (which includes, for example, the aspects of probing and smart flow selection, which aim at getting a picture of flows in their entirety. This aspect is important but easily lost on the reader. Section 4.2 cannot be addressed by iFIT as it is currently stated, as it is missing an aggregation function. I suggest that such a function is added and explicitly listed as a key component at the onset of section 4. Section 4.5 likewise does not make it clear how its topic (on-demand technique selection and integration) gets addressed using the framework. I think what section 4.5 is super important but some editing will be needed to make clear how these important aspects are being accomplished using the framework and its component. As is, the framework and some of these aspects stand too much side-by-side. Kind regards --- Alex _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
