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

From: "Anthony Barrera" <[email-masked]>
Date: Wed, 16 Jun 2010 09:20:28 -0700

Jeurgen,

Thank you for reviewing my comments and providing feedback, and
apologies for the delayed response. I understand your arguments and
would have to agree with your points, separate MIB modules may be better
suited for the majority of devices in general. As far as our products
are concerned, supporting 1 or 2 MIB modules does not make much
difference. Thanks - Anthony

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Saturday, May 29, 2010 2:10 AM
To: Anthony Barrera; [email-masked]
Subject: Re: [OPSAWG] draft-claise-energy-monitoring-mib

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:

> 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.
> 
>  
> 
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg