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 <[email protected]> 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 <[email protected]> *On Behalf Of *Greg Mirsky > *Sent:* Tuesday, October 6, 2020 6:05 PM > *To:* [email protected]; [email protected] > *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 > > > > > > > > > > > > > > >
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
