[OPSAWG] Comments on draft-song-opsawg-ifit-framework-09

[Alexander L Clemm <[e-mail]>]

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