Subject: [eman] EMAN MIB reviews and development process understanding

From: "Chris Verges" <[email-masked]>
Date: Thu, 28 Oct 2010 16:34:20 -0700

Hi EMAN WG,

I've been looking further into the ENERGY-AWARE-MIB, POWER-MONITOR-MIB,
and POWER-QUALITY-MIB from an implementer's perspective.  Speaking
personally and not on behalf of my employer, I am extremely excited by
the potential that these MIBs and the EMAN group has on simplifying
power management.  A common schema for data reporting and control
management will be awesome to finally get in place.

That being said, the three MIBs currently being proposed are definitely
expansive.  Understanding their nuances and providing adequate reviews
for all possible scenarios (intelligent PDUs, PoE network switches, PoE
edge devices, etc.) seems to be challenges that could impact release
dates.  I'm also a little confused with some of these MIBs, as they
appear to have some overlapping scope/implied meaning.  As an
implementer, I am eagerly poised to start coding these up, but want to
ensure that they are going to meet my long-term needs without
significant changes.

As an agenda suggestion for the next WG meeting, would it be appropriate
to discuss a phased release process?  In such a process, the
functionality added at each stage is separately contained, modular for
maintenance purposes, and adds upon each other in a focused approach.
For example, by exposing Phase 1 sooner, then enterprise-specific
extensions can be worked on while the features in Phases 2 and 3 are
being developed further.

To prompt discussion, here's one suggestion of how the work can be
broken down into phases:

Phase 1 - Core Functionality

*         Setup a table that lists all power management entities (like
ENTITY-MIB, but for power entities, so perhaps POWER-ENTITY-MIB?)

o    Purpose of the table is focused on enumerating all entities that
support power management using a concise, flexible structure

o    Objects pass the test "Is this object necessary to describing all
power entities?"

o    Create a unique index value (pwrEntityIndex)

o    Link pwrEntityIndex with entPhysicalIndex, if ENTITY-MIB is
supported

o    Describe the entity with pwrEntityName, pwrEntityDescr,
pwrEntityType, and pwrEntityParent

Phase 2 - State Functionality

*         Setup a sparse table that supports state monitoring/control of
power management entities (POWER-STATE-MIB?)

o    Purpose of the table is focused on providing state management of
power entities

o    Link to pwrEntityIndex

o    Describe the state with pwrStateLevel (off, on, tripped, shed,
reboot, ...?)

o    Describe the relative state with pwrStateRelLevel (0-100%?) and/or
pwrStateAcpiLevel (0..12?)

Phase 3 - Meter Functionality

*         Setup a sparse table that supports power management entities
that report meter data (POWER-METER-MIB?)

o    Purpose of the table is focused on providing meter data for power
entities

o    Link to pwrEntityIndex

o    Structure TBD ... probably similar to POWER-MONITOR-MIB or
POWER-QUALITY-MIB

Phase 4 - Configuration Control Functionality

*         Setup a sparse table that supports configuration parameters of
power management entities (POWER-CONFIG-MIB?)

o    Purpose of the table is focused on providing configuration
management of power entities

o    Link to pwrEntityIndex

o    Structure TBD ... probably based on the components of
ENERGY-AWARE-MIB not used in Phase 1

o    Describe the entity with pwrConfigKeywords, pwrConfigImportance,
pwrConfigRole, etc.

If the development plan/approach isn't already on the agenda, is this
something we can add?  If there is a call-in to the meeting, I'd be
happy to participate remotely as a interested implementer.
(Unfortunately, Beijing is beyond my travel budget!  :-)

Again, thank you for your work in establishing an industry standard in
this area!  Please let me know if there's anything I can do to help.

Best regards,

Chris

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Fri, 29 Oct 2010 00:45:30 -0500

Hi Chris,

Thanks for your detailed comments.  

I think from a IETF WG perspective, I think the first step would be to
arrive at a consensus on whether the proposed MIB variables would be
sufficient and would meet the requirements for power management. 

>From an implementation perspective,  I understand your phased approach.
A probable solution to your question is perhaps consider having separate
MIB modules -  

1.       Core functionality is covered by energy-aware-mib-00. 

2.       Power Metering and Power  states are grouped together -
draft-claise-energy-monitoring-mib-06.  In addition, this module also
contains energy/demand measurement. 

3.       Power Quality MIB - is already an optional MIB module in -
draft-claise-energy-monitoring-mib-06. 

The convergence or adoption of these drafts (or MIB modules)  depends on
the progress or consensus at the WG. 

Thanks

Mouli

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Chris Verges
Sent: Friday, October 29, 2010 5:04 AM
To: [email-masked]
Subject: [eman] EMAN MIB reviews and development process understanding

Hi EMAN WG,

o    Link to pwrEntityIndex

o    Link to pwrEntityIndex

o    Link to pwrEntityIndex

Best regards,

Chris

---

From: "Chris Verges" <[email-masked]>
Date: Fri, 29 Oct 2010 06:51:03 -0700

Hi Mouli,

I guess my concern with the way it is currently broken down is that it
appears to be "cluttered."  For example, in ENERGY-AWARE-MIB, a good
deal of the objects contained in the sequence are not obviously related
to a generic power entity.  In fact, things like Importance and Role are
almost directly descended from Cisco EnergyWise.  At what point do we
break that away are truly focus on the "core"?

Chris

From: Mouli Chandramouli (moulchan) [mailto:[email-masked]] 
Sent: Thursday, October 28, 2010 10:46 PM
To: Chris Verges; [email-masked]
Subject: RE: [eman] EMAN MIB reviews and development process
understanding

Hi Chris,

Thanks

Mouli

Hi EMAN WG,

o    Link to pwrEntityIndex

o    Link to pwrEntityIndex

o    Link to pwrEntityIndex

Best regards,

Chris

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 31 Oct 2010 10:14:24 +0100

Hi Chris,
 
Speaking as a contributor, I like your phased approach proposal, with
the observation that the MIB modules that will be implemented need not
be (all) serialized from a development point of view. Modularity and
scalability of the model are however important features included in your
proposal. 
 
Concerning remote participation - we shall have an audio stream
available for people located remotely, and there will be a jabber room
that will allow remotely located participants to make comments and ask
questions. We shall probably also use WebEx but only to make the audio
available to remote participants and maybe also share presentations as
they are projected on the screen in the room, but not for voice comments
from remote participants. 
 
Please try to connect and participate remotely. The invitation is of
course directed to all WG participants who cannot make it to Beijing. 
 
Dan

________________________________

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Chris Verges
	Sent: Friday, October 29, 2010 1:34 AM
	To: [email-masked]
	Subject: [eman] EMAN MIB reviews and development process
understanding

	Hi EMAN WG,

	I've been looking further into the ENERGY-AWARE-MIB,
POWER-MONITOR-MIB, and POWER-QUALITY-MIB from an implementer's
perspective.  Speaking personally and not on behalf of my employer, I am
extremely excited by the potential that these MIBs and the EMAN group
has on simplifying power management.  A common schema for data reporting
and control management will be awesome to finally get in place.

	That being said, the three MIBs currently being proposed are
definitely expansive.  Understanding their nuances and providing
adequate reviews for all possible scenarios (intelligent PDUs, PoE
network switches, PoE edge devices, etc.) seems to be challenges that
could impact release dates.  I'm also a little confused with some of
these MIBs, as they appear to have some overlapping scope/implied
meaning.  As an implementer, I am eagerly poised to start coding these
up, but want to ensure that they are going to meet my long-term needs
without significant changes.

	As an agenda suggestion for the next WG meeting, would it be
appropriate to discuss a phased release process?  In such a process, the
functionality added at each stage is separately contained, modular for
maintenance purposes, and adds upon each other in a focused approach.
For example, by exposing Phase 1 sooner, then enterprise-specific
extensions can be worked on while the features in Phases 2 and 3 are
being developed further.

	To prompt discussion, here's one suggestion of how the work can
be broken down into phases:

	*         Setup a table that lists all power management entities
(like ENTITY-MIB, but for power entities, so perhaps POWER-ENTITY-MIB?)

	o    Purpose of the table is focused on enumerating all entities
that support power management using a concise, flexible structure

	o    Objects pass the test "Is this object necessary to
describing all power entities?"

	*         Setup a sparse table that supports state
monitoring/control of power management entities (POWER-STATE-MIB?)

	o    Purpose of the table is focused on providing state
management of power entities

	o    Link to pwrEntityIndex

	o    Describe the state with pwrStateLevel (off, on, tripped,
shed, reboot, ...?)

	o    Describe the relative state with pwrStateRelLevel (0-100%?)
and/or pwrStateAcpiLevel (0..12?)

	*         Setup a sparse table that supports power management
entities that report meter data (POWER-METER-MIB?)

	o    Purpose of the table is focused on providing meter data for
power entities

	o    Link to pwrEntityIndex

	*         Setup a sparse table that supports configuration
parameters of power management entities (POWER-CONFIG-MIB?)

	o    Link to pwrEntityIndex

	o    Describe the entity with pwrConfigKeywords,
pwrConfigImportance, pwrConfigRole, etc.

	If the development plan/approach isn't already on the agenda, is
this something we can add?  If there is a call-in to the meeting, I'd be
happy to participate remotely as a interested implementer.
(Unfortunately, Beijing is beyond my travel budget!  :-)

	Again, thank you for your work in establishing an industry
standard in this area!  Please let me know if there's anything I can do
to help.

	Best regards,

	Chris