Subject: [eman] New draft draft-quittek-eman-reference-model-00

From: Juergen Quittek <[email-masked]>
Date: Mon, 8 Nov 2010 23:25:03 +0000

Dear all,

The discussions on this list during the last days and in restaurants at the
last nights have been quite inspiring. Particularly my understanding of the
fundamental steps of energy management has improved.

I tried to record some of the new insights in an Internet draft that I just
posted. It suggests a more detailed reference model for energy management
than we have it so far. Please find it at
http://datatracker.ietf.org/doc/draft-quittek-eman-reference-model/

This is just a contribution to the ongoing discussion. I have no intention
of adding another document to our charter. The content of this draft will
hopefully help understanding better what energy management is or could be.

I know this draft arrives too late for discussing it during the session
tomorrow. But we can do this on the list. Comments are highly appreciated.

Thanks,

    Juergen

------ Forwarded message
From: IETF I-D Submission Tool <[email-masked]>
Date: Mon, 8 Nov 2010 14:49:27 -0800
To: <[email-masked]>
Subject: New Version Notification for  draft-quittek-eman-reference-model-00

A new version of I-D, draft-quittek-eman-reference-model-00.txt has been
successfully submitted by Juergen Quittek and posted to the IETF repository.

Filename:  draft-quittek-eman-reference-model
Revision:  00
Title:   Reference Model for Energy Management
Creation_date:  2010-11-08
WG ID:   Independent Submission
Number_of_pages: 15

Abstract:
This memo discusses suggest a reference model for energy consumption
monitoring and control.  It defines entities involved in energy
management, their roles, and relationships between them.  Considered
entities include energy consumers, energy consumption meters, energy
consumption reporters, energy consumption controllers, and energy
consumption management systems.

The IETF Secretariat.

------ end of forwarded message

---

From: JinHyeock Choi <[email-masked]>
Date: Tue, 9 Nov 2010 16:30:06 +0900

Dear Juergen

Thanks for the draft
which also improved my understanding of energy management,
especially about involving entities & their interactions.

Here are some quick comments.

First, the figure in Sec 3 gives an impression that
single ‘Energy Management System’ manages
1.Power Provisioning Controller &
2.Energy Consumption Reporter
3.Power Controller
but usually the first is managed by an electric power company
whereas 2nd & 3rd may by network operator (or else).

For example, even if a mobile operator builds
a management system to monitor & control its equipments,
I wonder whether the system can also control the power supply.

It may be better to divide Energy Management System into two entities
(as done for Power Provisioning Controller & Power Controller.)

Second, I wish the draft mentions more about the
relationship among entities such as
a single Energy Consumption Reporter can associate with
several Energy Consumers/ Energy Consumption meters
to aggregate the monitoring information
or which constitute power domain or meter domain,
(which still elude my understanding.)

In summary, the draft clarifies the overall energy management picture much
(surprised how quickly you turned out a draft from discussion)
and I wish the content would be integrated into eman work items
such as architecture draft.

Thanks for your kind consideration.

Best regards

JinHyeock Choi

On Tue, Nov 9, 2010 at 8:25 AM, Juergen Quittek <[email-masked]> wrote:
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman
>
>

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 9 Nov 2010 14:03:06 -0800

Hi Juergen,

In addition to JinHyeock's comments below, I notice that none of the use cases described in section 5 describe a case whereby a single device contains multiple energy meters with multiple energy consumers.  Building off the simpler subset shown in Section 5.3, I created a more complex model that is required for our product set:

http://demo.cyberswitching.com/chrisv/20101109-01_Intelligent_PDU_Use_Case.pdf

(Admittedly, I'm not as skilled in the ancient art of ASCII [art] as you, so took refudge to Visio for time considerations.)

If I misused any of the terms, I apologize.  The draft was definitely full of definitions, and I'm working to come up to speed on your usage of them.

In this scenario, I need to report the data for EACH Energy Consumption Meter listed __AND__ multiple aggregations of that meter data, based on business case needs.  (That is, "domains" can be defined in several different ways, simultaneously.)

Please comment on how such a use case might be modeled to ensure flexibility and future feature expansion by both the IETF and enterprise vendors.

Chris

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of JinHyeock Choi
Sent: Monday, November 08, 2010 11:30 PM
To: Juergen Quittek
Cc: eman mailing list
Subject: Re: [eman] New draft draft-quittek-eman-reference-model-00

Dear Juergen

Thanks for the draft
which also improved my understanding of energy management, especially about involving entities & their interactions.

First, the figure in Sec 3 gives an impression that single 'Energy Management System' manages 1.Power Provisioning Controller & 2.Energy Consumption Reporter 3.Power Controller but usually the first is managed by an electric power company whereas 2nd & 3rd may by network operator (or else).

For example, even if a mobile operator builds a management system to monitor & control its equipments, I wonder whether the system can also control the power supply.

It may be better to divide Energy Management System into two entities (as done for Power Provisioning Controller & Power Controller.)

Second, I wish the draft mentions more about the relationship among entities such as a single Energy Consumption Reporter can associate with several Energy Consumers/ Energy Consumption meters to aggregate the monitoring information or which constitute power domain or meter domain, (which still elude my understanding.)

In summary, the draft clarifies the overall energy management picture much (surprised how quickly you turned out a draft from discussion) and I wish the content would be integrated into eman work items such as architecture draft.

Best regards

JinHyeock Choi

On Tue, Nov 9, 2010 at 8:25 AM, Juergen Quittek <[email-masked]> wrote:
> Dear all,
>
> The discussions on this list during the last days and in restaurants 
> at the last nights have been quite inspiring. Particularly my 
> understanding of the fundamental steps of energy management has improved.
>
> I tried to record some of the new insights in an Internet draft that I 
> just posted. It suggests a more detailed reference model for energy 
> management than we have it so far. Please find it at 
> This is just a contribution to the ongoing discussion. I have no 
> intention of adding another document to our charter. The content of 
> this draft will hopefully help understanding better what energy management is or could be.
>
> I know this draft arrives too late for discussing it during the 
> session tomorrow. But we can do this on the list. Comments are highly appreciated.
>
> Thanks,
>
>    Juergen
>
>
> ------ Forwarded message
> A new version of I-D, draft-quittek-eman-reference-model-00.txt has 
> been successfully submitted by Juergen Quittek and posted to the IETF repository.
>

---

From: Bruce Nordman <[email-masked]>
Date: Wed, 10 Nov 2010 11:09:17 +0800

Chris--
  In your diagram, does the Reporter communicate only the total power
consumed from each supply, or is the supply part broken out by consumer?
Certainly the former is simpler, but your diagram seems to indicate
the latter.
  In your diagram, the power seems not to be pooled, but rather the
two electricity domains don't interact.  How about logically dividing
the PDU into two units, each with only one power supply.  Would that
meet your needs?
--Bruce

On Wed, Nov 10, 2010 at 6:03 AM, Chris Verges <[email-masked]>wrote:

> Hi Juergen,
>
> In addition to JinHyeock's comments below, I notice that none of the use
> cases described in section 5 describe a case whereby a single device
> contains multiple energy meters with multiple energy consumers.  Building
> off the simpler subset shown in Section 5.3, I created a more complex model
> that is required for our product set:
>
>
> (Admittedly, I'm not as skilled in the ancient art of ASCII [art] as you,
> so took refudge to Visio for time considerations.)
>
> If I misused any of the terms, I apologize.  The draft was definitely full
> of definitions, and I'm working to come up to speed on your usage of them.
>
> In this scenario, I need to report the data for EACH Energy Consumption
> Meter listed __AND__ multiple aggregations of that meter data, based on
> business case needs.  (That is, "domains" can be defined in several
> different ways, simultaneously.)
>
> Please comment on how such a use case might be modeled to ensure
> flexibility and future feature expansion by both the IETF and enterprise
> vendors.
>
> Chris
>
> --
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "Chris Verges" <[email-masked]>
Date: Tue, 9 Nov 2010 20:04:47 -0800

Hi Bruce,

Given that my head is still spinning to understand all of the nuances in the different terms/definitions in the new reference-model-00 draft, I'm not sure.  :-)

Here's the traditional breakdown of a Smart PDU with 2 input cords, 6 banks, and 24 outlets:

·         PDU

o    Internal overhead to manage PDU

o    Input Cord #1

§  Bank #1

·         Outlet #1

·         ...

§  Bank #2

·         Outlet #5

·         ...

§  Bank #3

·         Outlet #9

·         ...

o    Input Cord #2

§  Bank #4

·         Outlet #13

·         ...

§  Bank #5

·         Outlet #17

·         ...

§  Bank #6

·         Outlet #21

·         ...

Each Outlet has an electrical meter.  These values are then aggregated to form the data for the Bank to which the Outlets are connected.  These Bank values are then aggregated for their parent Input Cord.  Finally, the total is aggregated for the PDU as a whole entity.

This is the fundamental architecture of Cyber Switching's ePower series, but could very well apply to any of the other PDU vendors: APC, Server Technology, Raritan, Geist, Eaton/HP, etc.

Customers have explicitly stated to us that even though each Input Cord may be part of a separate physical infrastructure path to two different power transformers, they don't care and want the power aggregated together at the PDU level.  Also, customers have stated that they want all of this data made available to them.  It may be redundant, it may be overlapping, but they don't really care because they find ways to use it for their particular business needs.

What you're calling "electricity domains" is, I believe, synonymous with "power grid being supplied by a single transformer segment", correct?  What I'm trying to get across is that such a breakdown is merely one of a thousand ways that our customers use our products in daily use.  I agree that it's a good use case to model, but it is not the only use case that needs to be modeled.  We need to provide a model that can scale upwards with these sorts of complex business needs that are as of yet unseen and undefined, and I am questioning whether the existing two drafts handle this sufficiently in their current forms.

If it helps the discussion, I can certainly put together a proposed MIB architecture to try and solidify what I'm meaning.  I see the Smart PDU / Submeter style of product as being sufficiently more complex than a standard computer / server from a model standpoint.  Or to put it another way, the needs related to a server is a subset of the needs related to the Smart PDU and PoE networking gear; if we solve those, the server will naturally be handled.

Thanks,

Chris

From: Bruce Nordman [mailto:[email-masked]] 
Sent: Tuesday, November 09, 2010 7:09 PM
To: Chris Verges
Cc: eman mailing list
Subject: Re: [eman] New draft draft-quittek-eman-reference-model-00

Chris--

On Wed, Nov 10, 2010 at 6:03 AM, Chris Verges <[email-masked]> wrote:

Hi Juergen,

Chris

-- 
Bruce Nordman