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
Sent: Tuesday, December 10, 2019 9:42 AM
To: draft-song-opsawg-ifit-framework.auth...@ietf.org
Cc: opsawg@ietf.org
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
