Editor's note: These notes have not been edited.
Meeting Minutes -- 35th IETF; Los Angeles, CA
Area: Network Management
WG: rmonmib
Date: 6 March 1996
Email: rmonmib@cisco.com
Archive: ftp://ftp.cisco.com/ftp/rmonmib/rmonmib
WG Chair (& meeting minutes):
Andy Bierman <abierman@cisco.com>
Area Advisor (& WG Editor):
Steve Waldbusser <waldbusser@ins.com>
_______________________________________________________
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 IDs.
The WG 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 I-D 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 I-D stating that the usrHistoryObjectTable can exist when the
associated usrHistoryControlStatus is not equal to 'active(1)'.
Also related to row creation, the WG clarified that the usrHistoryControl
entries can be activated, even if the associated usrHistoryObjectTable has
not been fully configured by the management station. Un-configured
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 WG considered email and meeting suggestions:
1) split into a base document and separate protocol-family-specific
documents; publish the base document now, with others to follow as
finished.
2) hold back publication of RMON-2 until more macros are produced
(email-ed by WG members to the list).
3) 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 WG 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 workgroup 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 WG 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 WG 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
WG consensus was to address this problem in the next 4 months.
Several approaches were then discussed, which had been posted to the mailing
list:
SNMPv2c:
>> Counter64 from RFC 1902
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 WG 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 WG was asked to consider developing a new bulk data transfer mechanism for
inclusion in RMON-2. There was no WG consensus to hold up RMON-2 to start this
development effort. There was general WG consensus that data transfer
improvement would be beneficial, but there wasn't clear consensus on which
time-frame, WG, or approach would be appropriate. The WG 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 WG discussed various aspects of a possible interoperability test event:
>> Time-frame
>> Scope
>> Ground Rules
>> Logistics
The WG 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 WG 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 WG 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 WG agreed to use the existing mailing list to discuss proposals for
future RMON work. WG members are encouraged to submit internet drafts for
consideration by the group. Comments on the drafts should be sent to the
mailing list.
The WG 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 WG efforts. Currently,
one proposal for future RMON work exists:
>> draft-bierman-rmon-atmrmon-00.txt