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

[Greg Mirsky <[e-mail]>]

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.

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?

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.

Regards,
Greg