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

From: Benoit Claise <[email-masked]>
Date: Mon, 24 May 2010 22:48:36 +0200

Hi Juergen,
> Hi Benoit,
>
> My basic comment is that I do not have a general problem with defining
> a network management architecture for energy management. I just do not
> think that a MIB definition document is the right place to do so.
>
> You are outlining the MIB module based on an (assumably well elaborated
> and appropriate) architecture that you have in mind.  It appears to be
> a good idea to specify this architecture in a separate document.
>
> But then we are probably not anymore talking about a single document
> but about a set including requirements, architecture, MIB module and
> one configuration and control. This would be a starting point for
> a new working group.
>    
This was discussed during the last OPSAWG meeting.
Based on question or comment from Dan, I remember explaining that there 
are multiple problems to be solved.
On one dimension, the use cases:

             Scenario 1: Switch with PoE endpoints......................17
             Scenario 2: Switch with PoE endpoints with further connected
             device(s)..................................................18
             Scenario 3: A switch with Wireless Access Points...........20
             Scenario 4: Network connected facilities gateway...........22
             Scenario 5: Data Center Network............................23
             Scenario 6: Power Consumption of UPS.......................25
             Scenario 7: Power Consumption of Battery-based Devices.....25

	These use cases can be categorized as:
	    Network elements (Routers and Switches)
	    Attached Devices
	    Converged Building Systems
	    Data Center
	    Home Energy Management
	    Smart Grid
	    etc...

One the other dimension, we have:
                         1. Monitoring
                         2. Discovery
                         3. Configuration
                         4. Fault

Ideally, we need to fill in all the cells of this table

A couple of points
- Presented like this, this will scare people. Or people will smile, 
trying that we want to boil the ocean. I remember Dan saying "you will 
be busy for the next 25 years ;-)"
    Also, it will certainly trigger some reactions from other SDOs, 
currently trying to solve similar problems.
- The monitoring is the easiest part, and I believe that we could have a 
(almost) common monitoring for most categories
     Think of power level or power quality as examples, which will be 
required everywhere.
- However, I'm convinced that:
     1. solving the power monitoring of network elements will not be 
sufficient
     2. introducing power monitoring without at least thinking of the 
configuration part is just not good enough
- We have introduced some concepts such as parent/child, importance, 
keywords, domain, etc. in the monitoring part. In other words, we are 
taking the experience we gained from delivering that architecture and 
providing monitoring with information we found is needed. And we know 
that those concepts could be applied to attached devices, connected 
buildings, date center. Potentially home energy management, potentially 
smart grid (hence the reason to reference IEC objects as much as possible).

> On 20.05.10 22:08  "Benoit Claise"<[email-masked]>  wrote:
>    
>> Hi Juergen, dear all,
>>
>> Thanks for reading the draft.
>>
>> The parent/child concept is a new concept, this is true.
>> However, this is an important one, and the primary one I which I would
>> like to focus now.
>>      
> Do I understand the text below correctly that you want to use this
> concept also for power control of devices.
This is what we do today.
> If yes, I would suggest
> discussing the energy parent / energy child concept in a separate
> document which can be referred to by all other ones using it.
>    
I let the WG chairs provide guidance on this.
>    
>> When we created
>> http://www.watersprings.org/pub/id/draft-quittek-power-monitoring-requirements
>> -00.txt,
>> I thought that this document was there to collect feedback for the
>> community regarding power&  energy management.  As such, I thought this
>> version 00 was only a first step.
>> I learnt during the last IETF that your goal was to let this draft die.
>>      
> Yes and no. I did not intend to have a separate requirements document.
> As long as requirements apply only to the MIB definition,
See my previous point, repeated here:

    - However, I'm convinced that:
         1. solving the power monitoring of network elements will not be
    sufficient
         2. introducing power monitoring without at least thinking of
    the configuration part is just not good enough

> I would like
> to include a lot of the text from this document in the MID document.
> I did not do so in the first version of the MIB module, because then
> I would have to add all authors from the requirements document there.
> But when we do our merger, this will not be an issue anymore and we can
> include text on requirements.
>
>    
>> My concern is the following: this requirement draft considers that the
>> target devices are: "all components of acommunication network including
>> routers, switches, middleboxes, hosts, etc.". However, with
>> claise-energy-monitoring-mib-03, we try to solve a bigger problem.
>>      
> Yes.
> We should agree at an early stage which is the problem we want to solve.
> I had a question on the last slide that I showed in Anaheim:
> "Shall we include smart meters at home in our scope?"
> And you extend this to building networks and smart grid.
> I felt the answer at the Anaheim session was a no, but I may be wrong.
>
> But if we do want to support smart grids and (non-IP) building networks,
> we should make sure we get expertise from these areas for reviewing our
> requirements and solutions.
>    
Note: I remember that Joshua, from one utility company, went to the 
microphone during the OPSAWG meeting, expressing that we want to solve 
more than what the requirements cover.
>    
>> Therefore, we have added our target devices at
>> http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#section-3
>>
>>
>>           The requirements for power and energy monitoring for networking
>>           devices are specified in [POWER-MON-REQ
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#ref-POWER-MO
>> N-REQ>].  The requirements in
>>           [POWER-MON-REQ
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#ref-POWER-MO
>> N-REQ>] cover devices that typically make up a
>>           communications network such as such as switches, routers, and
>>           various connected endpoints. For power monitoring to be useful,
>>           a specification should also be applicable to facility meters,
>>           power distribution units, gateway proxies for commercial
>>           building control, home automation devices and devices that
>>           interface with the utility and/or smart grid.  Due to this fact,
>>           the scope of the MIB modules in this document is broader than
>>           that specified in [POWER-MON-REQ
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#ref-POWER-MO
>> N-REQ>].  Several scenarios that cover
>>           these broader use cases are presented later inSection 6
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#section-6>
>> -
>>           Implementation Scenarios.
>>
>> I mean: what we want to achieve is a common MIB module for all use cases
>> above.
>>      
> I would very much like to support building networks.
> However, as said above, how would we get reviews from people experienced
> in the area?
>    
We're working closely with our connecting building experts in our company.
>    
>> Reporting the power and energy of routers/switches/hosts is not where
>> the big gain in terms of savings will be. The gain will be in  gateway
>> proxies for commercial building control, home automation devices and
>> devices that interface with the utility and/or smart grid.
>> If I take the example of building control, you know that the most meters
>> don't speak IP/SNMP. Sure, there are people working on the Internet of
>> Things, but it will not be for tomorrow, specifically not in building
>> management, where the change cycle is at least 10 or 15 years.
>> Also, scalability is a big concern. The NMS can't be polling every
>> single meter, or pushing policies to every single device. So we need a
>> mediator, doing the data aggregation, and this should be in the network
>> somewhere. Today it's done with proxy: proprietary or BACNET one one
>> side and IP on the other one.
>>
>> Btw, I want to stress that this parent/child is not an architecture out
>> of the blue. We have this implemented in shipping products, and also in
>> production networks.
>>      
> And it makes perfect sense in building networks.
>
>    
>> What we did with this draft is basically built on our experience and
>> improved our proprietary MIB.
>> So our customers and partners see some values in it.
>>
>> See also inline
>>
>>      
>>> Dear all,
>>>
>>> I am not convined that we should use the power parent / power child
>>> concept that is proposed in draft-claise-energy-monitoring-mib.
>>>
>>> The basic proposed idea is that one device reports on the energy
>>> consumption of another devices. This would be an extension of our
>>> network management architecture that I would like to be discussed
>>> in more detail considering all consequences. The architectural
>>> aspects of this are certainly worth creating separate document.
>>> Introducing architecture extensions as part of a MIB module
>>> definition does not appear to be the right way of doing it.
>>>
>>>
>>> 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.
>    
>> Second of all, a protocol such as DASH can report its non operational
>> states to the switch, while if the PC is non operational, SNMP will not
>> be operational.
>>      
> Please excuse my ignorance:
> Doesn't DASH run over SOAP?
> Why would SOAP be available and SNMP not?
>    
Let me park this one for now.
I'll come back to you.
>    
>> Third of all, the reason of monitoring power&  energy is to apply
>> policies later on. Most probably dynamic policies. And I'm convinced
>> that the NMS configuring dynamically every single device one at the time
>> is not a valid model anymore.
>>      
> Then let's discuss what is a valid model for this case.
> You propose a mid-level manager between NMS and managed node.
> This is a valid concept.
> However, we should then discuss this model more explicitly.
>    
Agreed.
1. which problem do want to solve -> we explained this in our draft
2. what do we need to solve this -> parent/child is one of the concepts.
>    
>>> 2. At a PoE power sourcing equipment (PSE) it appears to be
>>> sufficient that the PSE reports for all its Ethernet ports
>>> the power that is provided at the port. We do not need a
>>> parent-child concept here.
>>>
>>>        
>> This is the more simplistic case (scenario 1 below)
>> Again, what we want to focus on is:
>>
>>          6
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#section-6>.
>> Implementation Scenarios...................................16
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#page-16>
>>              Scenario 1: Switch with PoE endpoints......................17
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#page-17>
>>              Scenario 2: Switch with PoE endpoints with further connected
>>              device(s)..................................................18
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#page-18>
>>              Scenario 3: A switch with Wireless Access Points...........20
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#page-20>
>>              Scenario 4: Network connected facilities gateway...........22
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#page-22>
>>              Scenario 5: Data Center Network............................23
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#page-23>
>>              Scenario 6: Power Consumption of UPS.......................25
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#page-25>
>>              Scenario 7: Power Consumption of Battery-based Devices.....25
>> <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#page-25>
>>      
> I see your point.
> But again, I think that this is more than we should put into a MIB module
> specification document.
>    

As always, thanks for your comments.

Regards, Benoit.
>    
>>> We cannot assume that all PoE devices are capable of detecting by
>>> themselves which device is connected to which port (which would
>>> be required for the parent-child model). For endspan PSEs, this
>>> is not always given, for midspan PSE, it is rather an uncommon
>>> feature.
>>> However, if information on the connected devices is available,
>>> this can typically be detected by an NMS by reading the LLDP and
>>> LLDP-MED MIB modules. There is no need to code this information
>>> also into the energy MIB module.
>>>
>>>       Juergen
>>> _______________________________________________
>>> OPSAWG mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/opsawg
>>>
>>>        
>>

---

From: "Juergen Quittek" <[email-masked]>
Date: Sat, 29 May 2010 11:05:58 +0200

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]