Subject: Re: [OPSAWG] power parent / power child in claise-energy-monitoring-mib-03

From: Benoit Claise <[email-masked]>
Date: Thu, 10 Jun 2010 16:45:20 +0200

Hi Juergen,

[sorry for the delay in replying to you. I'm going through all OPSAWG 
emails now]

The concept of parent/child can most probably be used for something else 
than energy management.
You mentioned "device providing any service". Sure that's important, but 
even today with individual devices to which we have access, this is a 
difficult topic
So, I would not like to extend the scope right now beyond energy 
management, you know to something so big that it will take years to 
standardize.

You mentioned the DISMAN WG, now concluded.
My view of DISMAN is that this WG was 5 to 10 years to early.
Let me explain. Years ago, the number of devices to manage was low (even 
if we considered the number high at that point in time). Therefore the 
management was still easy (even if we considered otherwise at that 
time). These days, we HAVE TO put more intelligence in the network.
For example:
- with scripting
- with the routers monitoring themselves. "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." is 
one example I mentioned on this list some time ago.
- etc...
A second aspect why DISMAN was too early is that this is now that there 
is a converge of communication around IP: connected building, home 
automation, smart grid, internet of tedhings, you-name-it. This implies 
that, these days there are plenty of proxies, while waiting for IP to be 
ubiquitous

Regards, Benoit.

> Hi Benoit,
>
> I have a general question on the parent/child concept.
>
> Is the parent/child concept specific to energy management? Or do you see it
> rather as a generic distributed management concept applicable also to other
> management functions?
>
> I am asking because you said that the parent/child would release the NMS (or
> BMS, building management system ;-) from monitoring all children, see below.
> I suspect that in general you want to know more about a managed devices than
> just its power state and consumed energy. There are other, more important
> states to be monitored:
>    - Is the device providing any service?
>    - Is it working well or in a fault state?
>    - etc.
>
> If we delegate reporting of the device's states to its parent then we should
> think about discussing the parent/child concept in a more general context.
> Then it would appear like an issue for the DISMAN WG.
>
> Thanks,
>
>      Juergen
>
>
> On 24.05.10 22:48  "Benoit Claise"<[email-masked]>  wrote:
>
>     [snip]
>
>    
>>>>> Some of the use cases are questionable.
>>>>>
>>>>> 1. Why would a PC report its power consumption to another device
>>>>> just for the purpose that this device creates MIB objects for
>>>>> reporting on behalf of the PC? The easier and straight forward
>>>>> way would be the PC reporting power consumption in its own MIB
>>>>> modules.
>>>>> If there would be a need for data collection and aggregation
>>>>> of energy information between the managed devices and an NMS,
>>>>> then we aready have means for this which are generic for any
>>>>> kind of managed object. We do not need special support for it
>>>>> within individual MIB modules.
>>>>>
>>>>>
>>>>>            
>>>> If I take the specific example of PC that you mentioned below, there is
>>>> some value for a switch to report the PC power consumption.
>>>> First of all scalability: polling every single device in a network is a
>>>> big task already, and now if we add every single PC...
>>>>
>>>>          
>>> It should not make a big difference. The number of managed objects to be
>>> retrieved should be the same in both cases.
>>>
>>>        
>> On the top of the monitoring the power of every single router/switch,
>> you would also have to monitor all attached devices.
>>