Re: [eman] Feedback on draft-ietf-eman-requirements-05
Daniel Kharitonov <dkh@juniper.net> Thu, 09 February 2012 19:31 UTC
Return-Path: <dkh@juniper.net>
X-Original-To: eman@ietfa.amsl.com
Delivered-To: eman@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D23121E8042 for <eman@ietfa.amsl.com>; Thu, 9 Feb 2012 11:31:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.524
X-Spam-Level:
X-Spam-Status: No, score=-6.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkwDn8Nec3Wu for <eman@ietfa.amsl.com>; Thu, 9 Feb 2012 11:31:50 -0800 (PST)
Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0DC8221E8021 for <eman@ietf.org>; Thu, 9 Feb 2012 11:31:49 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKTzQfI+09vEKndd8dgtsLwXqbt4N+C74X@postini.com; Thu, 09 Feb 2012 11:31:50 PST
Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 9 Feb 2012 11:29:57 -0800
From: Daniel Kharitonov <dkh@juniper.net>
To: Ira McDonald <blueroofmusic@gmail.com>, "Mouli Chandramouli (moulchan)" <moulchan@cisco.com>
Date: Thu, 09 Feb 2012 11:29:57 -0800
Thread-Topic: [eman] Feedback on draft-ietf-eman-requirements-05
Thread-Index: AcznRkHFLOm97g2NQ0m1nkFNNOkQEwAGMK+T
Message-ID: <14803CE6B7CFE0439D9346D27557A82A5967AFEB27@EMBX02-HQ.jnpr.net>
References: <14803CE6B7CFE0439D9346D27557A82A5967AFEB1E@EMBX02-HQ.jnpr.net> <E9B25823FA871E4AA9EDA7B163E5D8A907848F61@XMB-RCD-106.cisco.com>, <CAN40gSvrLuTug3DUJQh=oRwHrbYafrRY8AUztHbRwROCqC4avg@mail.gmail.com>
In-Reply-To: <CAN40gSvrLuTug3DUJQh=oRwHrbYafrRY8AUztHbRwROCqC4avg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
x-exclaimer-md-config: e4081efb-6d29-443c-8708-750833aec629
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "quittek@neclab.edu" <quittek@neclab.edu>, "eman@ietf.org" <eman@ietf.org>
Subject: Re: [eman] Feedback on draft-ietf-eman-requirements-05
X-BeenThere: eman@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussions about the Energy Management Working Group <eman.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eman>, <mailto:eman-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/eman>
List-Post: <mailto:eman@ietf.org>
List-Help: <mailto:eman-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eman>, <mailto:eman-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2012 19:31:51 -0000
Hi Ira, Thanks for the links. IM> The PowerTransition group defines objects for nominal state IM> transition times between any two supported power states. Yes, this is what's relevant because estimate based on timestamps is reactive figure. If an NMS operator makes a decision about changing the power states, she should at least have idea of nominal tradeoffs before the state is engaged. > And this MIB defines explicit light sleep (Standby) and deep > sleep (Suspend) states and their standard behaviors I don't think we can cover the entire range of ICT devices merely based on definitions for printers. In fact, while being strictly non-realtime systems, imaging devices might be merely a subset of the proposed scope of effort. Generally speaking, an abstract ICT system may have N explicit power states, in each of which certain minimal characteristics (performance, QoS etc) are preserved. For instance, if a device has states ranked according to {performance, transition time to full capacity} tuple, state {100,0} would be immediately available, 100% operational, while {0, 10s} may correspond to printer's standby and {0,100s) may correspond to printer's "suspend". Along the same lines, a realtime device may never have {0, XX} states defined but sport a range of {XX, YY} modes suited to various modes of usage. ________________________________________ From: Ira McDonald [blueroofmusic@gmail.com] Sent: Thursday, February 09, 2012 8:16 AM To: Mouli Chandramouli (moulchan); Ira McDonald Cc: Daniel Kharitonov; quittek@neclab.edu; eman@ietf.org Subject: Re: [eman] Feedback on draft-ietf-eman-requirements-05 Hi Daniel, Relevant to your questions, you might want to look at our IEEE-ISTO Printer Working Group candidate standards for Printers and MFDs: "Power Management Model for Imaging Systems v1.0" ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspower10-20110214-5106.4.pdf "PWG Imaging System Power MIB v1.0" ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.pdf "PWG-IMAGING-SYSTEM-POWER-MIB" - ASN.1 source ftp://ftp.pwg.org/pub/pwg/candidates/cs-wimspowermib10-20110214-5106.5.mib The PowerLog group defines a FIFO list of state transitions with time stamps. The PowerTrap group defines a notification to report state transitions. The PowerSupport group defines objects about the capabilities of the device (or component/subunit) in a given state. The PowerTransition group defines objects for nominal state transition times between any two supported power states. The Power[Calendar/Timeout/Event] groups define objects for configured power transitions for device or component based on calendar (like IETF Schedule MIB), timeout, or event triggers. BTW - This MIB uses the standard DMTF CIM power states, but allows vendor extension substates (e.g., fine-grained Suspend substates). And this MIB defines explicit light sleep (Standby) and deep sleep (Suspend) states and their standard behaviors - note that Bruce Nordman does not like the use of these terms, but all Printers/MFDs that support power management have always made this distinction in the their private MIBs and embedded web servers. Cheers, - Ira (editor of the PWG power standards) 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:blueroofmusic@gmail.com<mailto:blueroofmusic@gmail.com> Winter 579 Park Place Saline, MI 48176 734-944-0094 Summer PO Box 221 Grand Marais, MI 49839 906-494-2434 On Thu, Feb 9, 2012 at 6:42 AM, Mouli Chandramouli (moulchan) <moulchan@cisco.com<mailto:moulchan@cisco.com>> wrote: Hello Daniel, Reply inline. Thanks Mouli -----Original Message----- From: eman-bounces@ietf.org<mailto:eman-bounces@ietf.org> [mailto:eman-bounces@ietf.org<mailto:eman-bounces@ietf.org>] On Behalf Of Daniel Kharitonov Sent: Wednesday, February 08, 2012 7:43 AM To: quittek@neclab.edu<mailto:quittek@neclab.edu> Cc: eman@ietf.org<mailto:eman@ietf.org> Subject: [eman] Feedback on draft-ietf-eman-requirements-05 Apologies if this has surfaced before as I did not have time to read the full eman discussions archive. I have two notes regarding the aforementioned draft: 2) Section 5.2 "Power State" Since the document correctly links reduced power states to tradeoffs in performance, service or capacity, it would be logical to report the characteristics of available states along same lines. For example, an operator of energy NMS might be interested in knowing that device supports not only power states A, B, C with expected consumption {a,b,c} watts but also operates at {100,50,30} capacity in those with expected in-out transition time not to exceed X/Y seconds. YCM>> Currently from a requirements point of view, for every entity, we have requirements to report the power state of an entity, (req. 5.2.1), YCM>> its power consumption (req. 5.4.1) and statistics for each power state (req. 5.2.6.) YCM>> There are notifications when power states changes occur (req 5.2.8) and from the time stamps of notifications, it should be possible to estimate the transition times. YCM>> As of now, we do not have requirements on the transition times from a power state to another state. Merely describing power states in not enough as energy savings in reduced power states must be necessarily weighted against the drawbacks. YCM>> The energy management standard provides the data and I would think the network manager should make the trade-offs from the information ? -- Daniel Kharitonov Juniper Networks Inc 1194 N Mathilda Ave Sunnyvale CA _______________________________________________ eman mailing list eman@ietf.org<mailto:eman@ietf.org> https://www.ietf.org/mailman/listinfo/eman _______________________________________________ eman mailing list eman@ietf.org<mailto:eman@ietf.org> https://www.ietf.org/mailman/listinfo/eman
- [eman] Feedback on draft-ietf-eman-requirements-05 Daniel Kharitonov
- Re: [eman] Feedback on draft-ietf-eman-requiremen… Mouli Chandramouli (moulchan)
- Re: [eman] Feedback on draft-ietf-eman-requiremen… Ira McDonald
- Re: [eman] Feedback on draft-ietf-eman-requiremen… Daniel Kharitonov
- Re: [eman] Feedback on draft-ietf-eman-requiremen… Benoit Claise
- Re: [eman] Feedback on draft-ietf-eman-requiremen… Daniel Kharitonov
- Re: [eman] Feedback on draft-ietf-eman-requiremen… Benoit Claise
- Re: [eman] Feedback on draft-ietf-eman-requiremen… Daniel Kharitonov