-------------------------------------------------------------------------- IETF-81 EMAN Working Group Meeting 07/24/2011 -------------------------------------------------------------------------- Thanks Bill Mielke for the notes. [BC] Benoit Claise [BN] Bruce Nordman [DR] Dan Romascanu [GC] Georgios Karagiannis [JC] JinHyeock Choi [JP] John Parello [JQ] Juergen Quittek [JS] Juergen Schoenwaelder [KL] Kerry Lynn [MC] Mouli Chandramouli [RM] Rich Morgan [RW] Rolf Winter [WH] Wes Hardaker Attendees: around 40 signed the blue sheet (more people in the room. For whatever reason the bluesheet didn't make it to one part of the room) 1. Note well, agenda bashing, note takers, blue sheets, 5 min -------------------------------------------------------------------------- - Standard boiler plate discussion. 2. Update from last meeting / WG Status 5 min -------------------------------------------------------------------------- - 4 WG items currently, 3 more to go, on schedule for many things, Requirements draft is late 3. Terminology -------------------------------------------------------------------------- draft-parello-eman-definitions-00, 5 min, Chairs - One of the biggest problems we have is converging on terminology to improve the drafts. [BC] - Also need to settle on the preferred sources of definitions from other standards. [JP] - This shouldn't be a big issue. List ISO, IEEE, etc... and just need to pick. [JQ] - Many of these terms are from physics so we should align with those.[RW] - Propose to discuss "Powered Device" vs. "Energy Managed Object" [JQ] - Sees a problem with the collision with the std definition of "Managed Object". [JQ] - [JP] proposal is Energy Managed Object or EMO which shouldn't collide. - Question: Should we have an abstract term for all objects? [BC] - [JQ] doesn't object but also doesn't see the need. Not in other standards. - [JP] appeals for a super class. - [DR] finds the EMO term confusing. - [MC] powered device versus power monitor versus energy aware device - [MC] thought that these two meant different things. - Electrical and Non-Electrical Object from other groups. [JP] - [JS] doesn't like these. - [KL] recommends we consider ASHRAE 201P - Proposal: Use electrical object for now, then continue on the mailing list [BC] 4. Requirements for Energy Management, -------------------------------------------------------------------------- draft-ietf-eman-requirements-04, 20 min, Juergen Quittek Status: Covered items from JQ's slides. Good News - We are making progress and getting closer to completeness. Open Issues: - Revise security considerations and references. - Terminology for reporting on other entities needs revision and improvement. - Features: - UUIDs? - Power and Energy Time Series - Metering Impedance? - High/Low Notifications - Power availability mode? 'minimum', 'ready' for PoE - Producers and Consumers - Outlet Gangs - Can someone provide text? - Aggregated reports? - When multiple devices are attached to the same source how to report. - [RM] Did a good job with Producers/Consumers. Used odometers as a paradigm. [JP] Also did a good job with aggregation where you need to pay attention to accuracy when summing and reporting that. - [GC] agree. - [KL] recommended reviewing ASHRAE 201P. - Concept of shedding load? Need to include scheduling as well. - [JP] We cover shedding though power state control. - Aggregation function - Need to be careful. IPFIX is discussing this. Complexity can become large quickly. Is somewhat not in favor of our supporting aggregation. Support the UUID [BC, as contributor]. - Chris Nosio (sp?) - Makes the point that some use cases will want to report aggregated values without disclosing the details of individual devices. - Reporting aggregated values does not preclude wanting/needing to control power individually. - Will update the AS to include Demand/Response. [MC] - Impedance, frequency of reporting, all discussed on the list. [MC] - Power interval. Need to solve that one as well. [MC] - [JQ] is planning to try and have a new version out soon that addresses list feedback. - Consensus: UUID in, power/time both, impedance out, N notifications in, producers/consumers in, outlet gangs in if someone provides suitable text, aggregation still open, power availability still open. New version by the end of next week. - [DR] Can we define a minimal set of aggregation functions to be used? 5. Energy Management Framework, -------------------------------------------------------------------------- draft-ietf-eman-framework-02, 20 min, John Parello - Define an energy domain of devices/objects to be managed. - What is the set of information to be stored at the super class level? - Identity, classification, context are needed for each. - Controls on power, power state, energy, demand, electrical quality, and battery. - Additionally we need to do relationships like aggregations, metering, powering, proxy, dependency. - We have multiple power state sets, and objects can report on those. Identification: - Converging on we need a UUID. Do we agree on a linkage tot he Entity MIB? - What to do with device type? Identify Entity MIB fields which would be required? - If you link to the Entity MIB or is it mandatory? Does this force people to implement Entity MIB. [WH] - [JP] indicated it is optional to implement Entity MIB via a link. - If Entity MIB is implemented then the physical link is used, otherwise not. [MC] Context: - Open issue: Potentially add to the Entity MIB? - To do: Establish guidance on how to set roles. Measurements: - Discussed demand. Demand is used for billing. Demand is a smoothed curve of the power graph. - Showed slide with graph of three values. - Odometers are a good solution for energy. - Need to add time series for demand as well in the requirements. - In the requirements, power and demand are discussed as being the same. They have the same units. [JQ] feels that we have it already covered in the requirements. - Question: Based on Michael Suchoff comments on the list, there is a question of how energy is measured. This should be defined. Answer: The method of measurement is being delegated to the manufacturer. What needs to be reported is standardized. [JP] - Incorporated the decision about multiple power state series. Seems to be accepted. - What about variable states? Not fixed enumerate states? include? - Do we need "time in state"? [JQ} is a +1. - Elwyn Davies - Working with devices that are out in remote locations. Do we need special power states for that? Do we account for charging states? Does the MIB handle this? - How to model batteries? Is this a relationship or a component? - Relationship: Use the UUID to model the relationships between specific things. - Open issue on gangs. Are these done via relationships? - Use relationships to model the deployments found in the Reference Model. Showed that the framework can cover the reference model. Should be added to the AS. Showed and discussed several examples. - [JC] Where is the object information stored in the case of remote monitoring (Parent/Child)? Answer: Stored on the device implementing the MIB or the remote device. Open Issues: - Do we agree on UUID? [JP] thinks we are. - Need to receive feedback on variable range of states? - If aggregation disappears then the aggregation relationship can go away. - How to model batteries? Discussion: - Haven't modeled the components? [JS] - Modeling of the battery? If we are not modeling components then why model batteries? Use the Entity MIB to capture the relationships. [JP] likes this point. Other draft: draft-quittek-eman-reference-model-01, 10 min, Juergen Quittek Motivation: - Energy management is new to us. Discussing concepts and models. - Not in contradiction to what [JP] explained. - Main problem has been devices reporting on other devices. - Introducing new concepts (parent/child, etc). - Is there and easier way? Here is a proposal. - Discussed example cases of what we are modeling. - Asked what a device would report about itself. - Device attributes - Inlet/Outlet attributes - Power distribution topology - Does this model also address wireless power transmission? Answer: Yes. - [WFM] - If you turn off an object it may be continue operating because it has a battery, but it may also continue to operate because it may have self-power generation/backup capability such as diesel generator. Conclusion: - According to [JQ] Reference model seems to be a better choice than the other ones discussed this far. - It is simpler. - closer to concepts we have experience with - resulting MIB will be simpler - does not assume topology - Avoids unnecessary relationships Discussion: - [JP] feels that their models are the same except for relationships. [JP] model embeds them in the devices. [JQ] favors moving them to the management system. Advantage of embedding is that everyone can discover the topology. - [JQ] depends on the operational scenario. Having to configure the data on the device may hinder installation scenarios. - [MC] agrees with [JP]. Described the issue in his terms. - How do you model things which are not directly powered? Discussed modeling of components. This is not an EMAN problem, is it a general proxy of MIBs issue. [JS] makes the point that neither of the proposals model components. - How do you do building management? Answer: completely independent of this work. Summary draft-quittek-eman-reference-model-01: the reference model reports what it knows, doesn't limit the topology, and doesn't report the device relationships. 6. MIBs -------------------------------------------------------------------------- 6.a. Energy-aware Networks and Devices MIB draft-ietf-eman-energy-aware-mib-02, 15 min, Benoit Claise Information Model: - NEW: Called out alternate IDs that can link to other management systems. - OPEN ISSUE: Do we want a single table, or multiple ones? Right now we are defining a single table. Changes: - Introduced requiring UUID - [JS] at IETF80: Should we use SNMP context to report on children? - Next Step: Document all use cases and investigate them. - Discussion at IETF81: UUIDs have solved the problem of SNMP context. - Open Issue: Should we seek to have these UUIDs put into the ENTITY MIB? - Special variables for EMAN? Only need to implement just those variables - Some discussion occurred among [BC], [JS], and [WH]. [BC] Some more objects might be referred to the ENTITY-MIB, with a minimum compliance statement for the ENTITY-MIB, specficically for EMAN. For example, the pmName, which refers to the entPhysicalName if the ENTITY-MIB is supported. - [DR]: Question about whether we need to update the Entity MIB with the UUID. His point is that we need to plan for this. What is the preference? [BC] makes the point that to do it right it goes in the ENTITY MIB; to do it quick it goes in the EMAN pmIndex. Open issue: How to model multiple relationships, even in the same topology? - [BC] there are a couple of email threads that still need to be addressed. 6.b. Power and Energy Monitoring MIB draft-claise-energy-monitoring-mib-09, 15 min, Mouli Chandramouli What is new? - Support for multiple power states. Revised the MIB. - Implemented as Textual Convention administered in IANA. - Discussed the 1 byte vs. the 2 byte solutions. - [JS] indicates that he doesn't feel we have consensus on which to use. Agree we need more discussion on this on the list. - Added 3 power state sets to the IANA section. [JS] indicates that the current criteria are pretty high. Open issues is whether we want to change these criteria? - [JS] indicates that standards track threshold is very high. [DR] confirms this is the case. Expert review will be introduced instead. - [BN]: this document is accepted as a working group item 6.c. Definition of Managed Objects for Battery Monitoring draft-ietf-eman-battery-mib-02, 5 min, Rolf Winter Open Issues: - [Missed it] - When to rearm the battery low notification. May be solved. - How closely to align the Smart Battery Specification? Next Steps: - Object name: Want to better align with the Smart Battery specification. 7. Energy Management (EMAN) Applicability Statement, -------------------------------------------------------------------------- draft-tychon-eman-applicability-statement-02, 15 min, Mouli Chandramouli - In response to question about use case scenarios at IETF80 we moved the scenarios to this document. - will add industrial automation scenarios - will add load shedding/Demand Response - [MC] wants feedback on whether the existing scenarios are sufficient. - [JP] proposes a merger between the Reference Model -00 and the AS. - Open issues: Which IEC standard is the correct one to use? Need guidance on which IEC standards are applicable. - Will ?: Would a use case of a total isolated device be interesting? Response is yes but request to the questioner to provide some text. Next Step: - Update with scenarios and target devices. 8. Other Drafts (if time permits) -------------------------------------------------------------------------- Communication of Energy Price Information, draft-jennings-energy-pricing-01, 5 minutes, Bruce Nordman No time to present. 9. Open microphone: whatever time is left --------------------------------------------------------------------------