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
