SNMP is a management protocol, not a data transfer one. SNMP Trap is like a UDP message - send and forget.
SNMP Notify can require confirmation, so you can make sure it reaches it's destination (or know that it could not). I rather disagree with the characterization "low data rate and high overhead" - compared to what, and by what criteria? P.S. IMHO, SNMP Traps are perfect for telemetry. Regards, Uri Sent from my iPhone > On Oct 17, 2018, at 04:27, Adrian Farrel <adr...@olddog.co.uk> wrote: > > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
