Re: [eman] Proposed alternation of framework

[john parello <[e-mail]>]

Hi Chris,

Thanks for the replies I agree with your assessments as well. Also with 
respect to initial products I think we are past that.

Both you and I have products which deliver the features that Bruce is 
talking about. So I think we are past initial product and down to 
setting common data modeling between them.

What we need is the common standard that we have expressed in the drafts.

w.r.t to the power domain the metering domain described in both

draft-claise-power-management-arch-02

and

draft-parello-eman-energy-aware-mib-00

have the flexibility to be specified based upon the physical metered 
topology but with the context information and tagging the different 
aggregation and reporting you asked for can be obtained.

This is very much analogous to what we do in IP networking with physical 
topology versus vlan etc.

Thanks
Jp

On 11/7/10 5:15 PM, Chris Verges wrote:
> Hi Bruce,
>
>
>
> Questions and comments inline:
>
>
>
> [BN] As an observation, power state is a property of an individual
> device and cannot be aggregated.  Power level (W) and energy use can be
> readily aggregated.
>
>
>
> [CV] With respect, I think power state can be aggregated.  For example,
> please consider a standard datacenter.  When all servers are turned on
> in the datacenter, it is at 100% "on" state.  If 30% of the servers are
> turned off, the datacenter's state has reduced to 70%.  This is fairly
> congruous with the ACPI model, where a server can be in different
> states, and each state represents a power usage level.
>
>
>
> [CV] How such aggregated state is determined is beyond the scope of any
> MIB, but the ability to report such information can offer a hook for
> innovation in the industry.
>
>
>
> [CV] I agree that power state, like reporting meter data, could be
> pushed off to a later release, as enumerating the entities themselves is
> far more critical (core?) to establishing anything more complex.
>
>
>
> [BN] There are a number of complications that I would propose deferring
> from our initial product.  These include transition states, support for
>
> reporting intervals, and reporting on components within a host.  As
> noted above, we could be making progress on these in parallel to the
> more basic work, particularly if the content was in separate I-Ds.
>
>
>
> [CV] What would now be in the initial product?  After reading your two
> recent threads, I'm a little confused over what the "initial product"
> is, as a definition and in its scope.
>
>
>
> [BN] Power Domain
>
>
>
> [BN] A system of power distribution with a common technology and fate.
> Technologies are usually distinguished by voltages and whether AC or DC.
> AC examples include 100V, 115V, 200V, and 230V.  DC examples include
> 380V, 48V, 24V, 12V, and 5V (variously including eMerge, PoE, USB, and
> vehicle standards).  Increasingly communications go along with power,
> but this is incidental to power reporting.
>
>
>
> [BN] Power domains are often in trees, but this is not strictly
> required.  A domain with a single source may have a controller at its
> root (e.g. a PoE switch), or not (e.g. a circuit breaker in a building).
> At this time, we should consider domains as having a single source of
> power; later we could relax that requirement.
>
>
>
> [BN] Common fate includes quality, reliability, availability, total
> capacity, and price.  How devices learn what domain they are in is out
> of our scope.
>
>
>
> [CV] With respect, this concept of a "Power Domain" is very limited to
> the standard utility/facilities definition.  Given the advent of newer
> reporting models and systems, should we extend this concept to simply
> mean any logical grouping of power entities.  The mapping between power
> domains and power entities can be many-to-many, not just one-to-many.
>
>
>
> [CV] For example, consider a deployment where the "power domain" is
> segmented in two ways: (1) the physical infrastructure, taking into
> account branch circuit and transformer capacities; and (2) the billing
> structure, where entities are "grouped" according to who pays the costs.
> If the MIB model only handles a 1:N mapping, the administrator needs to
> choose only one.  If the MIB model handles a M:N mapping, more complex
> and useful systems can be built on top of this schema.
>
>
>
> Enjoy Beijing,
>
> Chris
>
>
>
>
>
> _______________________________________________
> eman mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/eman