Subject: [eman] new revision of eman requirements

From: Juergen Quittek <[email-masked]>
Date: Tue, 12 Jul 2011 09:00:39 +0000

Dear all,

I posted a new version of the eman requirements yesterday.
Please find it at 
http://datatracker.ietf.org/doc/draft-ietf-eman-requirements/

All changes applied are based on comments on the mailing list on the
previous version that was posted two weeks ago.

Many thanks to all who read the draft and made comments on the mailing list.

Since I could not solve all issues raised on the mailing list, out list of
open issues has become longer and has 18 entries. You'll find them in
section 12 of the draft.

I would like you to particularly provide your input on the following open
issues:

(12.2) Do we have a requirement for high/low power notifications?
   I think we don't.

(12.3) Power and energy time series?
   Currently the draft states requirements for reporting time series
   of power and energy values.
     - Do we really need both?
     - Do we need just one? If yes, which one?
         -- IF I had to choose one, I would pick energy values.
     - Or is there no real requirement for time series
       stored in MiB variables?
          -- This concept is rarely applied to monitoring of
             other MIB variables, for example, packet numbers
             at IP interfaces.

(12.5) Aggregation functions
   Are there requirements on aggregation?
   Which are they?
      Georgios already commented on that on the list.
      I did not have enough time to digest his input

(12.6) Add a definition of 'demand'
   I got controversial comments on this issue. Some say
   we need to have requirements for reporting demand.
   Others say just reporting power over time intervals is sufficient.

(12.11) Shall we add a new power state 'disconnected from power'?

(12.12) Shall we remove the power state 'reduced power'

(12.14) Do we need entity types?
   Entity are requested by requirement 5.1.1. there were controversial
   opinions on the mailing list on whether or not the entity type
   should be removed from the requirements. The entity type would assign
   a type to a device or entity, such as "switch", "host", "display",
   "desktop phone", "light bulb", etc.

(12.16) Is there a need for metering power supply impedance?
   currently we have a requirement for providing means to report the
   impedance of a power source (requirement 5.4.9). Do we really need this?

Of course, feel free to also comment on the other open issues or to raise
new ones. All such contributions are highly appreciated.

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 13 Jul 2011 07:28:29 -0500

Regarding the Time Series debate - the crucial question - where is the
data / measurements stored. 
It would not be possible for small devices to store such data for a
sufficiently long time period. 

The NMS can store the values for a sufficiently long period of time, for
trending analysis. 

In the case of demand measurement, since the maximum over a window is
computed, it is important for the device store atleast a window length
of measurements. 

I am not sure about that Requirement 5.4.10 - Time Series of Power
Values - to be stored in the device

Thanks
Mouli

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Tuesday, July 12, 2011 2:31 PM
To: eman mailing list
Subject: [eman] new revision of eman requirements

Dear all,

Of course, feel free to also comment on the other open issues or to
raise
new ones. All such contributions are highly appreciated.

Thanks,

    Juergen

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

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 13 Jul 2011 07:52:16 -0500

I think the intent of requirement 5.1.1 should be simple. 

There is an entity to be monitored; it is possible to identify the
device with a number/index.
Secondly, it is also possible to describe what the device is - user
defined string - along the lines of
RFC 4133 - entPhysicalDescr . 

Grouping of entities is not related to this requirement, I think. 

Thanks
Mouli

-----Original Message-----

Dear all,

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 13 Jul 2011 14:52:54 +0200

Dear Mouli,

Thank you for commenting on this issue. I would like to have a look at the following point of view:

So far, storing time series of measurements on managed nodes is rarely standardized and rarely available as implementation.

Typically, it is the job of a network management system to collect time series and store them.

Take for example byte and packet counters at line cards. You see many curves showing time series of traffic rate/volume in the Internet, but almost all of them were collected at management stations or data collector modules, but not within MIB modules. (Please correct me if I'm wrong.) 

Now the question is: Is energy management so much different from other network management tasks, that we need the rarely used mechanism of storing time series in MIB modules?

If not, it would be sufficient to just report the number of total energy consumed since the last re-start as you do it with packet and byte counters.
This would be just a single managed object to be specified and implemented.

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 13 Jul 2011 08:01:28 -0500

Hi Juergen,

I think some of the requirements 5.4.9 (impendence) 5.4.8 (total
harmonic distortion) should be left as optional for implementation. 

Whereas Total Power, Active Power, Reactive Power, Power Factor seem to
be of interest and thus requirements for those parameters. 

Thanks
Mouli

-----Original Message-----

Dear all,

(12.16) Is there a need for metering power supply impedance?
   currently we have a requirement for providing means to report the
   impedance of a power source (requirement 5.4.9). Do we really need
this?

Thanks,

    Juergen

---

From: Michael Suchoff <[email-masked]>
Date: Wed, 13 Jul 2011 10:18:41 -0400

Dear Juergen,

The larger manufacturers of managed power distribution equipment (APC,
Eaton, Raritan...) all provide circular buffers of time stamped power
measurements.  Certification of our products for use with IBM System
Director required this as well.

The better products allow the polling interval to be specified and provide
ability for events (under currents, circuit breaker trips, etc.) to be
reported as traps.

Our larger data center customers wanted this feature too as they realized
polling thousands of devices minute by minute was inefficient and can yield
unacceptable timing uncertainty.

Our products are able to report accurate measurements - accuracy being
defined as how close do two or more devices agree with a calibrated
reference meter when measuring the same quantity.  This cannot be achieved
without considering time.

On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek <[email-masked]> wrote:

> So far, storing time series of measurements on managed nodes is rarely
> standardized and rarely available as implementation.
>
> Take for example byte and packet counters at line cards. You see many
> curves showing time series of traffic rate/volume in the Internet, but
> almost all of them were collected at management stations or data collector
> modules, but not within MIB modules. (Please correct me if I'm wrong.)
>
> Now the question is: Is energy management so much different from other
> network management tasks, that we need the rarely used mechanism of storing
> time series in MIB modules?
>
> If not, it would be sufficient to just report the number of total energy
> consumed since the last re-start as you do it with packet and byte counters.

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 13 Jul 2011 18:33:47 +0000

Hi Mouli,

As stated in the requirements abstract and introduction, the requirements
are about what needs to be covered by the standard, not what in the standard
should be REQUIRED, RECOMMENDED or OPTIONAL to be implemented by compliant
implementations. We will have this discussion when we do the compliance
sections of the MIB modules.

Thanks,

    Juergen

---

From: "Michael Suchoff" <[email-masked]>
Date: Wed, 13 Jul 2011 14:49:50 -0400

I'm not aware of any products that measure impedance of AC power line,
nor how a device could measure it, nor of what use it is for the
intended users of this MIB.

Why was this measurement chosen, as apposed to others more useful like
inrush current, displacement power factor, crest factor, sag, surge,
etc?

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Wednesday, July 13, 2011 2:34 PM
To: Mouli Chandramouli (moulchan); eman mailing list
Subject: Re: [eman] new revision of eman requirements - Open Issue -
12.16

Hi Mouli,

As stated in the requirements abstract and introduction, the
requirements
are about what needs to be covered by the standard, not what in the
standard
should be REQUIRED, RECOMMENDED or OPTIONAL to be implemented by
compliant
implementations. We will have this discussion when we do the compliance
sections of the MIB modules.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Thu, 14 Jul 2011 01:31:18 +0200

Hi Michael,

I highly appreciate your contributions.
Please see comments inline.

> intended users of this MIB.

Well, I think it was taken from the IEC references used so far.
But I do not yet have a copy of them. If you convince the WG it is of no use in our scenarios 
I will gladly remove it. Removing unnecessary complexity is a wonderful thing to do.

> inrush current, displacement power factor, crest factor, sag, surge,

Now you are going for increased complexity ;-)

Do you think of measuring inrush current or would you rather like to see a fixed value specified by the manufacturer?
I haven't been dealing much with inrush current, but as far as I remember it may vary significantly depending on the exact point in time you switch power on and it also depends significantly on the electric switch that you use.

We already have the power factor in requirement 5.4.5.

Is the crest factor really varying significantly in for AC powered systems?
It certainly varies if you use phase cutting. But then I wonder if the crest factor is what you want to measure.

Wouldn't sag be covered by voltage measurements? We have this in requirement 5.4.6.
The same would probably hold for surge. Or are you looking for recording sag or surge events?

Thanks,

    Juergen

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 13 Jul 2011 21:44:03 -0700

I can't speak for other domains, but for energy efficiency,
power factor covers the vast majority of interest in power
quality.  I agree that impedance seems unwarranted.
--Bruce

On Wed, Jul 13, 2011 at 11:49 AM, Michael Suchoff <
[email-masked]> wrote:

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

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Mon, 25 Jul 2011 15:01:31 -0500

I believe that it is very important for devices to maintain and report a (limited amount of) time series data for the energy and power related values.  This is needed to reasonably support a pull model for such information.  An NMS cannot poll individual devices with sufficiently accurate timing to collect and maintain this information on its own.  This is especially true as the NMS tries to scale up to a large number of devices and when the communications between the NMS and the device is subject to congestion and outages.

I think that the primary issue at play here is that the desired measurement interval (1 sec up to 1 min?) is likely shorter than the typical NMS polling interval (1 min up to 1 day?).  So the collection of the time series data must be delegated to the device and it must be retained there for a sufficiently long time that the NMS can be reasonably expected to be able to collect it on its next polling interval.

I believe that existing devices such as Smart PDUs already collect and maintain time series measurements and retain them in just this manner and for just this purpose.

William F. Mielke
Alcatel-Lucent
Distinguished Member of Technical Staff
6200 East Broad Street
Room: 4B01-1V
Columbus, OH  43213-1530
Email: [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 Juergen Quittek
> Sent: Wednesday, July 13, 2011 8:53 AM
> To: Mouli Chandramouli (moulchan)
> Cc: eman mailing list
> Subject: Re: [eman] new revision of eman requirements - open 
> issue 12.3: time series of energy/power values
> 
> Dear Mouli,
> 
> So far, storing time series of measurements on managed nodes 
> is rarely standardized and rarely available as implementation.
> 
> Take for example byte and packet counters at line cards. You 
> see many curves showing time series of traffic rate/volume in 
> the Internet, but almost all of them were collected at 
> management stations or data collector modules, but not within 
> MIB modules. (Please correct me if I'm wrong.) 
> 
> Now the question is: Is energy management so much different 
> from other network management tasks, that we need the rarely 
> used mechanism of storing time series in MIB modules?
> 
> If not, it would be sufficient to just report the number of 
> total energy consumed since the last re-start as you do it 
> with packet and byte counters.

---

From: Benoit Claise <[email-masked]>
Date: Mon, 25 Jul 2011 22:45:53 -0400

Dear Michael,

This is exactly what's available in the EMAN monitoring MIB for the energy
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09, 
section 5.5

Regards, Benoit
> The better products allow the polling interval to be specified and 
> provide ability for events (under currents, circuit breaker trips, 
> etc.) to be reported as traps.
>
> Our larger data center customers wanted this feature too as they 
> realized polling thousands of devices minute by minute was inefficient 
> and can yield unacceptable timing uncertainty.
>
> reference meter when measuring the same quantity.  This cannot be 
> achieved without considering time.
>
> On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Dear Mouli,
>
>     So far, storing time series of measurements on managed nodes is
>     rarely standardized and rarely available as implementation.
>
>     Take for example byte and packet counters at line cards. You see
>     many curves showing time series of traffic rate/volume in the
>     Internet, but almost all of them were collected at management
>     stations or data collector modules, but not within MIB modules.
>     (Please correct me if I'm wrong.)
>
>     Now the question is: Is energy management so much different from
>     other network management tasks, that we need the rarely used
>     mechanism of storing time series in MIB modules?
>
>     If not, it would be sufficient to just report the number of total
>     energy consumed since the last re-start as you do it with packet
>     and byte counters.
>     > From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>     Behalf Of
>     > Juergen Quittek
>     > [email-masked] <mailto:[email-masked]>
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "Michael Suchoff" <[email-masked]>
Date: Tue, 26 Jul 2011 11:07:02 -0400

Benoit,

I've looked over section 5.5 of the EMAN MIB and it is not how existing
products I'm familiar with work.

First, products that can accurately report energy (IEC 62053-21 energy
meters, smart PDUs that use special purpose energy measuring ICs, etc.)
do not derive energy by periodically polling a power measurement with a
pmEnergyParametersSampleRate.  In other words, energy in not derived
from the power measurement by multiplying by time (E = watts * time =
inaccurate energy measurement).  Rather, energy (E) is measured to the
product's certified IEC 62053-21 accuracy class and then the power
measurement is derived by dividing by time (power = dE/dt = energy /
time = accurate power measurement).

Second, products that report time series report all measurements
(voltage, current, power, energy) and can report intermediate
measurements using traps when values exceeding thresholds or state
changes occur.

Third, section 5.5 of MIB appears to be an attempt to have agent perform
programmable demand interval calculations.  This seems overly
complicated and places an unnecessary computational burden on the agent.
Existing products with time series simply report accurately time stamped
measurements.  The burden of computing demand interval (and other
analytics and what-ifs) is placed on the energy management program.

________________________________

From: Benoit Claise [mailto:[email-masked]] 
Sent: Monday, July 25, 2011 10:46 PM
To: Michael Suchoff
Cc: Juergen Quittek; eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:
time series of energy/power values

Dear Michael,

This is exactly what's available in the EMAN monitoring MIB for the
energy
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09,
section 5.5

Regards, Benoit

Dear Juergen,

The better products allow the polling interval to be specified and
provide ability for events (under currents, circuit breaker trips, etc.)
to be reported as traps.

On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek <[email-masked]>
wrote:

Dear Mouli,

Thank you for commenting on this issue. I would like to have a look at
the following point of view:

Typically, it is the job of a network management system to collect time
series and store them.

Take for example byte and packet counters at line cards. You see many
curves showing time series of traffic rate/volume in the Internet, but
almost all of them were collected at management stations or data
collector modules, but not within MIB modules. (Please correct me if I'm
wrong.)

Now the question is: Is energy management so much different from other
network management tasks, that we need the rarely used mechanism of
storing time series in MIB modules?

If not, it would be sufficient to just report the number of total energy
consumed since the last re-start as you do it with packet and byte
counters.
This would be just a single managed object to be specified and
implemented.

Thanks,

   Juergen

---

From: "Michael Suchoff" <[email-masked]>
Date: Tue, 26 Jul 2011 11:53:14 -0400

Bill,

I agree with you.  Our Smart PDUs (as well as Eaton's and APC's) use
fixed size circular buffers to store measurements.  Circular buffers
work with the limited memory space of embedded devices as well as the
limitations of SNMP tables.  An SNMP variable is available which
indicates index of most recent write into buffer.  By keeping track of
this variable, a manager can determine how many new entries have been
written into the buffer since the last poll and the new entries can
efficiently be retrieved using get-bulk.

Our present buffer size is 120 and the typical measurement interval is 1
minute.  Values for each measurement include the min, max and average
value that occurred during the measurement interval. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Monday, July 25, 2011 4:02 PM
To: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue12.3:
time series of energy/power values

I believe that it is very important for devices to maintain and report a
(limited amount of) time series data for the energy and power related
values.  This is needed to reasonably support a pull model for such
information.  An NMS cannot poll individual devices with sufficiently
accurate timing to collect and maintain this information on its own.
This is especially true as the NMS tries to scale up to a large number
of devices and when the communications between the NMS and the device is
subject to congestion and outages.

I think that the primary issue at play here is that the desired
measurement interval (1 sec up to 1 min?) is likely shorter than the
typical NMS polling interval (1 min up to 1 day?).  So the collection of
the time series data must be delegated to the device and it must be
retained there for a sufficiently long time that the NMS can be
reasonably expected to be able to collect it on its next polling
interval.

I believe that existing devices such as Smart PDUs already collect and
maintain time series measurements and retain them in just this manner
and for just this purpose.

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 26 Jul 2011 12:31:51 -0400

Dear all,

I think we are all in line with the statements made on the mailing list.

However, so far we haven't addressed the open issue as stated in the requirements draft:

> 12.3.  Power and energy time series?
> 
>    We have requirements for reporting of time series of power and energy
>    values.  Do we need both or just one of them?  If just one, then
>    which one?
Requirement 5.4.10 asks for time series of power values and requirement 5.5.4 asks for time series of energy values. Do we need both of them?

A second question would be: Do we need them to be exported by SNMP or rather by IPFIX or by both?

    Juergen

Am 25.07.2011 um 22:45 schrieb Benoit Claise:

> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-09, section 5.5
> 
> Regards, Benoit
>> Dear Juergen,
>> 
>> The larger manufacturers of managed power distribution equipment (APC, Eaton, Raritan...) all provide circular buffers of time stamped power measurements.  Certification of our products for use with IBM System Director required this as well.
>> 
>> The better products allow the polling interval to be specified and provide ability for events (under currents, circuit breaker trips, etc.) to be reported as traps.
>> 
>> Our larger data center customers wanted this feature too as they realized polling thousands of devices minute by minute was inefficient and can yield unacceptable timing uncertainty.
>> 
>> Our products are able to report accurate measurements - accuracy being defined as how close do two or more devices agree with a calibrated reference meter when measuring the same quantity.  This cannot be achieved without considering time.
>>

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 26 Jul 2011 12:00:05 -0500

I believe that we should be reporting both energy and power.  Given Michael Suchoff's comments thus far and based on my own experience the actual measurements are typically (frequently?) provided by specialized metering chips to insure accuracy.  We should seek to preserve this accuracy by reporting all of the commonly monitored values for each measurement interval and delegate to the device how best to collect the actual data.  I am assuming that Min, Max, and Average values for the various parameters will be readily available on the device so it should not be a large overhead to keep them.

Since some devices may be estimating rather than measuring these values the table needs to provide a means of identifying which it is reporting.  It is not clear to me whether this indication needs to be provided per field, per tabular row, or per device.  Thoughts from others?

I also think that we need to take care to generalize things a bit to allow the devices to report parameters such as their reporting interval and the size of their on-board history cache.  In some cases these values may be determined statically by the device (and may vary from vendor to vendor), but we should also provide a means for configuring these parameters as well for the devices which seek to be more flexible.

On the issue of Push vs. Pull models I suppose that each device manufacturer should be free to decide whether they want to support both, or just one of the two, so we need to clearly identify which combinations are required.  From my perspective a compliant device needs to be able to support either one or both methods, but that supporting neither is not really a valid choice.  This is just my opinion though.

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

    - Albert Einstein

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Juergen Quittek
Sent: Tuesday, July 26, 2011 12:32 PM
To: Benoit Claise
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3: time series of energy/power values

Dear all,

    Juergen

Dear Michael,

Regards, Benoit
Dear Juergen,

On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek <[email-masked]<mailto:[email-masked]>> wrote:
Dear Mouli,

Thanks,

   Juergen

Am 13.07.2011 um 14:28 schrieb Mouli Chandramouli (moulchan):

> From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of
> Juergen Quittek
> [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

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

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

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 26 Jul 2011 10:08:26 -0700

Hi Jeurgen,

I tend to agree, for simple devices an energy odometer(s) as describe
from the comments and what I presented from the ODVA suffices.

For time series of data like historical demand devices such as PDUs very
typically store this. Some our as long as a year's worth of data on the
device. For the very reason that Bill pointed out.

So it would seem that a power value and an energy odometer could be a
required minimum and then time series of power or demand can be
optional. 

We specified a power value as required in the monitoring mib with time
series of power and demand as optional.

Jp

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Wednesday, July 13, 2011 5:53 AM
To: Mouli Chandramouli (moulchan)
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue
12.3:time series of energy/power values

Dear Mouli,

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 26 Jul 2011 15:39:04 -0400

Hi John,

We are currently not discussing optional or mandatory implementation.

The question is whether or not we have a requirement for specifying a standard for reporting both, energy time series and power time series, or just one of them. What compliant devices must implement is an issue to be discussed later.

Do I understand right that you would support a requirement for specifying a standard for time series of power but not for time series of energy?

Thanks,

    Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 26 Jul 2011 15:10:07 -0700

Hi Jeurgen,

We need to express power, energy as a measurement (scalar).

For time series (vector) IMO having the capability of providing power over time series (which is demand) or energy over time is valuable and should not be excluded.  Even though for energy an odometer can suffice I see no need to prevent this for devices that have this capability.

Please take a look at the draft-claise-energy-monitoring-mib.  I think they did a good job of providing time series modeling that covers this.

thanks
Jp

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Tue 7/26/2011 12:39 PM
To: John Parello (jparello)
Cc: Mouli Chandramouli (moulchan); eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
 
Hi John,

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 26 Jul 2011 22:59:36 -0500

Hi Juergen,

The requirement of corresponding outlet does not seem clear to me. 

Does every device or component of the device (in the scope of EMAN) have
a corresponding outlet ? 
Secondly, it would be useful to understand if this requirement would
help in solving a Energy monitoring problem. 
It is not apparent to me. 

In fact, IMHO, the entire section - 5.3. Power inlet and power outlet -
while some requirements may be useful, it may be useful to reexamine and
double check some of the requirements. 

Thanks
Mouli

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 26 Jul 2011 23:07:06 -0500

Hi Juergen,

The requirement 5.4.2 of Power measurement interval needs to be
revisited. 

There is a good discussion on the mailing list on what is instantaneous
power. 

I presume, the power meter chip set shall make power measurements based
on "some" sampling scheme over a fixed interval. 
But this sampling scheme would not change for measurement collected
every 10 minutes or so. 

So, should this value be reported for every power measurement ?  

Thanks
Mouli

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 26 Jul 2011 23:10:44 -0500

The requirement title  5.4.3. Confidence in power values

Ccan be rephrased as 5.4.3. Measurement method 

to be actual or estimated or unknown ...

Thanks
Mouli

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 26 Jul 2011 23:16:02 -0500

Hi Juergen,

Requirement 7.2. Identity of other powered entities on which is reported

Focuses on the Parent having knowledge of the children. 

It is also useful to add a requirement - in the other direction also. 

The energy management standard must provide means for specifying the
identity of the powered entity 
Which shall monitor and report the power consumption of a given powered
entity.

Thanks
Mouli

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Jul 2011 09:29:12 -0400

Hi Mouli,

> Does every device or component of the device (in the scope of EMAN) have

Most devices will have a power inlet except they live from energy harvesting.
Only a minority of the devices will have power outlets. Examples are power distribution units (PDUs) or PoE switches. 

The requirement states that the standard we are developing must provide means for devices with power outlets to report power measured at their outlets. Obviously only devices capable of measuring power at their outlets can implement it.

Would you challenge this requirement?

> It is not apparent to me. 

Why would you think it is useless providing a power distribution unit means to report power that it delivers at its power outlets? I think this is essential for energy monitoring.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Jul 2011 09:42:55 -0400

Dear Mouli,

> So, should this value be reported for every power measurement ?  

No, of course not. This would be useless information in cases 
where the interval would be constant.

But I do not see what problem you would have with requirement 5.4.2:

> 5.4.2.  Power measurement interval
> 
>    The energy management standard must provide means for reporting the
>    corresponding time or time interval for which a power value is
>    reported.  The power value can be measured at the corresponding time
>    or averaged over the corresponding time interval.
This says that for power measurements you must be able to either report the time of the measurement or the interval over which you measured power.

Reporting just the time of measurement may not 100% precise, because for AC you would average over at least half a power cycle. But for energy management just reporting one time value should be sufficiently precise.

If you measure power over a longer time interval, for example, if you want to report demand then it is useful to be able to report the time interval for which you report power. Of course, this can be done in different ways. You can always report two time stamps (start and stop), or if you have a fixed interval length it is enough to report just one of them (start or stop time). And certainly there are more ways to do so.

What is wrong about this requirement?

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Jul 2011 09:44:00 -0400

Hi Mouli,

I agree. This is a good alternative title for this requirement.

Thanks,

    Juergen

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Jul 2011 09:51:22 -0400

Hi Mouli,

All that you miss is in requirement 7.6.

Thanks,

    Juergen

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 27 Jul 2011 08:55:08 -0500

Hi Juergen,

If you take a step back, it would be useful to monitor information
(using SNMP, ...)  that is dynamic which changes over time. 

Some of the parameters in my view are so constant (unless the metering
mechanism changes) and  I would presume would never change such as the
power measurement interval.

>From a MIB module point of view, adding "nearly constant" variables
might add to MIB walk time of the table ?

Thanks
Mouli

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 9:43 AM
To: Mouli Chandramouli (moulchan)
Cc: Juergen Quittek; eman mailing list
Subject: Re: [eman] new revision of eman requirements - Requirement
5.4.2

Dear Mouli,

>    or averaged over the corresponding time interval.
This says that for power measurements you must be able to either report
the time of the measurement or the interval over which you measured
power.

Reporting just the time of measurement may not 100% precise, because for
AC you would average over at least half a power cycle. But for energy
management just reporting one time value should be sufficiently precise.

If you measure power over a longer time interval, for example, if you
want to report demand then it is useful to be able to report the time
interval for which you report power. Of course, this can be done in
different ways. You can always report two time stamps (start and stop),
or if you have a fixed interval length it is enough to report just one
of them (start or stop time). And certainly there are more ways to do
so.

Thanks,

    Juergen

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 27 Jul 2011 16:00:54 +0200

> might add to MIB walk time of the table ?

Blindly walking complete tables or subtrees is in general not a
particularly smart implementation strategy for anything that wants to
be efficient and scale and play nice with additions that can happen
over time.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 27 Jul 2011 10:09:10 -0400

I have also wondered about near-constant variables.
How about identifying a group of these and put a time
stamp on the last time any of them changed.  That
way on each reading of energy/power data, just the
one time stamp needs to be reported and if it is not
what the NMS has, it knows it needs to re-request the
nearly-constant data, but otherwise it knows that none
of these have changed.

An example of this is the set of devices downstream of
a PoE switch or PDU  Adding or removing a device from
the list would trigger an update of this timestamp.
Adding or removing a component (if components are
modeled) would similarly trigger an update.

--Bruce

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Jul 2011 14:13:34 +0000

Hi John,

my Question was 

"Do I understand right that you would support a requirement for specifying
a standard for time series of power but not for time series of energy?"

I take you answer as a no. This would mean we keep both requirements (time
series of power and time series of energy). Is this correct?

Thanks,

    Juergen

On 26.07.11 18:10, "John Parello (jparello)" <[email-masked]> wrote:

>For time series (vector) IMO having the capability of providing power
>over time series (which is demand) or energy over time is valuable and
>should not be excluded.  Even though for energy an odometer can suffice I
>see no need to prevent this for devices that have this capability.
>
>
>Please take a look at the draft-claise-energy-monitoring-mib.  I think
>they did a good job of providing time series modeling that covers this.
>
>thanks
>Jp
>
>
>
>
>
>
>
>
>The question is whether or not we have a requirement for specifying a
>standard for reporting both, energy time series and power time series, or
>just one of them. What compliant devices must implement is an issue to be
>discussed later.
>
>Do I understand right that you would support a requirement for specifying
>a standard for time series of power but not for time series of energy?
>
>Thanks,
>
>    Juergen
>

---

From: Juergen Quittek <[email-masked]>
Date: Wed, 27 Jul 2011 10:34:47 -0400

Hi Mouli,

I am not sure if I get you right.
I did not talk about any MIB variables.
You asked me to take a step back.
Now I ask you to do the same thing.
Let's not look at MIB variables:

If you report power, would it be useful at all if the management system does not know for which time the power was measured?

Talking about implementations:
If you read a MIB variable "actualPower" then the time is the time of reading and implicitly known to the management system.

If you read a power value from a circular buffer, then for each value you read you must know for which time interval it was measured. This dies not mean you have to read a time stamp for each of them: A possible implementation could be to measure power for constant time intervals: Then you once read the time stamp for the starting time of the first buffered value and then read once the constant interval length and then all the power values in the buffer. A standard defined this way meets requirement 5.4.2. because for each power value the start and stop time has been reported to the management system.

Does this solve your concern?

    Juergen

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 27 Jul 2011 11:17:16 -0700

+1 on this.

We need power, energy and demand as a measured scalar value but there's
no reason to exclude a vector or log of readings if the device can
support it. My experience as well is that the poll periods are too long
for the data desired. Some peak demands can be down to the minute so
some local accumulation is definitely helpful and quite common.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Tuesday, July 26, 2011 10:00 AM
To: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue12.3:
time series of energy/power values

I believe that we should be reporting both energy and power.  Given
Michael Suchoff's comments thus far and based on my own experience the
actual measurements are typically (frequently?) provided by specialized
metering chips to insure accuracy.  We should seek to preserve this
accuracy by reporting all of the commonly monitored values for each
measurement interval and delegate to the device how best to collect the
actual data.  I am assuming that Min, Max, and Average values for the
various parameters will be readily available on the device so it should
not be a large overhead to keep them.

Since some devices may be estimating rather than measuring these values
the table needs to provide a means of identifying which it is reporting.
It is not clear to me whether this indication needs to be provided per
field, per tabular row, or per device.  Thoughts from others?

I also think that we need to take care to generalize things a bit to
allow the devices to report parameters such as their reporting interval
and the size of their on-board history cache.  In some cases these
values may be determined statically by the device (and may vary from
vendor to vendor), but we should also provide a means for configuring
these parameters as well for the devices which seek to be more flexible.

On the issue of Push vs. Pull models I suppose that each device
manufacturer should be free to decide whether they want to support both,
or just one of the two, so we need to clearly identify which
combinations are required.  From my perspective a compliant device needs
to be able to support either one or both methods, but that supporting
neither is not really a valid choice.  This is just my opinion though.

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

Phone: 614 367 5628
Fax: 614 367 5965

    - Albert Einstein 

	Dear all, 

	I think we are all in line with the statements made on the
mailing list.

	However, so far we haven't addressed the open issue as stated in

	>    values.  Do we need both or just one of them?  If just one,
then

	Requirement 5.4.10 asks for time series of power values and
requirement 5.5.4 asks for time series of energy values. Do we need both
of them?

	A second question would be: Do we need them to be exported by
SNMP or rather by IPFIX or by both?

	    Juergen

	

	Dear Michael,
	
	This is exactly what's available in the EMAN monitoring MIB for
the energy

	Regards, Benoit

	Dear Juergen,
	
	The larger manufacturers of managed power distribution equipment
(APC, Eaton, Raritan...) all provide circular buffers of time stamped
power measurements.  Certification of our products for use with IBM
System Director required this as well.
	
	The better products allow the polling interval to be specified
and provide ability for events (under currents, circuit breaker trips,
etc.) to be reported as traps.

	Our products are able to report accurate measurements - accuracy
being defined as how close do two or more devices agree with a
calibrated reference meter when measuring the same quantity.  This
cannot be achieved without considering time.

	On Wed, Jul 13, 2011 at 8:52 AM, Juergen Quittek
<[email-masked]> wrote:

	Dear Mouli,
	
	Thank you for commenting on this issue. I would like to have a
look at the following point of view:

	Typically, it is the job of a network management system to
collect time series and store them.
	
	Take for example byte and packet counters at line cards. You see
many curves showing time series of traffic rate/volume in the Internet,
but almost all of them were collected at management stations or data
collector modules, but not within MIB modules. (Please correct me if I'm
wrong.)
	
	Now the question is: Is energy management so much different from
other network management tasks, that we need the rarely used mechanism
of storing time series in MIB modules?
	
	If not, it would be sufficient to just report the number of
total energy consumed since the last re-start as you do it with packet
and byte counters.
	This would be just a single managed object to be specified and
implemented.
	
	Thanks,
	
	   Juergen

Behalf Of

---

From: "John Parello (jparello)" <[email-masked]>
Date: Thu, 28 Jul 2011 11:05:45 -0700

I can't vote  no when there'sand or and more on the bill.

I don't see any reason to restrict to just power. IMO a series of power, energy, and demand is useful if a device can support it.

So no don't restrict it to just power and please allow series for power, demand, and energy 

Jp

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Wed 7/27/2011 7:13 AM
To: John Parello (jparello); Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values
 
Hi John,

my Question was 

Thanks,

    Juergen

---

From: "Michael Suchoff" <[email-masked]>
Date: Thu, 28 Jul 2011 14:25:01 -0400

I would add current to the series as well.  Most AC devices presently
don't have circuitry to report power or energy, they simply report AC
current.  Also, for capacity planning, current is very useful (it is
current that limits how many devices can be placed on an electrical
branch circuit or PDU - not power).

Ideally, the time series would be structured as a table with the columns
being measurements (i.e. column 1 = time stamp, 2 = power, 3 = energy, 4
= current, 5 = voltage, etc).  The columns could be partitioned into
SNMP augmented tables (tables sharing same index).  This would allow
easy addition of new columns for products that offer more information.

I don't see reason for demand as a special table.  Demand (watts) is
easily computed from the energy readings.  For example, if kWh = 1000 at
1PM and kWh = 2000 at 1:15PM, then average power over the 15 minute
interval is (2000kWh - 1000kWh) * 60minutes/15minutes = 4kW.  Doesn't it
seem a lot simpler for management program to compute demand based on
polled energy readings (i.e. a simple SQL query) - rather than having to
write a procedure to configure the power agent to perform demand
computations?

From: [email-masked] [mailto:[email-masked]] On Behalf Of
John Parello (jparello)
Sent: Thursday, July 28, 2011 2:06 PM
To: Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue
12.3:timeseries of energy/power values

I don't see any reason to restrict to just power. IMO a series of power,
energy, and demand is useful if a device can support it.

So no don't restrict it to just power and please allow series for power,
demand, and energy

Jp

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Wed 7/27/2011 7:13 AM
To: John Parello (jparello); Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue

Hi John,

my Question was

"Do I understand right that you would support a requirement for
specifying
a standard for time series of power but not for time series of energy?"

I take you answer as a no. This would mean we keep both requirements
(time
series of power and time series of energy). Is this correct?

Thanks,

    Juergen

>> So far, storing time series of measurements on managed nodes is
rarely
>> Now the question is: Is energy management so much different from
other
energy

---

From: Brad Schoening <[email-masked]>
Date: Thu, 28 Jul 2011 22:12:43 +0000

An energy time series is can be reported as an odometer reading.  I think you'll need to be adaptable to allow either an absolute value like instantaneous kW, kWh over a sample period or odometer sampling for kWh.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Michael Suchoff
Sent: Thursday, July 28, 2011 2:25 PM
To: John Parello (jparello); Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values

I would add current to the series as well.  Most AC devices presently don't have circuitry to report power or energy, they simply report AC current.  Also, for capacity planning, current is very useful (it is current that limits how many devices can be placed on an electrical branch circuit or PDU - not power).

Ideally, the time series would be structured as a table with the columns being measurements (i.e. column 1 = time stamp, 2 = power, 3 = energy, 4 = current, 5 = voltage, etc).  The columns could be partitioned into SNMP augmented tables (tables sharing same index).  This would allow easy addition of new columns for products that offer more information.

I don't see reason for demand as a special table.  Demand (watts) is easily computed from the energy readings.  For example, if kWh = 1000 at 1PM and kWh = 2000 at 1:15PM, then average power over the 15 minute interval is (2000kWh - 1000kWh) * 60minutes/15minutes = 4kW.  Doesn't it seem a lot simpler for management program to compute demand based on polled energy readings (i.e. a simple SQL query) - rather than having to write a procedure to configure the power agent to perform demand computations?

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of John Parello (jparello)
Sent: Thursday, July 28, 2011 2:06 PM
To: Juergen Quittek; Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:timeseries of energy/power values

Jp

-----Original Message-----
From: Juergen Quittek [mailto:[email-masked]]
Sent: Wed 7/27/2011 7:13 AM
To: John Parello (jparello); Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] new revision of eman requirements - open issue 12.3:time series of energy/power values

Hi John,

my Question was

Thanks,

    Juergen