Minutes IETF125: green: Thu 06:00
minutes-125-green-202603190600-00

Meeting Minutes Getting Ready for Energy-Efficient Networking (green) WG
Date and time 2026-03-19 06:00
Title Minutes IETF125: green: Thu 06:00
State Active
Other versions markdown
Last updated 2026-03-29

minutes-125-green-202603190600-00

IETF 125 GREEN Meeting Minutes

Thursday March 19, 14:00-16:00 Shenzhen (UTC+8) 06:00-08:00 UTC

Intro by chairs

  • 10 minutes
    • NOTE WELL
    • Chairs slides & status
    • Scribe selection
    • Agenda bashing

The WG aims to be the core reference for energy measurement and control
within the IETF to avoid fragmentation. Bi-weekly interim meetings will
continue on Thursdays to finalize the core documents.

Reach out slide:
Tony Li - Does this mean that device management would stay here?
Diego - If you mean energy management on devices, then yes

Base Drafts and Model

New terms "Energy Object" and "Energy Saving" added.

Mahesh - What is the status of this document, are we ready to publish?
Qin - What to continue aligning with other drafts.
Benoit - We discussed previously about keeping this doc alive at this
time (i.e., don't publish now), and instead publish at the same time as
the other first documents, no need to publish too early.
Rob (in the chat window): Qin, if you drop me an email then I can help
move it.

A new use case (UC 16) regarding network-level cross-layer energy saving
was added. A hackathon in Vienna is planned to improve consistency
between use cases and the framework.

Diego - Any questions/comments.
None.

Data collection architecture and the relationship between device-centric
and controller-centric models.

Diego - Remember the note from Ali Rezaki on the European best
practices. I see it connected to the mention you made on certification.
It would be interesting that we acknowledge and try to address this in
the framework. I will add an issue for this.
Marisol Palmero - There is already open issue for this. There were other
references as well. There is a lot of work, it is very fragemented. I
agree that we need to address these references.
Diego - I believe that it is important to make clear that this document
and the GREEN core model is an enabler for addressing this kind of best
practice on energy management.
[From chat, Marisol]: The reference proposed by Ali Rezaki, mentioned
by Diego is here as an open issue:
https://github.com/ietf-wg-green/draft-ietf-green-framework/issues/55
Deepak Rajaram - General question on the use cases. Are we considering
abstraction/normalizing metrics. Looking at CATS, I see some some power
measured at different levels.
Marisol - To clarify, are you referring to layers 0, 1, and 2 at the
device or component.
Deepeak - Referring to individual devices then network layer, etc.
Marisol - This will be the role of the controller.
Qin - Model is focused on the device level, but next focus will be on
the network layer, will this be in the same model and document.
Marisol - Will be another model, and will probably a different file.
Qin - In the past there were some existing models that could be an input
to this part.
[Comments from chat, Benoît Claise] Deepak, I was not aware to that
document you mentioned. Would you mind forwarding to the mailing list
(or here)
[From chat, Deepak @Benoit], i am referring to :
https://datatracker.ietf.org/doc/draft-ietf-cats-metric-definition/
[From chat, Luis Contreras] Regarding the reference of Deepak to the
CATS metric work. CATS considers different level of metrics departing
from raw metrics (Level 0) to define a score (Level 2). This is being
defined in
https://datatracker.ietf.org/doc/draft-ietf-cats-metric-definition/. I
think we are not covering the metrics of GREEN from that perspective
[From chat, Deepak] of course there are other metrics being defined ,
but i see L0- power consumption is the one which is related to the work
here i guess
[From chat, Benoit] @Deepak, thanks @Luis, ah. I thought I understood
that that draft was about L1, L2, L3 ENERGY metrics
[From chat, Luis] @Benoit, not L as layer, but L as level in the
context of the aggregation proposition
[From chat, Diego] Not sure if this power consumption refers to the
network or the cloud infrastructure...
[From chat, Deepak] @Rob Thanks👍, do we also intend to further
classify /characterize the aggregation eg: Type of power
consumed-AC/DC/Battery/..
[From chat, Marisol] @Deepak, probably not related to the draft that
you mentioned, and it is a good reference to look at; but there are
already some approaches defining metrics based on score already in other
drafts, where they are based on the reference model presented at the
framework: please check:
https://datatracker.ietf.org/doc/draft-jadoon-green-isac-utilization/
and https://datatracker.ietf.org/doc/draft-amalj-sustain-shape/. Anyway
the controller or the abstraction level above, should consider the
definition of those score. I consider that scores are too complex from
the standardization point of view

  • Update on YANG base model
    • 15 min
    • Presenter: Gen Chen (onsite)

Defines identities for energy objects, power/energy attributes, accuracy
classifications, and relationships (e.g., poweredBy, meteredBy).

Tony Li - How do I turn things off?
Benoit - Yes, is one of the key questions. Can you postpone your
question to the next session.
Tony - How can I tell what can be turned off? How do I express other
relationships. I need to be able to say that this linecard is dependent
on that switchcard, so please don't turn off that switchcard.
Benoit - On the last one, I think that we can be address it here. We
could add a new identity. We have the notion of energy object. If this
is a functional dependency we could describe that. You seem confused?
Tony - Are you proposing adding a relationship?
Benoit - If that is what you want, then yes, it is open.
Diego - There is a question on the chat about renaming, please can you
reply it when you see it.
[From chat, David Slik] - The literals for relationship types
"powered-by", etc, are different from the literals in 7461, e.g.
"poweredBy". Was this change to provide
[From chat, Rob Wilton] @David, this might be to make the naming style
more consistent with how these are generally modelled in YANG
[From chat, David] That makes sense. Lots of different identifier
styles and it's worthwhile to maintain consistency.
[From chat, David] Re. additional relationship types, there are some
relationship concepts in section 3.2 - 3.4 of SNON
(https://www.snon.org/) that may be worth considering doing something
similar for energy objects.
Chenxinyu - Does the model consider the measurement period in the
reported energy
Gen Chen - Yes, this is covered.
Chenxinyu - What is the time interval, is it a minute or per section.
Gen Chen - For power, it is instantaneous.
Benoit - Question to Chenxinyu, do you need the interval? For the stats
we pull then/push them but we don't report the interval. Is this a
capability instead.
Gen Chen - I think that we can take this one offline.
[From chat, David] The work being done by DMTF (Distributed Management
Task Force) is also worth considering:
https://www.dmtf.org/sites/default/files/standards/documents/DSP2056_1.1.0.pdf

[From chat, Jan Lindblad] @David, thanks for the ref. In YANG the
naming convention is all lowercase-with-dash. In SNMP it was CamelCase.
Using camelcase names in YANG would give a high surprise factor.
[From chat, David] @Jan Thanks. Not suggesting a change, just
wondering out the source of the difference. Thanks for the explanation!

Open Discussion on Base Documents and Model

  • 20 min
  • Introduction and steering: Benoit Claise (onsite)

Tony Li - Regarding timing, I am most interested in how often the box is
measuring that value.
Benoit - There is an RFC on top of YANG Push that could provide this
information.
Tony Li - I'm more interested in the measurement rather than the
streaming interval
Benoit - At the moemnt we don't have it, but we could add it.
Thomas - Very interesting discussion, we have RFC 9196, which details on
how data can be exported and frequency. The questions here regarding on
measure is a generic discussion and not related exclusivey to GREEN
Benoit - Yes, that are lots of different counters that are getting
measured.
Thomas - We might need a generic solution.
Benoit - I agree, I believe this is a generic problem
Tony - How do I turn things off?
Benoit - Will get to this in a few slides.
[From chat, David] For energy measurements, we need two times to
indicate the interval. For power measurements, we need a point in time
where the instantaneous measurement was taken.
[From chat, Diego] Right, @David. But, as Thomas mentioned, these
measurements on intervals or on specific instants in time are not only
related to GREEN, but general for many other measurements.
[From chat, David] Yes, but wtihout careful management of time
intervals, it is difficult to overlap, sum, integrate and handle missing
data for energy measurements. Often cumulative energy measurements are
used to get around some of these problems, but that still requires a
time of acquisition.
[From chat, Diego] @David, I cannot agree more. My only point is that
those considerations can be applicable beyond energy-related measurments

[From chat, David] @Diego Agreed 100%

Carsten Rossenhoevel - We have been this kind of testing. Mobile base
stations have hundreds of paramaters, and it is a secret sauce. There
are other cases, e.g., that might want to be as open as possible.
Perhaps have an optional part to recommend a particular setting, e.g.,
manual control of fan speed. Maybe want to add some reporting
capabilities.
Benoit - On the benchmarking, I agree, we need to do.
Tony - My microwave it pretty smart, it takes a power level. What don't
we do something like that?
Benoit - We tried to do this. How useful is this when having multiple
vendors. E.g., what does 80% power level mean. I kind of agree that this
might be the best that we are doing.
Emile - We already have 3 sets of states, perhaps that is enough. Allow
the vendors to choose the set of states that they want.
Benoit - I'm not proposing a solution yet. It depends on what we want to
solve. This is identify ref, so we could always extend it. We could even
have a 4th definition, e.g., from 0-100.
Emile - I think that we can go with these 3 sets.
Diego - This is the kind of discussion to get in the interim calls.
Holger - Just looking at 3 states is enough, there is no on, off, sleep.
We need more that that.
Benoit - Need more states, how many? Do we need a range? Do we just have
an identity?
Tony - Can get arbitarily complex. Getting too complex.
Benoit - We have the two options in my last two slides. I believe we are
favoring option 2
Diego - I believe so
Rob - Start simple for the power states, I would like to work as much in
parallel as we can.
Thomas - On the power states, do we need a ranking? Or is it just
reporting that we are in a particular state.
Carsten Rossenhoevel - Fine the progress, make it clear that this is not
the last version. Should not imply that it is a linear scale.
[From chat, David] Re power states, my suggestion is that vendors
should enable discovery and understanding of consequence, since this
will be device and vendor-specific, and controllers should be able to
measure the effective change in energy resulting from a state
transition, since this will be dependent on network state, load,
traffic, etc. and cannot be (easily) predicted ahead of time. That way
the controller can learn how changes in power states effect the many
operational parameters of the device's contribution to the larger
system.
[From chat, David] +1 work on item #1 next, and this will provide
detailed feedback on the usability of YANG module to meet the desired
use cases.
[From chat, Rob] E.g., consider fan speeds on devices, do we need to
be configuration to control these at all. Lots of modern devices will
run these at the minimum speed necessary to achieve the necessary
cooling of the device.
[From chat, Jan] Not only is the power scale not linear, but the
effects of reducing the power of some components linear in any way. And
I bet few operators would dare to go into a lower power state if they
don't understand the implications in some detail.

Models

Update on the PETRA API, aiming to provide visibility into energy
consumption along a specific network path. The authors intend to request
adoption once core documents stabilize.

Diego - This would be a fair example of the idea I was mentioning about
going above (or beyond) the core model

New Proposals

Proposed using IPFIX for traffic-correlated energy telemetry.

[From chat, Kent] polling with NETCONF is not best practice. YANG Push
is.
Rob - I don't really understand why we using IPFIX rather than YANG Push
to export this.
Jinjie - To provide some options.
Benoit - If you use IPFIX there is something to optimize. You are
perhaps overloading IPFIX, there is why we have it generic in YANG.
Jinjie - We can discuss it later offline
Diego - Can we use the green list.
[From chat, Rob] @Jinjie, if the goal is to have an alternative export
mechanism to using YANG Push (or gNMI) then I'm not sure that is a great
idea. I.e., it would be great to understand more about the reasoning for
wanting to go this path. This could be a great discussion to have on the
GREEN WG alias.
[From chat, Marisol] I would like to reiterate the message from Rob,
+1 from my side. It will be good to address how the draft presented by
Xinyu Chen is seen from the adopted drafts (specifically aligned to the
use cases, and framework).

A mechanism combining local (device-centric) fast response with global
(controller-centric) strategic optimization.

Diego - You are considering this would be located above the GREEN
controller, right?
Xinyu - Yes
Rob - I am trying to understand how this would fit in the GREEN
framework
Xinyu- We are considering cross-layer scenarios and would like to
analyze how they fit in the core documents and model.
Rob - Please share on the list how this work aligns with the framework
draft. E.g., what extra information should be added into this draft, or
what parts are separate or build on top of that solution.

Introducing functional blocks for attributing energy consumption to
specific connectivity services. This work was moved from the IRTF
SUSTAIN RG to GREEN as it focuses on engineering and reporting rather
than pure research.

No further questions or comments.