Subject: [eman] Two NMS configuring the Power Monitor with two different Power State Series

From: Benoit Claise <[email-masked]>
Date: Tue, 03 May 2011 11:05:50 +0200

Dear all,

Let's discuss the following situation: what if we have 2 NMS', and they 
speak different Power State Series for a specific Power Monitor? Should 
this be allowed by the [EMAN-REQ]?

Tentative definitions for Power States Series and Power State are 
defined below. They should help the discussion (further discussion on 
these definitions will have to take place in the future):

Power State Series

A Power State Series is defined as a well known sequence of incremental 
energy saving modes of a device. This can be viewed as an interface for 
the underlying device-implemented power settings. Examples include DTMF, 
ACPI, etc...

Power State

A Power State is a uniform way to classify power settings on a Power 
Monitor (e.g., shut, hibernate, sleep, high).The Power State is composed 
of a Power State Series and a specific state within the series.

Actually this requirement has got some implications in terms of the MIB 
design (taking 
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07 into 
account)

- If the answer is yes, then we need to have an extra index in the power 
pmPowerTable. This index must abe a new TC, which is only for the Power 
State Series.  Note: the table needs to redesigned because the common 
variable (caliber, nameplate, etc...) are common per Power State Series. 
Then we can have a new table, for discovery, that will only contain  two 
indices: pmPowerMonitorIndex and the new TC-defined pmPowerStateSeries.
- If the answer is no, then there is the risk that NMS1 will set the 
DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the Power 
Monitor supports both the DMTF and the EMAN Power State Series), and 
there is a ping-pong game between two NMS's that don't synchronize 
between the two.

The alternative is that the first NMS would say: I will speak to the 
Power Monitor with the DMTF Power State Series, and then all the other 
NMS's will have to speak the same language (i.e. DMTF).

Somehow, the trade-off is the following:
- We ease the live of the NMS (they can speak the "language" of their 
choice) at the cost of slight more complex MIB (one extra index)
- We ease the live of the Power Monitor by simplifying the MIB design.

Conclusion: we have to clearly define what the requirements are.

Regards, Benoit.

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 3 May 2011 11:28:55 +0200

On Tue, May 03, 2011 at 11:05:50AM +0200, Benoit Claise wrote:
 
> Let's discuss the following situation: what if we have 2 NMS', and
> they speak different Power State Series for a specific Power
> Monitor? Should this be allowed by the [EMAN-REQ]?

Traditionally, it was always assumed that an SNMP management system
can more easily adapt to devices than the other way round.

> Actually this requirement has got some implications in terms of the
> MIB design (taking
> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-07
> into account)
> 
> - If the answer is yes, then we need to have an extra index in the
> power pmPowerTable. This index must abe a new TC, which is only for
> the Power State Series.  Note: the table needs to redesigned because
> the common variable (caliber, nameplate, etc...) are common per
> Power State Series. Then we can have a new table, for discovery,
> that will only contain  two indices: pmPowerMonitorIndex and the new
> TC-defined pmPowerStateSeries.
> DMTF:1 for example, and then NMS2 set it EMAN:3 (assuming that the
> Power Monitor supports both the DMTF and the EMAN Power State
> Series), and there is a ping-pong game between two NMS's that don't
> synchronize between the two.

If two management systems make changes without coordination, you
always have a chance for ping-pong effects, even within a Power State
Series. That said, it might be possible to provide guidelines such as
if a device is reporting a value of a given Power State Series
(e.g. DMTF:3), a management application should adapt and use DMTF
power states.

> Power Monitor with the DMTF Power State Series, and then all the
> other NMS's will have to speak the same language (i.e. DMTF).

I think that is a reasonably assumption to make if the number of
different Power State Series is kept limited (that is we prevent that
every vendor/organization comes up with its own creative series of
power states). A large number of different Power State Series will be
hindering interoperability, with or without ping-pong effects.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>