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 > > 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. Regardless of being in opsawg, we are trying to ensure that the network telemetry framework in our draft is completely consistent with the work that is being done in other WGs. If you find any specific inconsistency, please let us know. > 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. We are first tackling the requirements of a proper telemetry framework, and it currently requires new protocols to correctly manage telemetry data. However, when we finish polishing the requirements, we can find that some can be met by extending other protocols and we will proceed to update the framework accordingly. > 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. Thank you for pointing this. As mentioned above, we are now focusing on polishing requirements, so clarifying it and including a detailed gap analysis will be our next step. Please be tuned if you are interested. > 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. We will rework those statements to avoid this misinterpretation. It is not our intention to relegate the role of OAM, just to make clear that it is not what current network management needs. Telemetry is the answer to it and OAM has its limitations in scope and purpose. > 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. As I mentioned above, we will continue working on this to be sure the gaps and challenges are clear. > 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. Of course, nowadays, both security and privacy must be totally traversal requirements to any form of management and transmission of data that can be used to find or reveal some personal information. We will ensure both constraints are covered in the network telemetry framework. > Joe Again, thanks for your comments. Regards, Pedro -- Pedro Martinez-Julia Network Science and Convergence Device Technology Laboratory Network System Research Institute National Institute of Information and Communications Technology (NICT) 4-2-1, Nukui-Kitamachi, Koganei, Tokyo 184-8795, Japan Email: [email protected] --------------------------------------------------------- *** Entia non sunt multiplicanda praeter necessitatem *** _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
