Hi Tianran,
Let me expand on the thought I was having.
Is it possible, and useful, to develop a telemetry policy model that would
define a set of telemetry primitives that the iFIT application would send to
the iFIT controller? In other words, how might I automate the request from
an iFIT application by using some policy language that would scope the type
of analysis requested, constrain the telemetry mechanism applied and provide
potential success factors:
1. What to observe?
2. What to collect?
3. Where and which triggers to set?
4. Where to store?
5. How much data to store?
6. When to stop collecting?
Taking the first insight ("What to observe?"), this could expand to
something like (not exhaustive):
+-What to observe?
+-Anomalies
+-Loops
+-Congestion
+-High Latency
+-High Loss
+-Unexpected Traffic Increase
+-Etc.
+-Events
+-Low Link Utilisation
+-Low Node Utilisation
+-Unexpected Path
+-Path Performance Degradation
+-Etc.
+-Data Collection Filters
+-Flow/Packet Sample Rate
+-Interface/Port Info
+-Queue Info
+-Metadata Info
+-Timestamps
+-Drop Condition/Reason
Now to be clear, I am not advocating draft-song-opsawg-ifit-framework would
detail the model and parameters, just that it's a Framework I-D and if you
think this capability would be useful you might list this capability as
high-level requirement. Potentially existing IETF proposals/documents could
be used for the solution, I did have a search previously but could not find
anything specific that might be suitable. Perhaps a new document that refers
back to draft-song-opsawg-ifit-framework could be created if current no
suitable model/tree is found.
Another aspect of the draft-song-opsawg-ifit-framework that I was thinking
about was security, and specifically how to manage what is set, when its
triggered and who and what has access/may consume to the iFIT data. It seems
a compromised iFIT platform could accomplish some pretty nasty DDOS on the
forwarding plane of the network, and the data collectors themselves. I could
draft some text for Security section if you think it's useful.
BR, Dan.
-----Original Message-----
From: Tianran Zhou <[email protected]>
Sent: 09 October 2019 07:34
To: [email protected]; [email protected]
Cc: [email protected]
Subject: RE: [OPSAWG] Comments for draft-song-opsawg-ifit-framework-05.txt
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
