Subject: [eman] Review of draft-ietf-eman-framework-01

From: Bruce Nordman <[email-masked]>
Date: Sun, 27 Mar 2011 03:26:18 +0200

I have reviewed draft-ietf-eman-framework-01 and have the

following comments.

I  address some overarching topics initially followed by others

in order of appearance in the text.

These are necessarily entangled with comments on the requirements

document.  Many comments reflect ideas present in

    draft-quittek-eman-reference-model-01.

I should summarize some key differences in a separate email.

I assume consensus on several points as in draft-norwin-energy-consider-02.

These are (paraphrased):

-Scope: all devices

-Identity: needed (details being worked on)

-“power level” always refers to W.

-devices.  These are the basic unit of what consumes energy.  “host” is not

 the right word since some of these are non-IP.

-tracking intervals is the responsibility of the NMS, not a power monitor.

-how we present our work to non-IETF audiences will be critical when we

 get closer to becoming done.

-We need to decompose our entities into functions.  The current draft does

 this to some extent, but not as fully as in the Reference Model –

     draft-quittek-eman-reference-model-01

-Simple and Complex devices.  Most devices that use the eman framework in

  the future are likely to be those that report their own information, and
report

  only basic information.  We should identify the basic set of key data and

  ensure that the documents describe that set and show how it is a modest

  number of variables – not burdensome to implement or use.

Each of these has implications for the framework draft text.

Power States:

  I think we have three proposals: That outlined in the Architecture
document,

that proposed recently by Juergen (a registry of power state sets), and a

single set of basic sets (on/sleep/off – possibly also ready).  We don’t
have

agreement but I think we should refine each of these three to move the

discussion forward.  Once we come to a conclusion, that can be dropped

into this document.

Time

  We have not yet discussed this topic much, but I think need to.  We had

a good discussion about this in a recent Ecma Smart Data Centre meeting.

Presumably time values are based on the power monitor’s clock.  If a NMS
has a different view of time, it can decide what to do about that.  When

values are accumulated by an aggregator/collector, we need to consider

what it should do.  We should also specify what to do if a device cannot

account for some of its power consumption (e.g. reset meter and record

last time of reset).  Also, we need to consider what mobile devices do to
us;

when a moves within a building or between buildings, huge complications

arise.  Seems like our best options may be to specify that we make no claims

when this happens (that is, we might accumulate energy actually consumed
elsewhere), or always reset the energy meter to zero when a device is moved.

However, a device may not KNOW that it moved, making the “no claims”
position more practical.

  Do any other MIBs have time issues?

Unitary or disaggregated reporting

  This is a ‘reference model’ issue but I think worth pulling out
separately.

The Architecture document reads as if all information about a device being

monitored moves as a single unit.  The Reference Model breaks this into

three parts: power level, energy consumed, and power supply.  The document

often refers to power level and energy, but not supply.  Control of power
supply

is anticipated (via PDUs or PoE switches), so I assume we must monitor this

to begin with.  So, supply should get equal billing with power and energy.

  There is much that hinges on this point, and other differences between
this

draft and the Reference Model draft.

Power state of components and collections

  I know we have had some conversations about power states for entities
other

than whole devices – either components of devices or collections of devices.

I am inclined to say that in both cases the value is not defined (the same
would

hold for power supply).  Power levels and energy consumption can be

specified for components or collections.

Meter Domain

  I think this would be better called a “Domain” (or “Electricity Domain” or

“Energy Domain”).  We may want to control the supply of a domain even in

cases in which a meter is not present.  Also, not all devices in a domain
are

necessarily metered

Powered Device

  Many references to a power monitor would be better listed as “powered

device”.  For example, a device is part of a domain – the monitor simply

reports that fact – the monitor itself is not part of the domain as it is
not

using energy.

On to the document sections:

-Why is the title “Energy…Framework” and the page heading
“Power…Architecture”?  I don’t care which but seems like should be
consistent.

0. <initial notes>

-for Power Monitor term, I agree to use of term, but I do not think there

 is yet consensus on its definition.

-has anyone suggested that we include generation?  That said, if a device

reports on components, then its battery will sometimes generate electricity.

 I think we can just note that for batteries, the power consumption can be

 negative, and the energy consumed can drop over time.  I think power

 sources like a generator or solar panel are out of scope (though fine with

 me if people choose to use our MIBs for them).

-I think implementation scenarios should be in the requirements and

 applicability statement.  This document can address how these scenarios

 are implemented in the architecture, but not repeat details in other
documents.

-I completely agree – not Joules and Coulombs.  We do not need to explain

  conversions.

-I think we want to use mW, mA, and mV.  Not sure about A and Wh.

1.

-The examples should reflect the scope of all devices.  Same for section 2.

3.

-I think it helpful to separate definitions from commentary on those
definitions.

  The separation can be as simple as a new paragraph.

-Explanation and commentary occurs in both sections 3 and 5.  It may make

  sense to move all commentary to section 5.

3.1

-Clarify whether an Aggregator collects data from multiple power monitors,

  or adds up such data.  These are two distinct functions that could reside
in

  the same entity, or in different ones (or the summing function may not be

  present).

-The function of distributing power is separate from aggregating reported
data.

-Figure 2. Proxying and Aggregating are separate functions.  An entity may

  implement one, the other, or both.

-A new section heading should be inserted towards the bottom of page 11

  where the discussion turns to protocols.

5.1

-Every power monitor is said to require an index.  If a device reports on
itself

as a single unit, is there any need for an index?   Would this always just
be “1”?

5.2

-Issues of power distribution (topologies) should be separated from those

  of aggregation of reporting, as they do not need to be structure the same

  way (even as they will commonly have the same structure).

5.3.

-The concept of a domain is separate from proxying or aggregation.

5.5

-A new section on Identity should be inserted before 5.5 (which is now on
Context).

-The examples in this section should be drawn from all building types, not
just

  commercial buildings.

5.7

-Drop paragraph 1

-paragraph 2.  Line losses will make the output from one device different
from

  the input power to another one.

-paragraph 3.  I don’t think we need the multiplier – reporting in mW should
be

 accurate enough for our purposes and we do not span so many orders of

  magnitude to make the single unit burdensome.

5.9

-I would drop this section (on demand measurement).

5.10

-I would put all mention of the battery MIB in one place, near the beginning
of the

  document, as it is not interactive with the rest of the framework.

6.

-Changes we may make in the architecture might suggest changes to the MIB

  structure, so I am reluctant to make extensive comments at this time.

7.

-I don’t think we want the parent/child concept, but even so, this section

  implies that children are always powered from parents, which I do not

  see as our framework.  Certainly this happens sometimes, so can be
presented

  in that light.

8.

-The discussion beginning after the bullet points does not seem to be

  about configuration so should be a different section.

11.

-Per above, this should be moved to the Applicability and Requirements
documents.

I have some individual text edits, but won’t burden this email with them.

Cheers,

--Bruce (as a contributor)

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

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 29 Mar 2011 03:13:33 -0500

Hello

Here are comments on the  draft-ietf-eman-framework-01. 

Thanks
Mouli

Abstract should have some context what the document contains. Right now,
it is a one line sentence.

Terminology section should have a definition of what is an Energy Aware
device. 
  
Since the MIB variables are not defined in the framework document, the
UML diagram seems out of context. 

 I think the purpose of the framework document is to impress on the need
3 - 4 architectural points. 

Identity of the device - what are the variables needed to identify a
device 
Why is it important to have the notion of Parent/Child and how does this
help in energy monitoring scenarios 
The concept of Power States of device for monitoring and possibly
configuration of devices in future 
Demand measurement. - why is it important 
  
Some of the examples can be removed from the framework document. 
 
The example scenario of dual powered device provided by Chris Verges has
been captured in the requirements and is not needed in the framework
document. 

Section 11 - Implementation scenarios is part of many documents - One
possibility is have a detailed section of Use cases in the Applicability
Statement document.
If other or new use cases for energy monitoring, the applicability
statement can be expanded and the requirements document can be updated
to see if there are new energy monitoring requirements.  
For e.g.  there are some new use cases from PDU vendors and Printers
(power consuming entities which a network connection)
 
If the framework document is trimmed a bit,  I think this document will
be much better. My 2 cents. 
 
Thanks
Mouli