[Green] Modelling Design Meeting Minutes - Jan 26th Meeting

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Green WG,

The modelling team are making very good progress towards a base model.  We met today to discuss some more issues with the next meeting planned in 2 weeks.  As issues are resolved, the authors update the draft and model to reflect the consensus and present new issues for discussion.

Below are the rough minutes from the discussion, not everything was captured, but hopefully I have captured the key conclusions and agreements (which we checked at the end of the meeting).  Please let me know if there are clarifications or corrections.

Also, please review the draft (this is the same one that Benoit highlighted):

URL: https://www.ietf.org/archive/id/draft-bcmj-green-power-and-energy-yang-00.txt
Status: https://datatracker.ietf.org/doc/draft-bcmj-green-power-and-energy-yang/
HTMLized: https://datatracker.ietf.org/doc/html/draft-bcmj-green-power-and-energy-yang

And provide comments back to the authors and the list.  Although not guaranteed (since we will follow the standard adoption poll process), it is plausible (perhaps likely) that this draft will form the base draft for GREEN WG's power and energy YANG model and hence it would be better to get your reviews and comments in now - it is always easier to change things, particularly if they are significant, earlier in a drafts lifecycle.   In addition, comments, reviews, and discussion would all be welcome by the authors and WG chairs!





IETF GREEN WG Modelling Meeting - Jan 26

Attendees (when I checked) include: Rob Wilton, Benoit Claise, Bastiaan Wissingh, Hesham, Gen Chen, Jan Lindblad, Marisol Palmero, Roland Scott, Chih-Tsung Huang,

New draft sent out, link sent out to the list. Please review

Slide: Question 5: Precision & Accuracy

  *   Core consideration: Should we use percentages or absolute numbers, or a combination.

  *   Typical values, percentage accuracy is good, but measurements that are near 0, then percentage accuracy doesn’t work well (it shows huge variations)

  *   In electrical engineering use percentage + fixed.

  *   Reporting values similar to IEEE and IEC, but using YANG identities

  *   Default for accuracy, is accuracy like parent (i.e., hierarchical).
it’s the default
-> make it easier to report the tree and its subtrees

  *   added accuracy-measured-bronze-XXXX
bronze = 30 % variation, silver = 10%,
added the number to the end, which is contained in bronze (in this case)
not read as watt unit, but refer to the unit-multiplier
1000 = a thousand units of the unit-multiplier belongs to (ex: a 1000 milliwatt)

  *   Identities are split between bronze/silver/gold at different percentages + absolute offset.

  *   Consensus is that this is the right direction to go in.

Roland: Rather than kw/h we could be reporting at short timescales, e.g., watts/second.
Jan: Would be useful for energy & power. Absolute delta is using the unit delta.

Roland: does it still apply to finance?
Jan: yes, with the accuracy-measured-ones

Rob: which units
Jan: use for power and energy, and the related unit-multiplier
Rob: units will be hardcoded?
Jan: the unit multiplier is in the model and hence it up to the publisher

Slide: Q 5: Improved Accuracy Solution Operational Considerations

Benoit: The proposal is that it is more important to capture the accuracy at the device/domain level rather than individual components.

Roland: Do I define parent accuracy and then it works for the whole tree? Then the weakest accuracy in this tree defines the accuracy of the parent?

Jan: It would be safe to that, but if you have 100 linecards and 1 is bronze, and the rest is gold, then you

Rob: Where is the parent? This is taken?
Jan: This is the parent object in the hardware model.

Rob: Combining values at different accuracies may be tricky.

Benoit: Not clear how much collectors will focus on accuracy anyway, but the data is available if they need it.

Can we assume YANG-Push for Data Collection:

Benoit: From last meeting, we agreed that the data can be streamed, hence don’t need some of these tables (i.e., parameters table).
Benoit: Need to add “Energy Object” definition to the terminology draft. (to be actioned)

Further discussion/agreement below (end of Q6).

Question 6: Energy Monitoring Proposal:

Benoit: Presented on the slide.
Benoit: measurement-local means that the measurement is by the device, proposal to give it a default value of true.
Rob: Could try and make the names concise as possible.
Benoit: Yes, but should also try and check OC and be consistent.
Rob: Does it make sense to get a default for unit-multiplier, or have a default, or make it hierarchical?
Jan: Not to be hierarchical. Makes sense to me, but equally giving units makes it easier/simpler particularly for the client code to consume.
=> Conclusion: Either mandatory or default to 1, not inheritance. Leave it open to authors to discuss further.

Rob: object-id, is there any recommendations.
Jan: object-id is a flat namespace,
Benoit: what is the object-id not a uuid
=> Conclusion: Not constrain object-id definition with conventions.

Rob: Is the mapping from energy-object entries into hardware-components a 1:1 mapping or N:1 mapping. E.g., if you want to report power
Jan: Not sure whether this is a use case or not. But still it might be helpful to allow N:1 mapping
Rob: I think that it would be good to specify whether it the relationship is restricted to 1:1 or N:1 is also allowed.
Benoit: Want to keep it simple. (Rob agrees), but could keep it flexible.
Jan: Keeping it flexible increases complexity.
=> Conclusion: Keep it 1:1 for now, easier to do a bis to remove a restrict in future.

Roland: Different question, agree to go for YANG Push. Why not allow pull of data?
Jan: Controller will collect from multiple sources, but from a device perspective we want to keep it simple.
Rob/Benoit: The key point is that we are not going to cache any data on the device (e.g., any history or storage, or TSDB in the device). Pull will just give you the latest data.
=> Conclusion: No change, relying on YP is fine. YANG-Push might be doing the caching, if required

Question 7: total-energy-consumed/total-energy-produced

Discussing the different solutions:
Jan: Another solution would be to include energy-produced in energy-consumed (e.g. 10, 9)
Agreed that solution (1) or Jan’s solution.
Rob: Also need to track relationship between devices consuming energy (e.g. PoE).
Benoit: let’s look at the aggregatedBy relationship (in which we have 1 to many)
from there, we decide for solution 1, 1 and 9, or solution 4, 10 and 9 (concluded as next step forward).

Marisol: Rename energy-produced to energy-delivered. (consensus to rename)


Kind regards,
Rob