Operations and Management Area Working Group

Meeting 2010-03-24, 09:00 - 11:30

Minutes by David Partain and Brian E Carpenter 


1/ welcome and status - chair  Scott Bradner (SB)

NOTE WELL shown

WG status: RFC 5706 published since last time, one ID is in IESG review, = two other WG drafts in progress, most milestones achieved (except template for generic management data models).  Dan Romascanu: One of the router area ADs asked for a for doing data modeling work, so there's still a need for something like the 'Template for Generic Management Data Models'.

2/ Energy Management MIB: Juergen Quittek
   draft-quittek-power-mib
   http://tools.ietf.org/html?draft=draft-quittek-power-mib

First thing to know is what's going on before you can improve things.  

   This particular document implements the requirements document (draft-quittek-power-monitoring-requirements-00). This is a straightforward mapping of  the requirements: power state monitoring, consumption monitoring, battery monitoring, as three separate MIB modules. Open issues include:

* Identification of monitored unit (suggests Entity MIB).
* How many power states should be enumerated? Between 4 and 12 according to taste. Or should it be a device-dependent states table instead?
* Functionality details needed in the consumption MIB.
* Battery MIB needs work to align with UPS MIB and checking against existing private MIB modules.
* Should we cover smart meters?
* Should we care about other components of energy management?

Next steps: would like to merge with the following draft, which has good features.

Use of the Entity MIB:  Can we use it and assume it's there or is not much overhead.

Dan Romascanu (DR):  The energy MIB isn't available, either. Designing something other than Entity MIB is not free.  

Juergen Quittek (JQ):  But there is more in the Entity MIB than we need.

DR:  you don't have to have full compliance with Entity MIB.

DR  Regarding PoE, there is a MIB already defined.  

Conclusion:  JQ has had fruitful discussions with the people from Cisco and thinks that it would be useful to merge the two documents.

DR: any practical experience, especially with notifications?
A: some limited experience with simple private MIBs in data centers.

3/ Energy Monitoring MIB: Benoit Claise
   draft-claise-energy-monitoring-mib
   http://tools.ietf.org/html?draft=draft-claise-energy-monitoring-mib

Another response to the requirements. Broader targets - including network nodes, meters, building and home energy management, but not aggregated remote monitoring. Doesn't
assume Entity MIB, so has specific approach to identification (allowing for devices cascaded behind other devices). 

DR: How do you send power information from the PC to the router / switch?  

Benoit Claise (BC): It's a proprietary protocol so far

??: Some newer protocols allow you to do this.

DR: Switch in the phone just passes the information?

BC: That depends on the situation.

JQ: What's not clear, why does the phone act as a relay and why they don't speak IP directly to each other.

John P?: They do.  The phone is acting as a hu.

They have allowed for 6 operational states and 6 non-operational states.

JQ: We don't need to choose a number of states.  We need to choose whether we use an enum or not.

BC: It might be easier operationally to choose a number.

DR: But we can't foresee whether these states are enough for the long-term future. I believe we need both.  We need an integer giving a value and we need a state.
A: But we can't leave it open in the MIB.

Big open question is scope. Next steps include a power quality monitoring MIB module (look at IEC data model).

Joshua Etkin: Smart meters should definitely be in scope, they are coming in large numbers.

DR: Merging the two MIBs seems desirable. But the problem space extends outside IETF scope, which may need a broader effort as well. Might be that there is room for its own working group. That shouldn't delay this work.

BC: There are multiple stages in my to-do list, where this is just the beginning.

4/ "Green MIB": Sreekanth Sasidharan
   draft-sreek-powerconsumption-mib
   http://tools.ietf.org/html?draft=draft-sreek-powerconsumption-mib

   No presenter

DR: Authors of the first two MIBs, please include this author in the discussions.

JQ: I'm dubious about this work since it since it seems to be about reporting CO2 emissions, which I don't know how to do.

CL: I believe we need to support non-IP devices.  (See jabber logs)

BC: The author of the power consumption MIB is not listed in the attendees of list.

?? PHI Utility: We know how the power is produced

John ???:  Not every device can report its power quality, which is why we want to have it optional.  

BC: It's fine to merge the drafts.  The first question is to work on the question of how to index.  Can we conclude something?

DR:  We need to ask this question on the mailing list and discuss the right way forward. Let's ask the question on the mailing list.

JQ: We have a handful of similar issues.  We should put them all on the mailing list.

DR: Do we want to take it as a WG, do we want to take a merged version as -00, and what are the questions that need to be resolved?

BC: What do we do with the requirements draft?

JQ: Maybe we can integrate some of the requirements into the document?

SB:  Asks if this is space we should work in?  Many hands for, none against.

DR: We should recharter.

SB: We need to recharter, so we'll discuss this with the ADs.

5/ update RFC 4181?:  Randy Presuhn
   draft-presuhn-opsawg-rfc4181bis
   if yes, what else should be included?
   http://tools.ietf.org/html?draft=draft-presuhn-opsawg-rfc4181bis

   (no slides)

DR: This is an individual draft.  Goal is to update things like IPR templates and references.  Also an opportunity to fix some editorial issues.  There's a short list of such changes. Also a chance to fix stuff that's potentially wrong.  Have asked questions on the MIB doctors list, but not gotten much guidance.  Not a dramatic revision of 4181.  Suggest we make this an official item.

SB: There's one area that needs worked on.  The delta should be from 4181, not multiple delta statements.  There were a few hands when asked if we should do this, no one objected.

6/ The OAM Acronym Soup: Scott Mansfield
   draft-ietf-opsawg-mpls-tp-oam-def
   http://tools.ietf.org/html?draft=draft-ietf-opsawg-mpls-tp-oam-def

Goal:  create a set of definitions which are used across all of the MPLS-TP project.

SB:  This is important.  The disconnect between what different organizations mean is very important.  We're doing things that will be used by many different organizations and people, so this is important.
   
A handful (8?) of people have read it and all thought it should go to WGLC.

7/ Additional Private IPv4 Space Issues: Marla Azinger (MA)
   draft-azinger-additional-private-ipv4-space-issues
   http://tools.ietf.org/html?draft=draft-azinger-additional-private-ipv4-space-issues

SB:  Is there much more work that needs to be done?

MA: Don't think there's going to be very much more to be done.

SB: How many have read?

   (a handful)

??: Why is this coming to this working group?

MA: We looked at the various groups and reached the conclusion that this was the right place to do this work.

SB: do the people in the room think this is ready to go now?  (some support)

Ron Bonica: Perhaps we can send this out on an IETF LC.

BC: I want to read it again, before it goes to IETF LC.  Even if we don't adopt it as a WG item, perhaps we can do an informal call for input as a "WG LC" would make sense.

SB: That would be a reasonable alternative.  Then we can move it as an AD-sponsored Informational by Ron Bonica.


8/ Problem Statement for Plug-and-Play Deployment of Network Devices: Tina TSOU
   draft-tsou-network-configuration-problem-statement
   http://tools.ietf.org/html?draft=draft-tsou-network-configuration-problem-statement

   No presenter.