Dear Mr. Farrel, Thank you very muchu for your review and detailed comments. We will update the doc accordingly. As one of the authors from the operators, I think this is a good start point to contine the telemetry related work in OPSAWG. We belive telemetry will be used in the network to enhance the OPS capability and level. Especially in the SDN era, we need the detail network and service status information, which is suitable to be provided by telemetry, to develop the capability of the SDN archeticture.
Best Regards, Zhenqiang Li [email protected] From: Adrian Farrel Date: 2018-10-17 03:39 To: [email protected] CC: [email protected] 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 [email protected] https://www.ietf.org/mailman/listinfo/opsawg
