GREEN

Summary

This interim meeting focused on establishing a plan for the development of the GREEN data model and then delved into initial discussions on key technical issues, specifically "Granularity" and "Accuracy of Data" for power reporting. The working group agreed on an informal but structured approach for data model development, including regular interim meetings and the appointment of an editor. Discussions highlighted a tension between simplicity and the need for sufficient detail and flexibility in modeling, with participants seeking a compromise that supports various control architectures (centralized vs. decentralized) and reporting needs.

Key Discussion Points

1. GREEN Data Model Planning

The chairs presented a plan for developing the GREEN data model, which was generally accepted.

Informal Weekly Meetings: The chairs (Diego and Rob) will help facilitate weekly informal meetings (approx. 1 hour) to drive discussion and resolve open issues.
Monthly Updates: Formal updates on conclusions reached will be provided to the main GREEN mailing list monthly to keep the broader working group informed.
GitHub Repository: A GitHub repository will be created to host a working copy of the draft and data models, allow Pull Requests (PRs), and track issues.
Editor Appointment: Yan agreed to act as the editor for the data model draft, leveraging his Yang modeling experience. His role is to consolidate content and model proposed solutions for discussion.
Mailing List & GitHub: Discussions are welcome on both the main GREEN mailing list and the GitHub issue tracker. Participants working directly on the model are expected to track GitHub issues; summaries will be provided to the mailing list to avoid excessive noise.
Phased Adoption: The initial output will be treated as a "design team document" which, upon convergence and alignment, will be formally adopted as a working group document.
Scope: The scope includes defining a simple base energy Yang data model covering component, device, and network levels, identifying common groupings/metrics, and considering input from liaisons (e.g., ETSI). The model is not strictly required to conform to the framework document at this stage, and the aim is to agree on a rough structure first, with future refinements.
AD Approval: The approach of holding informal interims was vetted and approved by the AD, Mahesh.

2. Modeling Questions - Granularity (Question 3)

The discussion explored the desired level of detail and abstraction for power states in the data model.

High-Level Simplicity: Tony advocated for a very high-level, simple model, arguing that complex, granular control ("boiling the ocean") is difficult to implement consistently across devices and vendors, and smart devices often manage power internally.
Beyond On/Off: Rob suggested that a simple "on/off" might be too limited. He proposed using Yang identities to define a base set of states (e.g., on, off) and allow for deriving more specific states (e.g., high-power, low-power, sleeping) based on device type (optics, MPU, line card).
Intent-Based Control: Mahesh suggested the controller should express requirements (e.g., "send at least 1Gbps, return to full power in 500ms") rather than dictating specific power modes. The device would then determine the best way to meet those requirements. He stressed simplicity for controller usability.
Limited States & Verification: Diego proposed a small, rough classification of maximum modes (full, medium, low, off) that devices could map to, with verification through measurement ("always verify, never trust").
Centralized vs. Local Control: Jianping supported identities and highlighted the need to accommodate both centralized control (controller-driven) and local control (device flexibility).
"Nerd Knobs": Tursun suggested the possibility of allowing "nerd knobs" (fine-grained, potentially vendor-specific controls) as augmentation points, to enable experimentation and control loops, without standardizing every detail. Tony countered that the service provider market prefers to eliminate such complexity.
Capabilities Discovery: Jianping emphasized the importance of the controller discovering the end-device's power-saving capabilities to understand its operational modes and detect faulty behavior.
Compromise: A sense of those present indicated a preference for a reduced number of abstract identities for power states, with devices mapping their specific capabilities to these abstract states. The distinction between configurable states (simpler) and operational reporting (more detailed) was also noted.

3. Modeling Questions - Accuracy of Data (Question 8)

The discussion focused on how to handle the accuracy of reported power data, given Yang's limitations (no native floats/doubles) and varied device capabilities.

Diverse Accuracy Needs: Rob highlighted that accuracy requirements differ (e.g., kilowatts for a device vs. milliwatts for optics). He also questioned how to handle devices that cannot meet defined accuracy levels and how clients would use this information.
Best Effort & Reporting Accuracy: Tony suggested "best effort" for accuracy, as installing dedicated measurement circuitry is costly. He supported a mechanism for devices to report their accuracy (e.g., +/- 5% or qualitative classes like "gold, silver, bronze") but preferred quantitative metrics.
Beyond Instantaneous Value: Tursun noted that accuracy involves not just the value itself, but also its accuracy over time (sampling rate). He suggested that a capability model could be used to express complex accuracy characteristics, rather than embedding it directly in the data.
Static vs. Dynamic Reporting: Rob raised the issue of whether reported values are hardcoded (e.g., from a datasheet) or dynamically measured, and the potential for discrepancies between aggregated component power and total device power. Knowing if a value is static or dynamic is important.
Time Intervals & Aggregation: Diego stressed that for energy savings, aggregated consumption over a period is more relevant than instantaneous power, which might indicate anomalies. He argued for a way to enable reasonable aggregation and compilation of data.
Yang Telemetry: Rob suggested that Yang telemetry protocols (Yang Push) can help by allowing clients to specify reporting intervals, leading to more consistent data collection. He proposed reporting both instantaneous power usage and total power consumed since reset (similar to interface counters).
Units and Overflow: Tony mentioned OpenConfig's choice of watts and suggested using 64-bit milliwatt-hour counters to prevent overflow for long-term aggregation and support future low-power devices.
On-Box vs. Off-Box Aggregation: Discussion arose whether the device should perform aggregation (energy consumed over time) or just report instantaneous power, leaving aggregation to the controller. Rob argued on-box aggregation could be more accurate, while Tony preferred simpler on-box reporting.

Decisions and Action Items

Decision: The proposed approach for data model development (informal weekly interims, monthly mailing list updates, GitHub repository, Yan as editor) was agreed upon by those present.
Action Item: Yan to prepare initial model sketches/examples for the "Granularity" discussion, reflecting the points raised, for discussion in a future meeting.
Action Item: Rob to refine the summary of the "Accuracy of Data" discussion, with consideration for including fields for instantaneous power, total power since reset, and some level of accuracy reporting.

Next Steps

IETF 123 Meeting: The GREEN WG will meet at IETF 123 (Monday 1-hour session, Tuesday 2-hour session).
- The chairs will cover the proposed data model development plan and facilitate discussions on use cases, terminology, and metrics.
- A dedicated session similar to this interim will be held to continue technical discussions on data model issues.
- A call for presentations will be made for submissions related to use cases, terminology, and metrics.
Post-IETF 123 Informal Interims: Following IETF 123, regular, informal interim meetings will be established to continue driving consensus on the data model. These meetings will leverage GitHub for issue tracking, and Yan will play a key role in drafting concrete model examples and text.
Summarize Previous Discussions: Summaries of previous technical discussions will be prepared for the IETF 123 meetings to bring new attendees up to speed.

Session Date/Time: 07 Jul 2025 14:00