Subject: Re: [eman] New Version Notification for draft-ietf-eman-framework-03.txt

From: Bruce Nordman <[email-masked]>
Date: Sun, 6 Nov 2011 22:47:58 -0800

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.

On Mon, Oct 31, 2011 at 5:22 PM, John Parello (jparello) <[email-masked]
> wrote:

> Hi All,
>
> We have posted a new version of the draft as you may have already seen.:
>
>  [EMAN-FMWK] http://tools.ietf.org/id/draft-ietf-eman-framework-03.txt
>
> Thank you all for your comments from the last meeting and the list.
> We've tried very hard to get all your comments addressed.  The major
> edit was on terminology which cleared up a lot of other comments.
>
> If there is something we missed from your last comments please attribute
> it to oversight not exclusion. So please do let us know if we missed
> anything.
>
> As a quick summary of changes at
> http://tools.ietf.org/rfcdiff?url2=draft-ietf-eman-framework-03.txt:
>
>  - up to date with the terminology from
> http://tools.ietf.org/html/draft-parello-eman-definitions-03
>  - clearly mentioned optional Energy Object Relationships
>  - Tried to clear up the power network versus control network
>  - IPFIX mentioned but not required
>  - Added guidelines regarding the context
>  - removed the manufacturer power states
>  - added the 3 ODVA counters
>
> Thank you
> Jp
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>

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

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 Nov 2011 19:15:40 +0800

Hi Bruce,

Thanks for your review.
> The framework document (FWK) continues to make progress.The work of 
> the authors is much appreciated.
>
> -Relationships among devices, including power topology and proxying 
> for non-IP and non-EMAN devices
>
This is the Power Source Relationship.
Let's take the example of EO1 receiving power source from EO2, where EO2 
could be battery inside a PC, a power supply inside a router, or even an 
external PDU, etc...
EO1 is characterized by UUID1 and EO2 is characterized by UUID2
If EO1 knows about his power source, then eoMeteredBy = UUID2. Whether 
EO2 is a components of EO1 or not is irrelevant
Agreed that we should do a better job of explaining this in the 
framework, based on the latest design of the energy aware MIB. There is 
still some misalignment between the two

Actually every relationship type (Aggregation Relationship, Metering 
Relationship, Power Source Relationship, Proxy Relationship, Dependency 
Relationship) has a similar concept. What counts is that the EO's have 
UUID's.
And in the case where the relationship is known from parent or the 
children, then the MIB objects are populated.
No ambiguity. Note that these relationships are optional.
> -Treatment of components
See my previous comment
On the top of that, if the full ENTITY-MIB is supported on the router 
example, then the ENTITY-MIB provides the information that the power 
supply  EO2) is contained in the chassis (EO1)
Agreed that we should do a better job of explaining this in the framework.
>
> -Aggregation of information-unified views of objects, both monitoring 
> and control
>
Not sure what you mean
>
> The FWK draft could have the Reference Model (REF) -03 usefully merged 
> into it to fill in many of the gaps.
>
The REF-03 does a good job in section to explain why Energy Management 
is different.
> relationships among devices so that there is no ambiguity.In addition, 
> it enables reporting of relationships that are complex and/or not 
> fully known,
>
Where is the ambiguity in the [EMAN-FMWK]. I would say that "In 
addition, it enables reporting of relationships that are complex and/or 
not fully known," is correct as well with [EMAN-FMWK]. You can even have 
more relationships type in the future if you need...
> 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.
>
> 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.
>
> -1: Yes---add these scenarios by merging in content from REF
>
Yes, but in [EMAN-FMWK] or [EMAN-AS]?
> -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.
>

Let me answer a couple of important points here.
> -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.
>
ok.
>
> -Figure 2 -- as above, communication between parent and child may be 
> -"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.
>
> -I am all for use of UUIDs, but I don't remember that they were made 
> mandatory.
>
by design from the latest energy-aware-mib, if you want to model a 
relationship, it will be based on the UUIDs
>
> -"unique printable name".Unique globally? or within some context?Also, 
> -What does "keep track of" actually mean in this case?
>
> 5.4 Energy Monitoring
>
> -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.
>
This concept was inherited from ODVA.
>
> 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
>
> -I have no idea where these definitions came from -- not from the IEEE 
> standard.That can be found at eetd.lbl.gov/controls/1621 
> <http://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.
>
What would you like to be then?
>
> -"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.
>
Thanks again for your feedback.

Regards, Benoit (as a contributor)
>
>
> On Mon, Oct 31, 2011 at 5:22 PM, John Parello (jparello) 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi All,
>
>     [email-masked] <mailto:[email-masked]>
> eetd.lbl.gov/ea/nordman <http://eetd.lbl.gov/ea/nordman>
> [email-masked]
> 510-486-7089
> m: 510-501-7943
>
>
>