Subject: [eman] Framework issues (repost)

From: Bruce Nordman <[email-masked]>
Date: Thu, 23 Feb 2012 23:07:22 -0800

I have a number of concerns about the Framework draft.
I posted the comments below in November before our last
meeting. I believe all are still relevant to am reposting.
The original is:
  http://www.ietf.org/mail-archive/web/eman/current/msg00940.html

Thanks,

-Bruce

Comments on Framework -03

Bruce Nordman, November 6, 2011

The framework document (FWK) continues to make progress.  The work of the
authors is much appreciated.

The FWK addresses the following major types of content:

-Relationships among devices, including power topology and proxying for
non-IP and non-EMAN devices

-Power/energy measurement details

-Power state semantics

-Context information

The FWK does not address some issues important to eman:

-Details of power supply topology

-Treatment of components

-Aggregation of information-unified views of objects, both monitoring and
control

The FWK draft could have the Reference Model (REF) -03 usefully merged into
it to fill in many of the gaps.

There are also substantive issues raised below.

For REF, it provides explicit and detailed modeling of the power
relationships among devices so that there is no ambiguity.  In addition, it
enables reporting of relationships that are complex and/or not fully known,
so that an energy management system can be certain of the meaning of
reported data or the effect of control commands.  It does this in a way
which is simple to understand and implement.  The parent-child relationship
in FWK is apparent to the EMS in the data it has, and may be apparent to
individual devices, including parents and children.  The REF draft does not
conflict with the FWK but rather fills out details for the FWK.

REF also clarifies that components share many characteristics of devices
regarding energy reporting and control, but that devices have some
characteristics that components do not.  FWK focuses almost entirely on
devices rather than components (except to the extent that batteries are
mentioned), and the REF and FWK concepts of a device are consistent.  For
example, presumably components inside a device do not have power
relationships with other devices.

One fundamental point in FWK is that it states that parent/child
communication cannot be via the EMAN protocol.  It is certainly the case
that it is not required to be, and in many cases may be to non-IP devices,
but often one device will speak EMAN to a device “upstream” that is not the
management system, and so utilize that mechanism for reporting and control.
This assumes that “parent” concept applies to any relationship between two
devices in which power supply, monitoring, metering, or control are
involved.  Another possibility is that parent/child is only intended to be
applied to relationships that proxy to other (possibly non-IP) protocols.  This
is fine but it should then be made clear that many devices will have
energy/power relationships but do not fall into the parent-child
nomenclature.

The rest of this discussion is in order of appearance in the document.

Open issues:

-1: Yes—add these scenarios by merging in content from REF

-2: No (no variable states); No (not a requirement); batteries a component.

-3: Power levels are a different concept from a power state.  If a ‘power
cap’ requirement is introduced, this could be accommodated, but should not
be conflated with power state reporting or control.

1. Introduction

-First two paragraphs are generic content that should be moved to a
different draft.

2. Requirements and Use Cases

-This should be trimmed down considerably.

4. Energy Management Reference Model

-The third paragraph should emphasize that the data model is the important
part of EMAN and that SNMP (and IPFIX) are simply the most obvious and
immediately convenient ways to communicate that data.

-Figure 2 – as above, communication between parent and child may be
accomplished via EMAN among other possibilities, some not involving IP.

-“PC with line cards” - ??? wouldn’t router or switch be a better example
for line cards?

5. Framework High Level Concepts and Scope

-Delete the 19 lines beginning with the “Procurement” one. Not needed and
not helpful.

5.1 Domain

-Recast this as that a domain is a portion of an electricity distribution
system that is separately metered or carries some other important
distinguishing characteristic.  No need to mention “utility” or a utility
meter.

-Note that a child may be in a different electricity domain from a parent.

-Also note that a device may draw power from multiple domains
simultaneously, so that the domain concept really applies to a power
interface, not to an entire device.

5.2.1 Identification

-I am all for use of UUIDs, but I don’t remember that they were made
mandatory.

-“unique printable name”.  Unique globally? or within some context?  Also,
add more elaboration on this topic.

5.2.1 Context

-This should be a separate section from Identification, i.e. a new 5.3.

5.2.3 Importance

-Is this tied to a requirement or use case?

5.3 Relationships

-What does “keep track of” actually mean in this case?

5.4 Energy Monitoring

-No need to mention non-electrical energy.

-Fine to use odometer in the explanation as an illustrative example, but
these are electricity meters, NOT odometers, which measure distance
traveled.

-The “used, produced, net” list is too much for some applications and too
little for others.  The REF provides a way to make clear what meters in a
device mean.

5.4.1 Power Measurement

-It is not necessary for EMAN to have a concept of a meter separate from a
regular eman device which does metering.

-Later in paragraph 2, reference is made to “intent” of measurement; actual
topology can instead be used to clarify how measurements should correspond.

-I don’t think it necessary to distinguish between actual or estimated
measurements; instead, accuracy is all we need as an actual measurement
could be quite inaccurate (or accurate), and an estimate could be quite
accurate (or not).

5.4.2 Power Quality

-The Demand discussion should be in a separate section

-For batteries, only need a single sentence to point to the battery draft.

5.5.1 IEEE 1621 Power State Series

-I have no idea where these definitions came from – not from the IEEE
standard.  That can be found at eetd.lbl.gov/controls/1621

5.5.2 DMTF Power State Series

-The presentation should be limited to the DMTF set so the Figure should be
adjusted to do that (though referencing ACPI does seem OK).

5.5.3 EMAN Power State Series

-I don’t accept that this series should have the EMAN name.

-“non-operational” states do not necessarily have a lower power level than
on states in circumstances such as battery charging – making this statement
is simply not needed.

-This series combines two separate concepts – a power state, and an
activity or utilization level.  It seems fine to have EMAN able to report
level of activity of a device at the current time, but forcing these
together is arbitrary and unnecessary.  I would support a variable of
activity/utilization level – 0-100 seems like a good choice but others may
have a better suggestion.  Devices could support activity level as
read-only, or as read/write, to enable control.

7. Configuration

-I assume it is the management system that is doing the configuring.  This
seems out of scope for this document, but I do think it would be useful
content for somewhere.  I have thought that an “Implementation Advice”
non-normative draft would be a helpful addition to our collection.

-The middle paragraph in this section duplicates content from elsewhere in
the draft.

-The last paragraph seems out of place here.

9. Relationships to other Standards

-Seems like this entire section can be removed as duplicative.

-- 
*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: Fri, 24 Feb 2012 12:20:06 -0600

Hi Bruce,

Regarding your comment - in fact, components are modeled well in
Framework; using Entity MIB containment. 

Yes, Power supply Topology is not considered in Framework  - is there a
use case from an EMAN perspective for the discovering the  power supply
topology. 

I think it would be helpful if the review is not be based on the premise
that the reference model should integrated with the Framework. 

Thanks

Mouli

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Nordman
Sent: Friday, February 24, 2012 12:37 PM
To: eman mailing list
Subject: [eman] Framework issues (repost)

Thanks,

-Bruce

The framework document (FWK) continues to make progress.  The work of
the authors is much appreciated.

-Power state semantics

-Context information

-Treatment of components

-Aggregation of information-unified views of objects, both monitoring
and control

The FWK draft could have the Reference Model (REF) -03 usefully merged
into it to fill in many of the gaps.

For REF, it provides explicit and detailed modeling of the power
relationships among devices so that there is no ambiguity.  In addition,
it enables reporting of relationships that are complex and/or not fully
known, so that an energy management system can be certain of the meaning
of reported data or the effect of control commands.  It does this in a
way which is simple to understand and implement.  The parent-child
relationship in FWK is apparent to the EMS in the data it has, and may
be apparent to individual devices, including parents and children.  The
REF draft does not conflict with the FWK but rather fills out details
for the FWK.

REF also clarifies that components share many characteristics of devices
regarding energy reporting and control, but that devices have some
characteristics that components do not.  FWK focuses almost entirely on
devices rather than components (except to the extent that batteries are
mentioned), and the REF and FWK concepts of a device are consistent.
For example, presumably components inside a device do not have power
relationships with other devices.

One fundamental point in FWK is that it states that parent/child
communication cannot be via the EMAN protocol.  It is certainly the case
that it is not required to be, and in many cases may be to non-IP
devices, but often one device will speak EMAN to a device "upstream"
that is not the management system, and so utilize that mechanism for
reporting and control.  This assumes that "parent" concept applies to
any relationship between two devices in which power supply, monitoring,
metering, or control are involved.  Another possibility is that
parent/child is only intended to be applied to relationships that proxy
to other (possibly non-IP) protocols.  This is fine but it should then
be made clear that many devices will have energy/power relationships but
do not fall into the parent-child nomenclature.  

Open issues:

-1: Yes-add these scenarios by merging in content from REF

-2: No (no variable states); No (not a requirement); batteries a
component.

-3: Power levels are a different concept from a power state.  If a
'power cap' requirement is introduced, this could be accommodated, but
should not be conflated with power state reporting or control.

1. Introduction

-The third paragraph should emphasize that the data model is the
important part of EMAN and that SNMP (and IPFIX) are simply the most
obvious and immediately convenient ways to communicate that data.

-Figure 2 - as above, communication between parent and child may be
accomplished via EMAN among other possibilities, some not involving IP.

-"PC with line cards" - ??? wouldn't router or switch be a better
example for line cards?

-Delete the 19 lines beginning with the "Procurement" one. Not needed
and not helpful.

5.1 Domain

-Recast this as that a domain is a portion of an electricity
distribution system that is separately metered or carries some other
important distinguishing characteristic.  No need to mention "utility"
or a utility meter.  

-Note that a child may be in a different electricity domain from a
parent.

5.2.1 Identification

-I am all for use of UUIDs, but I don't remember that they were made
mandatory.

-"unique printable name".  Unique globally? or within some context?
Also, add more elaboration on this topic.

5.2.1 Context

5.2.3 Importance

5.3 Relationships

-What does "keep track of" actually mean in this case?

5.4 Energy Monitoring

-The "used, produced, net" list is too much for some applications and
too little for others.  The REF provides a way to make clear what meters
in a device mean.

5.4.1 Power Measurement

-It is not necessary for EMAN to have a concept of a meter separate from
a regular eman device which does metering.

-Later in paragraph 2, reference is made to "intent" of measurement;
actual topology can instead be used to clarify how measurements should
correspond.

-I don't think it necessary to distinguish between actual or estimated
measurements; instead, accuracy is all we need as an actual measurement
could be quite inaccurate (or accurate), and an estimate could be quite
accurate (or not).

5.4.2 Power Quality

-For batteries, only need a single sentence to point to the battery
draft.

-I have no idea where these definitions came from - not from the IEEE
standard.  That can be found at eetd.lbl.gov/controls/1621

-The presentation should be limited to the DMTF set so the Figure should
be adjusted to do that (though referencing ACPI does seem OK).

-I don't accept that this series should have the EMAN name.  

-"non-operational" states do not necessarily have a lower power level
than on states in circumstances such as battery charging - making this
statement is simply not needed.

-This series combines two separate concepts - a power state, and an
activity or utilization level.  It seems fine to have EMAN able to
report level of activity of a device at the current time, but forcing
these together is arbitrary and unnecessary.  I would support a variable
of activity/utilization level - 0-100 seems like a good choice but
others may have a better suggestion.  Devices could support activity
level as read-only, or as read/write, to enable control.

7. Configuration

-I assume it is the management system that is doing the configuring.
This seems out of scope for this document, but I do think it would be
useful content for somewhere.  I have thought that an "Implementation
Advice" non-normative draft would be a helpful addition to our
collection.

-The middle paragraph in this section duplicates content from elsewhere
in the draft.

-- 
Bruce Nordman