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

From: Alexander L Clemm <[email-masked]>
Date: Tue, 10 Dec 2019 09:42:11 -0800

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

---

From: Haoyu Song <[email-masked]>
Date: Tue, 10 Dec 2019 18:00:06 +0000

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-masked]> 
Sent: Tuesday, December 10, 2019 9:42 AM
To: [email-masked]
Cc: [email-masked]
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