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

From: "Juergen Quittek" <[email-masked]>
Date: Wed, 19 May 2010 08:39:29 +0200

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.

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.
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

---

From: Benoit Claise <[email-masked]>
Date: Thu, 20 May 2010 15:08:28 +0200

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.

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.

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.
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-MON-REQ>].  The requirements in
         [POWER-MON-REQ  <http://tools.ietf.org/html/draft-claise-energy-monitoring-mib-03#ref-POWER-MON-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-MON-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.

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.
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

> 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...
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.
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.
> 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>

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg
>

---

From: "Juergen Quittek" <[email-masked]>
Date: Thu, 20 May 2010 22:25:35 +0200

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.

> However, this is an important one, and the primary one I which I would

Do I understand the text below correctly that you want to use this
concept also for power control of devices. 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 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, 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.

> 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.

>          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
>          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>
> -

I would very much like to support building networks.
However, as said above, how would we get reviews from people experienced
in the area?

> of the blue. We have this implemented in shipping products, and also in

And it makes perfect sense in building networks.

> 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.

> states to the switch, while if the PC is non operational, SNMP will not

Please excuse my ignorance:
Doesn't DASH run over SOAP?
Why would SOAP be available and SNMP not?

> 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.

>         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>
>             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.

---

From: "Brad Schoening" <[email-masked]>
Date: Fri, 28 May 2010 11:59:51 -0400

Juergen,

Just a few points:

1. DMTF DASH (http://www.dmtf.org/standards/mgmt/dash) uses the DMTF's Web
Services for Management (WS-Management), which is indeed SOAP based.  DASH
is a desktop management standard with one of its key goals to replace
Wake-on-LAN with a true management protocol.  DASH integrates the hardware,
firmware and OS to enable management of in-service *and* out-of-service
devices (i.e, when a PC is in a 'hibernate' state), so it's really quite
different from SNMP management.  DASH runs on the network card and is
designed to be "light weight".

2. Networked building devices can be IP based, such as BACnet/IP, but they
seldom support SNMP.  However, even non-IP building protocols such as
BACnet/TP and ACRNET can be accessible to IP based devices.  So, I don't see
it as an architectural stretch to allow attributes for these to be reported
upon. Our proposal is much like how DMI allowed DMI & SNMP to interoperate:
 
	"DMI can co-exist with SNMP and other management protocols. For
example, when an SNMP 
	query arrives, DMI can fill out the SNMP MIB with data from its MIF.
A single workstation 
	or server can serve as a proxy agent that would contain the SNMP
module and service an 
	entire LAN segment of DMI-capable machines."

For our purposes, our model would allow (but not require) this statement to
be made:

	BACnet can co-exist with the SNMP energy management protocol. For
example, when an SNMP 
	query arrives, the gateway server can fill out the SNMP MIB with
data derived from BACnet objects. 
	single gateway can serve as a proxy agent that would contain the
BACnet information for 
	an entire BACnet broadcast domain of BACnet-capable devices.

3. My understanding at the meeting in Anaheim was a little different from
yours.  I understood that building devices and smart meters were definitely
in scope for these requirements.  First, sub-meters are critical to the
concept "you can't manage what you don't measure."  We should support
sub-meters used to monitor and audit energy use, without necessarily
supporting revenue meters used to bill for electrical usage.  Second, within
a building, the MIB should enable management what can be considered a
'micro-grid' of building and IT systems as required by Energy Management
Systems (EMS).

Regards,

Brad Schoening

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Juergen Quittek
Sent: Thursday, May 20, 2010 4:26 PM
To: Benoit Claise
Cc: [email-masked]
Subject: Re: [OPSAWG] power parent / power child in
claise-energy-monitoring-mib-03

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.

> However, this is an important one, and the primary one I which I would 

Do I understand the text below correctly that you want to use this concept
also for power control of devices. 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.

> When we created
> http://www.watersprings.org/pub/id/draft-quittek-power-monitoring-requ
> irements
> -00.txt,
> community regarding power & energy management.  As such, I thought 
> this version 00 was only a first step.

Yes and no. I did not intend to have a separate requirements document.
As long as requirements apply only to the MIB definition, 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.

> target devices are: "all components of acommunication network 
> including routers, switches, middleboxes, hosts, etc.". However, with 

Yes. 

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.

> 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?

> 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.
> 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.

>> 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.
>> 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...

> states to the switch, while if the PC is non operational, SNMP will 
> not be operational.

> that the NMS configuring dynamically every single device one at the 
> time is not a valid model anymore.

>> 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
>
.

I see your point.

>> 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