Subject: [OPSAWG] draft-claise-energy-monitoring-mib

From: "Anthony Barrera" <[email-masked]>
Date: Mon, 24 May 2010 09:11:20 -0700

All,

We have reviewed the Cisco draft-claise-energy-monitoring-mib and are
providing our feedback. We looked specifically at how well the draft
will support Western Telematic (WTI) Switched PDUs. Overall impression
is that the draft covers our core functionality well both in terms of
power control and power monitoring. We have also reviewed the NEC draft
and have noted a few comparisons.

WTI PDUs provide individual outlet level power control and monitoring
for attached devices. This idea directly follows Cisco's parent/child
concept, where the PDU itself is the parent and the attached devices are
the children. The PDU will report power consumption data to the NMS on
behalf of its attached devices that cannot communicate its consumption
data to the network on its own. 

WTI PDUs also support a proprietary SNMP MIB for power management. The
Cisco draft does allow for the same power control and monitoring
capabilities as the WTI proprietary MIB. Power levels for individual
outlets can be read and configured, and energy use on those outlets can
be queried. WTI PDUs also support control and monitoring of internally
configured outlet groups. Cisco's implementation of the "keywords"

concept allows for the flexibility of taking advantage of those
internally configured groups in addition to single outlets.

Standardized power level definitions, as presented in the Cisco draft,
will be more useful for network management than device-defined power
levels, as presented in the NEC draft. Allowing numerous network devices
to define their own set of power levels can make management difficult
for the NMS. An additional note, the NEC draft appears to only allow for
power monitoring, not for control of power levels on devices.

The NEC draft separates the power management MIBs into multiple MIB
modules, whereas Cisco has one centralized module. From an NMS
standpoint that needs to both control power levels and monitor energy
usage at those power levels, it seems like keeping them all in one
central MIB as Cisco has done makes more sense. In addition, adding
support for one centralized MIB can be easier to implement in the SNMP
agent of the supporting devices.

The Cisco draft does not support retrieval of voltage data. In addition
to power data, voltage data may be useful in deriving current data that
the NMS may want to monitor (i.e. for alarming before a circuit breaker
is tripped). We recommend adding a way to retrieve voltage data from the
monitored devices. 

Anthony Barrera

Western Telematic, Inc.

---

From: "Dolisy, Joel" <[email-masked]>
Date: Mon, 24 May 2010 16:49:18 -0500

All,

I agree that a set of standardized power level is something that is
needed to allow the NMS to properly present and evaluate the information
across multiple devices. For instance policies usually are designed to
target multiple devices, and that would be pretty difficult if different
devices each had their own.

Joel Dolisy
SolarWinds

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Anthony Barrera
Sent: Monday, May 24, 2010 11:11 AM
To: [email-masked]
Subject: [OPSAWG] draft-claise-energy-monitoring-mib

All,

Anthony Barrera
Western Telematic, Inc.

---

From: "Juergen Quittek" <[email-masked]>
Date: Sat, 29 May 2010 11:09:45 +0200

Dear Anthony,

Thank you very much for your helpful comments.

I see two main points in your message:

  1. support for the parent/child concept.

  2. a preference to have rather a single MIB module than separate
     ones for power state monitoring and for energy/power measurement.

I would like to further discuss your second point.

Basically, I do not see a big issue with having one or two modules.

The implementation effort is not much different, because the main work is
implementing the managed objects that do not vary in number between the two
alternatives.

But I see a difference in who would implement which functions. In your case,
you obviously want to implement both and then your preference is obvious.
But I see a huge number of cases where only the power state monitoring
functions would be implemented and not the energy monitoring functions.

The reason is that for power state monitoring you do not need any additional
support on many common devices. PCs for example, already have power
management interfaces. You can implement a POWER-STATE-MIB in a generic way
that can become makes it easy to become part of any Linux or Windows
distribution for any kind of PC. And I expect this to happen soon after
there is a standard POWER-STATE-MIB defined.

The situation is very different for the ENERGY-MIB. For implementing it, you
need instrumentation to measuring the current power consumption and thisis
not commonly available on PCs, routers, or switches today. There are
chipsets available for this purpose, but so far, they are not widely
deployed in PCs nor is there a commonly agreed interface to such a hardware
extension. Although I hope that soon we will be able to measure energy
consumption for every networked device, there is still a long way to go.

Bottom line is that I would see power state monitoring soon be part of
common operating systems and deployed massively, while energy monitoring
will have a much slower deployment rate because of extra hardware needed to
implement it.

We could solve this with compliance statements at the end of a single MIB
module saying that you may implement just the power monitoring part and not
the energy monitoring part, but I see the situation be better addressed by
two separate MIB modules for two separate management functions.
 
Thanks,

    Juergen

On 24.05.10 18:11  "Anthony Barrera" <[email-masked]> wrote:

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