Subject: [eman] R Fwd: Re: iana powerstate tc proposal

From: "John Parello (jparello)" <[email-masked]>
Date: Mon, 14 Nov 2011 09:46:00 -0800

My comments inline.

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

Subject: 

Re: [eman] iana powerstate tc proposal

Date: 

Mon, 14 Nov 2011 02:48:20 -0800

From: 

Bruce Nordman <[email-masked]> <mailto:[email-masked]> 

To: 

Benoit Claise <[email-masked]> <mailto:[email-masked]> 

CC: 

Mielke, William F (Bill) <[email-masked]>
<mailto:[email-masked]> , [email-masked] <[email-masked]>
<mailto:[email-masked]> 

I am guessing that the great majority of devices will support only a
single
power state series, so few will even have the potentiality for a
problem.
For the remainder, they will find the mapping obvious.

[jp] In my experience most implement multiple power states. At a minimum
manufacturer and then some standard.

Does anyone have a concrete example about how bad things could happen?
I think that would help the discussion.  On the other hand, I don't
think there
is a problem here so don't want to necessarily encourage the thread.

[jp] PC Vendors like Lenovo support ACPI , DMTF and Cisco EnergyWise.
For PoE Cisco Switches support PoE power levels and Cisco
EnergyWise.I've had no problem keeping it internally consistent for two
viewers of different interfaces. I have multiple MGT vendors (IBM,
SOlarwinds, CA, Joulex) all viewing devices with different views. So
it's not difficult and it's prevalent.

More below.

On Sun, Nov 13, 2011 at 7:38 PM, Benoit Claise <[email-masked]>
wrote:

Dear all,

There is no universal mapping, otherwise we would have a single power
state series. This is obviously true on both the EnMS and the device.

"two uncoordinated managers both attempting to control powerstates is
almost guaranteed to lead to chaos, regardless of whether they are using
the same or different powerstate sets." Agreed, but let's decompose this
problem into two
1. two uncoordinated managers both attempting to control powerstates
with the same power state series. 
    1.1 if the two EnMS disagree on what needs to be done, there is
nothing EMAN can do...
2. two uncoordinated managers both attempting to control powerstates
with different power state series. 
    2.1 if the two EnMS disagree on what needs to be done, there is
nothing EMAN can do...  (like 1.1)
    2.2 however, if the two EnMS attempt to set the same "profile" on
the energy object, then EMAN can potentially help

[jp] I agree with Bill. So long as the device remains internally
consistent we are fine. Take Lenovo workstations. They respond to Cisco
EnergyWise levels and ACPI and DMTF levels at the same time. The problem
of two viewers (mgt stations) wanting  a different view to the same
device is not something we need to address. IF a device can do this then
why limit it.  I have implementations that do this so why can't I if I
want in this standard. 

Now, taking a step back regarding this concurrent power state
requirement, [EMAN-REQ] specifies

5.2.3.  Multiple power state sets

   The energy management standard must provide means for supporting
   multiple power state sets simultaneously at a powered entity.

Which solutions do we have?
1. we remove this requirement: a single power state series is supported.
This pushes the potential mapping from different device types/vendors to
the EnMS
2. the device can support multiple power state series for reading, but
only one for control. This solves the problem 2.2
     2.1 A variant: the device can expose multiple power state series
for both monitoring and control, but the first EnMS that accesses it
fixes the interface to communicate with the device, i.e. the power state
series. Concern is: what if the first EnMS accessing the device is not
the right one.
3 . the device does its best in terms of mappings between the power
state series. This solves the problem 2.2, by basically saying: "we
trust the vendor to do what's right for his device type". 

[jp] Either the mgt station will have to views  (interfaces) to the
device to support the different state sets (ACPI, DMTF, Manufacturers)
or the device will. IMO the manufacturer is in a better position to
handle this than each Mgt station. IF you don't handle multiple power
states in this standard for the devices to model then you leave it to
Mgt stations to define  their own mapping (in UIs etc) which will be
different per mgt station vendor. So what is the point of a standard
then.

JP

---

From: Ira McDonald <[email-masked]>
Date: Mon, 14 Nov 2011 13:22:18 -0500

Hi John,

I agree that network devices (here I'm speaking from experience
with printers and MFDs, but also routers and switches) commonly
support multiple power state sets.

Nonetheless, there is room for "surprise" to the users of management
stations, because of the impedance matching of power state sets of
different granularity across different views.

For example, lots of levels of sleep states.  Or lots of levels of on
states.
After these are "folded" for a different view, the power usage logs may
look a bit surprising.

But devices know much more about the objective reality than general
management stations.

In our PWG power management efforts, we spent a fair amount of
effort to allow scheduled or event-triggered power state change policies
to be configured (or reported per out-of-band configuration).  Mixing
power state sets in this policy context across enterprises is trickier.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Printer Working Group
Co-Chair - IEEE-ISTO PWG IPP WG
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - TCG Embedded Systems Hardcopy SG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music/High North Inc
http://sites.google.com/site/blueroofmusic
http://sites.google.com/site/highnorthinc
mailto:[email-masked]
Winter  579 Park Place  Saline, MI  48176  734-944-0094
Summer  PO Box 221  Grand Marais, MI 49839  906-494-2434

On Mon, Nov 14, 2011 at 12:46 PM, John Parello (jparello) <
[email-masked]> wrote:

> My comments inline.****
>
>
>
> -------- Original Message -------- ****
>
> *Subject: *
>
> Re: [eman] iana powerstate tc proposal****
>
> *Date: *
>
> Mon, 14 Nov 2011 02:48:20 -0800****
>
> *From: *
>
> Bruce Nordman <[email-masked]> <[email-masked]>****
>
> *To: *
>
> Benoit Claise <[email-masked]> <[email-masked]>****
>
> *CC: *
>
> Mielke, William F (Bill) <[email-masked]><[email-masked]>,
> [email-masked] <[email-masked]> <[email-masked]>****
>
>
>
> I am guessing that the great majority of devices will support only a single
> power state series, so few will even have the potentiality for a problem.
> ****
> manufacturer and then some standard.****
>
>
> I think that would help the discussion.  On the other hand, I don't think
> there
> ****
> [jp] PC Vendors like Lenovo support ACPI , DMTF and Cisco EnergyWise. For
> PoE Cisco Switches support PoE power levels and Cisco EnergyWise.I’ve had
> no problem keeping it internally consistent for two viewers of different
> interfaces. I have multiple MGT vendors (IBM, SOlarwinds, CA, Joulex) all
> viewing devices with different views. So it’s not difficult and it’s
> prevalent.****
>
>
> More below.****
>
> On Sun, Nov 13, 2011 at 7:38 PM, Benoit Claise <[email-masked]> wrote:*
> ***
>
> Dear all,
>
> 1. two uncoordinated managers both attempting to control powerstates with
> the same power state series.
> 2. two uncoordinated managers both attempting to control powerstates with
> different power state series.
>     2.2 however, if the two EnMS attempt to set the same "profile" on the
> energy object, then EMAN can potentially help
>
> ****
>
> EnergyWise levels and ACPI and DMTF levels at the same time. The problem of
> two viewers (mgt stations) wanting  a different view to the same device is
> not something we need to address. IF a device can do this then why limit
> it.  I have implementations that do this so why can’t I if I want in this
> standard. ****
>
>
> Now, taking a step back regarding this concurrent power state requirement,
> [EMAN-REQ] specifies****
> 5.2.3.  Multiple power state sets****
>
>    The energy management standard must provide means for supporting****
>
>    multiple power state sets simultaneously at a powered entity.****
>
>      2.1 A variant: the device can expose multiple power state series for
> both monitoring and control, but the first EnMS that accesses it fixes the
> interface to communicate with the device, i.e. the power state series.
> Concern is: what if the first EnMS accessing the device is not the right
> one.
> 3 . the device does its best in terms of mappings between the power state
> series. This solves the problem 2.2, by basically saying: "we trust the
> vendor to do what's right for his device type". ****
>
> ** **
>
> [jp] Either the mgt station will have to views  (interfaces) to the device
> to support the different state sets (ACPI, DMTF, Manufacturers) or the
> device will. IMO the manufacturer is in a better position to handle this
> than each Mgt station. IF you don’t handle multiple power states in this
> standard for the devices to model then you leave it to Mgt stations to
> define  their own mapping (in UIs etc) which will be different per mgt
> station vendor. So what is the point of a standard then.****
>
> ** **
>
> JP****
>
> ** **
>
> ** **
>
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

---

From: Benoit Claise <[email-masked]>
Date: Tue, 15 Nov 2011 02:40:27 +0800

On 15/11/2011 01:46, John Parello (jparello) wrote:
> <mailto:[email-masked]>, [email-masked] 
> <mailto:[email-masked]> <[email-masked]> <mailto:[email-masked]>
>
>
>
> [jp] In my experience most implement multiple power states. At a 
> minimum manufacturer and then some standard.
>
>
> EnergyWise.I've had no problem keeping it internally consistent for 
> two viewers of different interfaces. I have multiple MGT vendors (IBM, 
> On Sun, Nov 13, 2011 at 7:38 PM, Benoit Claise <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
> Dear all,
>
> almost guaranteed to lead to chaos, regardless of whether they are 
> using the same or different powerstate sets." Agreed, but let's 
> decompose this problem into two
> consistent we are fine. Take Lenovo workstations. They respond to 
> Cisco EnergyWise levels and ACPI and DMTF levels at the same time. The 
> problem of two viewers (mgt stations) wanting  a different view to the 
> same device is not something we need to address. IF a device can do 
> this then why limit it.  I have implementations that do this so why 
> can't I if I want in this standard.
>
>
> 1. we remove this requirement: a single power state series is 
> supported. This pushes the potential mapping from different device 
> types/vendors to the EnMS
> fixes the interface to communicate with the device, i.e. the power 
> state series. Concern is: what if the first EnMS accessing the device 
> is not the right one.
> different per mgt station vendor. So what is the point of a standard then.
>
Agreed.

Regards, Benoit (as a contributor)