Subject: [eman] Comments on "Requirements for Power Monitoring"

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 9 Nov 2010 15:19:19 -0600

These comments are relative to
"draft-quittek-power-monitoring-requirements-02".

Substantive Comments:
---------------------

Section 4. Monitoring Models

"Applying these considerations to the required information leads to the
conclusion that most of the information can appropriately be reported using
the pull model.  The only exceptions are notification on power state changes
and high volume time series of energy consumption values."

I disagree with this conclusion.  The requirement is that users of this
standard be able to efficiently transfer the bulk data associated with the
time series data.  The ability to efficiently transfer bulk data is
independent of whether that transfer is initiated using either a push or a
pull model.  In other words, I disagree with the implied notion that large
data transfers can only be accomplished using a push model of management.
SNMP Get-Bulk is the currently defined solution to this problem as I
understand it within the existing IETF management standards and we should
support an approach which is consistent with the directions set in those
standard.

This does not mean that I don't see the need to extend those same standards
to include a more robust push model for use in cases such as this, if
desired, but the applicability of any such extension would be much wider
than simply energy management.  Therefore the proper place to address the
need for such a robust push model extension to SNMP would seem to be within
the SNMP area itself and not as part of the eman specifications.  Energy
management does not appear to have any particularly unique characteristics
in terms of how it's push model might operate whether for Time Series Data
or anything else.

I must admit that I am not currently familiar with the specifics of whether
the SNMP area is considering such an push model extension, or not, but in
the OPSAREA meeting held yesterday I believe that there was some discussion
to this effect.  If so I believe that anything we are proposing here must be
harmonized with anything that happens there.  Does this make sense?

Minor Wordsmithing:
-------------------

Section 1 - 3rd paragraph just before the bullet list:

"can be applied to several areas including" -> "can be applied to several
areas including but not limited to" 

Section 1.1 - 2nd paragraph after the first bullet list:

"without the consequence of a potential performance degredation" -> "without
the consequence of a potential performance or capacity degredation"

Section 3.4.2 - Last paragraph

"the precision of the measured data, i.e. the potential error in the
measured data, needs to be known as well"

I agree with the point being made here but I think the proper term is
"accuracy" rather than "precision".  This is a common point of confusion.
Precision refers to whether you are measuring in, for example, volts or
kilo-volts or milli-volts.  Accuracy refers to the degree to which a
measured value actually represents reality, so a given measurement may be
accurate to +- some percentage.

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

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

    - Albert Einstein

---

From: "Mielke, William F (Bill)" <[email-masked]>
Date: Tue, 9 Nov 2010 21:09:19 -0600

Sigh.  I apologize.  Somehow my email system has managed to send an
intermediate draft of my comments and thus deleted some of them.  I shall
reproduce them here:

--------------------
Substantive Comments
--------------------

Section 4. Monitoring Models
----------------------------

My first sentence should have instead read: "I disagree with part of this
conclusion, specifically the last sentence."

Section 5. Control Requirements
-------------------------------

I believe that there is some need of work on this section.  My initial
reading of it is that it suggests a more direct style of management and
control than is expected or desired.

A crude example of what I mean is that we do not expect a Network Management
System to be proactively monitoring the power states of an individual CPU on
some line card or to be actively setting and resetting the states on those
individual CPUs.  It is true that from a management perspective such an NMS
may have need to be able to drill down and to report on the current power
status of such a CPU, to perhaps examine historical data about the state
transitions thereof, and in some very rare circumstances even be able to
effect a direct control on on such a component (although in this example
such action would be absurd).  The concept itself will have greater or
lessor applicability depending on the levels of abstraction within the NMS
heiarchy which are being discussed.

A more likely scenario is that the NMS will want to set specific power
related policies within the line card itself (or the containing device) and
then rely on the line card to manage the transitions of the individual CPUs
itself.  From the NMS perspective, such policies would be established so as
to effect an operator specific set of desired service levels with respect to
capacity, availability, etc.  Upon setting such policy based parameters the
device should be as self-managing as possible with respect to it's own
resources.

The goal, of course, is to enable individual pieces of equipment to operate
semi-autonomously or in conjunction with their peers so as to better match
the actual power consumption of the network equipment to the required
network loads as they vary over time.

I think some discussion of this policy based scenario would be desirable in
this section.

Section 7. Suggested Actions
----------------------------

I believe that most of this section may be misplaced in this document.  The
main points being made are more implementation decisions than actual
requirements.

Returning to the example of the efficient transfer of Time Series Data, the
actual requirement is that users of this standard to be able to efficiently
transfer such data.  Any discussions of push mode management and/or binding
to specific implementations thereof such as the currently proposed IPFIX
approach would probably be better placed in the architecture/framework
document than here in the requirements.

I recommend that we simply delete this section in the requirements document
and work to incorporate any of the specifics of the implementations
appropriately within the architecture/framework document.

I believe that my concerns about defining more robust push mode extensions
to the existing SNMP management approach apply here as well.  Our proposals
must be in line with the management directions set by the SNMP area.  Any
possible approaches to achieving those (such as the current IPFIX proposal)
are best handled within the SNMP area itself and anything we have to say on
the subject would have to be harmonized with those management standards.

Section 9. Security Considerations
----------------------------------

Without trying to enumerate what they might be at this time, by the time we
are finished with this document I anticipate that we should have something
to say in this area.  Enabling control of power without imposing or
addressing security concerns would be a mistake I think.  I will try to
offer some suggestions in follow-up email and I believe that the
Architecture/Framework document has made a bit of a start in this area
already.

Thanks,

William F. Mielke
Alcatel-Lucent
Fax: 614 367 5965

    - Albert Einstein

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mielke, William F (Bill)
Sent: Tuesday, November 09, 2010 4:19 PM
To: [email-masked]
Subject: [eman] Comments on "Requirements for Power Monitoring"

Substantive Comments:
---------------------

Minor Wordsmithing:
-------------------

William F. Mielke
Alcatel-Lucent

    - Albert Einstein

---

From: Juergen Quittek <[email-masked]>
Date: Tue, 23 Nov 2010 18:04:53 +0000

Dear Bill,

Sorry for the late reply.
I have been busy with other things after the IETF.

In general, I have two replies on your comments:

First. there is no work item in the eman charter on developing means for
using IPFIX for energy management, for example, for defining IPFIX
information elements for this purpose. We may decide to add such items to
our charter in the future, but now is not the time to discuss this.

Second, the current draft on eman requirements has a section called
"suggested Actions". This one suggests the IETF to establish new work items
in the area of energy management. This has been done already and I would
suggest removing this section.

Please find more specific replies inline below.

> "draft-quittek-power-monitoring-requirements-02".

Again, two comments:
First, there were two exceptions. One was power state change notifications.
I assume you do not disagree, that these should be transmitted preferably in
push mode.

Second, yes, there is a bulk transfer option in SNMP. And yes, it may be
used for reporting energy and power values. However, for this kind of
reporting, other protocols have proven to be much more appropriate.

In the draft we state that
>>                                   However, the overhead of pull
>>   model monitoring is typically higher than for push model monitoring,
>>   particularly when large numbers of values are to be collected, such
>>   as time series of power values.
Do you have a problem with this statement? It is the main argument provided
for conclusion that you disagree with.

Particularly if you collect large amounts of data from large amounts of
reporting nodes, SNMP scalability is more limited than scalability of other
protocols. Particularly, IPFIX is much more efficient in transferring larg
numbers of data and it has a mediation and aggregation framework for large
numbers of data to be collected.

> in terms of how it's push model might operate whether for Time Series Data

You are right, it is not necessarily important whether it is the push or the
pull model. But the IETF has a developed a set of management protocols which
all have advantages and disadvantages in different application areas.
SNMP is the preferred protocol for general (pull-based) monitoring, NETCONF
is the preferred protocol for configuration management, and SYSLOG and IPFIX
are the preferred protocols for push-based monitoring where the strength of
IPFIX is on sending huge amounts of measured values.

Thus, for a continuous reporting of time series of power/energy values of
monitored devices, IPFIX seems to be a good choice, well suited for this
particular task.

> harmonized with anything that happens there.  Does this make sense?

I don't think that the SNMP community is working on developing a standard
for push-based bulk reporting. And one good reason for this is that there is
already IPFIX covering this task well.

> Minor Wordsmithing:

Thanks for all the comments.

We will consider them in the next revision.

    Juergen

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