Hi Adrian, I see. Thank you very much for your suggestions. We will update the document to clarify this.
Thanks, Tianran > -----Original Message----- > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > Sent: Wednesday, October 17, 2018 5:27 PM > To: Tianran Zhou <zhoutian...@huawei.com>; opsawg@ietf.org > Cc: draft-song-opsawg-...@ietf.org > Subject: RE: Thoughts on draft-song-opsawg-ntf > > Hi Tianran, > > Yes, I mean the "Trap" which is now called "Notification." > > You're right in your assessment of the drawbacks, and you should add to that > list the drawback of the low data rat and high overhead that come with the > protocol. > > I didn't mention the Notification to propose it as a mechanism for telemetry, > but just so that your introductory text has a complete description of the > pre-existing environment. > > Best, > Adrian > > > -----Original Message----- > > From: Tianran Zhou [mailto:zhoutian...@huawei.com] > > Sent: 17 October 2018 04:09 > > To: adr...@olddog.co.uk; opsawg@ietf.org > > Cc: draft-song-opsawg-...@ietf.org > > Subject: RE: Thoughts on draft-song-opsawg-ntf > > > > Hi Adrian, > > > > Thank you very much for your careful review and comments. > > > > On this discussion: > > "In 1.4 you have > > Since SNMP is poll-based, it incurs > > low data rate and high processing overhead. > > I don't think this is quite fair on SNMP. The protocol also includes > Notifications > > allowing information to be output by a device. Your main point about > > low data rates and high overhead, still stand, but with a different slant." > > > > Do you mean the SNMP trap, which is used for alarm and event? > > I agree, it's push based notification with binary encoding. However, > > 1. no easy CRUD operations 2. no customizable periodical and on-change > > export. So have to use poll operation. > > 3. need special definition and support, not apply for any mib data. > > > > Do you think the above are the SNMP defeat for telemetry use? > > > > Or what your thoughts? > > > > Thanks, > > Tianran > > > > > -----Original Message----- > > > From: Adrian Farrel [mailto:adr...@olddog.co.uk] > > > Sent: Wednesday, October 17, 2018 3:40 AM > > > To: opsawg@ietf.org > > > Cc: draft-song-opsawg-...@ietf.org > > > Subject: Thoughts on draft-song-opsawg-ntf > > > > > > Hi authors and working group. > > > > > > I just had cause to read this document and thought I would share my > > > comments on the list. > > > > > > The draft appears as -00, but it is a little more mature than that > > > implies because it replaces draft-song-ntf-02. > > > > > > I think a foundation document on telemetry would be useful for the > > > IETF, and the OPSAWG may be a good place to discuss and progress that > work. > > > This document seems like a reasonable starting point for that work > > > although there will inevitably need to be some additions and > > > modifications. Actually, I found this document pretty complete. > > > > > > My comments are a combination of substantive issues and nits. > > > > > > Hope this helps. > > > > > > Regards, > > > Adrian > > > > > > == Discussion points == > > > > > > In 1.4 you have > > > Since SNMP is poll-based, it incurs > > > low data rate and high processing overhead. > > > I don't think this is quite fair on SNMP. The protocol also includes > > > Notifications allowing information to be output by a device. Your > > > main point about low data rates and high overhead, still stand, but > > > with a different slant. > > > > > > --- > > > > > > Although you talk about IPFIX quite a bit later in the document, I > > > think > that, > > > as part of the scene setting, you might include a paragraph about it > > > early in 1.4. > > > > > > --- > > > > > > The text after Figure 1 did not completely convince me of the need > > > for interaction between the three "telemetry planes". Perhaps you > > > could expand the examples and discussion to highlight/clarify this? > > > > > > --- > > > > > > Clearly you are going to have to write some Security Considerations. > > > There is quite a lot to say about what is a layered security model > > > with > plenty > > > of attack vectors, and substantial risks as the telemetry data can > > > result in operational changes that could harm data delivery and even > > > bring the network down. Furthermore, examination of telemetry data > > > can reveal weaknesses in the network. > > > > > > == Nits == > > > > > > The authors will need to reduce the number of front page names to 5. > > > Move the others to a Contributors section. Might as well do this > > > sooner > rather > > > than later. > > > > > > --- > > > > > > Abstract > > > > > > This document suggests the necessity of an architectural framework > > > for network telemetry in order to meet the current and future network > > > operation requirements. > > > > > > Suggest you change this a little because you actually provide the > framework. > > > How about... > > > > > > This document provides an architectural framework for network > > > telemetry in order to meet the current and future network operation > > > requirements. > > > > > > --- > > > > > > You need to write an Introduction section and present it as Section 1. > > > You don't need a lot of text: start with the Abstract and expand it > > > a > little. > > > > > > --- > > > > > > The Requirements Language text should move to a new Section 1.1 > > > > > > --- > > > > > > You should expand the abbreviations on first use. I see: > > > AI > > > ARCA > > > ML > > > OAM > > > SDN > > > > > > --- > > > > > > A couple of the terms in 1.3 are confusing. > > > > > > > gNMI: gPRC Network Management Interface > > > Should that be gRPC? > > > > > > > gRPC: gRPC Remote Procedure Call > > > This seems circular. > > > > > > --- > > > > > > Not sure that RFC 1157 is the best reference for SNMP in section 1.4. > > > How about 3416? > > > > > > --- > > > > > > Figure 3 > > > Does gPRC mean gRPC? _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
