Hi Dan, Could you please help to clarify this? > (3) Additional Challenge - Have you considered a model-driven telemetry API > from the iFIT framework that could expose network performance to external > applications? Maybe something along the lines of: > > >> > o C6: Development of simplified iFIT telemetry primitives and model, > including: telemetry data (e.g., nodes, links, ports, paths, flows, > timestamps) query primitives. These may be used by an API-based > telemetry service for external applications to iFIT, for > monitoring end-to-end latency measurement of > network paths and application latency calculation via the iFIT > framework. > <<
What do you mean by model-driven telemetry API? What's the difference from other APIs? Do you actually mean to define information/data models? So the IPFIX template, YANG model, or proto file. Thanks, Tianran > -----Original Message----- > From: OPSAWG [mailto:[email protected]] On Behalf Of > [email protected] > Sent: Tuesday, October 08, 2019 3:48 PM > To: [email protected] > Cc: [email protected] > Subject: [OPSAWG] Comments for draft-song-opsawg-ifit-framework-05.txt > > Dear Authors, > > Please find some comments, thoughts and suggestions for > https://tools.ietf.org/html/draft-song-opsawg-ifit-framework-05 > > Overall, a really useful document and something I hope the WG can progress. > There are many in-band/in-situ OAM documents currently floating around in > at least four IETF WGs, so a document that helps coordinate the discussion > would be very valuable. > > General Comments > > (1) Abstract - The scope is clear, but the intention of this document could > be clarified. You might rephrase as: > > >> > For efficient network operation, most operators rely on traditional > Operation, Administration and Maintenance (OAM) methods, which > include proactive and reactive techniques, running in active and > passive modes. As networks increase in scale they become more > susceptible to hardware and software failures, and misconfiguration > errors. > > With the advent of programmable data-plane emerging "on-path" OAM > techniques, such as flow telemetry, provide unprecedented insight > and fast notification of network issues (e.g., jitter, increased > latency, packet loss, significant bit error variations, and unequal > load-balancing. > > In-situ Flow Information Telemetry (iFIT), would provide a method > for efficiently applying underlying on-path flow telemetry > techniques, applicable across various network environments. > > This document outlines an iFIT framework, which enumerates several > critical functional components and describes how these components > are assembled together to achieve a complete and closed-loop > working solution for on-path flow telemetry. > << > > (2) Use of "Application-aware network" - We may need to be careful with this > the usage of this word. It already has a well-used meaning in the context > of Cloud and SDN. If you are happy with the general description, we could > continue to use "application-aware networking", but we should add a > definition, such as: > > >> > Future networks must also support application-aware networking. > Application-aware networking is an emerging industry term and > typically used to describe the capacity of an intelligent network to > maintain current information about user and application connections > that use network resources and, as a result, the operator is able to > optimize the network resource usage and monitoring to ensure > application and traffic optimality. << > > (3) Additional Challenge - Have you considered a model-driven telemetry API > from the iFIT framework that could expose network performance to external > applications? Maybe something along the lines of: > > >> > o C6: Development of simplified iFIT telemetry primitives and model, > including: telemetry data (e.g., nodes, links, ports, paths, flows, > timestamps) query primitives. These may be used by an API-based > telemetry service for external applications to iFIT, for > monitoring end-to-end latency measurement of > network paths and application latency calculation via the iFIT > framework. > << > > (4) Security - I think this section requires significantly more text as I > can think of numerous issues that will need to be considered, or at least > highlighting best practices and considerations discussed in other > documents. I started working on a much more comprehensive security section, > I will send this to the authors directly (or the list if you prefer) over > the next few days. > > (5) Please find the edits, typos, NITs, suggested text in the attached > documents: > > o draft-song-opsawg-ifit-framework-05-review.txt - > https://github.com/danielkinguk/draft-song-opsawg-ifit-framework/blob/ma > ster > /draft-song-opsawg-ifit-framework-05-review.txt > o draft-song-opsawg-ifit-framework-05-review-diff.html - > https://github.com/danielkinguk/draft-song-opsawg-ifit-framework/blob/ma > ster > /draft-song-opsawg-ifit-framework-05-review-diff.html > > I hope this helps. > BR, Dan. > > -----Original Message----- > From: I-D-Announce <[email protected]> On Behalf Of > [email protected] > Sent: 26 September 2019 18:29 > To: [email protected] > Subject: I-D Action: draft-song-opsawg-ifit-framework-05.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : In-situ Flow Information Telemetry Framework > Authors : Haoyu Song > Zhenbin Li > Tianran Zhou > Fengwei Qin > Huanan Chen > Jaewhan Jin > Jongyoon Shin > Filename : draft-song-opsawg-ifit-framework-05.txt > Pages : 16 > Date : 2019-09-26 > > Abstract: > Unlike the existing active and passive OAM techniques, the emerging > on-path flow telemetry techniques provide unmatched visibility into > user traffic, showing great application potential not only for > today's network OAM but also for future's automatic network > operation. Summarizing the current industry practices that addresses > the deployment challenges and application requirements, we provide a > closed-loop framework, named In-situ Flow Information Telemetry > (iFIT), for efficiently applying a family of underlying on-path flow > telemetry techniques in various network environments. The framework > enumerates several key architectural components and describes how > these components are assembled together to achieve a complete and > closed-loop working solution for on-path flow telemetry. Following > such a framework allows better scalability, fosters application > innovations, and promotes both vertical and horizontal > interoperability. > > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-song-opsawg-ifit-framework/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-song-opsawg-ifit-framework-05 > https://datatracker.ietf.org/doc/html/draft-song-opsawg-ifit-framework-0 > 5 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-song-opsawg-ifit-framework-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html or > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
