EMAN Working Group Minutes - November 10, 2010 (draft, as of November 11, 2010) 1. Note well, agenda bashing, note takers, blue sheets, 5 min Chairs reviewed the history of the energy management topic in IETF. 2.a. Energy Management Requirements, 15 min, Juergen Quittek draft-quittek-power-monitoring-requirements-02 Capabilities that need to be in place to provide a more energy efficient Internet; one item is obviously power management. Why monitoring is important. What needs to be monitored - Actual power state - Current power source - Power (Rate of energy usage -- instantaneous reading) - Energy consumption Ken Karlberg: Have you thought about a more granular perspective like measuring the energy consumption of an application? Juergen: Assigning energy usage to software applications is a difficult problem. The working group is focusing on the physical entities that can be directly measured. Can extend to other quantities like power quality and battery status. Discussed meta-information. The issue of control. Control may be an initial work item or a later work item but it cannot be ignored. Some monitoring examples - Intelligent Power Distribution Units - Power over Ethernet - Mid-level managers / proxies - Energy management systems with special characteristics. What is needed? - Reporting quantities, etc. Big Issue: - Identification of monitors Dan Romascanu: Did we consider using the Entity MIB? Juergen: Can be used except in the proxy case. Jabber: Are we accounting for the reporting of individual power strip sockets? Juergen: We want to support this when it can be done, otherwise only aggregate data may be available. John Parello: Some smart PDUs have RS-232 so identification there may not be a problem in the future. Janu: Some devices have facilities for providing identification information and the requirements should account for these cases. Mouli Chandramouli: Based on Cisco studies most of the energy usage is in the hardware and very little can be assigned to the software but there may be a need to address this case down the line. Stuart Cheshire: iPhone/notebook consumption depends very much on what it's doing. Chair asked if the sense of the room was that this should be made a working group draft. No objections. Take to the list. 2.b. Considerations, 15 min, Bruce Nordman [ as a contributor only ] draft-norwin-energy-consider-01 Introduced himself. Energy background which is important to help insure that the standard is as widely applicable as possible. Draft is not a standards track document. - Some information can be incorporated into the other documents. - To document some of the decisions and why they were made. Scope of devices - All IP devices. - Non-IP devices as identified in other drafts. Power state terms - Need only a limited number of power states. - Additional elaboration via other distinct variables. - The term ?power level? is confusing as others view it as "Watts". Control Model - EMAN should equitably support all management models. Role of Control - Ensure that control considerations do not undermine the architecture. Identity - Core requirement. - If use existing method describe which one and how to use. - Does not replace or interfere with existing mechanisms for device or service discovery. Concepts in other drafts - Focus on functions rather than boxes Presentation to non-IETF audiences - Consider ways to organize and present information to maximize accessibility. Dan Romascanu: IETF has a clear and well defined terms for things that are required or optional or whatever. Are we proposing something new? Bruce: No. Rolf Winter: this needs to be a living document, at least to start with - no hurry to make it an RFC. John Parello: How would that work with respect to normal WG process? Juergen: not a problem, doesn't have to become an RFC. We need to try to make the information in these standards more general useful and accessible to those outside of IETF. This is intended to be a living document and help facilitate discussion and understanding. Power - Various details need to be addressed. Use cases, scenarios, contexts - Should to be gathered together in one place. Take up on the list. Multiple Power Sources - Need to address. Question: lots of work done already; could we use existing MIBs? Bruce: will try, but not sure. Conclusions - Five items easy to agree on; five others that need discussion. - Question: Wireless groups have done a lot of work in this area already. Are we looking at these existing MIBs and associated work? Bruce: The group should look at these and take them into consideration. Mehmet Ersue: What non-IETF audiences do we have in mind? Bruce: roduct manufacturers, energy managers, policy makers, etc. John Parello: Should this work be coordinated with other groups? Benoit: Yes. The applicability statement in the charter will address this as part of the standard IETF process. Dan Romascanu: We could liaison with other groups, e.g. WGLC. People in the room who are active in other groups should convey eman status and progress and report any comments. Chair: More feedback on list, please. 3. Energy Management Framework, 20 min, Benoit Claise [ as a contributor only ] draft-claise-power-management-arch-02 The relationship between the documents is called out in the charter. We want to cover a number of Use Case Scenarios in the MIB modules. Concept of Parent/Child - Justification - Scaling issue if the NMS would control each child. Discussion about the applicability of this term. Juergen: need more clarity. What can a Parent actually do? Benoit: power strip should be able to identify connected (child) devices. John Parello: we should start by defining the P/C relationship. Ken Carlberg: need decision points - what's to be controlled? Bill Mielke: could there be a recursive hierarchy of children? Benoit: will discuss this on the list. Bottom line: Take the discussion to the mailing list. Concept of Power Levels - Agreed to change term ?power level? to ?power state?. - Proposing 12 such states. 6 operational / 6 non-operational - Manufacturer specific states are mapped into the generic states. Bruce: Too many states; operational details separate from power state. Bill Mielke: ok so far, will need more extensible model long-term. Benoit asks for further proposal and lots of list discussion. Regardless need at least 5 power states. Comment: Current proposal is OK for a first pass but long term we need to consider more extensible options for supporting manufacturers. Bottom line: Take the discussion to the mailing list. Come with proposals. Terminology to be agreed on soon. Outstanding question is whether to use IPFIX. Device power state transitions will take time. Juergen: Get MIB/requirements done, then consider this. Bill Mielke: Should stay close to SNMP management paradigm; only talk about actual requirements = low overhead. Benoit: We will keep developing the Framework on the list. Chair asked if the sense of the room was that this should be made a working group draft. No objections. Take to the list. 4. Energy-aware Networks and Devices MIB, 15 min, John Parello draft-parello-eman-energy-aware-mib-00 Energy Aware MIB - This MIB is concerned with identifying energy aware devices. - Capabilities of the parent and the child are not modeled yet. Concepts - Basic information to identify the device and set a business context. -- Collected once or at configuration. Juergen Quittek: Why do we need the business context on the device? John: (1) Helps to enable distributed management. (2) It is more generally useful even in other management areas where it is lacking. (3) More critical in the case of power to enable intelligent management. Bruce Nordman: Which SNMP variables are required? John: All. Various data are included in the current proposal. - Some fields provide references to other MIBs, if available. Role of the Entity MIB is key. Dan Romascanu: This standard could require that Entity MIB be supported to be an energy aware entity. If the manufacturer does not want to implement a full entity MIB they can only populate those portions that are needed for energy management. Benoit: Only for the objects that are related to the parent? Dan: Yes. Juergen: Power Monitor can report about own box using entity MIB, but can't do it for other devices. Benoit: Any clashes of indexes? with Entity Index? with pmIndex? Juergen: If there is a clash, we could use a pair of information (SNMPengineID) Bottom line: Continue discussion on the mailing list. MIB relationships were driven by customer requests to facilitate the correlation of IDs which had already been discovered. There are examples of working implementations. Rich reporting can be enabled even using this small set of attributes. Chair asked if the sense of the room was that this should be made a working group draft. No objections. Take to the list. 5.a. Power and Energy Monitoring MIB, 15 min, Mouli Chandramouli draft-claise-energy-monitoring-mib-06 Emphasized the areas of focus for the MIB - Power measurement - Attributes of power measurement - Power levels - Demand Energy measurement - Power Quality - These are optional modules - Important point: based on the pmIndex defined in the energy-aware MIB Cisco has a prototype implementation. They have shown that even a few simple contextual attributes are sufficient to provide a rich set of reporting capabilities. Power quality is measured for each phase in multiple phase contexts. 5.b. Power and Energy Monitoring MIB, 15 min, Juergen Quittek draft-quittek-power-mib-02 Briefly: - The two proposals are not that different. - Main differences between the two are: no sliding window for energy monitoring, power states, optional modules, index, - Juergen believes the two can be merged. Chair: Suggests that the two creators work together to merge the MIBs and bring that to the working group. 7. Energy Management Applicability, 10 min, John Parello draft-tychon-eman-applicability-statement-00.txt Discussed that deployment scenarios are being considered. Requests additional comments on the email list. Emphasized that we should reuse available standards where possible and applicable. Need Use Cases/Scenarios in a single document. List of other standards (RFCs and from other organizations). Lots to do. Bottom line: More discussion on the mailing list is needed. 6. Battery MIB, 10 minutes, Juergen Quittek draft-quittek-power-mib-02 Currently part of draft-quittek-power-mib-02 - just need to divide it. What to monitor? - Current charge - Age of the battery - State of the battery - Etc. Open Issues - Align with the UPS MIB module - Do we need battery ID? Still homework to be done. Need a battery ID to signal when battery is changed? Request: If you have experience with batteries or care about batteries please participate on the mailing list. Not (yet) proposed as a WG item. Meeting finished at 1501. One chair observed 1500.