Re: [OPSAWG] WGLC: Comments on draft-opsawg-ntf

[Haoyu Song <[e-mail]>]

Hi Greg,

Thank you very much for the review and comments!
We agree that network telemetry doesn’t contradict with OAM, and in fact, OAM is an important part of network telemetry. We will take your insight and reword the corresponding paragraphs for clarification. Please see inline for more response.

Best regards,
Haoyu

From: OPSAWG <[e-mail]> On Behalf Of Greg Mirsky
Sent: Tuesday, October 6, 2020 6:05 PM
To: [e-mail]; [e-mail]
Subject: [OPSAWG] WGLC: Comments on draft-opsawg-ntf

Dear Authors,
thank you for your work on this document. I believe that it is important to analyze and explain what is network telemetry, how it relates to the established tools that support network operations, administration, and maintenance (OAM).

Traditionally, OAM tools support two components of the FCAPS network management model - Fault Management (FM) and Performance Monitoring (PM). The former, FM, in addition to a failure detection tool, may include, for example, a protection switchover coordination protocol. Both FM and PM, when in use, produce information that reflects the state of the network.

Network telemetry may be viewed in two aspects - telemetry information that reflects the state of the network and methods used to collect and transport telemetry information.

At this point, I believe, we see that OAM and telemetry have something in common - information that characterizes the state of the network, a part of the network. If that is the case, then I think that statements about the relationship between OAM and telemetry:
   As evidenced by the defining
   characteristics and industry practice, network telemetry covers
   technologies and protocols beyond the conventional network
   Operations, Administration, and Management (OAM).  Network telemetry
   promises better flexibility, scalability, accuracy, coverage, and
   performance and allows automated control loops to suit both today's
   and tomorrow's network operation requirements.
or
   One difference between the network telemetry and the network OAM is
   that the network telemetry assumes machines as data consumer, while
   the conventional network OAM usually assumes human operators.
are arguable, at the minimum. I believe that there's no contradiction between OAM protocols and telemetry collection methods. On the contrary, each is essential and is complementary to the other, especially when detecting a network failure. To illustrate the latter, I can offer a case of monitoring a standby path that protects a working path. While an on-path method of collecting information can be used to monitor the condition of the working path, the standby can be monitored, in my opinion, only using an active OAM method injecting specially constructed test probes.

Another, rather general comment I have is on using RFC 7799 classification of PM methods. I think that the first reference to RFC 7799 is appropriate in or before Section 2.4.

[HS] will do.

Further, in Section 3, the document differentiates between Event-triggered Data and Streaming Data. I think that, based on the current definitions, there's little if anything that differentiates these two. Consider the definition of Streaming Data:
   Streaming Data:  The data are continuously or periodically generated.
      It can be time series or the dump of databases.  The streaming
      data reflect realtime network states and metrics and require large
      bandwidth and processing power.
Can timer expiration be viewed as an event? Also, If the timer that defines the frequency of data set export is long, is the information truly real-time? Or, doesn't Event-triggered Data reflects the state in real-time?

[HS] I think I see your point. Timer expiration is an event for sure. I think the difference is subtle.  For example, event-triggered data can be actively pushed (so it’s real-time) or passively polled (so it’s not real-time), but streaming data are always pushed. I’ll make the definition and description of streaming data more rigid to differentiate it from the event-triggered data.

Information collected in Figure 3 (could be tagged as a table) is very interesting. I think that it would be beneficial to add more explanation to the content of the table.

[HS] Do you really mean Figure 3 or some other figure?

Regards,
Greg