Hi Joe, Here I also try to response an earlier question you raised in anther email: “Others commented that a detailed comparison and evaluation is required in order to determine what the right approach/recommendation should be.” I think the nature of the doc is more like a survey than an in-depth analysis and comparison of techniques.
When we say that "new protocol" is needed, we are actually saying those existing protocols other than the conventional OAM protocols are "new", such as gPRC，YANG PUSH. Maybe we need to rephrase this point. Of course, we don't exclude the possibility that, when new gaps are identified, newer protocols are indeed needed. For example, in control plane and data plane, we have already identified some of the new needs. We also don't mean to deprecate the existing OAM protocols and techniques. I agree with you that it will coexist with telemetry even in future automated network operations. We'll make the expression more accurate in the future revisions. We admit that there are still work need to be done about this doc and that's exactly why we need the collaboration from the community. What we are trying to do is to make the work useful and align its purpose and scope with OPSAWG. Thank you very much! Best, Haoyu -----Original Message--- From: Joe Clarke [mailto:[email protected]] Sent: Sunday, October 28, 2018 8:51 PM To: [email protected]; [email protected] Cc: [email protected] 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 this new version, and I'll tack on to your comments. These are my comments as a contributor. > 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. I do agree that we need a baseline for terminology, much like was done for OAM. Where I struggle is where this work should be done. On one hand, a WG like opsawg does make sense. However, the existing work spans multiple WGs and areas. It seems to me that the authors will have to do quite a bit of leg work to make sure that their framework aligns with work that is quickly maturing and being implemented. In terms of sectional comments, the abstract mentions that telemetry requires new protocols. But there are already protocols that provide "telemetry" (and some like gRPC, YANG push, etc. have emerged "recently"). From my reading, I do not know if the authors feel more new protocols are needed. The abstract also mentions that future directions are discussed for each section. I did not see this. In general, each section describes some informal requirements and enumerates some challenges with existing work. What I was hoping to see is a more in-depth gap analysis with this existing work with respect to requirements. I disagree with the point in section 2.4 that a key difference between telemetry and OAM is human vs. machine operations. You say that telemetry is designed to build closed-loop, machine-driven control systems whereas OAM requires human intervention. I feel that a holistic closed loop control system would use telemetry _and_ OAM. I could certainly see (as with SNMP traps, IPFIX, or gRPC streams) that a human might make some post-processing assessment of that data. That said, trying to define what this system looks like will be a closing battle IMHO. What works for one operator will almost certainly not work for another. When the authors list out the existing work in each of the main telemetry categories, I'm not seeing the gap analysis to the requirements they list prior. For example, they describe what iOAM is, gloss over some challenges, but don't really say where it fits with the requirements (or what more is required specific to those requirements). That is only one example. I see the same with every other mentioned example. I agree with you, Adrian that security needs to be fleshed out. In terms of the data that telemetry provides, there should be robust security requirements around it. Joe _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
