[Green] IETF GREEN WG Modelling Meeting - May 11

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

Hi all,

These are the rough notes that I took from today's discussions.  There were no slides shared and we spend nearly the entire discussion on controlling power and setting power states.


IETF GREEN WG Modelling Meeting - May 11

Attendee include: Rob Wilton, Benoit Claise, Hesham (AI Notes), Gen Chen, Jan Lindblad, Marisol Palmero, Emile Stephan

Discussion on power work in LSR:

Power state adoption:

  *   Jan: Power states from a controlled POV are difficult to use (e.g., off/on/sleep are useful)

     *   Laptops have lots of different settings for controlling power.
     *   Wanting a declarative definition of what is possible.
  *   Benoit:

     *   First question is: Do we need power states?
     *   Went through this discussion in EMAN, but there is no good solution.
     *   Could do something intend based. But redoing the same discussion.
     *   Tough problem, hard to resolve.
  *   Rob: Do YANG identities help solve this problem?

     *   Maybe, but we are not solving the interopability problem.
  *   Jan: I think that you are on the right track.

     *   They know abotu their own siutation, but need to express constraints to the devices.
     *   What do you write into an SLA.
  *   Rob:

  *   Jan: Who knows most about how to put the power for a device?

  *   Rob: Suggest

  *   Jan: Is hardware control configuration or operational state?

     *   E.g., should the device come back if it has been powered down?
  *   Benoit: We should ask operators what they would like to do here.

  *   Marisol: Looking at how many of the usecases require that we set power state:

     *   7 or 8 are impacted by power state, those are directly depending on the capability to dynamically transition resources between operational states according to traffic demand, workload conditions, or orchestration policies. This is especially relevant for:

** network infrastructure optimization,
** wireless and fixed network energy saving,
** workload scaling,
** cloud-native environments,
** and automated energy management.
** Power State should be considered a dynamic operational capability rather than only static telemetry.

  *   Gen Chen:

     *   Showing the power state optimization.
     *   Choices:
        *   Should these be actions?
  *   Benoit: Jan, What is your preference (on how to model power states)?

     *   SHould this be a configuration or YANG Actions?
     *   Better to factor out into a separate configuration tree (for setting power states)
  *   Benoit: Do we need to model this according to NMDA?

     *   Jan, this may not work well when most of the data is config false, generated by the device.
  *   Rob: Do you want the config and oper in the same model or separate trees?

  *   Benoit: I’m not sure that the IETF will solve this, but okay will listing all of these, or just the simple ones.

  *   Benoit: I think that the ideal is something that is intent based.

  *   Rob: Could augment the capabilities model to list what power states are available?

  *   Benoit: Having 2 YANG models (for config vs state would be the worse choice).

  *   Benoit: Feedback from DT:

     *   Don’t wnat to have an automated way to change power that isn’t part of configuration.
     *   If there is a separate green controller then it would add too much complexity.
     *   Getting something ephemeral with an RPC is too complex.
     *   Doing it through the CLI would be simpler.
     *   Trying to reduce the number of different points of configuration in the network.
     *   This favours a clear read/write in terms of admin-status.

Conclusion:

  *   Will go for WG adoption with some minimal ability to set power states.