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

[Greg Mirsky <[e-mail]>]

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

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.

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 <[e-mail]> wrote:

> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>