Re: [eman] EMAN-REQ: the notion of importance

Brad Schoening <brads@coraid.com> Thu, 01 March 2012 16:25 UTC

Return-Path: <brads@coraid.com>
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 7323121E8229 for <eman@ietfa.amsl.com>; Thu, 1 Mar 2012 08:25:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.636
X-Spam-Level:
X-Spam-Status: No, score=-2.636 tagged_above=-999 required=5 tests=[AWL=0.963, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 r9qLruzyB-zs for <eman@ietfa.amsl.com>; Thu, 1 Mar 2012 08:25:46 -0800 (PST)
Received: from server505.appriver.com (server505c.appriver.com [98.129.35.7]) by ietfa.amsl.com (Postfix) with ESMTP id 7433821E80DF for <eman@ietf.org>; Thu, 1 Mar 2012 08:25:45 -0800 (PST)
X-Note-AR-ScanTimeLocal: 3/1/2012 10:25:44 AM
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: GLOBAL - coraid.com
X-Policy: Too many policies to list
X-Primary: brads@coraid.com
X-Note: This Email was scanned by AppRiver SecureTide
X-ALLOW: @coraid.com ALLOWED
X-Virus-Scan: V-
X-Note: Spam Tests Failed:
X-Country-Path: UNKNOWN->UNITED STATES->UNITED STATES
X-Note-Sending-IP: 98.129.35.1
X-Note-Reverse-DNS:
X-Note-Return-Path: brads@coraid.com
X-Note: User Rule Hits:
X-Note: Global Rule Hits: G237 G238 G239 G240 G244 G245 G256 G347
X-Note: Encrypt Rule Hits:
X-Note: Mail Class: ALLOWEDSENDER
X-Note: Headers Injected
Received: from [98.129.35.1] (HELO smtp.exg5.exghost.com) by server505.appriver.com (CommuniGate Pro SMTP 5.4.4) with ESMTPS id 195472664; Thu, 01 Mar 2012 10:25:44 -0600
Received: from MBX22.exg5.exghost.com ([169.254.1.210]) by HT05.exg5.exghost.com ([98.129.23.150]) with mapi; Thu, 1 Mar 2012 10:25:41 -0600
From: Brad Schoening <brads@coraid.com>
To: Juergen Quittek <Quittek@neclab.eu>, Benoit Claise <bclaise@cisco.com>
Date: Thu, 01 Mar 2012 10:25:40 -0600
Thread-Topic: [eman] EMAN-REQ: the notion of importance
Thread-Index: Acz3x/F9SOKGPnFyRNqYnGfJ4pJljg==
Message-ID: <CB74E1E0.22020%brads@coraid.com>
In-Reply-To: <CB7555B9.45CEF%quittek@neclab.eu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.14.0.111121
acceptlanguage: en-US
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Cc: eman mailing list <eman@ietf.org>
Subject: Re: [eman] EMAN-REQ: the notion of importance
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, 01 Mar 2012 16:25:48 -0000

Juergen,

Power shedding is probably a more accurate term for the use cases here for
priority/importance than just simply power down.  There are many things in
a commercial setting that can be turned down, but not necessarily off.
Things such as variable speed fans, battery chargers, etc.



On 3/1/12 7:53 AM, "Juergen Quittek" <Quittek@neclab.eu> wrote:

>Hi Benoit,
>
>I would like to standardize a mechanism, in this case the power down
>priority.  That's what standards do.  I do not see reason to limit
>the application of the mechanism (power down priority) to a single
>Use case (power down less business relevant devices first).
>
>Why should the IETF do so?  Our task is to define useful mechanisms.
>I do not like excluding other use cases.  Take for example a network
>with two kinds of devices:
>  - a few devices consuming a lot of energy and having high energy
>    saving potential
>  - a huge amount of devices with low power demand and very little
>    Power saving potential when turned to sleep mode.
>
>Even if the business importance of the few major power consumers
>is higher than the business importance of the many small devices,
>an energy manager may decide to achieve its power saving objectives
>easier by powering down a just few main energy consumers instead of
>powering down myriads of small devices that only marginally
>contribute to energy saving.
>
>We can't foresee constraints to be considered for powering down
>Devices.  Giving the operator a "priority" allows the operator
>to implement any scheme, may it be based on importance or mot.
>
>Thanks,
>    Juergen
>
>
>On 01.03.12 16:03, "Benoit Claise" <bclaise@cisco.com> wrote:
>
>>
>>
>>
>>    Juergen, Rolf, John
>>
>>    Looking at Rolf's feedback:
>>
>>      I thought this is what you refer to as importance. If you have to
>>switch
>>something off because you cannot power all devices and you have to decide
>>between 911 services or the phone in the janitors office, the priority
>>will tell you. So this is EMAN and I think we can say that, whatever this
>>object means it has to do with energy and I agree with your example that
>>it helps you to decide what to power-off first in case you need to/want
>>to. If this is what importance means (I personally would still call it
>>something less ambiguous, but if we describe it better I am fine with it)
>>I think it is something relevant. But you were referring to other use
>>cases. Care to share more?
>>
>>
>>    Would you guys be happier with a compromise such as "business
>>    importance", "context importance" or "Energy Management Importance"?
>>
>>    Expanding on Juergen's proposal:
>>    OLD:
>>       5.1.3. Power-down priority
>>
>>   The standard must provide means for retrieving and reporting
>>   power priorities of powered entities. Power-down priorities indicate
>>   an order in which powered entities should be switched to lower power
>>   states in case lower power states are desired.
>>
>>
>>    NEW:
>>       5.1.3. xxxxx
>>
>>   The standard must provide means for ranking devices in the context
>>   of a site or deployment, indicating which devices are more critical
>>   to the operation. The value is useful during peak demand when deciding
>>   which devices could be turned off. A ranking of devices gives an
>>   operator or control system a way to determine which devices should
>>   receive power or could be turned off for cost savings during peak
>>   hours of operation. In other words, if an operator is asked to turn
>>off
>>   devices during a certain period, xxxx indicates an order in which
>>powered
>>   entities should be switched to lower power states.
>>
>>
>>Regarding your role proposal 5.1.2, I believe it's fine.
>>
>>Regards, Benoit (as a contributor)
>>
>>
>>      Dear all,
>>
>>The requirements draft is the first one to be agreed on.
>>We can do this without having to deal with all details
>>that the framework and the MIB modules can solve.
>>
>>In the current version draft-ietf-eman-requirements-05 there
>>is a requirement
>>
>>OLD
>>   5.1.2.  Context information on powered entities
>>
>>   The energy management standard must provide means for retrieving and
>>   reporting context information on powered entities, for example, tags
>>   associated with a powered entity that indicate the powered entity's
>>   role, or importance.
>>
>>
>>Seeing the ongoing discussion I suggest separating "role" and
>>"importance"
>>and moving from the fuzzy term "importance" to "power-down priority".
>>This would look like the following:
>>
>>NEW
>>   5.1.2.  Context information on powered entities
>>
>>   The standard must provide means for retrieving and reporting context
>>   information on powered entities, for example, tags associated with a
>>   powered entity that indicate the powered entity's role.
>>
>>   5.1.3. Power-down priority
>>
>>   The standard must provide means for retrieving and reporting
>>   power priorities of powered entities. Power-down priorities indicate
>>   an order in which powered entities should be switched to lower power
>>   states in case lower power states are desired.
>>
>>I think that the proposed requirement 5.1.3 covers Rolf's requirements
>>
>>
>>for accurate naming and John's requirements for the functionality he
>>calls "importance".
>>
>>Thanks,
>>    Juergen
>>
>>
>>On 29.02.12 10:02, "Rolf Winter" <Rolf.Winter@neclab.eu>
>><mailto:Rolf.Winter@neclab.eu> wrote:
>>
>>
>>
>>        Hey John,
>>
>>I am not asking for an IANA registry but a good description and
>>justification of importance. For most requirements it is just naturally
>>clear to have them such as having the ability to monitor power states. No
>>justification needed in my opinion. Then a half sentences in the document
>>requires something that is called "importance". Here I see a need for a
>>description and justification because it means different things to
>>different people.
>>
>>BTW, I don't think that priority means the order in which devices need to
>>be powered up. It certainly doesn’t mean that in the PoE context:
>>
>>"This object controls the priority of the port from the point
>>of view of a power management algorithm.  The priority that
>>is set by this variable could be used by a control mechanism
>>that prevents over current situations by disconnecting first
>>ports with lower power priority.  Ports that connect devices
>>critical to the operation of the network - like the E911
>>telephones ports - should be set to higher priority."
>>
>>I thought this is what you refer to as importance. If you have to switch
>>something off because you cannot power all devices and you have to decide
>>between 911 services or the phone in the janitors office, the priority
>>will tell you. So this is EMAN and I think we can say that, whatever this
>>object means it has to do with energy and I agree with your example that
>>it helps you to decide what to power-off first in case you need to/want
>>to. If this is what importance means (I personally would still call it
>>something less ambiguous, but if we describe it better I am fine with it)
>>I think it is something relevant. But you were referring to other use
>>cases. Care to share more?
>>
>>Best,
>>
>>Rolf
>>
>>
>>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>>London W3 6BL | Registered in England 2832014
>>
>>
>>
>>
>>          -----Original Message-----
>>From: John Parello (jparello) [mailto:jparello@cisco.com]
>>Sent: Dienstag, 28. Februar 2012 20:05
>>To: Rolf Winter; Mouli Chandramouli (moulchan); Ira McDonald; Brad
>>Schoening
>>Cc: eman mailing list
>>Subject: RE: [eman] EMAN-REQ: the notion of importance
>>
>>Hi Rolf,
>>
>>I used the terms in the email - it's defined in the framework,
>>definitions and MIB.  I'm not just throwing terms out I'm trying to
>>help to show *you* the difference in the email text. So let's focus on
>>the problem not try to discredit my word selection and  transitively
>>my premise in the drafts.
>>
>>On to the concept you're not seeing.
>>
>>Here's an example of the different concepts. Priority is ordering
>>(precedence) like boot ordering,   while importance is context
>>(significance).
>>
>>Example:
>>
>>So say I have devices on my trading floor and it is completely powered
>>off. I may have to power  them up in a certain order based on priority
>>but once they are up their running importance is different.
>>
>>(PRIORITY)
>>Network Services
>>File Services
>>Software / Application Repository servers Database Servers Clients
>>Access Lobby Phones Trading Phones
>>
>>Once they are running the importance to the business is different and
>>could be
>>
>>(IMPORTANCE)
>>Network Services  (90-100)
>>Trading Phones  (80-90)
>>File Services (70-80)
>>Databases Servers (60-80)
>>Client Access (30-50)
>>Lobby Phones (10-30)
>>Software / Application Repository Servers (1-20)
>>
>>The former is precedence the latter is significance.  Since priority is
>>already used in the PoE world for this I used "importance" to
>>distinguish the concepts. Especially since the word priority us used
>>for an action or process more times than for a device or thing. So
>>priority IMO seemed more natural to the process or power versus a
>>description of the device.
>>
>>Simply put importance is needed to know what you can power off during
>>peak demand (but not solely that's just one very major use case)
>>
>>BTW Notice my use of a "fuzzy"  name space for the device roles and
>>importance. Not all data needs IANA registry to be useful. So "fuzzy"
>>does not equal bad. Site defined guided data is extremely useful.
>>
>>I've used importance with nearly a dozen EnMS vendors and scores of
>>vendors  and it's been easy to explain versus PoE priority. Happy to
>>show a running system if that clears it up. Suggest any new word you
>>like for the glossary and happy to discuss and select one but let's
>>make sure the concepts are retained.
>>
>>A bit shocked this is being debated for re-justification though as  I
>>first presented at IETF-78 and it's been in the drafts since then.
>>
>>To the Chairs: We need more input in this WG from EnMS vendors and BMS
>>vendors because personally, dealing with over 100 vendors in a
>>community of developers who use these concepts daily, I'm finding those
>>actively participating in the group woefully not representative of
>>problem space at all. We need more diverse input because these concepts
>>are in common use and a call for re-justification at this point
>>highlights that weakness.
>>
>>Perhaps a demo of existing EnMS' to help educate the WG?
>>
>>Jp
>>
>>
>>-----Original Message-----
>>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On Behalf Of
>>Rolf Winter
>>Sent: Tuesday, February 28, 2012 1:16 AM
>>To: Mouli Chandramouli (moulchan); Ira McDonald; Brad Schoening
>>Cc: eman mailing list
>>Subject: Re: [eman] EMAN-REQ: the notion of importance
>>
>>Well let me make myself clearer then.
>>
>>You said: "Given the precedence of use of priority in other IETF MIBs,
>>I think the value of importance is clearly illustrated." I disagree
>>here because some proponents of importance state that "Priority
>>describes precedence while importance describes significance. Those are
>>two different concepts.". If that indeed is the case then you
>>conclusion seems wrong. If priority != importance then we should
>>clearly describe what importance is. I think saying importance ==
>>significance doesn't do the job. It is just a substitute of the word
>>using a thesaurus but not a definition of how this is used and why this
>>is a requirement. But please go ahead and come forward with a good
>>definition of it and a good justification of it as a requirement. We
>>can more concretely discuss about it then.
>>
>>Best,
>>
>>Rolf
>>
>>
>>
>>
>>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>>London W3 6BL | Registered in England 2832014
>>
>>
>>
>>
>>            -----Original Message-----
>>From: Mouli Chandramouli (moulchan) [mailto:moulchan@cisco.com]
>>Sent: Dienstag, 28. Februar 2012 10:02
>>To: Rolf Winter; Ira McDonald; Brad Schoening
>>Cc: eman mailing list
>>Subject: RE: [eman] EMAN-REQ: the notion of importance
>>
>>Rolf,
>>
>>I do not know what you disagree on.
>>
>>Initially, some folks jumped on the bandwagon it is not useful in
>>Energy Management.
>>And then a clear example of a similar term from the IETF PoE MIB was
>>shown.
>>
>>Now the question is definition of the term.
>>
>>I had mentioned in my email, that if it is a question of a clearer
>>definition of the term, that can be provided.
>>
>>Thanks
>>Mouli
>>
>>
>>-----Original Message-----
>>From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
>>Sent: Tuesday, February 28, 2012 2:05 PM
>>To: Mouli Chandramouli (moulchan); Ira McDonald; Brad Schoening
>>Cc: eman mailing list
>>Subject: RE: [eman] EMAN-REQ: the notion of importance
>>
>>Mouli,
>>
>>I disagree. There are people on the list that seem to disagree that
>>importance and priority are the same concept. Just the word
>>
>>
>>
>>          importance
>>
>>
>>            is utterly confusing. It could relate to security, cost,
>>power-up or
>>power-down priority etc. Somebody mentioned PoE and there I agree it
>>is clearly defined. Importance is not. Let us first clearly define
>>
>>
>>
>>          how
>>
>>
>>            it is used, then let’s make a requirement out of it in case
>>the WG
>>feels it should be. And let us not forget to make clear what it means
>>in the context of EMAN.
>>
>>Best,
>>
>>Rolf
>>
>>
>>NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
>>London W3 6BL | Registered in England 2832014
>>
>>
>>
>>
>>              -----Original Message-----
>>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
>>
>>
>>
>>
>>
>>          Behalf
>>
>>
>>
>>              Of Mouli Chandramouli (moulchan)
>>Sent: Dienstag, 28. Februar 2012 06:57
>>To: Ira McDonald; Brad Schoening
>>Cc: eman mailing list
>>Subject: Re: [eman] EMAN-REQ: the notion of importance
>>
>>Given the precedence of use of priority in other IETF MIBs, I think
>>the value of importance is clearly illustrated.
>>
>>
>>
>>Regarding Role, it is not intended to be an IANA registry.  This
>>concept is already used by deployments.  Should not be dismissed as
>>not useful.
>>
>>
>>
>>If the question is – clearer description of these terms, in the
>>requirements draft, it is possible to provide some text and also
>>
>>
>>
>>
>>
>>          how
>>
>>
>>
>>              these concepts can be useful.
>>
>>
>>
>>Thanks
>>
>>Mouli
>>
>>
>>
>>From: eman-bounces@ietf.org [mailto:eman-bounces@ietf.org] On
>>
>>
>>
>>
>>
>>          Behalf
>>
>>
>>
>>              Of Ira McDonald
>>Sent: Monday, February 27, 2012 11:15 PM
>>To: Brad Schoening; Ira McDonald
>>Cc: eman mailing list
>>Subject: Re: [eman] EMAN-REQ: the notion of importance
>>
>>
>>
>>Hi,
>>
>>Brad - good precedent - because it makes the "importance"
>>machine readable (and therefore useful).
>>
>>But since EMAN (and many other IETF WGs) have consistently backed
>>
>>
>>
>>            away
>>
>>
>>              from any standard definition of "role" (w/ behavior
>>semantics that
>>
>>
>>
>>            are
>>
>>
>>              predictable), a text string of "role" is useless (except in
>>a
>>vendor- or site-specific manner - out-of-scope IMHO).
>>
>>And I suggest that the "universe of things" is too diverse to lend
>>itself to an IANA registry of standard "role" keywords.
>>
>>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/b
>>l
>>ueroofmusic>
>><http://sites.google.com/site/blueroofmusic>http://sites.google.com/site/
>>h
>>ighnorthinc<http://sites.google.com/site/highnorthinc>
>><http://sites.google.com/site/highnorthinc>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 Mon, Feb 27, 2012 at 12:10 PM, Brad Schoening <brads@coraid.com>
>><mailto:brads@coraid.com>
>>wrote:
>>
>>Benoit,
>>
>>
>>
>>There is a precedence for doing this on the device in the PoE MIB,
>>rfc3621 which defines pethPsePortPowerPriority:
>>
>>   pethPsePortPowerPriority OBJECT-TYPE
>>    SYNTAX INTEGER   {
>>               critical(1),
>>               high(2),
>>               low(3)
>>     }
>>    MAX-ACCESS read-write
>>    STATUS current
>>    DESCRIPTION
>>        "This object controls the priority of the port from the
>>
>>
>>
>>
>>
>>          point
>>
>>
>>
>>                       of view of a power management algorithm.  The
>>priority
>>
>>
>>
>>
>>
>>          that
>>
>>
>>
>>                       is set by this variable could be used by a control
>>
>>
>>
>>
>>
>>          mechanism
>>
>>
>>
>>                       that prevents over current situations by
>>disconnecting
>>
>>
>>
>>
>>
>>          first
>>
>>
>>
>>                       ports with lower power priority.  Ports that
>>connect
>>
>>
>>
>>
>>
>>          devices
>>
>>
>>
>>                       critical to the operation of the network - like
>>the E911
>>         telephones ports - should be set to higher priority."
>>    ::= { pethPsePortEntry 7 }
>>
>>
>>
>>
>>
>>Brad Schoening
>>e: brads@coraid.com ⟐ m: 917-304-7190
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>              Redefining Storage Economics
>>
>>
>>
>>
>>
>>From: Benoit Claise <bclaise@cisco.com> <mailto:bclaise@cisco.com>
>>Date: Mon, 27 Feb 2012 05:17:24 -0600
>>To: eman mailing list <eman@ietf.org> <mailto:eman@ietf.org>
>>Subject: [eman] EMAN-REQ: the notion of importance
>>
>>
>>
>>Dear all,
>>
>>There is a discussion amongst the "EMAN requirements" authors right
>>now about the notion of importance.
>>We're trying to evaluate the requirements related to the
>>
>>
>>
>>
>>
>>          "importance".
>>
>>
>>
>>              The current draft version
>><http://tools.ietf.org/html/draft-ietf-
>>
>>
>>
>>            eman-
>>
>>
>>              requirements-05>  only mentions:
>>
>>
>>5.1.2.  Context information on powered entities
>>
>>   The energy management standard must provide means for retrieving
>>
>>
>>
>>            and
>>
>>
>>                 reporting context information on powered entities, for
>>example,
>>
>>
>>
>>            tags
>>
>>
>>                 associated with a powered entity that indicate the
>>powered
>>
>>
>>
>>            entity's
>>
>>
>>                 role, or importance.
>>
>>
>>So there are no justifications why the importance is required.
>>The people who want this, please provide some more
>>
>>
>>
>>            text/justifications
>>
>>
>>              Some extra questions:
>>- Is this importance specific to EMAN or is this generic also for
>>non Energy Objects?
>>- Importance is important related to ...?
>>
>>Regards, Benoit (as a contributor for the EMAN-REQ)
>>
>>
>>
>>
>>
>>_______________________________________________
>>eman mailing list
>>eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman
>>
>>
>>
>>
>>          _______________________________________________
>>eman mailing list
>>eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman
>>
>>
>>        _______________________________________________
>>eman mailing list
>>eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman
>>
>>
>>      _______________________________________________
>>eman mailing list
>>eman@ietf.orghttps://www.ietf.org/mailman/listinfo/eman
>>
>>
>>
>>
>>
>