[OPSAWG] Review of draft-ietf-opsawg-ntf

["Adrian Farrel" <[e-mail]>]

Hi authors, WG,

I needed to read this document to check out a couple of things, and so
here is a review that I collected along the way. I hope it is useful.

In general, I found the document a help collection of thoughts on the space
and I encourage more work to refine it.

Best regards,

Adrian

===

I think that the Introduction launches in with the use of two terms that
could use just a little more explanation. They are "Network Visibility"
and "Network Telemetry".

You don't need pages of text to explain them, but just very quick
context-setting text. Such as...

   Network visibility is the ability of management tools to see the
   state and behavior of a network.  It is essential for successful
   network operation.

   Network telemetry is the process of measuring, recording, and
   distributing information about the behavior of a network.  Network
   telemetry has been considered as an ideal means to gain sufficient
   network visibility with better flexibility, scalability, accuracy,
   coverage, and performance than conventional OAM technologies.

---

Although you expand "OAM" in the Abstract, you need to also expand it
on first use in the body of the text.

---

Section 1

s/technique/techniques/

---

I don't think you use any normative language, so you can drop section
1.1 and the two references.

---

The start of Section 2 is a bit abrupt.

   Thanks to the advance of the computing and storage technologies,
   today's big data analytics gives network operators an unprecedented
   opportunity to gain network insights and move towards network
   autonomy.

While this is sort of true, it steps over the fact that "big data" has
to be collected (where collection means both recorded and moved into a
single dataset).

So, I would break this down into:
- what is big data?
- what development in analytic tools is now meaning can be done with 
  big data
- how this might be applicable to networks if the right data can be
  recorded, collected, and analysed.

You get to this last point nicely in paragraph 3, so you only need to
set that up.

---
   
You need to check for all abbreviations being expanded on first use.   
I found:
ROI
CAPEX
RIB
ACL
MIB
QoS
CPU
GPB

---
   
2.2

s/are lack of formal/lack a formal/

---

2.3

This is a good collection of terms and explanations. Thanks. It would be
even better if you were able to add (informative) references to point
the reader at places to go for more background information.

Maybe the explanation of "YANG" should include an expansion of the
abbreviation.

---

I don't find the inclusion of "YANG FSM" in this document convincing.
You only include it in the terminology section and in Figures 5 and 6.
But you don't have any explanation of what the term means, nor any
indication of how it is relevant to this document.

---

2.4

draft-kumar-rtgwg-grpc-protocol may not be the best reference for gRPC.
I know you're only looking for an informative reference, but this draft
expired 30 months ago.

I don't have any suggestions for a better reference, but there is 
probably something on https://grpc.io

---

2.4

I think I would add to the second list of bullets in this section to 
describe "in-network data aggregation/correlation". One of the
applications AI and other "smart algorithmics" is to improve the 
collection and reporting of data from the network. That is, network
devices and aggregation points can work out which events and what 
data needs to be stored, reported, or discarded thus reducing the
load on the central collection and processing points while still
ensuring that the right information is ready to be processed in a
timely way.

I might also add "in-network processing". That is, there is not a
necessary step to gather all information to a central point so that it
can be processed and actions taken - it is possible for some processing
to be done in the network, and actions taken more locally and more
responsively.

This might link in to section 4.3 for the discussion of "Data Query,
Analysis, and Storage" because it is not inconceivable that the analysis
and storage will be distributed, and that the queries may be 
hierarchical.  That wouldn't require a change to the structure of Figure
4.

---

Section 3

   So far, some telemetry related work has been done within IETF.
   However, the work is fragmented and scattered in different working
   groups.  The lack of coherence makes it difficult to assemble a
   comprehensive network telemetry system and causes repetitive and
   redundant work.

This will not age well. Maybe say instead...

   A telemetry framework collects together all of the telemetry-related
   work from different sources and working groups within the IETF.  This
   makes it possible to assemble a comprehensive network telemetry 
   system and to avoid repetitious or redundant work.

---

4.1

s/mutual exclusive/mutually exclusive/

---

4.2

   as shown in Figure 2.  Therefore, we categorize the
   network telemetry into four distinct modules.

Figure 2 then shows five boxes. So either...

   as shown in Figure 2.  Therefore, we categorize the
   network telemetry into five distinct modules.

...or...

   as shown in Figure 2.  Therefore, we categorize the
   network telemetry into four distinct modules together with Network
   Operation Applications.

---

It would be helpful if there was some text to accompany Figure 3 to
announce and explain the six row categories.

---

Figure 5 and 6 you have "IOAM" and "In-situ OAM". Can you be consistent.

---

Figure 5 has "Custom Data" is this "Complex Data"?

---

Something doesn't see right in section 5. You talk about the "telemetry
data" being, for example "static". I don't think it would be helpful if
the data was static. You possibly mean that the counters can or cannot
be configured. Or something like that.

---

You don't seem to use the reference to RFC 1157.

---

It would be helpful to note at the top of the Appendix that it is non-
normative.