CURRENT MEETING REPORT

Reported by Andy Bierman, Cisco Systems

Minutes of the Remote Network Monitoring Working Group (rmonmib)

Agenda

1. agenda bashing
2. general RMON-2 MIB corrections
3. usrHistoryTable corrections
4. RMON Protocol Identifiers document
5. TimeFilter Issues
6. Counter64 Issues
7. RMON-2 Implementation Issues
8. Future RMON work
   

Materials

• draft-ietf-rmonmib-rmon2-03.txt
• draft-ietf-rmonmib-rmonprot-01.txt
  

Summary

The Chair presented a series of issues regarding the current RMON-2 Internet-Drafts. The working group discussed and resolved (when possible) each issue in turn, within the time allotted.

1) agenda bashing

• The agenda was accepted without comment.

2) general RMON-2 MIB corrections

• Minor typos, clarifications, and cosmetic changes were listed and discussed briefly. The next Internet-Draft for the MIB will contain the appropriate corrections.
  
• MIB change: *MatrixTopNRate objects have SYNTAX Integer32; this will be changed to SYNTAX Gauge32
  

3) usrHistoryTable Corrections

• The DESCRIPTION clauses are incorrect concerning usrHistory control table row creation and row deletion behavior. Clarifying text will be added to the next Internet-Draft stating that the usrHistoryObjectTable can exist when the associated usrHistoryControlStatus is not equal to 'active(1)'.
  
• Also related to row creation, the working group clarified that the usrHistoryControl entries can be activated, even if the associated usrHistoryObjectTable has not been fully configured by the management station. Unconfigured usrHistoryObject instances should default to { 0 0 }, and each associated instance of usrHistoryValStatus should be set to 'valueNotPresent(1)'.
  

4) RMON Protocol Identifiers (PI) document

• The completion possibilities for this document were discussed. The current draft does not contain a complete set of network and transport layer protocol macro identifiers. Enough are present to support most network layer protocols, but there is minimal support for transport layer protocols other than UDP or TCP. It should be noted that only protocols that encapsulate other (child) protocols within them need to be documented before they can be encoded in a protocolDirID string.
  

The working group considered email and meeting suggestions:

• split into a base document and separate protocol-family-specific documents; publish the base document now, with others to follow as finished. Hold back publication of RMON-2 until more macros are produced (emailed by working group members to the list).
• Consider the document to be a work-in-progress; publish now, and collect PI macros on the mailing list until enough are completed for additional publication.
• Up to 3 updates over the next 2 years may be required. The working group decided to proceed with approach '3'.
  

Another PI document issue was discussed regarding the ongoing addition of enumerations to the list of 'workgroup-assigned' values. The possibility of asking IANA to maintain the enumeration list (e.g. IANAIfType) was discussed. The details of this task will be finalized on the mailing list. The list currently contains one entry. Presumably, more entries will be defined over time. A WEB page to help facilitate PI collection may be maintained by InterWorking Labs.

The format of the working group assigned list was discussed, with the possibility of creating some limited hierarchical structure to the enumeration list. (e.g. IPX family instead of 'rawIpxOver802.3'). No consensus or details were finalized and this issue will be discussed further on the mailing list.

5) TimeFilter Issues

Minor clarification to the TimeFilter TC: TimeMark values do not need to be updated when rows are deleted.

The working group discussed the intended behavior of the TimeFilter; whether the TC scope should be per-conceptual-row, or per-instance in each row. It was agreed that the current defined behavior (per row) was more desirable and no changes to the TC will be made. MIB designers should attempt to group objects within the same 'time-filtered' conceptual row, such that all or most of the objects are expected to change value with similar frequency.

6) Counter64 Issues

The working group has been asked to consider some level of SNMPv1 and/or SNMPv2c support for Counter64 octet counters in the applicable RMON-2 tables.

First, the time-frame of any such changes was discussed:

• now--published with the initial RFC
• soon--published within 4 months of the initial RFC
• later--published if and when RMON-2 is updated

Working group consensus was to address this problem in the next four months.

Several approaches were then discussed, which had been posted to the mailing list:

1. SNMPv2c:
   • Counter64 from RFC 1902
2. SNMPv1:
   • OCTET STRING ((SIZE(8))
   • Opaque
   • Counter32/Counter32 pair--atomic-get requirement on agent
   • Counter32/Counter32 pair--no atomic-get requirement
   • scaled Counter32
   • any combination of one SNMPv1 approach and Counter64

There was strong working group consensus in favor of a Counter32/Counter32 pair as well as a Counter64 object.

7) RMON-2 Implementation Issues

Three types of implementation issues were discussed:

• Interoperability
• Conformance
• Performance

The working group was asked to consider developing a new bulk data transfer mechanism for inclusion in RMON-2. There was no working group consensus to hold up RMON-2 to start this development effort. There was general working group consensus that data transfer improvement would be beneficial, but there wasn't clear consensus on which time-frame, working group, or approach would be appropriate. The working group decided that the mailing list will remain open for discussion of interoperability issues and other RMON-related issues, even though the RMON-2 work is drawing to a close.

The working group discussed various aspects of a possible interoperability test event:

• Time-frame
• Scope
• Ground Rules
• Logistics
  

The working group agreed to schedule a test event in the July 1996 time-frame, Possible facilities will be investigated, as well as possible sponsors. Chris Wellens offered to have her company (InterWorking Labs) facilitate the test event details (chrisw@iwl.com), which seemed acceptable to the working group members present. Test participants would be expected to pay an entry fee and sign and abide by the ground rules agreement. The scope would be limited to basic RMON-2 NMS and agent interoperability tests for all groups. Some obvious areas of concern include row creation, protocol directory and the TimeFilter index. Tests would be done under complete non-disclosure and test scripts would be available in advance to the event participants. Details for the test event will be finalized on the mailing list.

8) future RMON work

Future rmonmib working group endeavors were briefly discussed. Possibilities include:

• RMON for other media:
  • ATM-RMON
  • Switched & 100 MBit Ethernet
  • FDDI-RMON
  • WAN-RMON
• Data Aggregation and other optimizations
  • high-level RMON-MIB for mid-level managers
  • collection by subnet or address mask
  • Counter64
  • more efficient data transfer mechanisms
    

The working group agreed to use the existing mailing list to discuss proposals for future RMON work. Working group members are encouraged to submit internet drafts for consideration by the group. Comments on the drafts should be sent to the mailing list.

The working group agreed to request a BOF session at the next IETF (Montreal). The session will be open first to prepared presentations, then open (time permitting) to presentations from the floor. The goal of the BOF will be to identify areas of common interest for future rmonmib working group efforts. Currently,one proposal for future RMON work exists:

• draft-bierman-rmon-atmrmon-00.txt