Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

[Brad Schoening <[e-mail]>]

Thomas,

The power domain provides a first-order grouping.  The keywords and relationships in EMAN-Energy-Aware-MIB provide for additional characterization that allow you to "slice and dice" your energy objects in context specific ways (such as the landlord – tenant relationship you mentioned).

Sec 5.2 of the Energy-Aware-MIB states:


        An Energy Object can provide a set of eoKeywords. These keywords
        are a list of tags that can be used for grouping and summary
        reporting within or between Energy Management Domains.


You ask: "why not put the domain into the keywords as well"?  Well, because having a first order grouping into a single domain is both useful and practical.  It tends to closely match the physical distribution of power, while the keywords allow for additional levels of grouping when and if required.  This minimizes the parsing you would need to do in simple use cases.

The discussion has been a useful exercise to validate that the existing model works well to address the use cases you and Juergen have raised.  As Benoit notes, implementation experience over the last 6 years has also verified the usability of this approach.

Regards,

Brad


From: Thomas Dietz <[e-mail]<mailto:[e-mail]>>
Date: Mon, 3 Feb 2014 13:30:28 +0000
To: Brad Schoening <[e-mail]<mailto:[e-mail]>>, Bruce Nordman <[e-mail]<mailto:[e-mail]>>, eman mailing list <[e-mail]<mailto:[e-mail]>>
Subject: RE: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Hi Brad,

You tend to put all those elements that put some structure (except the domain) into the keywords. Those keywords need to be parsed by the Management System and does complicate building some more structure into these objects. Usually the world is more complex than putting one thing exactly to one domain all the time. In addition putting structure to keywords makes filtering in advance for those objects that the Management System wants to act on more complex because it first needs to read all keywords for all objects, parse them and filter out those that it does not need right now.

If I would play devil’s advocate why not put the domain into the keywords as well?

Best Regards,

Thomas

--
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014
Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB

From: Brad Schoening [mailto:[e-mail]]
Sent: Friday, January 31, 2014 4:57 PM
To: Thomas Dietz; Bruce Nordman; eman mailing list
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

HI Thomas,

As Mouli mentioned in a separate email, the use case you mention can be address with keywords.  A single domain + keywords gives flexibility in characterizing your environment.  Given this, I think the current single domain model has shown it address all the specific concerns raised  thus far.

Best Regards,

Brad

Brad Schoening
Engineering | Coraid
Tel: [phone]
[e-mail]<mailto:[e-mail]> | www.coraid.com<http://www.coraid.com>
Coraid: Redefining Storage


From: Thomas Dietz <[e-mail]<mailto:[e-mail]>>
Date: Fri, 31 Jan 2014 08:15:36 +0000
To: Brad Schoening <[e-mail]<mailto:[e-mail]>>, Bruce Nordman <[e-mail]<mailto:[e-mail]>>, eman mailing list <[e-mail]<mailto:[e-mail]>>
Subject: RE: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

Dear Brad, all,

first of all I second Jürgen’s view that we should not artificially limit ourselves if there is no technical reason.

And what the discussion below shows is exactly the reason for that. The definition of the domain leaves some room for interpretation. Thus, IMHO it should be allowed to have an implementation of a domain that allows that objects are part of more than one domain. You could define the domain as a sort of “geographical domain” and have a building that get controlled by the owner and some rental units that are controlled by the tenant. This would imply that the same object are part of two different domain. And this example would match in my opinion the definition of domain in the framework document.

Best Regards,

Thomas

--
Thomas Dietz
NEC Europe Ltd., NEC Laboratories, Network Research Division, 69115 Heidelberg, Germany

NEC Europe Limited, Registered in England 2832014
Registered Office: Athene, Odyssey Business Park, West End  Road, London, HA4 6QE, GB

From: eman [mailto:[e-mail]] On Behalf Of Brad Schoening
Sent: Thursday, January 30, 2014 11:08 PM
To: Bruce Nordman; eman mailing list
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

"If one uses domain in the recommended fashion, then a device that receives
power from two sources (each sub-metered) is definitely in two different
domains."

Or a new domain, which combines the two and has its own power policy.  In which case, a single domain suits our model quite well.

Regards,

Brad

From: Bruce Nordman <[e-mail]<mailto:[e-mail]>>
Date: Thu, 30 Jan 2014 13:31:11 -0800
To: eman mailing list <[e-mail]<mailto:[e-mail]>>
Subject: Re: [eman] WG Last Call for draft-ietf-eman-energy-monitoring-mib-08 and draft-ietf-eman-energy-aware-mib-13

For the Domain issue, I have always believed that the Framework draft
did not define the concept well.  Since it is ambiguous in the Framework,
it is not surprising that we are running into problems with it in later
stages (the MIBs for example).

The current Framework states (6.3.6):

   An Energy Management Domain can be any collection of Energy
   Objects in a deployment, but it is recommended to map 1:1
   with a metered or sub-metered portion of the site.

If one uses domain in the recommended fashion, then a device that receives
power from two sources (each sub-metered) is definitely in two different
domains.
If one uses it differently, as is permitted, then many reasonable
and useful usages require more than one domain.

Another way to think about this is that it was a flawed idea in
the first place that a device is in a domain at all.  It is the
power interface (or interfaces, for devices which receive supply
from more than one) that is in the domain, not the device itself.
An interface is more clearly in one domain.  Different types of
entities (devices, components, power interfaces) have different
types of data available, so having domain only in the PI is quite
reasonable.

Thus, the correct answer to me for domain for a device is either
zero or multiple.  To recommend one as a compromise seeks OK.
For a PI, only a single domain is needed.

I second Juergen's line of reasoning that it is quite unnecessary
and not justified to make the framework change to single at this time.

Thanks,

--Bruce

--
Bruce Nordman
Lawrence Berkeley National Laboratory
nordman.lbl.gov<http://nordman.lbl.gov>
[e-mail]<mailto:[e-mail]>
510-486-7089
m: 510-501-7943
_______________________________________________ eman mailing list [e-mail]<mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/eman