Subject: [eman] Framework draft comments

From: Bruce Nordman <[email-masked]>
Date: Thu, 14 Jul 2011 00:28:16 -0700

This is not an exhaustive list of my comments, but only major ones.

Issues beyond this draft

In some cases we speak to covering entire devices as well as arbitrary

components (entities) of devices.  However, the use cases and other

discussions/examples are overwhelmingly only about entire devices.

The perceived need to cover components in addition to devices has

led to terminology such as “object” and “entity”.  I think EMAN is primarily

about entire devices and many features only applicable (well or at all)

to them and not to components.  I think we should recast the requirements

and framework to be device centric, and then add limited reporting of

information about components to this.  The component reporting does

seem legitimate in niche applications.   Note that devices such as a blade

server chassis can be reported as a set of devices, with each blade server

a separate device, even if they are DC-powered.  Each server has its own

basic network presence.  The chassis may also consume power, but this

is just like a PoE switch.

A critical need for effective energy management is for devices to report

basic information about their identity in a general sense (not their network

identify specifically).  This is data such as brand and model, as well as

a standard classification of device type.  This needs to be clearly stated

in the applicability statement, requirements, framework, and in a MIB.

Overall comments

In general, I believe that the approach outlined in the current version of

the “reference model” draft (draft-quittek-eman-reference-model-02) has

significant advantages over that presented in the framework draft.

The reference model is more general, flexible, and ultimately simpler.

It enables exposing details of power distribution topology when needed,

and does not require this when not.

Some of the language in the draft seems more like requirements, and so

should be moved to that document (e.g. Section 5.4).  Some of the

discussion at the beginning of section 5 is really more appropriate to
Applicability.

There should be explicit mention of the possibility of multiple “parents”

and multiple EMSes.  Similarly, it should be clarified that there is no
limit

to the number of levels of devices that report on subsidiary devices,

and/or aggregate information about them.  All the examples show only

a single level of this.

Any support for demand or time-series data should be clearly identified

as optional and not burdened by complexity.  For example, only a single

series should be addressed (e.g. not consider multiple EMSes requesting

conflicting lengths of time periods).

Terminology

“Energy Management Domain” – Section 6 uses the term “Meter Domain”

which seems much more appropriate for this concept since having a

meter at the root is at its core.  Also, the discussion should clarify how

“nested” meter domains should be treated.

“Power State”.  A better definition can be found in IEEE 1621:

“3.1.7 power state: A condition or mode of a device that broadly

characterizes its capabilities, power consumption, power indicator

coding, and responsiveness to input.”

Specifics

For aggregation, the rationale for summation seems much more solid than

for the other metrics mentioned under “aggregation relationship” and these

others are readily calculable from the full data set and so not needed.

The definition of “Proxy relationship” seems to combine two distinct

issues – one device reporting data for a second device, and translating

from non-IP/EMAN domains to EMAN.  Reporting on a second device is

useful regardless of whether the second device can directly report on

itself or not, so the two functions should be kept distinct.

In line with this, it is specified that the communication between a parent

and child is out of scope for EMAN.   Many devices will get information

from a subsidiary device with the EMAN protocol and then report that.

It seems unnecessary to have both the “proxy” and “parent/child” concepts;

the former seems a better choice.

It would be helpful if someone would write down the implications of using

IPFIX to transmit EMAN data.  Some or all of this would be helpful for the

Applicability statement to help those not well versed in IETF protocols to

know how it can be used.  Also, does enabling IPFIX to be used require any

content in our drafts?

The description of IEEE 1621 power states is not from 1621.  The definitions

in 1621 are not actually so useful or relevant here – the important point is

that a device can categorize its states into the three basic power state

categories.

Section 5.5.2 – This section lists the full set of DMTF states then includes
a

table of only a subset.  It needs to be clarified which the standard is
intended

to cover.  Also, it should be noted that to date, products do not implement

either S1 or S2, so that the actual ACPI (and by extension DMTF) series is

smaller than the official listing suggests.

Section 5.5.3 – There is nothing specific to EMAN in this series so it
should

not be named this way.  For state details, one can only be “awakened” from

a sleep state, not an off state.   IEEE 1621 maps hibernate to off, not
sleep.

The term “standby” is inherently confusing and should not be included in

EMAN documents.

Also, all of the divisions of states within the On state are completely
arbitrary,

and really reflect different levels of activity within the On state, and not

different power states.  If level of activity is of interest, it should be
reported

as its own variable, not conflated with the distinct concept of power state.

--Bruce (as contributor;  note: I will be off email Mon-Sat / July 18-23)

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943