Subject: Re: [OPSAWG] Proposed draft for Energy, Efficiency and Carbon Emission

From: Benoit Claise <[email-masked]>
Date: Sun, 21 Mar 2010 20:42:00 -0700

Hi Dave,
> Hi,
>
> Let me stroke my grey beard and pontificate a little ;-)
>
> One of the core tenets of SNMP is to keep MIB modules simple, so the
> managed device can focus on doing its primary job rather than
> performing management calculations.
>
> > From the BRIDGE-MIB (RFC1493), summarizing similar text in MIB-I
> (RFC1156) and MIB-II (RFC1213):
>
> "   To be consistent with IAB directives and good engineering
> practices,
>     an explicit attempt was made to keep this MIB module as simple as
>     possible.  This was accomplished by applying the following criteria
>     to objects proposed for inclusion:
>
>     1. Start with a small set of essential objects and add only as
>        further objects are needed.
>
>     2. Require that objects be essential for either fault or
>        configuration management.
>
>     3. Consider evidence of current use and/or utility.
>
>     4. Limit the total number of objects.
>
>     5. Exclude objects that are simply derivable from others in this or
>        other MIB modules.
>
>     6. Avoid causing critical sections to be heavily instrumented.  The
>        guideline that was followed is one counter per critical section
>        per layer.
> "
>
> Following #1, I don't agree with the suggestion
> "    It will be a good idea to combine all the MIBs which are being
> proposed around this area into a single draft (RFC) so that with
> single implementation, nodes can comply and serve different needs like
> smart meters, carbon calculators and power management systems."
>
> We should look at the proposed objects and decide which are essential.
> We aren't looking to standardize "any object that somebody might
> possibly want to use in the future"; we are trying to standardize the
> set of essential objects necessary for managing the targeted devices,
> so MIB modules are kept as simple as possible.
>
> If somebody believes there are objects that would be useful beyond the
> set of essential objects, they can supplement the essential MIB module
> with experimental or private MIB modules. From MIB-II (RFC1213):
>
> "  This approach of taking only the essential objects is NOT
>     restrictive, since the SMI defined in the companion memo provides
>     three extensibility mechanisms: one, the addition of new standard
>     objects through the definitions of new versions of the MIB; two,
> the
>     addition of widely-available but non-standard objects through the
>     experimental subtree; and three, the addition of private objects
>     through the enterprises subtree.  Such additional objects can not
>     only be used for vendor-specific elements, but also for
>     experimentation as required to further the knowledge of which other
>     objects are essential.
> "
>
> Per #3 and #4, we should limit the number of objects, and choose those
> that are essential by considering evidence of current use and/or
> utility.
>
> Per #5, a MIB module typically does not contain calculated
> expressions, such as consumption and utilization. The agent should
> provide the raw data (usually simple counters) that can be used for
> such calculations, and a management application can then do the
> calculations offline.
>    
Well, maybe that's not the right choice anymore: too many devices with 
too many OID to poll on regular basis.
For example, a MIB OID for the link utilisation would be have been 
pretty useful.
Instead of graphing the ifInOctets and ifOutOctets every 5 minutes in 
order to see the trend, I use the EXPRESSION-MIB to create the OID + 
RMON event when the threshold of 50% is crossed for one hour (or 
whatever numbers suit you). That way, I receive a SNMP notification when 
it's time to upgrade my WAN link.
I have that working in my lab, but this solution is too complex for most 
of my customers.

Regards, Benoit.

> This approach is also important because different applications serve
> different purposes. Have the agent provide the essential raw data, and
> then let the applications do whatever
> calculations/correlation/comparisons are needed to suit the purpose of
> the application.
>
> Per #6, we want to minimize how much management work the critical
> sections are doing by limiting the number of objects and minimizing
> the amount of work that must be done to provide the objects. Simple
> counters are preferred over complex calculated values.
>
> Let's keep these basic tenets in mind as we develop these power MIB
> modules.
>
> dbh
>
>    
>> -----Original Message-----
>> From: [email-masked]
>> [mailto:[email-masked]] On Behalf Of Juergen Quittek
>> Sent: Thursday, February 18, 2010 6:06 AM
>> To: sreekanthss; [email-masked];
>> [email-masked]; [email-masked]
>> Subject: Re: [OPSAWG] Proposed draft for Energy,Efficiency
>> and Carbon Emission
>>
>> Dear Sreekanth, Krishna and Sahana,
>>
>> Here is my review of your draft
>> draft-sreek-powerconsumption-mib-01:
>>
>> 0. General comment:
>>     Do I understand correctly, that this draft proposes a way
>>     to determine a device's energy consumption by observing the
>>     utilization and deriving the energy consumption by a very simple
>>     heuristic function that maps utilization to energy consumption?
>>     If yes, this should be explained well in the draft.
>>
>> 1. Section 1, first two sentences:
>>    "The carbon emission for a device is calculated as a function of
>>     Energy Consumed (Power in Watts) and efficiency (which is
>>      
> dependent
>    
>>     on throughput).  Mathematically the carbon emission is directly
>>     proportional to Energy Consumption Rate (ECR)."
>>
>>     These sentences are contradicting. Obviously the first one is
>>      
> wrong
>    
>>     and the second one is right. The carbon emission is a function of
>>     the to the energy consumption. You don't need the efficiency in
>>     this function as you say correctly in the second sentence.
>>
>> 2. Section 1, third sentence:
>>     How do you define full, half and idle utilization. If you don't
>>     define it in your draft, please five a reference to a standards
>>     document that does so. Otherwise an implementer would not know
>>     what to do.
>>     [For example for a router, I would be interested to learn how you
>>     can define full and idle utilization. I hardly observed any
>>      
> router
>    
>>     that is not sending packets every few seconds and also I hardly
>>     observed any router that sends and receives continuously at full
>>     line speed on ALL interfaces.]
>>
>> 3. Section 1, fourth sentence:
>>    "For all practical purpose, the carbon emission from a device
>>     is calculated considering how much percentage of time the device
>>     has been utilized full, half and idle."
>>     What if a network is designed to run devices typically at a load
>>     of roughly 30%? Would this be half loaded? How would you compare
>>     this to a device running continuously at roughly 65%?
>>
>> 4. Section 1, fifth senstence:
>>     "Mib" ->  "MIB"
>>     "successfully" ->  ""
>>
>> 5. Section 4, lines 1-2:
>>     "The global MIB variables defined are for the system as a
>> whole and a
>>     table of MIBs are being defined for the indpendent devices
>> within the
>>     system."
>>     What are "global MIB variables"?
>>     All accessible objects are within a single table in this
>> MIB module.
>>     It is not a "table of MIBs".
>>     What are "independent devices within the system"?
>>     "indpendent" ->  "independent"
>>
>> 6. Section 5, line one:
>>     This MIB module is not "a part of EntityMIB". You may want to
>>      
> call
>    
>>     it a sparse augment, because it uses the same index as the
>>     entPhysicalTable.
>>
>> 7. DESCRIPTION clause of powerConsumptionTable:
>>     "You don't measure a carbon footprint". You measure energy
>>     consumption (or time spent in different utilization states?).
>>
>> 8. DESCRIPTION clause of powerConsumptionEntry
>>     "For any instance in the entityMIB for which
>>     entPhysicalContainedIn is 0, then row in this
>>     table is mandatory"
>>     This is a tough requirement. What if you have a few entities for
>>     which you cannot measure? If your statement remains as it is you
>>     could not build a compliant implementation of your MIB module in
>>     such a case.
>>
>> 9. DESCRIPTION and SYNTAX clauses of
>> powerEnergyConsumptionFull/Half/Idle
>>     DESCRIPTION and SYNTAX clauses of powerThroughputFull/Half/Idle
>>     DESCRIPTION and SYNTAX clauses of powerEffeciencyFull/Half/Idle
>>     You use OCTET STRING as SYNTAX. This is underspecified.
>>     What encoding would you use? Float, integer, ASCII?
>>
>> 10. DESCRIPTION clauses of powerEnergyConsumptionFull/Half/Idle
>>     You state "Energy Consumption measured in watts when resource
>>     is running at full/half/idle capacity".
>>     Is this an ongoing measurement or is this a constant value
>>     measured once for the current configuration of the device?
>>
>> 11. DESCRIPTION clauses of powerThroughputFull/Half/Idle
>>     Again: is this actually measured throughput or is it a constant
>>     value measured once for the current configuration of the device?
>>
>> 12. DESCRIPTION clause of powerThroughputFull
>>     How do you define full throughput? All interfaces running at
>>     full line speed? Routing engine fully loaded? All monitoring
>>     capabilities activated?
>>
>> 13. DESCRIPTION clauses of powerEffeciencyFull/Half/Idle
>>     How do you define efficiency? Watts per bit? In percent?
>>     As a value (0..1)?
>>
>> 14. DESCRIPTION and SYNTAX clauses of powerLoad:
>>     You state: "Load is the total power consumption
>>     which is measured as a function of load and throughput"
>>     Load is a function of load and throughput? This would be
>>     a recursive function :-)
>>     Again, OCTET STRING is not sufficient. How do you encode?
>>     What are your units? Percent?
>>
>> 15. DESCRIPTION powerCo2Emission:
>>     How would you determine this? It depends on the power source.
>>     If you use solar power or atomic power, the emission is very
>>     low. How would you calculate it? Would you just include emissions
>>     from producing energy or also from cooling the device? What about
>>     emissions from building the device?
>>
>> 16. DESCRIPTION clauses of powerEffeciencyPercentageFull/Half/Idle
>>     "Percentage of the equipment running on full load"
>>     Is it the percentage of components in the device running
>>     full/half/idle?
>>     Or is it the percentage of time for each utilization?
>>
>> Kind regards,
>>
>>      Juergen
>>
>>
>>
>>
>>
>> On 29.01.10 12:56  "sreekanthss"<[email-masked]>  wrote:
>>
>>      
>>> Hi Juergen,
>>>
>>>     Thanks for the comments. We had submitted the second
>>>        
>> version of the MIB
>>      
>>> draft.
>>>
>>>
>>>        
>> https://datatracker.ietf.org/idst/auto_post.cgiauth_key=uzSQjO
>> gFHn07ZmpJHGqCjl
>>      
>>> zAiciyPt4Z&submission_id=20883
>>>
>>> Below are the major changes :
>>>
>>> i)  As per your suggestion we had considered the entity
>>>        
>> MIB. Now, the new
>>      
>>> draft (v01) has a dependency with RFC4133. The
>>>        
>> implementation caution is,
>>      
>>> anyone who is going to implement the new suggested MIB
>>>        
>> should have support for
>>      
>>> entity MIB. While, our first version was giving the
>>>        
>> flexibility to implement
>>      
>>> the new MIBs independently.
>>>
>>> ii) Since the table index is replaced by the physical table
>>>        
>> index of entity
>>      
>>> MIB, the limitation of 200 is removed.
>>>
>>> Answering your other queries :
>>>
>>> -Regarding the Octet string, we need octet string because
>>>        
>> we have to support
>>      
>>> decimal values.
>>>
>>> -Regarding the C02 emission, you are right that independent
>>>        
>> hardware devices
>>      
>>> cannot report this value. This is a calculated value from
>>>        
>> the Power (Energy)
>>      
>>> and Efficiency at a particular instance. The idea is to
>>>        
>> provide this MIB for a
>>      
>>> device to calculate and report the value.
>>>
>>> -The classification of idle, half and full are simplistic
>>>        
>> because they are
>>      
>>> approximated for the calculation of ECR (Energy Consumption
>>>        
>> Rate) and is the
>>      
>>> widely used method for data nodes.
>>>
>>> Thanks,
>>> Sreekanth, Krishna and Sahana
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder
>>>        
>> [mailto:[email-masked]]
>>      
>>> Sent: Wednesday, January 20, 2010 5:31 PM
>>> To: sreekanthss
>>> Cc: [email-masked]
>>> Subject: Re: [OPSAWG] Proposed draft for Energy, Efficiency
>>>        
>> and Carbon
>>      
>>> Emission
>>>
>>> On Wed, Jan 20, 2010 at 10:48:10AM +0100, sreekanthss wrote:
>>>
>>>        
>>>> I and two of my collegues had submitted the below draft
>>>>          
>> (dated 6th Jan,
>>      
>>>> 2010).
>>>>
>>>>
>>>>          
> https://datatracker.ietf.org/idst/status.cgi?submission_id=20434
>    
>>>> This draft proposes the MIB structures for power (energy),
>>>>          
>> efficiency and
>>      
>>>> utilization complying to the carbon footprint calculation
>>>>          
>> logic  for data
>>      
>>>> network elements.
>>>>          
>>> The MIB modules has a number of flaws. For example, you do not
>>> represent numbers using OCTET STRING (SIZE(1..8)). It is unclear
>>>        
> why
>    
>>> some objects are read-write and some read-only. The MIB ignores
>>> existing MIB modules and reinvents part of the ENTITY-MIB. Usage
>>>        
> of
>    
>>> DisplayString is pretty much outdated (and why the length limit of
>>> 80?) or the tabe index limit of 200? The duplication of scalars
>>>        
> and
>    
>>> the table looks strange. And finally, I doubt that hardware
>>>        
>> pieces can
>>      
>>> report CO2 emission because that depends how the energy consumed
>>>        
> by
>    
>>> the hardware was generated. The classification into idle, half,
>>>        
> and
>    
>>> full also seems to be way to simplistic given today's power
>>>        
>> management
>>      
>>> schemes.
>>>
>>> /js
>>>
>>> --
>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen,
>>>        
> Germany
>    
>>> Fax:   +49 421 200 3103<http://www.jacobs-university.de/>
>>>
>>> **************** CAUTION - Disclaimer *****************
>>> This e-mail contains PRIVILEGED AND CONFIDENTIAL
>>>        
>> INFORMATION intended solely
>>      
>>> for the use of the addressee(s). If you are not the
>>>        
>> intended recipient, please
>>      
>>> notify the sender by e-mail and delete the original
>>>        
>> message. Further, you are
>>      
>>> not
>>> to copy, disclose, or distribute this e-mail or its
>>>        
>> contents to any other
>>      
>>> person and
>>> any such actions are unlawful. This e-mail may contain
>>>        
>> viruses. Infosys has
>>      
>>> taken
>>> every reasonable precaution to minimize this risk, but is
>>>        
>> not liable for any
>>      
>>> damage
>>> you may sustain as a result of any virus in this e-mail.
>>>        
>> You should carry out
>>      
>>> your
>>> own virus checks before opening the e-mail or attachment.
>>>        
>> Infosys reserves the
>>      
>>> right to monitor and review the content of all messages
>>>        
>> sent to or from this
>>      
>>> e-mail
>>> address. Messages sent to or from this e-mail address may
>>>        
>> be stored on the
>>      
>>> Infosys e-mail system.
>>> ***INFOSYS******** End of Disclaimer ********INFOSYS***
>>> _______________________________________________
>>> OPSAWG mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>        
>>      
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>