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

From: Greg Mirsky <[email-masked]>
Date: Tue, 6 Oct 2020 18:04:40 -0700

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

---

From: Haoyu Song <[email-masked]>
Date: Wed, 7 Oct 2020 20:34:43 +0000

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 <[email-masked]> On Behalf Of Greg Mirsky
Sent: Tuesday, October 6, 2020 6:05 PM
To: [email-masked]; [email-masked]
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:
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

---

From: Greg Mirsky <[email-masked]>
Date: Thu, 8 Oct 2020 14:09:15 -0700

Hi Haoyu,
thank you for your kind consideration of my comments.
I apologize for the confusion in the last comment

I meant to reference Figure 2, thank you for catching that and asking for
the clarification.

Regards,
Greg

On Wed, Oct 7, 2020 at 1:34 PM Haoyu Song <[email-masked]> wrote:

> 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 <[email-masked]> *On Behalf Of *Greg Mirsky
> *Sent:* Tuesday, October 6, 2020 6:05 PM
> *To:* [email-masked]; [email-masked]
> *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
> 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.
>
>
>
> 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
> [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.
>
>
>