Subject: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Feb 2012 00:52:47 +0100

Dear all,

 From the IETF 82 meeting minutes, 
http://www.ietf.org/proceedings/82/minutes/eman.txt

    [BC] - Is there something that can be done in the reference model
    that can't be done in the framework?

    [BN] - Bidirectional supply issue is problematic in the framework
    because of the parent/child relationships. Reference model
    inherently focuses on net energy flow.

We would like to know if there are other things that this one (discussed 
in my previous email on the list), that the [EMAN-REF] could do while 
the [EMAN-FMWK] could not?

[EMAN-FMWK] = 
http://datatracker.ietf.org/doc/draft-ietf-eman-framework/, the official 
EMAN document
[EMAN-REF] = 
http://datatracker.ietf.org/doc/draft-quittek-eman-reference-model/

Regards, Benoit (as a contributor for the [EMAN-FMWK]

---

From: Brad Schoening <[email-masked]>
Date: Mon, 27 Feb 2012 19:45:10 -0600

Bruce,

Could you explain what you mean by 'bi-directional supply'.  I searched for the term 'bidirectional' in your document and wasn't able to find it.

Brad Schoening
e: [email-masked] ⟐ m: 917-304-7190

<http://www.coraid.com/> Redefining Storage Economics

From: Benoit Claise <[email-masked]<mailto:[email-masked]>>
Date: Mon, 27 Feb 2012 17:52:47 -0600
To: eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?

Dear all,

From the IETF 82 meeting minutes, http://www.ietf.org/proceedings/82/minutes/eman.txt
[BC] - Is there something that can be done in the reference model that can't be done in the framework?
[BN] - Bidirectional supply issue is problematic in the framework because of the parent/child relationships. Reference model inherently focuses on net energy flow.
We would like to know if there are other things that this one (discussed in my previous email on the list), that the [EMAN-REF] could do while the [EMAN-FMWK] could not?

[EMAN-FMWK] = http://datatracker.ietf.org/doc/draft-ietf-eman-framework/, the official EMAN document
[EMAN-REF] = http://datatracker.ietf.org/doc/draft-quittek-eman-reference-model/

---

From: Bruce Nordman <[email-masked]>
Date: Mon, 27 Feb 2012 22:17:20 -0800

Certainly.  IEEE is in the process of standardising UPAMD, a standard for
distributing low-voltage DC power.  Originally designed for notebook
computers,
the goal is now a wide variety of products.  From a power perspective a
UPAMD
hub looks a lot like a PoE switch or mid-span, but power is not restricted
to flow
only away from the hub.
Similarly, HDBaseT supports power flowing in either direction.  It is in
many ways
a superset of PoE.
As more devices get batteries, and as we have more stand-alone batteries and
local generation, the usefulness of more flexible power distribution only
increases,
and technology is arriving to enable that.
In both of these cases, the devices getting power will be mostly or entirely
ones that have communication (usually IP) and so should be able to make good
use of EMAN.

In general, one can compute power metering or power supply relationships
from data on wiring topology.  The reverse is generally not possible.
This is why the wiring topology is so useful - arguably necessary.

--Bruce

On Mon, Feb 27, 2012 at 5:45 PM, Brad Schoening <[email-masked]> wrote:

> Bruce,
>
> Could you explain what you mean by 'bi-directional supply'.  I searched
> for the term 'bidirectional' in your document and wasn't able to find it.
>
> Brad Schoening
>  <http://www.coraid.com/> Redefining
> Storage Economics****
>
> ** **
>
> From: Benoit Claise <[email-masked]>
> To: eman mailing list <[email-masked]>
> [BN] - Bidirectional supply issue is problematic in the framework because
> of the parent/child relationships. Reference model inherently focuses on
> net energy flow.
>
> in my previous email on the list), that the [EMAN-REF] could do while the
> [EMAN-FMWK] could not?
>

-- 
*Bruce Nordman*
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Tue, 28 Feb 2012 00:34:16 -0600

Benoit,

As mentioned in the minutes of the IETF meeting, 

[BC] - Is there something that can be done in the reference model that
can't be done in the framework? 

There were a couple of points I mentioned in the meeting  (missed in the
minutes)

1.       Framework allows modeling the entities and its internal
components (based on the Entity MIB). 

2.       Framework allows - flexible relations -  poweredBy, meteredBy,
ControledBy.  

There are scenarios - in which all of these functions can be performed
by the same entity.  

In some important cases, there are different entities doing these
functions . 

Thanks

Mouli 

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Benoit Claise (bclaise)
Sent: Tuesday, February 28, 2012 5:23 AM
To: eman mailing list
Subject: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?

Dear all,

[BC] - Is there something that can be done in the reference model that
can't be done in the framework? 

	[BN] - Bidirectional supply issue is problematic in the
framework because of the parent/child relationships. Reference model
inherently focuses on net energy flow.

[EMAN-FMWK] =

---

From: Brad Schoening <[email-masked]>
Date: Tue, 28 Feb 2012 00:41:45 -0600

Bruce,

Thanks for providing the reference to UPAMD, but I'm still very puzzled about the term you used, 'bidirectional'.

According to the IEEE web site at http://grouper.ieee.org/groups/msc/upamd/

"The Universal Power Adapter for Mobile Devices (UPAMDTM) standard defines a power delivery connection between a power adapter and a power using device in the 10 Watt to <240 Watt range. A communications link between the power adapter and the mobile power using device is also defined.
…

The UPAMDTM standard creates a common interconnect for power delivery in the 10W to <240W power range to portable and fixed devices. This standard supports more universal use and reuse of power adapters replacing brand specific and model specific power adapters.
"

As you note, this is similar to PoE.  Could you be specific about the language for UPAMD that specifies "power is not restricted to flow only away from the hub."  My admittedly cursory reading of the above leads me to believe this is just for "power delivery" only, as the standard itself states.

Brad Schoening

From: Bruce Nordman <[email-masked]<mailto:[email-masked]>>
Date: Tue, 28 Feb 2012 00:17:20 -0600
To: Brad Schoening <[email-masked]<mailto:[email-masked]>>
Cc: Benoit Claise <[email-masked]<mailto:[email-masked]>>, eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?

Certainly.  IEEE is in the process of standardising UPAMD, a standard for
distributing low-voltage DC power.  Originally designed for notebook computers,
the goal is now a wide variety of products.  From a power perspective a UPAMD
hub looks a lot like a PoE switch or mid-span, but power is not restricted to flow
only away from the hub.
Similarly, HDBaseT supports power flowing in either direction.  It is in many ways
a superset of PoE.
As more devices get batteries, and as we have more stand-alone batteries and
local generation, the usefulness of more flexible power distribution only increases,
and technology is arriving to enable that.
In both of these cases, the devices getting power will be mostly or entirely
ones that have communication (usually IP) and so should be able to make good
use of EMAN.

--Bruce

On Mon, Feb 27, 2012 at 5:45 PM, Brad Schoening <[email-masked]<mailto:[email-masked]>> wrote:
Bruce,

Brad Schoening
e: [email-masked]<mailto:[email-masked]> ⟐ m: 917-304-7190<tel:917-304-7190>

Dear all,

--
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman<http://eetd.lbl.gov/ea/nordman>
[email-masked]<mailto:[email-masked]>
510-486-7089
m: 510-501-7943

---

From: Benoit Claise <[email-masked]>
Date: Tue, 28 Feb 2012 13:55:26 +0100

Mouli,
> There were a couple of points I mentioned in the meeting  (missed in 
> the minutes)
>
> 1.Framework allows modeling the entities and its internal components 
> (based on the Entity MIB).
>
Yes, this was covered by 
http://www.ietf.org/proceedings/82/slides/eman-0.pdf

A new section has been added

    4.2. Components and Containment Tree

The framework for Energy Management manages two different types of 
Energy Objects: an entire device and components within device

A typical example of a typical Energy Object is a switch. However, a 
port within the switch, which provides Power to one end point, might 
also a be an Energy Object if it meters the power provided. A second 
example is PC, which isis a typical Energy Object. However, the battery 
within the PC might be managed as an individual Energy Object as well.

Some more examples of Energy Objects components within a device: power 
supply within a router, an outlet within a smart PDU, etc...

In the [EMAN-AWARE-MIB], each Energy Object is managed with an unique 
value of the entPhysicalIndex index from the ENTITY-MIB [RFC4133].

The ENTITY-MIB [RFC4133] specifies the notion of physical containment 
tree, as:

"Each physical component may be modeled as 'contained' within

another physical component.A "containment-tree" is the conceptual 
sequence of entPhysicalIndex values that uniquely specifies the exact 
physical location of a physical component within the managed system.It 
is generated by 'following and recording' each 'entPhysicalContainedIn' 
instance 'up the tree towards the root', until a value of zero 
indicating no further containment is found."

RFC-EDITOR'S NOTE: not sure if this should be in [EMAN-FMWK], or in 
[EMAN-AWARE-MIB], or both.

Disclaimer: the text is certainly not perfect and should be improved. At 
this point in time, I try to close on the open issues and not to provide 
perfect text...

> 2.Framework allows -- flexible relations -  poweredBy, meteredBy, 
> ControledBy.
>
> There are scenarios -- in which all of these functions can be 
> performed by the same entity.
>

Mouli,
We had to address the point 1., you were right.
However, I'm confused about how your point 1. and 2. refer to the 
question "Is there something that can be done in the reference model 
that can't be done in the framework?"

Regards, Benoit.
>
> Thanks
>
> Mouli
>
> *From:[email-masked] [mailto:[email-masked]] *On Behalf 
> Of *Benoit Claise (bclaise)
> *Sent:* Tuesday, February 28, 2012 5:23 AM
> *To:* eman mailing list
> *Subject:* [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?
>
> Dear all,
>
> We would like to know if there are other things that this one 
> (discussed in my previous email on the list), that the [EMAN-REF] 
> could do while the [EMAN-FMWK] could not?
>
> [EMAN-FMWK] = 
> http://datatracker.ietf.org/doc/draft-ietf-eman-framework/, the 
> official EMAN document
> [EMAN-REF] =

---

From: "John Parello (jparello)" <[email-masked]>
Date: Tue, 28 Feb 2012 10:12:12 -0800

“but power is not restricted to flow
only away from the hub.  “

I direct the readers to our proposal for energy odometers taken from the ODVA. If this becomes prevalent (and it already is in the manufacturing space BTW) then the need for Energy Objects to have odometers for produced, consumed, and net energy seem quite pointed.

Jp

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bruce Nordman
Sent: Monday, February 27, 2012 10:17 PM
To: Brad Schoening
Cc: eman mailing list
Subject: Re: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?

--Bruce

Bruce,

Brad Schoening

 Redefining Storage Economics <http://www.coraid.com/> 

  <http://www.coraid.com/> 

  <http://www.coraid.com/> 

From: Benoit Claise <[email-masked]>
Date: Mon, 27 Feb 2012 17:52:47 -0600
To: eman mailing list <[email-masked]>
Subject: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations? <http://www.coraid.com/> 

  <http://www.coraid.com/> 

Dear all,

From the IETF 82 meeting minutes, http://www.ietf.org/proceedings/82/minutes/eman.txt <http://www.coraid.com/> 

[BC] - Is there something that can be done in the reference model that can't be done in the framework? <http://www.coraid.com/> 

	[BN] - Bidirectional supply issue is problematic in the framework because of the parent/child relationships. Reference model inherently focuses on net energy flow. <http://www.coraid.com/> 

<http://www.coraid.com/> 

-- 
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman
[email-masked]
510-486-7089
m: 510-501-7943 <http://www.coraid.com/>

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 28 Feb 2012 14:11:16 -0800

Brad--
  As you have discovered, the information on the public web page is
fairly general.  Best I can suggest to dig into details is to join the
standards committee.   In any case, it supports power interfaces
that can switch direction.
  For "similar to PoE", that was in reference to a central supply of
power with many ports  Since the standard is not public, I don't
think I can cite the language.  UPAMD connections can also be
peer-to-peer.  For "power delivery only" - definitely - it is not a
communications standard.  HDBaseT, on the other hand, does both.
  I am pleased that communications technology is enabling power
distribution approaches that were not possible beforehand, or at
least much more difficult.
--Bruce

On Mon, Feb 27, 2012 at 10:41 PM, Brad Schoening <[email-masked]> wrote:

> Bruce,
>
> Thanks for providing the reference to UPAMD, but I'm still very puzzled
> about the term you used, 'bidirectional'.
>
> According to the IEEE web site at
> http://grouper.ieee.org/groups/msc/upamd/
>
> "The Universal Power Adapter for Mobile Devices (UPAMDTM) standard
> defines a power delivery connection between a power adapter and a power
> using device in the 10 Watt to <240 Watt range. A communications link
> between the power adapter and the mobile power using device is also defined.
> …
>
> The UPAMDTM standard creates a common interconnect for power delivery in
> the 10W to <240W power range to portable and fixed devices. This standard
> supports more universal use and reuse of power adapters replacing brand
> specific and model specific power adapters.
> "
>
> As you note, this is similar to PoE.  Could you be specific about the
> language for UPAMD that specifies "power is not restricted to flow only
> away from the hub."  My admittedly cursory reading of the above leads me to
> believe this is just for "power delivery" only, as the standard itself
> states.
>
>
> Brad Schoening
> From: Bruce Nordman <[email-masked]>
> To: Brad Schoening <[email-masked]>
> Cc: Benoit Claise <[email-masked]>, eman mailing list <[email-masked]>

---

From: Leonard Tsai <[email-masked]>
Date: Wed, 29 Feb 2012 06:29:05 +0800

Hi, Brad,

  I am on the UPAMD working group - also, I am one of the originals who started the group with Bob Davis (chair person). 

  UPAMD is not like PoE. The statement about the power may flow any direction between devices (after negotiation) is to enable device to power other device in case of needs.

  UPAMD is mainly for flexible power delivery to reduce eWaste (of mobile power adapters) by including some intelligence so that they can be repurposed in the case when the main device (for example, notebook) is no longer functional or obsolete. 

 Leonard 

On Feb 28, 2012, at 2:41 PM, Brad Schoening wrote:

> <68E3C3EC-27AF-42E8-8F70-14A7C87B9B6F[20].png> Redefining Storage Economics
>  
> 
>>  Redefining Storage Economics
>>  
>> 
> _______________________________________________
> eman mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/eman

---

From: Brad Schoening <[email-masked]>
Date: Tue, 28 Feb 2012 17:49:51 -0600

Leonard,

Thanks for the helpful details on UPAMD.  It would be great if you could expand a bit on your explanation of how power may flow bi-directionally.  Given a Power Adapter and a Device, the bi-directional part seems to be between devices, not back to the Power Adapter.

For example, if my laptop could be powered by USB, and I imagine I could connect laptop A to laptop B and power them A -> B or B -> A depending upon the need and battery state.   Is this about correct?

Thanks,

Brad

Brad Schoening

From: Leonard Tsai <[email-masked]<mailto:[email-masked]>>
Date: Tue, 28 Feb 2012 16:29:05 -0600
To: Brad Schoening <[email-masked]<mailto:[email-masked]>>
Cc: Bruce Nordman <[email-masked]<mailto:[email-masked]>>, eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK]

Hi, Brad,

 Leonard

Bruce,

Brad Schoening
e: [email-masked]<mailto:[email-masked]> ⟐ m: 917-304-7190

<68E3C3EC-27AF-42E8-8F70-14A7C87B9B6F[20].png><http://www.coraid.com/> Redefining Storage Economics

--Bruce

Brad Schoening

[x-msg://652/]<http://www.coraid.com/> Redefining Storage Economics

Dear all,

_______________________________________________
eman mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/eman

---

From: Leonard Tsai <[email-masked]>
Date: Wed, 29 Feb 2012 08:13:06 +0800

Hi, Brad,

  the UPAMD conf call will starts in 50 mins from now. I encourage you to attend. It's the best way to get familiar. 

  If the power adapter contains a "power hub", then the power may flow back to the adapter (hub) then to another device. This is considered in the case that the laptop A is connected to the power adapter (with a hub) B, while a phone C is also connected to the same power adapter B. User may want to move some of the power from larger battery inside laptop A to the phone C via power adapter B. Another case is for the "smart" power adapter - i.e. the power adapter has other active circuitry. When there is no AC input, the user may consider to control the amount of power from laptop A back to the active circuitry inside adapter B. 

  I hope this short description helps but the best way is still to attend and read the draft. Welcome.

Leonard 

On Feb 29, 2012, at 7:49 AM, Brad Schoening wrote:

> <68E3C3EC-27AF-42E8-8F70-14A7C87B9B6F[32].png> Redefining Storage Economics
>  
> 
> From: Leonard Tsai <[email-masked]>
> Cc: Bruce Nordman <[email-masked]>, eman mailing list <[email-masked]>

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 28 Feb 2012 22:42:57 -0800

Just to clarify, the Reference Model assumes modeling of components with
the Entity MIB as EMAN has been assuming, so for reporting energy use,
there is no difference with the Framework on that.

That said, I have often wondered about what it means for an internal
component to have relationships such as powered-by or metered-by with
an external device.  I think of components as drawing power from the chassis
they are part of, not directly from an external source.

--Bruce

On Mon, Feb 27, 2012 at 10:34 PM, Mouli Chandramouli (moulchan) <
[email-masked]> wrote:

> Benoit,****
>
> ** **
>
> As mentioned in the minutes of the IETF meeting, ****
>
> ** **
>
> can't be done in the framework? ****
>
> ** **
>
> minutes)****
> **1.       **Framework allows modeling the entities and its internal
> components (based on the Entity MIB). ****
>
> ** **
>
> **2.       **Framework allows – flexible relations -  poweredBy,
> meteredBy, ControledBy.  ****
>
> There are scenarios – in which all of these functions can be performed by
> the same entity.  ****
>
> functions . ****
> Thanks****
> Mouli ****
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf
> *Subject:* [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?*
> ***
>
> ** **
>
> Dear all,
>
>
> http://www.ietf.org/proceedings/82/minutes/eman.txt****
>
> can't be done in the framework? ****
>
> net energy flow.****
> ****

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 29 Feb 2012 01:10:00 -0600

Thanks Leonard to explanation of UPAMD.   

Bidrectional power flow can be modeled with the Framework  easliy-
PoweredBy relationship and with directional flow measurement of energy
EnergyConsumed / EnergyProduced.

That should not be viewed as a  limitation of Framework. 

Thanks

Mouli

Dear all,

[EMAN-FMWK] =

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 28 Feb 2012 23:17:47 -0800

My understanding of parent/child is that the parent is always providing
the power supply or the power metering to the child.  If the power flow
direction reverses, doesn't the parent become the child and the child
become the parent?

Also, I am unsure of how we are using the term "Produced".  My understanding
is that "produced" would be from an electricity generator, or that withdrawn
from a battery.  When power flows through a wire, it is being neither
produced
nor consumed - only moved from one place to another - it crosses an
interface.

--Bruce

On Tue, Feb 28, 2012 at 11:10 PM, Mouli Chandramouli (moulchan) <
[email-masked]> wrote:

> Thanks Leonard to explanation of UPAMD.   ****
>
> ** **
>
> EnergyConsumed / EnergyProduced.****
>
> ** **
>
> That should not be viewed as a  limitation of Framework. ****
>
> ** **
>
> Thanks****
>
> Mouli****
>
> ** **
>
> ** **
>

---

From: "Mouli Chandramouli (moulchan)" <[email-masked]>
Date: Wed, 29 Feb 2012 01:23:11 -0600

I thought Reference model  - models entities with inlet and outlets.  

So, Power is measured at that granularity of  inlet and outlet - not at
a component level. 

Mouli

From: Bruce Nordman [mailto:[email-masked]] 
Sent: Wednesday, February 29, 2012 12:13 PM
To: Mouli Chandramouli (moulchan)
Cc: Benoit Claise (bclaise); eman mailing list
Subject: Re: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK]
limitations?

That said, I have often wondered about what it means for an internal
component to have relationships such as powered-by or metered-by with
an external device.  I think of components as drawing power from the
chassis
they are part of, not directly from an external source.

--Bruce

On Mon, Feb 27, 2012 at 10:34 PM, Mouli Chandramouli (moulchan)
<[email-masked]> wrote:

Benoit,

Thanks

Mouli 

Dear all,

[EMAN-FMWK] =

---

From: Brad Schoening <[email-masked]>
Date: Wed, 29 Feb 2012 01:25:42 -0600

Bruce,

Consider a power adapter and powered device.  If the flow reverses, and the device sends DC power back to the adaptor, it does not change the parent/child relationship.  Why would it?  Can we consider this issue closed?

I agree that 'produced' is a vague term.  Is it produced by a solar array or produced by a battery that had stored the energy previously.  From the perspective of renewable energy credits, there is a big difference between the two.  I would much prefer to have an energy used value that is signed to indicate flow.

Regards,

Brad

Brad Schoening

From: Bruce Nordman <[email-masked]<mailto:[email-masked]>>
Date: Wed, 29 Feb 2012 01:17:47 -0600
To: "Mouli Chandramouli (moulchan)" <[email-masked]<mailto:[email-masked]>>
Cc: eman mailing list <[email-masked]<mailto:[email-masked]>>
Subject: Re: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?

Also, I am unsure of how we are using the term "Produced".  My understanding
is that "produced" would be from an electricity generator, or that withdrawn
from a battery.  When power flows through a wire, it is being neither produced
nor consumed - only moved from one place to another - it crosses an interface.

--Bruce

On Tue, Feb 28, 2012 at 11:10 PM, Mouli Chandramouli (moulchan) <[email-masked]<mailto:[email-masked]>> wrote:
Thanks Leonard to explanation of UPAMD.

Bidrectional power flow can be modeled with the Framework  easliy-    PoweredBy relationship and with directional flow measurement of energy EnergyConsumed / EnergyProduced.

Thanks
Mouli

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Benoit Claise (bclaise)
Sent: Tuesday, February 28, 2012 5:23 AM
To: eman mailing list
Subject: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK] limitations?

Dear all,

---

From: Bruce Nordman <[email-masked]>
Date: Tue, 28 Feb 2012 23:27:09 -0800

Entire devices have power interfaces.  Devices can have components that
consume power and report their total consumption.  Power distribution inside
a device is not modeled.  So, an entity for power reporting can be the
device,
an interface, or a component.
--Bruce

On Tue, Feb 28, 2012 at 11:23 PM, Mouli Chandramouli (moulchan) <
[email-masked]> wrote:

> I thought Reference model  - models entities with inlet and outlets.  ****
>
> So, Power is measured at that granularity of  inlet and outlet – not at a
> component level. ****
>
> ** **
>
> Mouli****
>
> ** **
>
> ** **
>
> *From:* Bruce Nordman [mailto:[email-masked]]
> *Sent:* Wednesday, February 29, 2012 12:13 PM
> *To:* Mouli Chandramouli (moulchan)
> *Cc:* Benoit Claise (bclaise); eman mailing list
> *Subject:* Re: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK]
> limitations?****
>
> ** **
>
> --Bruce****
> [email-masked]> wrote:****
>
> Benoit,****
>
>  ****
>
> 2.       Framework allows – flexible relations -  poweredBy, meteredBy,
> ControledBy.  ****
>
> *To:* eman mailing list****
>
>
> Dear all,****
> Regards, Benoit (as a contributor for the [EMAN-FMWK]****
>
>
> https://www.ietf.org/mailman/listinfo/eman****
>
>
>
>
> --
> *Bruce Nordman*
> m: 510-501-7943****

---

From: Brad Schoening <[email-masked]>
Date: Wed, 29 Feb 2012 10:41:53 -0600

Bruce,

Components inside a chassis can be modeled using the ENTITY-MIB and linked to EMAN. This is straightforward to implement.

http://www.ietf.org/rfc/rfc2737.txt

Brad Schoening

Date: Wed, 29 Feb 2012 01:27:09 -0600

Entire devices have power interfaces.  Devices can have components that
consume power and report their total consumption.  Power distribution inside
a device is not modeled.  So, an entity for power reporting can be the device,
an interface, or a component.
--Bruce

On Tue, Feb 28, 2012 at 11:23 PM, Mouli Chandramouli (moulchan) <[email-masked]<mailto:[email-masked]>> wrote:
I thought Reference model  - models entities with inlet and outlets.
So, Power is measured at that granularity of  inlet and outlet – not at a component level.

Mouli

From: Bruce Nordman [mailto:[email-masked]<mailto:[email-masked]>]

--Bruce
On Mon, Feb 27, 2012 at 10:34 PM, Mouli Chandramouli (moulchan) <[email-masked]<mailto:[email-masked]>> wrote:
Benoit,

There were a couple of points I mentioned in the meeting  (missed in the minutes)

1.       Framework allows modeling the entities and its internal components (based on the Entity MIB).

2.       Framework allows – flexible relations -  poweredBy, meteredBy, ControledBy.

There are scenarios – in which all of these functions can be performed by the same entity.

In some important cases, there are different entities doing these functions .

Thanks
Mouli

Dear all,

--
Bruce Nordman
Lawrence Berkeley National Laboratory
eetd.lbl.gov/ea/nordman<http://eetd.lbl.gov/ea/nordman>
[email-masked]<mailto:[email-masked]>
510-486-7089<tel:510-486-7089>
m: 510-501-7943<tel:510-501-7943>

---

From: "John Parello (jparello)" <[email-masked]>
Date: Wed, 29 Feb 2012 10:37:49 -0800

"""

an external device. 

"""

Ah this may the difference in thinking here. You're thinking in a view
from the device only and not the system.  So if you had 3 generators
powering 10 devices each you would only want to say that each device is
powered by its inlet chassis. What we are trying to do is ignore the
topology between the generator and 10 devices and know what happens if I
turn off a single generator what is affected. Which endpoints are
services by the 3 generators.

To translate to networking terms. You're saying a client receive trading
data only from its interface. If I had 3 trading servers with 10 clients
connect we track the connection at layer 7 if you will between the
server and clients. So the relationship here would be
"getstradedatafrom".

See the difference?

Jp

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Bruce Nordman
Sent: Tuesday, February 28, 2012 10:43 PM
To: Mouli Chandramouli (moulchan)
Cc: eman mailing list
Subject: Re: [eman] [EMAN-FMWK] versus [EMAN-REF]: [EMAN-FMWK]
limitations?

--Bruce

Benoit,

Thanks

Mouli 

Dear all,

[EMAN-FMWK] =