Subject: [eman] Nameplate was RE: Comments on Requirements and Framework

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 26 Mar 2012 09:34:26 -0700

Hi Brad,

Thanks for the discussion. Nameplate was a term we discussed at length (See  archives) and from consensus I added it to the very first draft of the definitions. So it is well defined.

Hope that helps.

Jp

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brad Schoening
Sent: Sunday, March 25, 2012 8:20 PM
To: Bruce Nordman
Cc: eman mailing list
Subject: Re: [eman] Comments on Requirements and Framework

Bruce,

	3. "Metering.   Another key point is that metering occurs only in components."

	How do smart meters relate to components? I'm puzzled about this statement.  Also, for PDU's measuring power for all outlets, outlet gangs, or individual outlets, which is the 'component'.

	A power interface is a component.  If each outlet has an individual meter, each would be its own power interface.
	If there is just one meter for all of them, as above, then there is just a single power interface.

In actuality, a meter often won't have a physical connection to what is being metered.  I'm wondering if a "power interface" is being confused with a "metering location".  Conceptually, a meter measures the current flowing through a wire or bus. In actuality, a meter usually measures the magnetic field generated by current flowing through a wire and doesn't have any physical connection to the wire.  

In the case above, of a PUD with a single meter, but say, eight outlets each of which can be programmatically turned on or off, wouldn't the "power interface" be the outlet, not the meter point?

		4. Nameplate.  Devices often have actual nameplates that will have power values different from what this definition specifies.

		We defined nameplate inorder to match the actual nameplate, if it exists.  Juergen helped us clarify some details about the units used.  Could you explain why you believe our nameplate attribute wouldn't match real nameplate values and perhaps we could address that.

	The definition in version -05 of the definitions draft says:

	        The Nameplate Power is the maximal (nominal) Power 
	        that a device can support.

	It doesn't speak to the value from a nameplate (which as you note, may or may not be present).
	My understanding is that these are often safety ratings for the chassis, and so significantly in
	excess of the maximum that the actual device could ever draw.  For devices that can have
	extra hardware added, e.g. PCI slots, extra memory, line cards, then the maximum would
	depend on the configuration at any particular time.
	
	If the term "Nameplate" is used, then shouldn't that only reference a value from an actual
	nameplate, and so be undefined if it is absent.

We really, really do mean "Nameplate" power here.  If there is a nameplate on the equipment, then it should be identical to the EMAN Nameplate MIB attribute.  If there is no nameplate label, but the nameplate value is known, than it should be that value.  Nameplate power is often used for provisioning.  It's not unusual to apply a discount factor to nameplate power, but that is something best left to the EnMS.  If it's not available, then yes, it should be NULL.

John:  If we don't have "Nameplate" in our EMAN definitions, can we add it?

We're open to suggestions on how to improve the definition of "nameplate" here if you feel it isn't clear.

Regards,

Brad

Brad Schoening
e: [email-masked] ⟐ m: 917-304-7190

  <http://www.coraid.com/>  Redefining Storage Economics

From: Bruce Nordman <[email-masked]>
Date: Sun, 25 Mar 2012 20:40:59 -0500
To: Brad Schoening <[email-masked]>
Cc: eman mailing list <[email-masked]>
Subject: Re: [eman] Comments on Requirements and Framework

On Mon, Mar 26, 2012 at 3:22 AM, Brad Schoening <[email-masked]> wrote:

Hi Bruce,

I have a couple of questions regarding your comments that perhaps you could help clarify.

1. "The concept of “Power Interface” is critical and needs a bit more elaboration and consistency."

As I belive Chris Verges pointed out a while back, power is often distributed on a common bus and not in point-to-point relationships.  This is why power quality problems often flow backward onto the grid.  

If you have a dumb power strip, or a common busbar, or a smart meter measuring current by a connection-less CT, could you explain how the term "power interface" would be applied in these contexts?  I would prefer if we drop the term power interface but I'm open to further clarification about it.

If the power is provided commonly, as on the power strip or busbar, that would be a single power interface
since there is no metering or control distinction in how things are connected.  

	In many instances, perhaps we are thinking of a power interface as a power supply, converting AC-to-DC current.

If a device has an integral AC/DC supply, then the power interface is before the supply.  The AC/DC
supply could be modeled as a separate ordinary component, since it does consume power. 

	2. Time Series Data - Who is particularly interested in this and/or has knowledge of how best to implement it or not?

	Our requirements was based upon suggestions and guidance from Laurent Guise, Standardizations Director, Schneider Electric.  

Thank you. 

	3. "Metering.   Another key point is that metering occurs only in components."

	How do smart meters relate to components? I'm puzzled about this statement.  Also, for PDU's measuring power for all outlets, outlet gangs, or individual outlets, which is the 'component'.

A power interface is a component.  If each outlet has an individual meter, each would be its own power interface.
If there is just one meter for all of them, as above, then there is just a single power interface.

	4. Nameplate.  Devices often have actual nameplates that will have power values different from what this definition specifies.

	We defined nameplate inorder to match the actual nameplate, if it exists.  Juergen helped us clarify some details about the units used.  Could you explain why you believe our nameplate attribute wouldn't match real nameplate values and perhaps we could address that.

The definition in version -05 of the definitions draft says:

        The Nameplate Power is the maximal (nominal) Power 
        that a device can support.

It doesn't speak to the value from a nameplate (which as you note, may or may not be present).
My understanding is that these are often safety ratings for the chassis, and so significantly in
excess of the maximum that the actual device could ever draw.  For devices that can have
extra hardware added, e.g. PCI slots, extra memory, line cards, then the maximum would
depend on the configuration at any particular time.

If the term "Nameplate" is used, then shouldn't that only reference a value from an actual
nameplate, and so be undefined if it is absent.

The language of "maximal" is fine with me, but that often does not correspond to the
nameplate value.

	Regards,

	Brad

Thanks,

--Bruce (as contributor) 

	Brad Schoening
	e: [email-masked] ⟐ m: 917-304-7190

	 Redefining Storage Economics <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	From: Bruce Nordman <[email-masked]>
	Date: Sun, 25 Mar 2012 15:50:52 -0500
	To: eman mailing list <[email-masked]>
	Subject: [eman] Comments on Requirements and Framework <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	The following are my comments on the Requirements and Framework drafts - as contributor. <http://www.coraid.com/> 

	--Bruce <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	I see significant progress since our last meeting in the Requirements and Framework drafts.  While there is still a considerable amount of work to do, for the first time I feel as though I can see “light at the end of the tunnel”. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	These comments cover these two drafts, both some common issues, and ones specific to each.  Other emails will provide more specific comments that may be of less general interest. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	I believe that we need a document for Implementation guidance or details, for useful content that doesn’t fit into any of our chartered documents.  I don’t think we need to add this to our charter (though this might be a good solution), and it doesn’t have to be an IETF document at all.  There are other organizations who could host this material.  Some information in the Framework could be transferred to this document, and it would also expand on some issues discussed only in passing in the Framework.  This would both streamline our chartered documents, and provide a place for information we would not put into them. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	COMMON <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	PE and EO.  The terms “Powered Entity” and “Energy Object” are both used, it seems to mean the same thing.  I see value in both terms, and suggest that PE be for the actual hardware involved, and EO the data representation of information about the PE.  In some cases it may not be clear which is to be used, in which case it probably doesn’t matter.  Regardless of what we decide, someone will need to go through all drafts to harmonize and correct usage of these terms (and others). <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	PI.  The concept of “Power Interface” is critical and needs a bit more elaboration and consistency.  A PI is a component, though has features other components do not have (notably wiring relationships).  Every device must have at least one PI – that said, for a device with only one PI, the power and energy values for the device and its PI will be identical.  There are distinct characteristics of PIs, devices, components, and PEs/EOs that should be itemized. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	A PI could implement reporting and control of power supply (whether it is operating as an inlet or outlet) through the power state of the PI.  This would be either On or Off.  Off would mean no power could flow.  On would mean that it could (but might not be at any particular time).  Thus, no separate mechanism for power state control is needed in the framework or MIBs.  For this purpose, I think we want to add a power state series that has only On and Off (what we call it I think does not matter – could reference PIs or not).  Many PIs will only implement the On power state – that is, they can’t be controlled. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	PIs consume no power themselves, but do have wiring relationships. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Metering.   Another key point is that metering occurs only in components.  The reported values for a device is simply the sum of all its PIs.  As components draw from the pool of power in a device, they don’t participate in that calculation.  I assume that nested components have their own pools of power.  For example, if there is a memory component contained in a line cardcomponent contained in a device, I assume that the memory power consumption is also reflected in the total line card consumption. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Proxy.  The proxy topic covers several distinct functions.  One is proxying of reporting, and the other proxying of control.  This should be split into these two concepts. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Domain.  Previous discussions on the list in the last month have raised the question of whether a domain label MUST correspond to a subset of a power distribution tree or whether it is for arbitrary use by the manager of a facility.  Personally, I would put this as a keyword which would be “domain=xxx” as part of the keyword list.  If the consensus is that a separate variable is warranted, then I would call it Domain if it has no required meaning, and “Meter Domain” if it is tied to a power distribution topology.  If Meter Domain, then we need to specify if these can be multi-level, or not, as that has implications. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Priority, Importance, Grouping.  These may be useful, but they seem ill-defined and inevitably just defined by the operator of a specific facility.  For this reason, the keyword mechanism seems appropriate, particularly as they should be mostly or entirely static. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Time Series Data.  We don’t need time series for power values.  Power over time is energy so if you want to get a view over time, go to energy.  For time series details in general, REQ 5.7 notes this is an open issue.  Who is particularly interested in this and/or has knowledge of how best to implement it or not? <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Power Measurement Method.  What matters in the end is the accuracy of a value, not how it was obtained.  So, lets assure that accuracy does what we need it to then drop the Method requirement 5.3.3 (and associated Framework text). <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Power states.  Should we distinguish between transition states and long-term stable states?  It doesn’t make sense to request a transition, and reporting that makes sense for long-term stable states may not make sense for transitions. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	REQUIREMENTS <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	5.3.2. Power Measurement Interval.  This can be deleted.  If power is being measured over time, that isenergy.  For how any device determines its power value, I don’t think we need to describe that in EMAN.  Devices will do it in ways that make sense for them, and management systems will be satisfied. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	5.4.6. Maximum and average power per power state.  Drop this.  A can of worms.  Also mentioned in 5.4. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	7. Clarify that only devices do reporting.  Devices commonly report for components (including PIs) they contain.  This issue is devices reporting for OTHER devices, or components not contained in themself.  I think implicitly if you can report on a device other than yourself, you might be able to report on components of that device. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	7.5, 7.6, and 7.7.  These all seem unnecessary and can be deleted. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	FRAMEWORK <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	The whole draft needs a review for SHALL/SHOULD/MAY to add these where missing or not capitalized. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	The definition example text and other NOTEs should be moved to a different document.  This could logically be part of discussion text of concepts – not listed with the definition.  Occasionally a NOTE may be warranted with a definition. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	There is no need for the concept of a stand-alone meter.  A meter is simply a device that consumes no energy.  One can reference a “meter device”. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Aggregation is a function, not a relationship.  An aggregation could be modeled by a reporting device as a pseudo-device that it also reports on that has wiringrelationships to each of the entities it is aggregating.  These other entities would NOT show the reverse association.  While in general wiring topologies are only between PIs, aggregation could also reference entire devices or single compoents to aggregate.  So long as there was a marker that this was not a real additional device, then the aggregation would not break anything else, and not require any new data structures.  I think this cleanly solves this problem. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Nameplate.  Devices often have actual nameplates that will have power values different from what this definition specifies.  This is needlessly confusing.  Personally I would not include this at all, but if it is included, then “Maximum” would be a much better term. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	The “EMAN” power series should not have that name.  It doesn’t derive from any EMAN requirements.  That said, there is nothing wrong with it being registered with IANA as the others are, but theFramework should reference some other document that describes it (ideally astandard, but a manufacturer’s document could be suitable).  That said, I think the last half of the table is not different power states at all, but simply different levels of activity within a state. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	Section 5.  This conflates several distinct topics – the section should be rewritten to separate them.  First is IP vs. non-IP devices.  Non-IP devices can certainly not report over EMAN.  The second is devices that can report via EMAN vs. those that cannot, whether they are IP or non-IP.  The third is devices that have their key information themselves, or where a second device is the source ofthat information.  The device in question can be iP or non-IP, and can be EMAN-capable or not.  Finally, the section discusses proxying and aggregation.  By isolating these different issues / circumstances, we can then explain how EMAN covers each. <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

	  <http://www.coraid.com/> 

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

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

<http://www.coraid.com/>