opsawg-...@ietf.org
Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
On 10/16/18 15:39, Adrian Farrel wrote:
> Hi authors and working group.
>
> I just had cause to read this document and thought I would share my
> comments on the list.
Thanks, Adrian. I have had a chance yo read
Dear Joe,
Thank you very much for your comments. Please find my answer inline.
On Sun, Oct 28, 2018 at 11:50:43PM -0400, Joe Clarke wrote:
> On 10/16/18 15:39, Adrian Farrel wrote:
> > Hi authors and working group.
> >
> > I just had cause to read this document and thought I would share my
> > c
On 10/16/18 15:39, Adrian Farrel wrote:
> Hi authors and working group.
>
> I just had cause to read this document and thought I would share my
> comments on the list.
Thanks, Adrian. I have had a chance yo read this new version, and I'll
tack on to your comments. These are my comments as a con
__
From: OPSAWG on behalf of Haoyu song
Sent: Thursday, October 18, 2018 2:11:34 PM
To: Blumenthal, Uri - 0553 - MITLL; Randy Presuhn
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
I don't think we are trying anything "re-inventing the wheel".
First,
Message-
From: OPSAWG [mailto:opsawg-boun...@ietf.org] On Behalf Of Blumenthal, Uri -
0553 - MITLL
Sent: Thursday, October 18, 2018 12:20 PM
To: Randy Presuhn
Cc: opsawg@ietf.org
Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
I, as a reader, still wonder about re-inventing the whe
I, as a reader, still wonder about re-inventing the wheel - even with the 1st
paragraph of 1.4 untouched.
Regards,
Uri
Sent from my iPhone
> On Oct 18, 2018, at 14:12, Randy Presuhn
> wrote:
>
> Hi -
>
>> On 10/18/2018 12:58 AM, Tianran Zhou wrote:
>> Well, the first paragraph in section 1.
Hi -
On 10/18/2018 12:58 AM, Tianran Zhou wrote:
Well, the first paragraph in section 1.4 is neither clear nor necessary.
I would suggest to remove this paragraph. Is that OK for you?
The paragraph does seem clear, but is (in my opinion) incorrect.
However, it appears to be an integral part of
18, 2018 12:51 PM
> To: opsawg@ietf.org
> Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
>
> Hi -
>
> On 10/17/2018 6:37 PM, Tianran Zhou wrote:
> > I do not mean to say the SNMP design is problematic.
> > But I think it's not designed for periodicall
Hi Adrian,
Thank you very much for the comments. I'll try to address all your comments in
the new revisions. Given the time and bandwidth, I may leave some parts (e.g.,
security concern) to future revisions.
Yes, gRPC is a recursive acronym and "g" doesn't mean google although we all
know whe
Hi -
On 10/17/2018 6:37 PM, Tianran Zhou wrote:
I do not mean to say the SNMP design is problematic.
But I think it's not designed for periodically getting
operational data, which is one important case for streaming telemetry.
That's one of the possible use cases for RFC 2981 or RFC 3877,
and
] On Behalf Of Randy Presuhn
> Sent: Thursday, October 18, 2018 8:38 AM
> To: opsawg@ietf.org
> Subject: Re: [OPSAWG] Thoughts on draft-song-opsawg-ntf
>
> Hi -
>
> On 10/16/2018 8:08 PM, Tianran Zhou wrote:
>
> > 2. no customizable periodical and on-chang
Hi -
On 10/16/2018 8:08 PM, Tianran Zhou wrote:
2. no customizable periodical and on-change export. So have to use poll
operation.
Have you tried RFC 2981 or RFC 3877?
If so, what aspects of their design did you find problematic?
3. need special definition and support, not apply for an
ct: 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 rath
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 ove
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 ; opsawg@ietf.org
> Cc: draft-so
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
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
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 enhan
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 fo
19 matches
Mail list logo
