Re: [eman] Proposed alternation of framework

Hi John,

We may be a little off on our interpretations of the ideal data model.  I hope you'll bear with me as we try to come to an understanding on it.

I agree that both of the proposed MIB sets have all of the information needed -- "in some way".  What I'm arguing is, with respect, they may not have the ideal structure to represent this information quite yet.

The current structure proposed in ENERGY-AWARE-MIB couples the definition of the power management entity with its network management data (domain, keywords, role) fairly tightly.  This kind of "high cohesion" is notoriously bad for complex systems that need to evolve over time.  Perhaps I'm making an assumption here, but wouldn't it be fair to state that our understanding of managing energy via networks will continue to change over the next decade?

All I'm proposing is breaking the existing MIB set apart into more of a "low cohesion" pattern.  Like with objects modeled using CRC cards [1] from object oriented programming, each MIB/table should have a clearly defined set of roles and responsibilities:

·         ENTITY-AWARE-MIB

o    pmEntityTable

§  Superclass: None

§  Responsibilities: List all "energy-aware" devices/components/etc. of the SNMP agent that are available

§  Collaborations: pmNetworkMgmtTable

o    pmNetworkMgmtTable

§  Superclass: pmEntityTable

§  Responsibilities: Provide network management attributes for modeling an energy-aware entity's relationship to the physical infrastructure, other logical devices, business-case groupings, etc.

§  Collaborations: pmEntityTable

o    pmEntityPhysicalMapTable

§  Superclass: None

§  Responsibilities: Map the entries in pmEntityTable with entPhysicalTable (ENTITY-MIB)

§  Collaborations: pmEntityTable, entPhysicalTable

o    pmEntityLogicalMapTable

§  Superclass: None

§  Responsibilities: Map the entries in pmEntityTable with entLogicalTable (ENTITY-MIB)

§  Collaborations: pmEntityTable, entLogicalTable

o    ...

·         ...

(I'm using this pattern because it comes across visually in an e-mail, but effectively the IETF RFC's do the same thing in their textual descriptions of each of the components.)

Currently, pmEntityTable and pmNetworkMgmtTable and pmEntityPhysicalMapTable from above are all glued together into a single pmTable in ENTITY-MIB.  Yet as you can see from above, they all accomplish various different things.  If we split them into three separate tables, not only is it clearer in terms of understanding, but it also helps when the EMAN WG decides (for example) 2 years from now to introduce some new "Smart Grid" integration schema that NIST is pushing.  Changes become more isolated to a handful of tables rather than impacting the core pmEntityTable, upon which a lot else will be built.

Thanks,

Chris

[1] http://en.wikipedia.org/wiki/CRC_cards

-----Original Message-----
From: john parello [mailto:jparello@cisco.com] 
Sent: Monday, November 08, 2010 9:35 PM
To: Chris Verges
Cc: eman@ietf.org
Subject: Re: [eman] Proposed alternation of framework

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

> eman@ietf.org <mailto:eman@ietf.org> 

> https://www.ietf.org/mailman/listinfo/eman <https://www.ietf.org/mailman/listinfo/eman> 