IETF Virtual Interim GREEN WG Session Agenda - 20250707

About GREEN

Materials, Charter, Documents

• GREEN WG General Info
• GREEN GitHub Repositories
• GREEN Documents, Drafts and I-Ds

GREEN Chairs & Area Director

• Area Director: Mahesh Jethanandani
• WG Chairs: Diego Lopez, Robert Wilton

Session link, minutes, chat

• Meetecho Link remote participation
• Meeting Minutes
• Meeting Chat

IETF GREEN Interim Session Times

GREEN has a single 2hr session: Mon 7th July, 14:00-16:00 UTC.

Upcoming Meetings

1. 2 sessions at IETF 123

   • Monday 21st, session 2, 1 hour
   • Tuesday 22nd, session 4, 2 hours

2. Further interim meetings, perhaps informal may be scheduled before
   IETF 124.

GREEN Agenda 14:00-16:00 GMT Monday

Welcome (10 mins)

• NOTE WELL
• Scribe selection
• Agenda bashing

Main Discussion (1 hr 40)

YANG Data Models - Next Steps (Rob Wilton) (10 mins)

Rob introduced the plans to progres with the design of a base model (see
slides)

• We will likely have to repeat these points in Madrid, addressing the
  wider GREEN audience

Data Models Discussion (1 hr 30)

• Discussion based on Rob's issues slides

Q3: Mow much granularity in power control?

• Tony: It should be very very high level. We do not need a fine
  control, or describe/use all the available power savings choices
• Different config and state.
• Mahesh: It is good to keep things simple, but let's consider some
  degree of flexibility. Think about optical devices and their low
  power modes

• Jan: Simplicity.

  • Can't need to know about all devices.
  • Need to keep a model different from operational complexity.
  • Need to express it in term was is requested and the limits in
    power consumption. And timing (how much it takes to return to
    the desired condition) must be taken into account.

• Rob: Use of identities:
  https://www.rfc-editor.org/rfc/rfc7950.html#page-163

• Qin : Identities help. See energy-saving-power-state identity in
  draft-cwbgp-green-common-energy-management, I think it is a good
  example
• Diego: I believe that a limited number of controlable states (3-4
  maximum) and appropriate measuremens would be the most suitable
  strategy
• Marisol: We have the IANA states, and we could leave devices/systems
  to choose the ones they implement
• Rob: IANA power states are too granular to be practical or usable in
  most cases

• Toerless:

  • Lots of nerd knobs in Linux.
  • Lots of routers range from simple to complex in terms of user
    interface.
  • Examples could be given.

• Tony Li:

  • Want to elimate Nerd Knobs (both customers and vendors)
  • The more that we can make automatic, the better it is.

• Toerless:

  • Seeing automation.

• Emile: Contollers need to be informed of the capacities of the
  devices

• Tony: The controller-centric approaches have problems scaling and
  being applied in many network service providers

  • Controllers in SP market, very much the exception.
  • Only people are other those with large programming staff.

• Rob: Let's try to simoplify how features are made available and how
  choices are made

• Diego:

  • We should cope with both small and large control loops.
  • Don't assume that there will only a single controller, or that
    it will be fully distributed.
  • What is relevant is how much information (and how many
    categories) are used in the control loop
  • We should not prescribe a particular deployment style

• Gen Chen:

  • Need to understand and report device capabilities.

• Tony:

  • Augment devices with your capabilities.

• Diego:

  • And a limited number of generalized power states seems to be the
    only possible compromise

• Qin: I tend to agree with Toerless, we can not fully trust device to
  do the job without mistake, device needs to expose more information
  for better debugging or troubleshooting.

• Issue Summary:
  • Want to support both controllers and control on the device
    (i.e., distributed behaviour)
  • Want to be able to have a simple model, that can be extended.
  • Bandwidth requirements for interface.
  • Can split between simpler config and more complex state.
  • Should consider capabilities
  • Can augment, but would want guidance, and this was different in
    ANIMA.

Q8: How to control or report accuracy of the information?

• Marisol: In POWEFF draft we did address accuracy, and we tried to
  simplify as much as possible from a practical point of view. We
  defined a accuracy factor to be defined by the vendor, similar to
  the 80+ certification for PSUs, which defines accuracy
• Tony: TRhe best we are gonna get will be base on software estimates,
  very close to best effort
• Jan: We could go for some kind of accuracy reporting standard, like
  the bronze-silver-gold rings in resistors
• Tony: Prefer quantitive rather than qualitive.
• Diego: Marisol, would that be somehow related to the accuracy report
  Jan proposed?
• Marisol: Yes, Diego! this is aligned with the comment from Jan ...
  check on https://www.clearesult.com/80plus/ most vendors will
  register PSU under the 80+ cert.

• Toerless:

  • Had this problem for a long time, e.g., MIBs.
  • We've survived with traffic stats.
  • Perhaps a capability model to express the accuracy.

• Toerless:

  • Need to list all possible lists of inaccuracies

• Tony:

  • Jan's idea of reporting accuracy is a reasonable approach.

• Jan:

  • Classes allow different granularity.

• Toerless:

  • Sampling intervals.

• Tony:

  • Exposing the sampling rate would be okay.

• Qin: In addition to Jan's proposal, the same approach as hardware
  yang can be followed, using value-precision to represents a sensor
  value precision range

• Marisol: I wanted to mention related to sustainability, vendors
  defined product carbon footprint based on the lifecycle status:
  manufacturing, transport, usage and end of life. Aligning with this,
  the analysts are based on big ranges of accuracy... we somehow
  should think about how to link some of this terms

Q9: What time intervals is the data being reported over?

• Toerless: A possible approach could be adding timestamps to the
  measurements
• Rob: YANG Push also provides some timing metadata that could be used
  for this purpose
• Tony: Instantaneous values would be much easier to implement

• The unit issue: We can overflow counters, especially if we use
  something like milliWatts

  • Toerless: The worst case would be using milliWatts-hours to
    meter energy consumption

• Summary:

  • Report instanstaneous power
  • Perhaps also report total power consumed since device was last
    cleared.
  • Perhaps report over over a longer time interval.
  • Do need ability to report accuracy of the information (e.g.,
    perhaps +/- 5%.)
  • Tony Li, wanted Watts not milliWatts. Could use 2 counters.

Closing (10 mins)