Subject: [OPSAWG] draft-claise-energy-monitoring-mib

From: "Chris Verges" <[email-masked]>
Date: Tue, 8 Jun 2010 07:26:33 -0700

Dear IETF working group,

My name is Chris Verges.  I'm a project manager at Cyber Switching,
Inc., a manufacturer of intelligent power distribution units found in
many datacenters and test labs today.  Our products bridge the gap
between the power grid and the data network, providing remote management
capabilities of the power grid.

Given our unique position in many networks, Brad Schoening asked me to
provide comments on two proposed MIBs from the perspective of an
implementer.  (Hereinafter, the two MIBs are colloquially referred to as
"NEC MIB" for http://tools.ietf.org/html/draft-quittek-power-mib-01 and
"Cisco MIB" for
http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03.)

First, I applaud both MIBs as a huge step forward!  Such standards offer
great potential to promote usage of energy data in making business
decisions.  At present, all vendors in our industry implement their own
unique set of MIBs that are disjoint and may not offer the full scope of
data available in the MIB.  I'm professionally very excited by the
interoperability that this could help to bring to the Smart Grid.

Second, as requested, I read the two drafts as an implementer and
consumer of the data being exposed.  Some thoughts:

* I like the NEC MIB's integration of AC and DC into the same node
elements.  Based on their implementation, it appears as though the
elements which are unique to AC are "optional" while the ones shared by
both are "mandatory."  There is great flexibility for consuming data in
this manner, and such a structure would greatly enhance the Cisco MIB.

* While both provide power data, the Cisco MIB's methodology seems to
encompass more types of equipment.  The implementation on our product -
an advanced power strip that provides metering per outlet, per bank, and
per input - seems to be more straight forward with the Cisco MIB.

* One fundamental difference that I noted between the two MIBs was
instantaneous vs. historical data.  Both are important, though I
question whether the NEC MIB's implementation of historical data (by
timestamp, with much calculation left up to the user) is really a good
solution for SNMP.  The inherent time delay between querying OIDs could
result in disjoint
timestamps/data due to the lack of an atomic query.  This type of query
seems better suited for a web service that can ensure data integrity.
Perhaps extending the Cisco MIB to include a "kWh" measurement, much
like a utility meter provides, would be beneficial.  (Constantly
incrementing.)

* Power phases need to be an integer between 0 and 360.  There are some
meters that provide very specific phase metrics, and every angle counts
to understand the power quality provided by the upstream source.

The NEC MIB's desire to use several existing MIBs (like Entity Sensor)
seems like the best way to go at first thought.  However, upon a closer
inspection, the structure just seems better suited to simple edge
sensors, like temperature probes, rather than a complex network
hierarchy like power.  (At a device level, the Entity Sensor approach
would work fine; at
the PDU level, it begins to break down.)  The power grid is more complex
than a single power supply on a server, and I hope that the IETF
endorses a quality MIB that properly models that complexity to make the
data truly useful and universally consumable.

My leaning, therefore, would be to use the Cisco MIB as a basis going
forward, and merge in specific aspects of the NEC MIB.

Sincerely,

Chris Verges
-- 
Standard disclaimer: The views and opinions expressed in this article
are those of the author (me) and do not necessarily reflect the official
policy or position of Cyber Switching, its officers, or other employees.

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 8 Jun 2010 21:59:56 +0200

Hi Chris,

Thank you for spending the effort of reading the drafts!

Please find some replies on your comments inline.

> per input - seems to be more straight forward with the Cisco MIB.

Indeed, my company also produces manageable power strips with integrated
probes at which our MIB design is also targeted ;-)

> seems better suited for a web service that can ensure data integrity.

The difference between the two tables is that the Cisco MIB assumes
fixed interval length for energy measurements while the NEC MIB
supports flexible interval lengths.

In the Cisco MIB the interval is defined by a (start of measurement)
timestamp per Energy value and the interval length. In the NEC MIB
the interval is given by the (end-of-measurement) timestamp per
Energy value and the time difference to the previous timestamp.
Also the NEC MIB has an object specifying the interval length.

Both MIB definitions would be almost equivalent if the NEC MIB
requests implementations to always report according to the
specified interval length.

But our observation is that sometimes the controller or processor
of a device is busy with more important issues than reading the
current energy value when an interval end is reached in time.
Then this measurement comes too late and there is no clean way
to report the resulting energy value.
 
Therefore we added this flexibility for devices that cannot guarantee
to accurately report energy consumption according to a given interval
length. Of course, devices capable of reporting accurately should do so.

> to understand the power quality provided by the upstream source.

Would you allow value 0 as well as value 360?
Would these be two values with identical semantics or would they
be semantically different?

> data truly useful and universally consumable.

I agree. We see so many conflicts with the Entity Sensor MIB that
We now prefer to give up the re-use of the definitions made in the
Entity Sensor MIB.

> forward, and merge in specific aspects of the NEC MIB.

Thanks,

    Juergen

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 8 Jun 2010 13:10:43 -0700

Hi Juergen,

My pleasure.  Hope it helps.

> be semantically different?

The two are the same in my book.  Consider this more mathematical form
of what I meant to say: [0,360).  A zero-reference will almost always be
required for the data to make any sense, and 0 degrees == 360 degrees
for the purposes of all trig functions.

Regards,
Chris

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 8 Jun 2010 13:18:28 -0700

One more thing ...

> to report the resulting energy value.

Our product design uses a single processor for each energy meter and a
timestamp "freeze" protocol internally, to ensure the data is consistent
when reported to the user.  I'm not entirely sure on how other products
work, but just wanted to mention that use of a protocol like this could
fix some of these issues.  My main concern of using the NEC MIB's
historical data reporting is the proper handling of the "rollover"
condition that occurs when the index into the historical data exceeds
the available buffer size.  Is SNMP really the best protocol for
relaying historical data?  Or is it better at instantaneous metrics?
The use of a constant counter (like kWh) can show a great deal of
historical information, especially if polled and trended by the agent
requesting the information.

We often tell our customers to use our XML/JSON-based web services
rather than SNMP for polling data updates where consistency is
important.  This more complex structure allows our unit to group data
together for consistency purposes, if that consistency is actually
required.  SNMP is a wonderful protocol, but it is rather "Simple" at a
basic level.

On a slightly related aside, I'm actually looking into IF-MAP as an
alternate mechanism for reporting this type of data in a consistent way
to multiple agents.  I won't touch on this further than to mention that
you're free to contact me directly with more info, as it will be
unproductive for progress on the MIBs.

Regards,
Chris

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 8 Jun 2010 22:43:49 +0200

Hi Chris,

Thank you for this clarification.

I don't like two values in the NMS database meaning the same thing.
So let's exclude 360 as you suggest.

Best regards,

    Juergen

On 08.06.10 22:10  "Chris Verges" <[email-masked]> wrote:

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

---

From: "Juergen Quittek" <[email-masked]>
Date: Tue, 8 Jun 2010 22:47:00 +0200

Hi Chris,

I see your point. And I agree.

SNMP is much better suited for reporting continuously increasing
values than values per interval that a management system needs
to sum up itself.

Thanks,

    Juergen

---

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Jun 2010 16:52:10 +0200

Thanks Chris for reviewing the two MIBs.
Some comments inline.
> encompass more types of equipment.
Exactly, this is one of the major differences
> The implementation on our product -
Do you suggest that pmPhaseIndex could any value from 0 to 360 (or 359)?

         pmPhaseIndex OBJECT-TYPE
             SYNTAX          Integer32 (0 | 120 | 240)
             MAX-ACCESS      not-accessible
             STATUS          current
             DESCRIPTION
                "A phase angle corresponding to 0, 120, 240."
              ::= { pmACPwrQualityPhaseEntry 1 }

> forward, and merge in specific aspects of the NEC MIB.
Thanks Chris.

Regards, Benoit.

---

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Jun 2010 16:57:23 +0200

Juergen,
> We now prefer to give up the re-use of the definitions made in the

This is also the conclusion to which we arrived.

Regards, Benoit.

---

From: "Chris Verges" <[email-masked]>
Date: Thu, 10 Jun 2010 10:15:01 -0700

Hi Benoit,

>               ::= { pmACPwrQualityPhaseEntry 1 }

Yes.  pmPhaseIndex could be Integer32 (0..359).  Equipment that doesn't
monitor phase angle would most likely end up using 0, 120, and 240; but
equipment that does could use the full range provided.

Regards,

Chris