Hi Uri,

Thanks for the comments. I'd like to clarify there's no black and white 
separation between conventional OAM and telemetry. Conventional OAM is also 
indispensable in many cases and some tools is also evolving to bear more 
characteristics of a typical telemetry system. I'll make the modification and 
clarification accordingly.

Haoyu

-----Original Message-----
From: Blumenthal, Uri - 0553 - MITLL [mailto:u...@ll.mit.edu] 
Sent: Wednesday, October 17, 2018 5:55 AM
To: adr...@olddog.co.uk
Cc: Tianran Zhou <zhoutian...@huawei.com>; opsawg@ietf.org; 
draft-song-opsawg-...@ietf.org
Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf

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

_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

Reply via email to