Re: [OPSAWG] YANG based Collection and Aggregation Framework//: New Version Notification for draft-opsawg-poweff-00.txt

["Jan Lindblad (jlindbla)" <[e-mail]>]

Qin,

Excellent feedback! Thanks for taking the time to read and compose detailed comments.

I'm very grateful for the reading list; now I know what to do on the train to Prague :-) I was unaware of most of these, so very timely pointers. I am aware, however, that there is plenty of prior work in this field, and much going on right now in IETF and at vendors. I hadn't seen anything that addressed the Time Series Database (TSDB) integration, though, so I thought I'd write down what I had been thinking. My hope is that this draft will merge with existing work in the area.

Your observation that this approach favors traceability of data flows all the way back to individual sensors is gratifying; that is very much the core idea. Too many times have I said "Nice graph; so are you reading PSU voltage and current sensors on the device? Is that the true power, or reactive/apparent power? How accurate is that reading? Is the local cooling cost (i.e. fans) included?" and usually (and I hear many others reporting the same experience) such questions cannot be answered the same day. The measurements are not transparent.

Let's continue the discussion in Prague.

Best Regards,
/Jan


On 1 Nov 2023, at 06:50, Qin Wu <[e-mail]> wrote:

Hi, Jan, Marisol:
I have read the latest version of draft-lindblad-tlm-philatelist<https://datatracker.ietf.org/doc/draft-lindblad-tlm-philatelist/> and feel it is very interesting draft since it can aggregate data from various different data sources using different telemetry technologies.
First I see many metadata related work in this space , some of them are ongoing, some of them have already expired, e.g.,
1.       out of band metadata collection  https://datatracker.ietf.org/doc/draft-ietf-opsawg-collected-data-manifest/
2.       in band metadata collection         https://datatracker.ietf.org/doc/html/draft-ietf-netmod-node-tags-09
3.       Semantic Metadata Annotation  https://datatracker.ietf.org/doc/draft-netana-opsawg-nmrg-network-anomaly-semantics/
4.       cloud-native metrics and time series format  https://datatracker.ietf.org/doc/html/draft-richih-opsawg-openmetrics-00
5.       self-describing format for metadata abstract  https://www.ietf.org/archive/id/draft-gray-sampled-streaming-03.txt

Secondly. I think the metadata can be used to collect telemetry context information, telemetry data classification information,
In your draft, the metadata collected by YANG based collection and aggregation framework seems more related to measurement related attributes,
Such as measurement unit, mathematic operation such as sum, average, max, min,etc, I remember XPATH 1.0 do support some of mathematic computation operation, such as max, min and logical operation such as AND and OR,
This has been discussed in https://www.ietf.org/archive/id/draft-ietf-netmod-eca-policy-01.
I can imagine the network device has already support some of mathematic computation operation, therefore can report summary statistics data using telemetry interface.

3.Regarding measurement quantities, I think open metrics also can be used to aggregate metrics related data, express all system states as numerical values;
counts, current values, enumerations, and Boolean states, I am wondering how these two work are different, whether draft-lindblad-tlm-philatelist<https://datatracker.ietf.org/doc/draft-lindblad-tlm-philatelist/> can better align with
open metrics regarding metric aggregation.
4. Section 3.3 said:
“

Each flow is associated with one or more inputs, one output and a

   series of processing operations.  Each input flow and output flow may

   have an pre-processing or post-processing operation applied to it

   separately.  Then all the input flows are combined using one or more

   aggregation operations.


”
It is very interesting to keep track of flow from the data source to destination group and traverse a set of aggregation points,
It seems to provide a good visibility to the flow path within the analytics platform, I am wondering what is the benefit or goal to keep track of these flow path?
Is this implementation specific?

-Qin
发件人: OPSAWG [mailto:[e-mail]] 代表 Marisol Palmero Amador (mpalmero)
发送时间: 2023年10月28日 1:07
收件人: [e-mail]<mailto:[e-mail]>
抄送: Gonzalo Salgueiro (gsalguei) <[e-mail]<mailto:[e-mail]>>; Jan Lindblad (jlindbla) <[e-mail]<mailto:[e-mail]>>; Snezana Mitrovic (snmitrov) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; Per Andersson (perander) <[e-mail]<mailto:[e-mail]>>; Esther Roure Vila (erourevi) <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
主题: [OPSAWG] FW: New Version Notification for draft-opsawg-poweff-00.txt

Dear OPSA WG,

Earlier this week, we posted a new draft that introduces a data model for power and energy related metrics :
https://datatracker.ietf.org/doc/draft-opsawg-poweff/
The focus is mainly on runtime information provided by power sensors, but also an extension to other related metrics and given attributes that will complement the representation of the energy consumed by the network device, implemented in hardware or software, as well as by specific network components.
This is a first-version approach where we see still challenges based on implementation.
Note: Some of those challenges are covered on Jan`s draft: draft-lindblad-tlm-philatelist<https://datatracker.ietf.org/doc/draft-lindblad-tlm-philatelist/>

Along with POWEFF draft, we’ve also updated the version of the Sustainability Insights draft:
https://datatracker.ietf.org/doc/draft-almprs-sustainability-insights/
where we introduced an updated architecture reference diagram, that provides a more structured view of the functional blocks that might be part of where those attributes and metrics might be produced, processed, visualized, etc. We also have reviewed and added Use Cases that such framework could drive.

We greatly appreciate your thoughts and comments.

Many thanks,
Marisol Palmero


From: [e-mail]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Date: Friday, 20 October 2023 at 17:45
To: Gonzalo Salgueiro (gsalguei) <[e-mail]<mailto:[e-mail]>>, Jan Lindblad (jlindbla) <[e-mail]<mailto:[e-mail]>>, Marisol Palmero Amador (mpalmero) <[e-mail]<mailto:[e-mail]>>, Snezana Mitrovic (snmitrov) <[e-mail]<mailto:[e-mail]>>
Subject: New Version Notification for draft-opsawg-poweff-00.txt
A new version of Internet-Draft draft-opsawg-poweff-00.txt has been
successfully submitted by Marisol Palmero and posted to the
IETF repository.

Name:     draft-opsawg-poweff
Revision: 00
Title:    Power and Energy Efficiency
Date:     2023-10-20
Group:    Individual Submission
Pages:    37
URL:      https://www.ietf.org/archive/id/draft-opsawg-poweff-00.txt
Status:   https://datatracker.ietf.org/doc/draft-opsawg-poweff/
HTMLized: https://datatracker.ietf.org/doc/html/draft-opsawg-poweff


Abstract:

   This document motivates and specifies a data model to report power
   and energy efficiency of an asset.  As highlighted during the IAB
   workshop on environmental impacts
   (https://datatracker.ietf.org/doc/html/draft-iab-ws-environmental-
   impacts-report-00), visibility is a very important first step
   (paraphrasing Peter Drucker's mantra of "You cannot improve what you
   don't measure").  During the workshop the need for standardized
   metrics was established, to avoid proprietary, double counting and
   even contradictory metrics across vendors.

   This Power and Energy Efficiency Telemetry Specification (POWEFF) is
   required to promote consistency across vendors and consumers, based
   on: 1.  The definition of datasets and attributes defining a common
   data model utilized by the standard calculation to yield power and
   energy efficiency value for any asset or network element.  2.  The
   standard calculations utilizing the specified datasets and attributes
   which will yield energy consumption and energy efficiency value for
   any asset or network element.

   The model provides information and data requirements for calculating
   the Power and Energy Efficiency for specific assets.  Assets can
   include hardware (physical or virtual), software, applications, or
   services.



The IETF Secretariat