GREEN @ IETF 123 - July 2025

Materials, Charter, Documents

GREEN Chairs & Area Director

IETF 122 GREEN Session Times

GREEN has two sessions:


GREEN Session 1 Agenda (12:00-13:00, Monday 20250721)

Intro by chairs

Diego will share on the GREEN list a summary of the received liaisons
(W3C, ITU-T and ETSI), especially with the references that have been
shared and that could be of interest for WG group

Rute Sofia: Diego and Rob, I can assist with the ETSI EE work and
overlaps
Rob: Rute, that would be great, thanks!

Drafts candidate for adoption

SoH: Have you read any version of the use cases draft?
Yes: 31
No: 25
No opinion: 0

Rob: We will start a new adoption poll. It is important to remark this
document will not likely go for a WG LC

Mahesh Jethanandani: Support the idea of putting the use case draft for
an adoption call to gauge interest.

Rob: It would be interesting to look into the previous draft from Carlos
Pignataro. I assume you have talked with the autjors

Joe Clarke: The current definition of efficiency is confusing, as it
seems to be somehow mixed with energy usage, not to which that the
extent that usage is suited to the intended purpose

SoH: Have you read any version of draft-bclp-green-terminology?
Yes: 25
No: 11
No opinion: 2

SoH: Do you support WG adoption of draft-bclp-green-terminology?
Yes: 36
No: 0
No opinion: 7

Rob: Good support for adoption poll. Please be active on the list in
this poll

Mahesh: Similar poll for use case draft?

Rob: Did that before, needs update. Will do on the mailing list after
that.

Mahesh Jethanandani: Appreciate how the framework document is driving
the modeling requirements. Thanks Benoit.

SoH: Have you read (any version) of draft-belmq-green-framework?
Yes: 17
No: 30
No opinion: 2

Rob: It is probably a little premature to start an adoption poll, but
the issues are relevant for the discussion tomorrow

Diego: We are trying to advance in parallel with the semantic issues in
the framework and the base model. It is important you read the document,
think about the open questions and the issues, and come tomorrow to
share your ideas

Other results

Mahesh Jethanandani: Speaking as a contributor. These are very
interesting concepts, but I think the DiffServ and marking approaches
belong to another WG

SoH: Do you think this work (draft-sofia-green-energy-aware-diffserv) is
of interest to the IETF?
Yes: 33
No: 1
No opinion: 18

Rob: I think there is general interest; up to chairs to discuss with ADs
to find out where it fits best
(later in chat: work clearly out of GREEN's current WG charter)

Roland Schott:

Rute Sofia: We believe the marking would impact not only routing but
scheduling as well

Rob: Thanks for sharing with us this. It is interesting to know about
the impact of enegry monitoring and contorl in other areas


GREEN Session 2 Agenda (17:00-19:00, Tuesday 20250722)

Intro by chairs

New draft proposals

Rob: I do not see a problem in augmenting the base model to incorporate
the kind of data you are considering

Jari: do you cover energy consumption per ISAC use case? they can have
different requirements and different options, for example, shutting
s.th. down

Muhammad: Each use case considers different parameters, and the model we
are proposing accounts for the different potential applications

Diego: Can this be generalized to a general querying API for path
information? Not just focussed on the radio.

Alberto: Addressing a challenge that we have seen? Is this in scope for
GREEN?

Rob: We need to check with Mahesh, because this work seems to be at the
edge of GREEN scope

Benoît (chat): Just very quickly browsed draft-petra-green-api. I
understand Diego's question. Isn't it a generic north bound API, use
case specific. A kind of "abstractions" if I want to speak the ONIONS
language? Are those use case specific APIs in scope? If yes, were do we
stop?

Marisol Palmero (chat): My understanding is that if we consider under
use cases end to end use cases, like video streaming, we should consider
such an API to understand the energy from the E2E (for instance, optical
path + IP )

Rob(chat): Marisol, I think that I agree. The question I have is whether
this should be covered by a core model in the first phase, or if this is
a more advanced solution that should follow on afterwards?

Marisol Palmero(chat): that point I agree, I think it should be part of
GREEN even if this is postponed

Diego (chat): That was my idea when I asked Alberto

Rob: This seems to be in scope for GREEN. I suggest you to talk with the
authors of the use case draft and consider incorporating these UCs in
the general document

Reports/updates from Hackathon

Benoit: It was a copy of the API or a map onto YANG?

Luis: It was a copy in this case

Roland Schott: Would you recommend the kind of processing for real use
cases? And what about exposure using ALTO?

Luis: A metric in a real case should consider averages to avoid
fluctuations. We have not consider ALTO yet.

Mahesh Jethanandani (chat): @Luis, a question for you, and in general
for folks who want to measure energy consumption in the transport
network. I assume that the transport network is used to carry traffic
for more than one service. How do you measure the energy consumption for
a particular service like video streaming in the transport network?

Shane Kerr (chat): I don't really understand what efficiency means in
the sustainability insights / POWEFF slides. Sorry if I missed it. Ah
okay there's a while draft about that! 😄

Marisol Palmero (chat): yes! from a simplistic point of view, based on
implementation perspective, how energy efficiency has been implemented
it is basically looking at Power Suply Unit (PSU) ... But once we link
to all the components (line cards, etc) from the network element this
could complicate the formula...

Discussion on the GREEN Base Model

Metric Questions

Q3: Control Granularity

Benoit: I agree with the questions, but I am not sure about the
conclusions onn granularity

Rob: We are thinking about a simpler starting point and getting more
complex as we gain experience

Diego: I believe the use of capabilities is the main conclusion to be
considered here. The other conclusions express a rather general
understanding of the problem

Mahesh: I agree with the conclusions, probably starting with an on/off
control

Benoit: May be the order of the questions imply we started with the most
difficult one

SoH: Is the WG happy about the displayed conclusions from virtual
interim 3 on control granularity?

Yes: 14
No: 0
No opinion: 10

Rob: This seems to indicate the conclusions are a good starting point
for modeling

Artur Hecker: I would like to see how the users get involved in the
power control process

Rob: So you believe users should be enabled to express their objectives
in terms of energy consumption

Artur Hecker: Users need to make informed decisions and communicate
their service providers

Rob: This would require new mechanisms for user/provider interaction

Q8: Control or report accuracy

Rob: Conclusions seem self-evident

Diego: That would imply they are useful as base anyway

Muhammad: What does the accuracy imply

Rob: Is about the precision in measurements and how detailed units are

Mahesh: What are the implications of keeping separate counters

Ronald: You can always evaluate accuracy by evaluating the device

Rob: Probably "conclusions" is too strong, as we are talking here about
starting points

SoH: Is the WG happy about the displayed conclusions on accuracy?

Yes: 18
No: 0
No opinion: 6

Q9: Time intervals for reporting data

Robert Wills: We have to take into account the precison vs accuracy, and
instant measures vs measures performed for a period

Diego: From the operation point of view, the important metric is much
more on energy than power, Joules better than Watts

Benoit: Agree on this

SoH: Is the WG happy about the displayed conclusions from virtual
interim 3 on time intervals?

Yes: 14
No: 3
No opinion: 3

Modeling Questions

Q1: Layering/relationship between models

Mahesh: At the network level we need to figure out, for a giving
service, how energy is related to service level

Artur: Service consumption implies an estimation, and that requires a
clear methodology

Rob: YANG models are not suited for such a methodology, but we should
probably agree on how aggregates are built

Benoit: the EMAN WG created the ENTITY-MIB v4 RFC 6933, to add the UUID.
It became the ietf-hardware YANG module RFC 8348. We must choose the
right indexes (or primary keys). For services and users, that would be
interesting but the hardware can not support that.

Diego: We should aim for models as regular as possible whatever the
level in consideration. That would simplify aggregation, processing and
interpretation

Artur (chat): in the hackathon, we were not religious about measuring.
We took what we could get. For the service end points we could actually
measure the service only, for the 5G network and the transport we
allocated proportionally. This only makes sense if the load-energy
profile is linear.

Gaetan Feige: It would be interesting to consider means for making
estimates for devices that cannot provide measurements themselves

Marisol: We should consider as well the means for querying and
interpreting what is modeled.

SoH: Should the WG address in parallel device/component/network level
models?

Yes: 26
No: 0
No opinion: 0

SoH: Shall the WG consider usage guidance?

Yes: 15
No: 2
No opinion: 3

Rob: Informational documents describing how to use the models for
providing and collecting information

Benoit: I said "no" because is not clear to me how the guidance would be
used to go beyond device capabilities

Gaetan: Device capabilities could be complemented

Rob: An email on the list would be useful