Subject: [OPSAWG] new draft on energy monitoring considerations

From: "Rolf Winter" <[email-masked]>
Date: Tue, 6 Jul 2010 11:05:25 +0200

Hi group,

we had extended discussions about energy monitoring in the recent past. We thought it might be worth stepping back from the detailed discussions and re-start with the bigger picture. We wrote a short draft which we would like to expand with your help while working on the energy monitoring issue to:

- distil the architectural properties of energy management
- fix terminology so we all talk about the same thing
- make clear where energy monitoring is different from other monitoring tasks that have been specified within the IETF
- work on use cases to guide the more detailed MIB work (in order to not forget or exclude important ones, also slightly outside the IETF radar)
- document why certain decisions were made for later reference

This document is obviously a first shot but I think it will be a valuable piece of text to have as the discussions progress. Feedback is more than welcome.

http://datatracker.ietf.org/doc/draft-norwin-energy-consider/

Thanks,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 6 Jul 2010 07:54:35 -0700

Hi Rolf and company,

Excellent gathering of requirements.  The specific scope related to
monitoring and the wide net cast in section 5.3 was particularly
interesting.

In section 5.4, it is mentioned that the following five items are
relevant for a device's power state:

   1. the current state (on/sleep/off)
   2. the time of the last change
   3. the current real power (energy consumption rate)
      averaged over a short time interval
   4. total energy consumption
   5. energy consumption since the last report or for
      The last configured time interval

What about expanding the current state to include other possibilities,
like "tripped" in the case of a circuit breaker monitor, "rebooting" in
the case of an intelligent power strip commonly found in datacenters,
and "off with tag-out/lock-out" in the case of a local manual safety
override?

There would seem to be a potential race condition related to SNMP's
ability to report on a single OID at a time and the required dependency
between the time of the last change and the various energy metrics in
items 3 thru 5.  If the caller queries one then the other, the time
delay between the queries introduces some possible data consistency
problems.  How do we ensure that the data is correctly interpreted by
the caller when we do not have control over the propagation delay
inherent in the network itself?

Does this proposal limit the power metrics to "real power" (kWh) only?
Will it address any other metrics like voltage, amperage, power factor,
crest factor, frequency, etc. independently?  Such metrics can be
critical for advanced NMS/BMS/EMS implementations that try to optimize
power efficiency at a holistic level.  True that kWh is the primary
metric for billing, though it would be nice to support future
advancements, too.

It seems I have more questions than answers!  Looking forward to your
thoughts.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rolf Winter
Sent: Tuesday, July 06, 2010 2:05 AM
To: [email-masked]
Subject: [OPSAWG] new draft on energy monitoring considerations

Hi group,

we had extended discussions about energy monitoring in the recent past.
We thought it might be worth stepping back from the detailed discussions
and re-start with the bigger picture. We wrote a short draft which we
would like to expand with your help while working on the energy
monitoring issue to:

- distil the architectural properties of energy management
- fix terminology so we all talk about the same thing
- make clear where energy monitoring is different from other monitoring
tasks that have been specified within the IETF
- work on use cases to guide the more detailed MIB work (in order to not
forget or exclude important ones, also slightly outside the IETF radar)
- document why certain decisions were made for later reference

This document is obviously a first shot but I think it will be a
valuable piece of text to have as the discussions progress. Feedback is
more than welcome.

Thanks,

Rolf

NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
London W3 6BL | Registered in England 2832014 

_______________________________________________
OPSAWG mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/opsawg

---

From: "Randy Presuhn" <[email-masked]>
Date: Tue, 6 Jul 2010 11:01:12 -0700

Hi -

> From: "Chris Verges" <[email-masked]>
> To: "Rolf Winter" <[email-masked]>; <[email-masked]>
> Sent: Tuesday, July 06, 2010 7:54 AM
> Subject: Re: [OPSAWG] new draft on energy monitoring considerations
...
> inherent in the network itself?

There's no reason to optimize a design for badly-written applications,
particularly when the solution (retrieving multiple varbinds per query)
also provides substantial bandwidth and processing cost benefits.

Randy

---

From: "Rolf Winter" <[email-masked]>
Date: Wed, 7 Jul 2010 08:42:29 +0200

Chris,

thanks for the comments.

> and "off with tag-out/lock-out" in the case of a local manual safety

I would leave out states such as "rebooting" from the energy monitoring part. I am not sure this is defined elsewhere such as the entity MIB e.g., need to check. Generally, the state "buckets" described in the document can contain arbitrary sub-states. If any of the above is deemed necessary for a particular class of devices this can be defined. However I don't necessarily believe they should be part of the least common denominator, which is what this document tries to capture. Generally, the document tries to capture that and the architectural aspects of energy monitoring. That means that most of goory details should go into other documents.
  
> metric for billing, though it would be nice to support future

The draft is not even requiring the measure anything in case a device can somewhat reliably estimate its power consumption. For a server this might be more difficult than for a, say, microwave oven, but these things will likely depend on the device capabilities and your use case. 

> It seems I have more questions than answers!  Looking forward to your

This is very helpful. Thanks for joining the discussion.

Rolf