Subject: Re: [eman] Comments on Power Management Architecture

From: JinHyeock Choi <[email-masked]>
Date: Tue, 2 Nov 2010 20:28:22 +0900

Hi John

thanks for your reply
with which, in combination with the updated draft,
I can grasp more clear picture.

> [jparello] That's true however the assumption is that the communication
> between the NMS and POwer Monitors would be via SNMP. So the Architecture is
> a description of what we need that is then implemented via SNMP data model.

Now with explicit reference model in ver-02, I can see it clear.

>> For example I guess that
>>
>>   Large time series of energy consumption values of a Power Monitor Child
>>   are reported by Power Monitor Parent to NMS though IPFIX (or Syslog)
>>
>> but can’t be sure that’s right.
>
> [jparello] The group has not put a requirement for IPFIX but that could be
> brought up the the WG meeting.

ok.

>> BTW which entity is IP enabled?
>> Which entity understands IP to report to NMS (via SNMP)?
>> All Power Monitor or Power Monitor Parent?
>
> [jparello] The assumption is that we are starting with SNMP first so a
> Parent power monitor would implement the mib and then and subtended devices
> that did not or could not implement SNMP would be aggregated to the Power
> Monitor parent.

ok. I assume it’s Power Monitor Parent

>>> From the document, I assume either
>>
>> i) a Parent provides a Child power (as in PoE) or
>> ii) a Child reports power information to its Parent.
>
> [jparello] The parent may or may not provide power to the child. For
> instance a PoE switch would have PoE endpoints as children and in this case
> would clearly provide power to the child. In the case of a wireless
> controller the controller may be the parent of the wireless APs but they may
> draw power directly from a wall outlet.

I assume
Power Monitor Children reports its power information to its Parent
and may or may not draw power from the Parent.

thanks for your clarification & see you in Beijing

best regards

JinHyeock

On Sat, Oct 16, 2010 at 3:43 AM, john parello <[email-masked]> wrote:
> Hi JinHyeock,
>
> Thanks for the feedback and review. We have made changes to help clarify
> some of your point and it will be posted to the list.
>
> Please see inline for our thinking on the various points.
>
> On 10/5/10 11:05 PM, JinHyeock Choi wrote:
>>
>> Hi
>>
>> Here are some comments.
>>
>> 1. Communication model
>> I wish the communication model between Power Monitor&  NMS
>> (to which information would be ultimately reported, I assume).
>> is more clearly presented.
>>
>> The power monitoring information is defined in detail
>> but it’s not clear
>> which entity report that information
>> to which entity through which mechanism.
>>
>
> [jparello] That's true however the assumption is that the communication
> between the NMS and POwer Monitors would be via SNMP. So the Architecture is
> a description of what we need that is then implemented via SNMP data model.
>
>> For example I guess that
>>
>>   Large time series of energy consumption values of a Power Monitor Child
>>   are reported by Power Monitor Parent to NMS though IPFIX (or Syslog)
>>
>> but can’t be sure that’s right.
>>
>
> [jparello] The group has not put a requirement for IPFIX but that could be
> brought up the the WG meeting.
>
>> Though there are some related contents in 7. Fault Management,
>> I wish more clear statements&  elaboration.
>>
>> For more clear communication model,
>> it would help to add some paragraphs about
>>
>> 1) participating entities
>>     as defined in Nordman I-D .
>>
>>     Participating entities are monitoring systems that receive
>>     information and networked devices that provide information on energy
>>     consumption and power state information concerning themselves or
>>     potentially also other devices.
>>
>
> [jparello] Yes I think we have this covered in the definition of Power
> Monitor itself.
>
>> BTW which entity is IP enabled?
>> Which entity understands IP to report to NMS (via SNMP)?
>> All Power Monitor or Power Monitor Parent?
>>
>
> [jparello] The assumption is that we are starting with SNMP first so a
> Parent power monitor would implement the mib and then and subtended devices
> that did not or could not implement SNMP would be aggregated to the Power
> Monitor parent.
>
>> 2) monitoring model
>>     SNMP/ MIB or IPFIX
>>     as presented in [POWER-MON-REQ].
>>
>> BTW [POWER-MON-REQ] propose to (in Sec 6) develop
>> a standard for pull-based power state monitoring
>> and push based one (with IPFIX or Syslog).
>> About which, this document won’t make any statement?
>>
>
> [jparello] See previous that IPFIX could be brought up as a WG item IMO.
>
>> 2. Power Monitor Parent&  Child
>> There are some ambiguities regarding
>> Power Monitor Parent&  Child relationship.
>>
>> First it’s not clear which makes two entities
>> Power Monitor Parent&  Power Monitor Child.
>>
>
> [jparello] We have added this in the next revision about to be posted.
>
>>> From the document, I assume either
>>
>> i) a Parent provides a Child power (as in PoE) or
>> ii) a Child reports power information to its Parent.
>>
>
> [jparello] The parent may or may not provide power to the child. For
> instance a PoE switch would have PoE endpoints as children and in this case
> would clearly provide power to the child. In the case of a wireless
> controller the controller may be the parent of the wireless APs but they may
> draw power directly from a wall outlet.
>
>> However, in 4.3, it’s written
>>
>>         A Power Monitor Child can be fully dependent on the Power
>>         Monitor Parent (as in the case of Power Over Ethernet) or
>>         independent from the parent (such as a PC connected to a
>>         switch).
>>
>> What makes a PC a child to a switch?
>> Just because it’s connected to the switch or
>> is it assumed that the PC report its power usage to the switch?
>>
> [jparello] Yes. The idea is that some device that is capable of
> communicating power usage could act as an aggregation point for other
> subtended devices. So a switch could be a parent for connected PCs. One
> could have one PC that is the parent and SNMP capable and other PCs that are
> not capable as children. The proposed architecture allows for one device
> that can communicate power information to an NMS can act as a parent or
> aggregation point for others that cannot communicate to the NMS.
>
>
>> Also what if a Parent provides a Child a power
>> but the Parent neither monitor the Child’s power usage
>> nor the Child makes no report to the Parent?
>>
>
> [jparello] In that case we envision the parent to at least provide the
> nameplate power characteristics of itself or even better of the children.
> The power usage data model allows the Power Monitor parent to describe how
> and to what accuracy the usage is reported. In this scenario it would be a
> poor participant but could still presumably report nameplate power.
>
>> In the above case,
>> The Parent plays no role in the Child’s Power Monitoring.
>>
>
> [jparello] see above.
>
>> Here are some more questions.
>>
>> 1) Can a Child have more than one Parents?
>> For example a IP phone may get a power from PoE
>> but report its power usage to a building gateway.
>>
>
> [jparello] The parent is defines as the device that aggregates and provides
> reporting it may not be the source of the power. So we specifically don't
> want a device to report its power to two parents as that would cause double
> counting.
>
>> 2) Does Parent always report
>> the power information of its’ Child for its stead?
>> If so, to whom, NMS of it’s own Parent?
>>
>
> [jparello] The parent may report the power usage on behalf of the child or
> may delegate it to the child and aggregate it to the NMS.
>
>> 3) It’s written
>>
>>      A Power Monitor cannot be at the same time a Power Monitor
>>      Parent and a Power Monitor Child.
>>
>> But the above seems to contradict with
>> Figure 4 of Scenario 1 of [POWER-MON-MIB]
>> in which
>> SWITCH PORT is the CHILD of SWITCH and
>> the PARENT of IP PHONE at that same time.
>> Please clarify.
>>
>
> [jparello] For SNMP the NMS would talk to each parent directly to get power
> information. Having a parent that is also a child of another parent would
> cause the devices to begin to "walk the network". As such we specified each
> parent as a disjoint tree of power reporting.
>
>
>> 4) Which entity report to NMS with IP?
>> A Child can make its own report to NMS
>> or always a Parent should report for its stead?
>>
>
> [jparello] By definition the parent aggregates it.
>
>
> Thanks so much!
> John
>
>

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 2 Nov 2010 20:30:41 +0900

Hi Ted

Kindly see in line comments.

> [tg] model we should be looking for is:
>
> * entity that are not capable of monitoring/manage its own power to align up
> to a device who can do this for it, hence this device will be a child of the
> device who control it.

ok. I see the general reasoning behind PARENT-CHILDREN relationship

> [tg] please read: monitoring of the device who is monitoring other devices
> is orthogonal about its own consumption. Take the case of an electric meter
> of a home. The meter may not be capable of measuring its own usage, but can
> measure the power drawn by the home. Now the power drawn by the meter can be
> monitored by someone else, hence the flexibility presented!

Oh, this is the angle I didn’t perceive before, interestingly intricate.

In the above case, Electric meter
is a PARENT to the home with respect to home power consumption and
can be a CHILDREN to some monitoring device
with respect to its own power consumption, right?

I guess this prevents double energy counting
and PARENT-CHILDREN relationship is more flexible/ complicated
than I had expected.

> [tg] in the light of all above cases, it depends. if a device is capable of
> doing so, it will, else it can ask somebody else to manage it for him.

If a CHILD can make its own reporting,
why does it need a PARENT in the first place?

Also to the same question, John replied as below

Thanks for your clarification and see you in Beijing.

Best regards

JinHyeock

On Sun, Oct 17, 2010 at 4:47 PM, Ted Ghose <[email-masked]> wrote:
> in line, look for [tg]
> On Tue, Oct 5, 2010 at 11:05 PM, JinHyeock Choi <[email-masked]> wrote:
>>
>> Hi
>>
>> Here are some comments.
>>
>> 1. Communication model
>> I wish the communication model between Power Monitor & NMS
>> I wish more clear statements & elaboration.
>>
> [tg] if entity is ip enable, it can report its own information. if the
> entity is ip enable and do not have capability to monitor its own energy
> usage, it should at least be capable of telling (automatically or by
> configuration) who is monitoring its usage.
>
>
>> 2) monitoring model
>>    SNMP/ MIB or IPFIX
> [tg] ipfix is a better choice, I'd keep it open for discussion. ipfix is
> more designed towards data collection for data mining.
>>
>> 2. Power Monitor Parent & Child
>> Power Monitor Parent & Child relationship.
>>
>> Power Monitor Parent & Power Monitor Child.
>>
> [tg] model we should be looking for is:
>
> * entity that are not capable of monitoring/manage its own power to align up
> to a device who can do this for it, hence this device will be a child of the
> device who control it.
>
>>
> [tg] if someone providing the PoE power, it will be double counting to
> measure it from building gateway. In this light we should have one and only
> one parent.
>>
> [tg] if and only if a child wish the parent to report or control its power.
> We will always like to to make the end device to make the call.
>>
>> 3) It’s written
>>
> [tg] please read: monitoring of the device who is monitoring other devices
> is orthogonal about its own consumption. Take the case of an electric meter
> of a home. The meter may not be capable of measuring its own usage, but can
> measure the power drawn by the home. Now the power drawn by the meter can be
> monitored by someone else, hence the flexibility presented!
>>
> [tg] in the light of all above cases, it depends. if a device is capable of
> doing so, it will, else it can ask somebody else to manage it for him.
>
> Best Regards
>
> -tg-
>>
>> Best Regards
>>
>> JinHyeock Choi
>> _______________________________________________
>> eman mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/eman
>
>