------------------------------------------------------- IETF-80 EMAN Working Group 03/30/2011 ------------------------------------------------------- Thanks Bill Mielke for the notes. Attendees: around 50 signed the blue sheet. 1. Note well, agenda bashing, note takers, blue sheets, 5 min Benoit: - Review the agenda and ask for adjustments. - Review the status of the milestones. 2. Requirements/Framework 2.a. Requirements for Energy Management draft-ietf-eman-requirements-01, 10 min, Juergen Quittek - Document has been adopted and is at the second revision. - Asked for suggestions for additional scenarios. - Added scenario for multiple power supplies. - Added power outlet gangs. - Added batteries in powered devices. - Anticipate a big revision based on the decisions to be taken today. Power States: - How many do we need? - Do we need different sets of states? - IEEE 3 modes. - We have set of 12 in framework document. - ACPI - DMTF - And more ... - What to do? - Georgios Karagiannis: What is the relationship between Power States and Power States of Power Monitor Parents? - Answer: no connection. The states of the two devices have nothing to do with each other. - Options: - Supoort one fixed list of states - Support open list of individual states registered at IANA - Support open list of sets of states registered at IANA - Dan Romascanu: clarifying question. One NMS will always work within a single set of power state series - Wes Hardaker comment: Agrees with Dan. - Two sets of users: Generic Managers and Specific Managers - Possibly do both - simple defined set of states for generic managers and specific set for more specialized support. - Dan Romascanu: Comment: - Can do sparse allocation of IDs with groupings and gaps. - His contributor preference is an IANA enumeration. - Speaker Comment: - Question: What types of discovery protocols are we considering? - Answer: only objects - Question: What type of links? - Answer: No specification of a specific link type. - Russ White Comment: - Based on experience using a magic numbering scheme is not a good path. - Juergen Schoenwalder Comment: - Need to constrain how new lists can be registered. - Favors a single numbering scheme over the the two number scheme. - Georgios Karagiannis: - Question about the scope of the work. Energy grids included? Which energy direction is included? - Answer: Send suggestions to the list. We are not covering grids. - Chris Verges (on jabber): +1 to the dual simple/complex model proposed Chairs' summary of consensus: - multiple sets of power states in IANA - we need to carefully define the "IANA Considerations" section so that there is no explosion of sets - one single registry for all sets versus one registry per set is still undecided 2.b. Energy Management Framework draft-ietf-eman-framework-01, 10 min, John Parello - Document adopted in last meeting. - Described what the charter has to say about the document content. Changes from the last revision: - Added patterns for aggregator, proxy, or distributor to the terminology. - Expanded keyword examples to cover PDU outlet gangs. - Added UML for Energy Aware from the charter. - Added UML for the Power States -- Will likely change based on current discussions. Review key Concepts: - Described as a software pattern. - Parent is an aggregator, proxy, or distributor. - Not imposing that pattern on the deployed context. Power State Series Georgios Karagiannis: - Question about how the power states of the aggregator line up with the states of the children? - Answer: Needs to be addressed. Possibly aggregate the states up from children as a set. Open Issues: - Agree on usage of the term "Power Monitor"? - Answer yes and add to the glossary. - Do we support power producing devices? - Proposal: Investigate ODVA - Update requirements if needed. - Should implementation scenarios be included? - Move to applicability statement. - Standardize on the Units? Speaker Comment: - Distribution related comment ... - New developments in home power generation? - Answer: We are focusing on monitoring first and deployment scenarios will be addressed later. Speaker Comment: - SI Units will not save us. It is insufficient. - Answer: We still need to agree on the units. 2.c. Reference Model for Energy Management draft-quittek-eman-reference-model-01, 10 min, Juergen Quittek - Not in conflict with draft-ietf-eman-framework-01: describe the function - Described his breakdown of functionality and taxonomy of functions. - Described various key scenarios progressing from simple to more complex cases. - Highlights the mapping to Parent and Child. - Highlights the need to interact with multiple management systems. - Discussed the need to separate the functions out to account for proxying/gateways. - Discussed how extending for control is easy. Speaker Comment: - Noted that in this model elements can take on multiple roles. John Parello: - Regarding Parent/Child being a location, from an object oriented point of view, the Parent and Child are Super Clases. Other items as interfaces. Robert Comment: - Will we embrace energy harvesting? If so then this model may need additional work. - Answer: We have not really thought through the harvesting cases. - Comment about where the control loops are implemented. 3. MIBs 3.a. Energy-aware Networks and Devices MIB draft-ietf-eman-energy-aware-mib-01, 10 min, John Parello New items in the draft - Clarification of Child Specific attributes - Added more identifiers - Discussed linkages to other MIBs and that they are optional. Changes in draft: - Clear up refrence to other MIBs - Add alternate keys for NMS linkages - Identify persistent objects Open Issues: - Length and format for PowerMonitorID - UUIDs per port may be burdensome for devices. - May need internal indexing. - Should some of these duplicated Juergen Quittek: - Support multiple parents for each child? - Answer: Not currently but not opposed to it intrinsically. Concern over double counting. The use case must be described in the requirement 3.b. Power and Energy Monitoring MIB draft-claise-energy-monitoring-mib-07, 10 min, Mouli Chandramouli - Focus is on Power measurement, Power Levels, Energy Measurement, and Power Quality. - What's new in this version? - Merged the two models presented at Beijing. - Relationship to Entity MIB has been specified and clarified for cases where Enitity MIB is or is not imlemented. - What's next? - Possible revisions based on JuergenS presentation. - Update to account for final decisions on Power States. - Revise draft based on feedback to improve the text. - Chris Verges (jabber): - On pmPowerIndex, this seems like a complex if/else-if/else schema that isn't structurally enforced in the MIB. What NMS or end user confusion might occur as a result of this? - Answer: to be answered on the list. . 3.c. SNMP Contexts and the ENTITY-MIB Juergen Schoenwaelder, 10 min - Juergen was concerned that there may have been confusion on the Entity MIB usages. - Not advocating a position, merely wants to have the reality clearly understood and described. - Discussed the organization of SNMP engines, contexts, and MIB trees. - The information model is describing a physical containment tree. - Uses the terms Parent and Child which are not overloaded. Benoit Comment: - Expressed concern about having child contexts pointing to other contexts and whether this works or will be problematic. Bill Mielke Question: - In the real world, how are contexts used? - Answer: typically with the BRIDGE-MIB, where each instance is a different VLAN Dan Romascanu Comment (from a procedure point of view): - If this WG has some special needs relative to Entity MIB we can charter work to come up with a new revision of the Entity MIB, RFC4133bis, if needed. Then move deviceClass to IANA. - [Missed some other comment] John Parello Comment: - SNMP context, process oriented. Not really used for relation Set of context meteredBy, aggregatedBy Juergen Quittek Comment: - Discussed about how to implement children pointing to parents. Use the UUID as a key? - Apparently, could be done by extending the deviceClass John Parello Comment: - Pointers are typically (in SNMP) - We may need a more general scheme to account for non-SNMP cases. Benoit Claise Comment: - Not clear to him what is the impact of using this solution of extending Entity MIB? - Can this cover all use cases? - Answer: Current EMAN MIB does not cover all use cases. JuergenQ Comment: - We need to investigate this option and do analysis? Chairs conclusion: - Proposes to consolidate the use cases to the applicability statement and then proceed from there: evaluate what we can and can't model with the ENTITY-MIB. - General agreement on this approach from the room. 3.d. Energy Monitoring and Management of Networked Entities using SNMP and Role-Specific Sparse Tables draft-verges-eman-separate-modules-mib-00, 10 min, Benoit proposes to let people read through the description provided by Chris for each slide. Dan R. Comment: - Comment on "EMAN is more than this one working group" comment on the slides. - Wearing his official IETF AD hat he recommends that the group stay focused on the chartered items. - Chris's answer (via jabber): Yes, it is intended to mean "there are multiple objectives. And to indicate that the work that EMAN does will be continued into the future." John P Comment: - Question about how Chris is defining health of a device. This is not in the charter, per se. - Chris answered: [Missed]. Taking this to the list. Benoit Comment: - Chris proposes to merge the drafts. As long as there are intereting things in there then by all means let's incorporate them. 3.e. Definiton of Managed Objects for Battery Monitoring draft-quittek-eman-battery-mib-00, 10 min, Juergen Quittek MIB has been separated out into its own document. Open question is still what needs to be monitored? Technologies? - Many more possible options exist but the are mostly academic. John Parello Comment: - May be mixing and matching States from orthogonal dimensions. full, empty is not a power sate - Answer: Agree, take it to the list. JuergenS Comment: always local to the device? - Answer: Robert Comment: - Are the states meant to be mutually exclusive? - Answer: Needs to be part of the discussion. Alex Comment: - Is concerned about the list of battery technologies and whether we should take this to IANA. - Likes to have such lists and views them as useful but is concerned over the accuracy and applicability of this list. Mouli Comment: - UPS MIB comment. [Missed the details.] Sense of the room to accept this document as WG. -> hum in favor of accepting it 4. ODVA 4.a. Energy Awareness from the ODVA organization (Industrial), 10 min, John Parello ODVA is a business league who is growing out of the electrical area. - Members are electrical backgrounds with some knowledge of networking. - This is the converse of our expertise. ODVA is investigating an official IETF liason. There are lots of parallels between us and them, including phases. We may want to merge our use cases with their use cases as they are migrated into the applicability statement. Chris Verges (jabber): - Let's "borrow" the ODVA's use cases for a validity check against the Applicability Statement The following drafts were not presented, due to the lack of time. 5. Applicability 5.a. Energy Management (EMAN) Applicability Statement draft-tychon-eman-applicability-statement-01, 5 min, 5.b. Energy perspective on applicability draft-nordman-eman-energy-perspective-01, 5 min, Bruce Nordman 6. Other Drafts and Presentations 6.a. Considerations for Power and Energy Management draft-norwin-energy-consider-02, 5 min, Bruce Nordman 6. Open microphone: whatever time is left