Subject: [eman] Proposed alternation of framework

From: Bruce Nordman <[email-masked]>
Date: Sun, 7 Nov 2010 15:09:35 -0800

<< warning: long email >>

eman proposal for adjusting framework in current I-Ds

Bruce Nordman

November 7, 2010

The following takes the basic principles from the current I-Ds, and

makes a few changes that I see as making the framework simpler

and more transparent, and also provides some additional features.

It does not address control, nor many (future) optional features.

As an observation, power state is a property of an individual device

and cannot be aggregated.  Power level (W) and energy use can be

readily aggregated.

There are a number of complications that I would propose deferring

from our initial product.  These include transition states, support for

reporting intervals, and reporting on components within a host.

As noted above, we could be making progress on these in parallel to

the more basic work, particularly if the content was in separate I-Ds.

There is nothing magic about the terminology used below and I am

sure it can be improved.

Basic concepts I propose are:

Powered Device

An electricity-using device that is almost always “atomic” – not

separated into constituent parts that can be powered and function

autonomously in normal use.  They may have IP connectivity or lack it.

They may be able to report energy/power information themselves,

or rely on a power proxy to do this.

Most devices have a single power source, no battery, and do not power

other devices, so these just report a unitary notion of energy/power.

Other devices have multiple power sources (from different electricity

“domains”), an internal battery (which is functionally an additional
source),

and/or downstream power loads (other devices; a battery that is charging

is effectively an additional load).  Thus, these have the total net
consumption

of the device itself, the power input from each source, and the power output

to each load.  The complexity required for these more complex devices

should not be burdensome on the simpler devices.  We need terms that

distinguish simple from complex devices; whether having a battery always

makes a device complex I am not sure.

In addition to the information noted in the current I-Ds, a device is also a

member of a “Power Domain” (or more specifically, each power source is).

Power Proxy

A power proxy reports power/energy data on behalf of a second device.

For purposes of energy management, it IS the device.  The second device

may or may not have IP connectivity, but in either case, all energy/power

information (including any subsidiary notion of identity) should come from

the proxy to the rest of the IP network.  In the long run, we should hope
that

fewer and fewer devices require a proxy, but for a considerable time we will

have devices that lack IP connectivity, or that have it but lack ability to
report

on their own power/energy status.

Note that a host may implement many power proxies; each proxy is logically

independent of the others.  It seems likely that any device that provides
proxy

services can report on its own power/energy status.  A proxy will almost
always

(perhaps always) be implemented by a Power Distributor, but proxying a
distinct

function.

The proxy may be in the same domain as the second device, or a different
domain.

If in the same domain, the proxy may be in a device that distributes power
to the

second device, or not.  Thus, there are three possible relationships:
different domain,

powering (consequently same domain), not powering (but same domain).

Power Distributor

These consumes power themselves and distribute power to other devices, which

may include further distributors.  A distributor may have incomplete
information

about downstream devices and their power consumption, missing identity,
power

consumption, or both, from some devices.  A distributor is a device, so may
have

more than one power source, and may include a battery.

It is helpful to first think of power being distributed along a tree
structure, with

parent and child controllers, but the structure need not be limited to
classic trees.

Other than batteries, at this time power flow is only in one direction (that
is, all

flows are either sources into a device, or sinks out of it).

A distributor may be in one power domain, but more commonly the downstream

powered devices will be in a different domain; a Power over Ethernet switch
is a

prime example of this.  Most commonly, each domain will have a single source
of

power (ignoring batteries), but this may not be required.

Power Domain

A system of power distribution with a common technology and fate.
Technologies

are usually distinguished by voltages and whether AC or DC.  AC examples
include

100V, 115V, 200V, and 230V.  DC examples include 380V, 48V, 24V, 12V, and 5V

(variously including eMerge, PoE, USB, and vehicle standards).  Increasingly

communications go along with power, but this is incidental to power
reporting.

Power domains are often in trees, but this is not strictly required.  A
domain with

a single source may have a controller at its root (e.g. a PoE switch), or
not (e.g.

a circuit breaker in a building).  At this time, we should consider domains
as having

a single source of power; later we could relax that requirement.

Common fate includes quality, reliability, availability, total capacity, and
price.

How devices learn what domain they are in is out of our scope.

Power Manager

This concept is NOT defined in our standard, but is a key expected user of

the facility.  It is an interested entity and has no specific relation to
device.

It may be in the same power domain, or not.

A power manager will commonly send out a broadcast request to all devices

in a power domain and ask for current information.  In this case, a
distributor is

not involved in the request for that function, though a device which is a
distributor

will report its own (net) consumption, and may implement proxies that
respond

to this request.

To avoid double-counting, the manager needs to know what domains provide

power to others).  A manager may use distributors that are gateways between

domains as aggregators, and so not bothering to query devices in the second

domain at all, or as often.  For example, the domain that a PoE switch is in
may

be queried more often than the domain of devices powered by that switch.

Other Notes

This system has no concept of a meter.  Rather, a meter is a distributor,
and

today’s meters don’t have direct knowledge of what they are providing power
to

(remember that a distributor can have incomplete knowledge, including none).

A key point is that there is no assumed relationship between the power
distribution

topology and the communications topology.

Somewhere, attention needs to be paid to wire losses – there is a difference

between power supplied to a device, and power consumed by one.   When

measurement is done at both ends of the wire, it can be calculated, but more

commonly, the measurement is done at only one end so just needs to have a

flag for which it is.

Power data are allowed to be estimated by a device from knowledge it has

rather than directly measured.  This is then noted in accuracy reporting.

Power estimation may be as important as proxying in the coming years.

Communication

The core definition is what information a device provides when queried.

A proxy IS the device for these purposes, so responds the same as a direct

device (with a flag somewhere noting it is a proxy in case someone cares).

A distributor is a device so responds the same way as a simple device
(albeit

with more complexity to the response).

Distributors may find it helpful to query devices they supply power to, but

this is simply a usage of our facility, not a separate mechanism.

Because control and intervals are not implemented, communication is only

in one direction.

Usage examples

Most common today is devices on mains AC power in which a domain is

a circuit breaker, a larger area (e.g. zone or floor of a building), or an
entire

building.  A vehicle is a building on wheels (and always its own domain).

PoE necessarily creates a different domain.   Usually all devices powered

from a PoE switch are in the same domain.  PoE switches usually have a

capacity constraint distinct from that of the domain it is part of.

A UPS has a distinct domain downstream of it from its mains power source,

as the fate of these devices is different from what the UPS sees from its
primary

source.

Other Other Notes

There is no distinction by building type (home, commercial, vehicle) in any

of this.

Likely none of this affects the battery MIB proposal.

Many control approaches will include distribution a price (and price
forecast)

to devices.  Prices will be by domain, as they may vary.  For example, UPS
will

have its own price when off-grid.  PoE devices may get higher price if
switch

is near capacity.  People in charge of a domain may want to impose their own

carbon taxes implicitly.  Local batteries/generation may raise or lower the
price

otherwise seen on a domain.  Price distribution NOT part of the energy/power

reporting mechanism, though will use the same domain concept.  There is a

standard for getting a price to a building – my concern is only local
distribution

of a price within a building or a domain.

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

---

From: "Chris Verges" <[email-masked]>
Date: Sun, 7 Nov 2010 17:15:08 -0800

Hi Bruce,

Questions and comments inline:

[BN] As an observation, power state is a property of an individual
device and cannot be aggregated.  Power level (W) and energy use can be
readily aggregated.

[CV] With respect, I think power state can be aggregated.  For example,
please consider a standard datacenter.  When all servers are turned on
in the datacenter, it is at 100% "on" state.  If 30% of the servers are
turned off, the datacenter's state has reduced to 70%.  This is fairly
congruous with the ACPI model, where a server can be in different
states, and each state represents a power usage level.

[CV] How such aggregated state is determined is beyond the scope of any
MIB, but the ability to report such information can offer a hook for
innovation in the industry.

[CV] I agree that power state, like reporting meter data, could be
pushed off to a later release, as enumerating the entities themselves is
far more critical (core?) to establishing anything more complex.

[BN] There are a number of complications that I would propose deferring
from our initial product.  These include transition states, support for

reporting intervals, and reporting on components within a host.  As
noted above, we could be making progress on these in parallel to the
more basic work, particularly if the content was in separate I-Ds.

[CV] What would now be in the initial product?  After reading your two
recent threads, I'm a little confused over what the "initial product"
is, as a definition and in its scope.

[BN] Power Domain

[BN] A system of power distribution with a common technology and fate.
Technologies are usually distinguished by voltages and whether AC or DC.
AC examples include 100V, 115V, 200V, and 230V.  DC examples include
380V, 48V, 24V, 12V, and 5V (variously including eMerge, PoE, USB, and
vehicle standards).  Increasingly communications go along with power,
but this is incidental to power reporting.

[BN] Power domains are often in trees, but this is not strictly
required.  A domain with a single source may have a controller at its
root (e.g. a PoE switch), or not (e.g. a circuit breaker in a building).
At this time, we should consider domains as having a single source of
power; later we could relax that requirement.

[BN] Common fate includes quality, reliability, availability, total
capacity, and price.  How devices learn what domain they are in is out
of our scope.

[CV] With respect, this concept of a "Power Domain" is very limited to
the standard utility/facilities definition.  Given the advent of newer
reporting models and systems, should we extend this concept to simply
mean any logical grouping of power entities.  The mapping between power
domains and power entities can be many-to-many, not just one-to-many.

[CV] For example, consider a deployment where the "power domain" is
segmented in two ways: (1) the physical infrastructure, taking into
account branch circuit and transformer capacities; and (2) the billing
structure, where entities are "grouped" according to who pays the costs.
If the MIB model only handles a 1:N mapping, the administrator needs to
choose only one.  If the MIB model handles a M:N mapping, more complex
and useful systems can be built on top of this schema.

Enjoy Beijing,

Chris

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Sun, 7 Nov 2010 22:51:21 -0600

Hello all.  Being new to the IETF I have been mainly lurking on the EMAN
list until now.  I am in Beijing and will be attending the EMAN WG meeting
on Wednesday and look forward to meeting those who can attend face-to-face.
I am in the process of reading through the current drafts and should be
prepared to offer any insights or thoughts by the Wednesday meeting.
 
I want to thank everyone for their thought provoking contributions thus far
and look forward to working with you in this important area.
 
With that as an introduction I have provided some informal thoughts on
Bruce's comments in-line below.
 
Sincerely,

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email:  <mailto:[email-masked]> [email-masked]
Phone: 614 367 5628
Fax: 614 367 5965

"Live like you're going to die tomorrow.
 Learn like you're going to live forever."

    - Albert Einstein 

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Nordman
Sent: Sunday, November 07, 2010 6:10 PM
To: [email-masked]
Subject: [eman] Proposed alternation of framework

Bruce Nordman

November 7, 2010

readily aggregated. 

[WFM] As Chris Verges has pointed out there may be some reasonable
approaches to state aggregation.  The ability to do so will depend to some
degree on the semantics and definition that are assigned to the term power
state. For example, a generic set of power states could be defined (along
with some concept of extensibility thereof) which each device is free to map
to a rough percentage of the total potential power consumption of that
device.  These values could be device specific and exposed through a MIB.
By mapping these values to a unitless quantity like a percentage we could
enable a useful form of aggregation for power states which can remain device
specific.

I am not advocating anything here, merely observing the possibility.

[WFM] I agree that we need to have some discussion of the first set of work
products from this group and a potential rollout of functions across those.
Reporting is a logical first step which could be addressed in isolation but
from my perspective power states and control mechanisms are key features of
any final working products this group must address.  I personally am
agnostic, however, on the specific timing of how these features are to be
rolled out across formal WG outputs.

sure it can be improved.

Powered Device

An electricity-using device that is almost always "atomic" - not 

"domains"), an internal battery (which is functionally an additional
source), 

member of a "Power Domain" (or more specifically, each power source is).

Power Proxy

function.

Power Distributor

[WFM] While the concept of uni-directional flow is a nice simplifying
concept, and indeed it may be true at any particular instant in time, it is
not clear that this would be true in general for a given device over time.
The example that I am thinking of is a house with solar panels installed.
During the daytime on a sunny day these systems can produce more power than
is required which can then flow backwards through the main electric meter
and is thus "sold" back to the power utility on the main grid.  At night the
house then operates as normal with respect to the grid, or it may also
supplement its power needs via battery reserves which are typically
recharged via the solar panels during the day as well.

Whether this concept extends to other devices or uses in other alternative
energy scenarios remains to be seen.

This does raise the issue that the power flow on a given metering point may
actually be negative, something that may not be immediately obvious.  Using
the example of the house described above, the power meter provided by the
utility may actually report "negative KW" during the day and "positive KW"
at night.

[WFM] Interestingly, batteries are actually an interesting case.  In this
context I am speaking of rechargable batteries (not single use chemical
batteries which I suppose could be considered a specialized power
source/domain in their own right with their own environmental impacts).
Rechargable batteries have an internal resistance which will cause them to
discharge over time.  As such they are a load to the overall system.  When
they are being utilized as a temporary power source they are depleting their
internal reserves which must ultimately be restored from some other primary
power source.  So the environmental footprint of a battery is ultimately
tied to the primary energy source which is used to charge it.  Solar cells
would have one carbon footprint, whereas a coal burning power plant would
have another.  This suggests to me that carbon footprint of a battery is
ultimately tied back to the primary source used to charge it, which could
vary over time (i.e. it may typically be recharged from solar cells when
they are available and producing power, or from the power utility
otherwise).

So if on one day they happen to be recharged via the solar cells their
instantaneous carbon footprint at that point in time would be zero, whereas
if on a differnt day they happened to be recharged from utility power their
carbon footprint would be a function of the utility's carbon load.

Whether we need or indeed want to produce a standard which can reasonably
account for such cases or not is something that we will need to decide.
Perhaps initially not, but as alternative energy sources become a larger
part of every day life these may become important.

This then raises the question of whether our power reporting mechanism can
or should account for allowing each device to report it's own carbon impact
to facilitate a more meaningful form of aggregation.  This in turn raises
the question of how a given device would even know what it's carbon impact
was since this is a function/attribute of the source.

I am not personally at a point of advocating any particular position on
these issues.  I am merely raising them for consideration.  The direction we
take will have downstream consequences.

Power Domain

[WFM] This seems a reason simplifying assumption for a first version of the
standard but long term we may wish to consider scenarios where the devices
query their sources as well as vice versa. 

Power Manager

to this request. 

[WFM] I agree that discovery mechanisms such as the one you describe are
something that we will need to take account of.  This is true even for
common reporting use cases.

Other Notes

today's meters don't have direct knowledge of what they are providing power
to

[WFM] Agreed.  The two are completely distinct.  To the extent that
management systems will need to understand both we may wish to consider
whether the power reporting capabilities we define are capable of providing
the information necessary to enable them to discern the structure of the
power distribution topology when devices have been configured with such
information.

This is also something that we will need to decide if it is in or out of
scope for our efforts. 

Somewhere, attention needs to be paid to wire losses - there is a difference

flag for which it is.

Communication

in one direction. 

[WFM] I understand your comment and why you make it given your stated
assumptions regarding scope.  I would hope that intervals might actually
still be addressed from a reporting perspective even if only based on
default intervals defined by the standard, or by enabling device specific
default intervals coupled with a means of reporting the durations thereof.
Without some device maintained means of reporting historical information the
per device polling overhead introduced on the communications network is
likely to be far greater than is actually required for efficient operations.
In addition, enabling the devices to report historical information
decentralizes the collection of the raw data and removes the need for
"tight" timing constraints on the actual polling of the devices making the
system more tolerant of network outages and delays.

Usage examples

source.

Other Other Notes

of this.

standard for getting a price to a building - my concern is only local
distribution

[WFM] In addition to pricing a parallel concept exists for reporting of the
carbon loading.  Agreed?  From a reporting perspective enabling a reasonable
ability to distribute such cost and environmental data from the sources to
the ultimate sinks would seem to be a significant goal of this work.

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Mon, 8 Nov 2010 01:02:01 -0600

Hello,

Here are my comments on norwin-energy-consider-01.

1.  Section 3 - Scope of energy management is already covered in
requirements draft. There are no additional requirements in this draft. 

2.  Section 4 - Terminology - The purpose is to have common terminology
understood by all - I agree this is import and is sort of similar to the
work in other WG; for e.g.
http://tools.ietf.org/html/draft-ietf-roll-terminology-04  for RPL.  

If Terminology is the focus, then this draft should explain/clarify lot
of other commonly used terminology - perhaps, from the basics - what is
energy, what is power, devices,  what are the methods of power/energy
measurement, then moving on to monitoring, power states, configuration
....

In terms of power states, my thought is it will take some time to evolve
to precise definitions for the devices. It may be useful if we can focus
on the devices in consideration - network devices, devices attached to
the network;  building devices and then perhaps, we can converge on this
discussion soon. 

I do not agree Power Levels should be equivalent to measured value of
power. 

3.  Section 5.1 Control  - This section calls for distributed control
instead of restricting to policy based control only. This is a valid and
interesting point to be considered. 

    Section 5.2 - Identity - calls for recognizing a Universal Product
Code (UPC) and discovering if the device is a TV.  Firstly, this
requires that TV, MicroWave has a network connection (IPV6, 6lowPAN,
...). Protocols developed in WG such CORE can be be used in that
scenario. Refer to  http://tools.ietf.org/html/rfc5826

    Section 5.3 - NMS considerations - This section the describes how
NMS would work for energy management. 

    Section 5.6 - Power considerations - There is an interesting point
on power source - internal or external - (powered by outlet of powered
by battery). I think this can be useful. 

    Section 5.7 - Power state monitoring - this material is covered in
the requirements doc. 

    Section 5.8 - Use cases - There many use cases presented in the
requirements doc.  I am not sure if the use case on - Vehicles is
relevant to energy monitoring - Vehicle energy is fuel or battery ?  

4.  Section 7 - Outstanding questions - Units of measurement - I thought
this question was settled and there is rough consensus on the IEC
measurement model ? 

                                        Multiple power sources -is an
interesting point. 

In conclusion, this draft is a combination of some requirements, some
terminology, and some open issues. 

Thanks

Mouli

---

From: Juergen Quittek <[email-masked]>
Date: Mon, 8 Nov 2010 16:41:10 +0000

Hi Chris,

I think Bruce and you are talking about different kinds of domains. Our
current documents do not yet define well enough what a domain is. This is
something we should take care of.

As far as I understand it, Bruce is talking about power distribution domains
containing, for example, devices with the same source (and fuse) of power.
You are taking also about consumer domains related to functionality or cost
centers, etc.

All these are valid kinds of domains, but they are significantly different
and should not get confused. Let's start listing which kinds of domains we
want to support in eman, what is support needed for them, and how we can
clearly define them in order to avoid confusion.

Thanks,

    Juergen

On 08.11.10 09:15  "Chris Verges" <[email-masked]> wrote:
> [CV] For example, consider a deployment where the ³power domain² is segmented
> in two ways: (1) the physical infrastructure, taking into account branch
> circuit and transformer capacities; and (2) the billing structure, where
> entities are ³grouped² according to who pays the costs.  If the MIB model only
> handles a 1:N mapping, the administrator needs to choose only one.  If the MIB
> model handles a M:N mapping, more complex and useful systems can be built on
> top of this schema.

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 9 Nov 2010 09:47:32 +0800

My comments inline below.

> requirements draft. There are no additional requirements in this draft.
There are differences.  I would be happy to provide proposed edits to
the requirements draft to harmonize the two.

> 2.  Section 4 – Terminology - The purpose is to have common terminology
> understood by all – I agree this is import and is sort of similar to the
If Terminology is the focus, then this draft should explain/clarify lot of
> other commonly used terminology – perhaps, from the basics – what is energy,
> what is power, devices,  what are the methods of power/energy measurement,
> then moving on to monitoring, power states, configuration  ….
>
Thank you for the reference.  Which draft would a terminology section
 be added to?

> to precise definitions for the devices. It may be useful if we can focus on
> the devices in consideration - network devices, devices attached to the
> network;  building devices and then perhaps, we can converge on this
> discussion soon.
>
The key to me is that the more power states that are defined, the more that
this becomes product-dependent and implementation-dependent, and the
power state becomes a proxy for other characteristics.  An alternative is to
simply report the other characteristic directly, and thus relax the need for
many power states.  I do agree that a listing of relevant states for various
classes of devices would be highly informative.  For a past example of this,
see:

http://www.energy.ca.gov/publications/displayOneReport.php?pubNum=CEC-500-2008-035
On page 21 (page 40 of the PDF), there is a table of power states for
various devices, and average power levels.  This just for illustration.

>  I do not agree Power Levels should be equivalent to measured value of
My concern is that in many audiences, particularly for energy contexts, the
term "power level" will be interpreted as the numeric level in watts.  If we
use
the same term to mean something else, confusion will result.

> interesting point to be considered.
Facilitating distributed control (and most important, hybrids of central and
distributed)
should have minimal impact on eman.  I think only one feature is required
for distributed
control (though some should be optional as not needed for the distributed
case) -- the
concept of a named electricity domain.

>     Section 5.2 - Identity - calls for recognizing a Universal Product Code
> (UPC) and discovering if the device is a TV.  Firstly, this requires that
> TV, MicroWave has a network connection (IPV6, 6lowPAN, ...). Protocols
> developed in WG such CORE can be be used in that scenario. Refer to
> http://tools.ietf.org/html/rfc5826
>
Goal here is for IP-connected devices.  About 1/3 of TVs sold this year in
the U.S. are
to have IP connections, and the share will certainly rise quickly.  UPC is a
possible solution
for illustration.   The CORE work seems very important, but designed for
specific application
contexts.  EMAN is not context-specific so the mechanism needs to be
generic.

>  Section 5.3 - NMS considerations – This section the describes how NMS
> would work for energy management.
> Section 5.6 – Power considerations - There is an interesting point on power
> source - internal or external - (powered by outlet of powered by battery). I
> think this can be useful.
>
>     Section 5.7 – Power state monitoring – this material is covered in the
> requirements doc.
>
The goal here was to define basic functionalities that all devices should
support, to distinguish
those from optional features.

>     Section 5.8 - Use cases – There many use cases presented in the
> requirements doc.  I am not sure if the use case on – Vehicles is relevant
> to energy monitoring – Vehicle energy is fuel or battery ?
>
Only electricity use, principally for non-motive-power consumption, though
nothing should
be excluded.  Vehicles have long provided power to both built-in and
dynamically added
devices, just as other building types do.  Regardless of motive power,
vehicles can have
high costs for on-board power (I've seen $1/kWh as typical for the
U.S.--presumably higher
in many other countries) as well as frequent times of constrained capacity,
so monitoring
and controlling these loads is key to ensure good user experience.

> this question was settled and there is rough consensus on the IEC
Does that specify J or Wh as the basic unit of energy for reporting?
Wh is not an SI unit but certainly much more common for electricity use.
I think we need to explicitly compare the uses the IEC standard is
intended for and compare it to ours.  There is another IEC standard,
62301 on Standby Power, that is also quite relevant for measurement
(though it does not speak to the Wh or J question as it focuses on
power values, not energy).

>                                         Multiple power sources –is an
> interesting point.
>
One we cannot ignore, even if we don't immediately address.

> terminology, and some open issues.
Thank you,

--Bruce

> Mouli
>
>
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

---

From: john parello <[email-masked]>
Date: Mon, 08 Nov 2010 21:27:09 -0800

Hi William,

Looking forward to meeting you at the session!

I agree with your comments especially w.r.t to the power usage over 
time. For the implementation that I have of power monitoring I have been 
getting requests for the historical tracking on devices from both device 
manufacturers and NMS vendors.

Especially PDU manufacturers who have this capability but have no 
standard/common way of reporting it.

If you look at the optional historical power reporting in 
draft-claise-energy-monitoring-mib-05 you'll see that we have modeled it 
based upon the existing standards and with input from power meter and 
control manufacturers.

See you at the session!
John

On 11/7/10 8:51 PM, Mielke, William F (Bill) wrote:
> Email:<mailto:[email-masked]>  [email-masked]
> Phone: 614 367 5628
> Fax: 614 367 5965
>
> <<  warning: long email>>

---

From: john parello <[email-masked]>
Date: Mon, 08 Nov 2010 21:35:18 -0800

Hi Chris,

Thanks for the replies I agree with your assessments as well. Also with 
respect to initial products I think we are past that.

Both you and I have products which deliver the features that Bruce is 
talking about. So I think we are past initial product and down to 
setting common data modeling between them.

What we need is the common standard that we have expressed in the drafts.

w.r.t to the power domain the metering domain described in both

draft-claise-power-management-arch-02

and

draft-parello-eman-energy-aware-mib-00

have the flexibility to be specified based upon the physical metered 
topology but with the context information and tagging the different 
aggregation and reporting you asked for can be obtained.

This is very much analogous to what we do in IP networking with physical 
topology versus vlan etc.

Thanks
Jp

---

From: john parello <[email-masked]>
Date: Mon, 08 Nov 2010 22:13:16 -0800

Hi Bruce,

Thanks for the feedback on the framework draft. I think in general I'm 
pleased with the draft since after going through your proposed changes 
my inner voice kept saying - that's covered, that's covered.

I think since this is a new group there's a bit of terminology that we 
are familiar with since the drafts have been in the OPSAWG for a year 
now. So we've converged on terms.

See inline and I think you'll see we are all seeing the same elephant...

(some deletia for readability)

On 11/7/10 3:09 PM, Bruce Nordman wrote:
<deletia>
> and cannot be aggregated.  Power level (W) and energy use can be

[jp] As we discussed I'd agree the state transitions are up to the 
manufacturer/implementer. Having deployed the concept of levels we've 
had a better acceptance with levels versus state transitions. I think 
the issue we are dancing around is that other standards use the term 
STATE like the DMTF and we need to reconcile with that.

> the more basic work, particularly if the content was in separate I-Ds.

[jp] See prior emails. We have a large contingency of folks that have 
specifically asked and implement this type of interval. Having a 
standard way to report that will help us all.

> or rely on a power proxy to do this.

[jp] I don't see any difference between Power Device or the term Power 
Monitor we defined.

> and/or downstream power loads (other devices; a battery that is charging

[jp] I disagree with your use of "most". That's relative. That depends 
on who you talk to and context.  I'll take a leap here but I think you 
are referring to consumer devices. If you ask a data center admin he 
would say most devices run DC, have multiple power sources. We've seen 
data centers where all devices had batteries.

> makes a device complex I am not sure.

[jp] Any solution should not hinder the simple path and I think we do 
that wrt to parent child and simple, short variables for context and 
reusing existing known standards in the space.

> on their own power/energy status.

[jp] I think what you are trying to grok here is our notion of Parent 
and Child. We specifically used the term Parent/Child to refer to a 
generic type. I think what you are confusing is an "is type of" versus 
"is capable of" relation ship.

In our implementation we specifically desired type to be Parent and 
things like ability to proxy for a device to be a capability.

In network management we deal with this a lot. Is a a device a switch an 
power distribution unit or router. Or are those capabilities. Think 
about a PoE switch and you'll see what we are talking about.

So in general I don't like the term Proxy for classifying a device as 
that's more a capability.

The good thing is is that we cover this concept.

> (perhaps always) be implemented by a Power Distributor, but proxying a

[jp] again capability versus type

> powering (consequently same domain), not powering (but same domain).

[jp] The notion of "in a domain" versus regrouping and categorization is 
something we have dealt with in network management for along time. Think 
of physical topology, SNMP domains etc. Our use of a Power Monitor 
domain covers this and your reclassification can be done with our notion 
of keywords which allow for regrouping.

> more than one power source, and may include a battery.

[jp] Again get familiar with is type of versus is capable of. There is 
no clear line between a power distributor. Recall my example of a PoE 
switch. From a power management point of view it's simple a Ethernet 
based PDU.
> flows are either sources into a device, or sinks out of it).

[jp] Not sure what you mean here.
> power (ignoring batteries), but this may not be required.

[jp] Again most is relevant to context

> a single source of power; later we could relax that requirement.

[jp] For this we are in agreement. In fact our deployments of this 
architecture we suggest mapping the data network to the power 
distribution network and assume the same source of power for all devices 
in a domain. Lets get experience with this and then move on to the more 
complex.

> It may be in the same power domain, or not.
[jp] I think the reason we don't call this our specifically is that is 
taken as a given here amongst most members of the IETF that work on 
SNMP. This would be the management station (NMS) and/or more 
specifically the EMS.

> will report its own (net) consumption, and may implement proxies that

[jp] I don't think you can make that assumption as devices will have 
multiple capabilities.

> be queried more often than the domain of devices powered by that switch.

[jp] again I think we cover this in the parent child aggregation

> today’s meters don’t have direct knowledge of what they are providing power

[jp] We do have the notion of meter in the energy aware mib. Also more 
devices will be considered meters wrt to their end devices. Take for 
example a PDU. It is a power distributr but it is also a meter for the 
device that is connected to it. Your last assumption on not knowing what 
is connected does not apply to all devices. A PoE switch for example is 
a switch, a power distributer and a meter for the attached devices and 
very much knows what is connected via LLDP/CDP etc.

> commonly, the measurement is done at only one end so just needs to have a

[jp] My opinion on wire loss is that it need not be specifically 
accounted for. In general we are estimating power breakdowns that will 
correlate to sub meters. Once you account for inaccuracy of reporting 
and have to handle error you can account for line loss. In general we've 
found that the slopes of the curves of power usage once aggregate are 
enough to correlate to actual readings from the source.
> Because control and intervals are not implemented, communication is only

[jp] It seem like you have a specific system in mind here. Can you site 
an implementation or working example. Without that I don't think we can 
converge on the above.

> building.  A vehicle is a building on wheels (and always its own domain).

[jp] again common is relative. DC in the datacenter :)

> of a price within a building or a domain.

[jp] We should have a longer discussion on price. I think for our group 
we are taking a a more global view and can't assume price is the common 
control point. you mention price as the control and also want to defer 
control so I'm not sure where to take this.

In general my option on price is that it's constraint just like CO2e or 
perhaps business need. Why it would be used as a control mechanism is a 
topic we should discuss. Would price be fed to a device when an operator 
wants to shut if off for maintenance?

Also price is not applicable in every country. Our host country this 
year for example has a yearly fee for some buildings and control is 
arbitrary not based on price but on messages sent to facility managers.

In general thanks for the review and I think with a bit more discussion 
we can converge. I see nothing that would amend our current draft.

Thanks!
Jp

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 9 Nov 2010 07:08:32 -0800

Hi John,

We may be a little off on our interpretations of the ideal data model.  I hope you'll bear with me as we try to come to an understanding on it.

I agree that both of the proposed MIB sets have all of the information needed -- "in some way".  What I'm arguing is, with respect, they may not have the ideal structure to represent this information quite yet.

The current structure proposed in ENERGY-AWARE-MIB couples the definition of the power management entity with its network management data (domain, keywords, role) fairly tightly.  This kind of "high cohesion" is notoriously bad for complex systems that need to evolve over time.  Perhaps I'm making an assumption here, but wouldn't it be fair to state that our understanding of managing energy via networks will continue to change over the next decade?

All I'm proposing is breaking the existing MIB set apart into more of a "low cohesion" pattern.  Like with objects modeled using CRC cards [1] from object oriented programming, each MIB/table should have a clearly defined set of roles and responsibilities:

·         ENTITY-AWARE-MIB

o    pmEntityTable

§  Superclass: None

§  Responsibilities: List all "energy-aware" devices/components/etc. of the SNMP agent that are available

§  Collaborations: pmNetworkMgmtTable

o    pmNetworkMgmtTable

§  Superclass: pmEntityTable

§  Responsibilities: Provide network management attributes for modeling an energy-aware entity's relationship to the physical infrastructure, other logical devices, business-case groupings, etc.

§  Collaborations: pmEntityTable

o    pmEntityPhysicalMapTable

§  Superclass: None

§  Responsibilities: Map the entries in pmEntityTable with entPhysicalTable (ENTITY-MIB)

§  Collaborations: pmEntityTable, entPhysicalTable

o    pmEntityLogicalMapTable

§  Superclass: None

§  Responsibilities: Map the entries in pmEntityTable with entLogicalTable (ENTITY-MIB)

§  Collaborations: pmEntityTable, entLogicalTable

o    ...

·         ...

(I'm using this pattern because it comes across visually in an e-mail, but effectively the IETF RFC's do the same thing in their textual descriptions of each of the components.)

Currently, pmEntityTable and pmNetworkMgmtTable and pmEntityPhysicalMapTable from above are all glued together into a single pmTable in ENTITY-MIB.  Yet as you can see from above, they all accomplish various different things.  If we split them into three separate tables, not only is it clearer in terms of understanding, but it also helps when the EMAN WG decides (for example) 2 years from now to introduce some new "Smart Grid" integration schema that NIST is pushing.  Changes become more isolated to a handful of tables rather than impacting the core pmEntityTable, upon which a lot else will be built.

Thanks,

Chris

[1] http://en.wikipedia.org/wiki/CRC_cards

-----Original Message-----
From: john parello [mailto:[email-masked]] 
Sent: Monday, November 08, 2010 9:35 PM
To: Chris Verges
Cc: [email-masked]
Subject: Re: [eman] Proposed alternation of framework

Hi Chris,

Thanks for the replies I agree with your assessments as well. Also with respect to initial products I think we are past that.

Both you and I have products which deliver the features that Bruce is talking about. So I think we are past initial product and down to setting common data modeling between them.

and

have the flexibility to be specified based upon the physical metered topology but with the context information and tagging the different aggregation and reporting you asked for can be obtained.

This is very much analogous to what we do in IP networking with physical topology versus vlan etc.

Thanks

Jp

> device and cannot be aggregated.  Power level (W) and energy use can 

> be readily aggregated.

> [CV] With respect, I think power state can be aggregated.  For 

> example, please consider a standard datacenter.  When all servers are 

> turned on in the datacenter, it is at 100% "on" state.  If 30% of the 

> servers are turned off, the datacenter's state has reduced to 70%.  

> This is fairly congruous with the ACPI model, where a server can be in 

> different states, and each state represents a power usage level.

> [CV] How such aggregated state is determined is beyond the scope of 

> any MIB, but the ability to report such information can offer a hook 

> for innovation in the industry.

> pushed off to a later release, as enumerating the entities themselves 

> is far more critical (core?) to establishing anything more complex.

> [BN] There are a number of complications that I would propose 

> deferring from our initial product.  These include transition states, 

> support for

> mean any logical grouping of power entities.  The mapping between 

> power domains and power entities can be many-to-many, not just one-to-many.

> If the MIB model only handles a 1:N mapping, the administrator needs 

> to choose only one.  If the MIB model handles a M:N mapping, more 

> complex and useful systems can be built on top of this schema.

> [email-masked] <mailto:[email-masked]> 

> https://www.ietf.org/mailman/listinfo/eman <https://www.ietf.org/mailman/listinfo/eman>