Editor's note: These minutes have not been edited.
Meeting Minutes -- 37th IETF; Los Angeles, CA
Area: Network Management
Working Group: rmonmib
Date: December 9 & 10, 1996
WG Chair (& meeting minutes):
Andy Bierman <abierman@cisco.com>
Area Advisor (& WG Editor):
Steve Waldbusser <waldbusser@ins.com>
____________________________________________________
Summary
-------
The RMONMIB WG met in San Jose to further clarify the scope
of the next generation RMON development effort.
Reading Material
----------------
ID-1:
Remote Network Monitoring MIB Protocol Identifiers
draft-ietf-rmonmib-rmonprot-v2-00.txt
ID-2:
Remote Network Monitoring MIB Extensions for Switch Networks
draft-waterman-rmonmib-smon-00.txt
ID-3:
Remote Network Monitoring MIB Extensions for ATM Networks
draft-bierman-rmon-atmrmon-01.txt
ID-4:
Definitions of Managed Objects for IEEE 802.3 Repeater Devices
draft-ietf-hubmib-repeater-dev-03.txt
Agenda
----------
Agenda bashing
New RMON-2 Protocol Identifiers
discussion of ID-1
scope of protocols left to add for 2nd Rev
High Speed Interface counter support (Counter64, 32/32 pair)
different approaches; ID-3 and ID-4
specific application to RMON-2
possible application to RFC 1757 for 100-BaseT interfaces
Switch-based RMON
framework for switch-based monitoring; ID-2
switch port aggregation; ID-3
Consensus Reading
determine common ground for new work items; limit
charter to work that can be finished in two meetings (8 mo)
determine work effort involved in each new feature
gauge consensus for proposed solutions
Bulk Transfer (time permitting)
identify general and (possibly) RMON-specific bulk-transfer
mechanisms
MIB-based vs. protocol-based approaches
SNMP vs. FTP/TFTP-based approaches
Minutes
-------
(1) RMON-2 Protocol Identifiers (PI) specification
==================================================
The PI macro section will be modified to make machine parsing easier,
by placing all non-macro text within ASN.1-style comments.
The addition of 'BEGIN' and 'END' keywords will also be considered.
The audience was urged to read ID-1 and submit comments
and PI macro additions/corrections to the mailing list.
The usage of PI macros (i.e. protocolDirID and protocolDirParamaters
objects) was discussed. There was concern the variance of different
protocol directory (PD) implementations will make it difficult for an NMS
to use RMON-2 data, since there can be many different encapsulations
of a given upper layer protocol.
The WG agreed that by convention, the 'anylink' wildcard
mechanism in the base layer encapsulation should be supported by all
implementations. This lowers the expectation of concurrent support for
specific base-layer encapsulations, but many probes will support both
mechanisms.
(2) Addition of high-capacity counters to RMON
==============================================
Counter64 and Counter32 'rollover' counters will be added to all appropriate
RMON-2 data tables, for all RMON-2 octet and packet counter objects.
The exact mechanism (e.g., new columns in existing table, new sparse-augments table)
will be considered on the mailing list.
Implementations are expected to follow the rules in RFC 1573 when
creating particular 'high-speed' counter entries. If the data source
indicates an ifEntry, then the associated ifSpeed must be at least
20 MBits/second for octet counters, and 650 MBits/second for packet
counters.
(3) RMON for Switching Devices
==============================
The SMON MIB (ID-2) was presented and discussed at length.
Several issues were raised during discussion which will be further discussed
on the mailing list. The WG must first determine the proper scope for the SMON
work.
There were a broad range of comments and concerns. Several people commented
about the inherit difficulty in attempting to standardize a MIB which attempted to
define a generic switch MIB.
There were some who felt very strongly that 'switch internals'
could not be effectively standardized, due to great differences
between switch architectures, and only the behavior exterior to
the switching could be standardized (i.e., monitor at the ports only).
Some people felt that switch-specific MIB objects should be developed
by a different standards body (e.g., IEEE for 802.1p/Q instrumentation),
and some felt that the RMONMIB WG could undertake such an effort, in cooperation
with the appropriate standards working groups.
The SMON MIB proposes several potential work-items for the WG,
related to switching devices:
- agent aggregation
- port aggregation
- global statistics
- 'local' vs. 'backplane' statistics
- per-priority (QoS) statistics
- per VLAN statistics
- internal 'probe-tap-point' management
The WG will further discuss each feature proposal in ID-2 on the mailing list.
The port aggregation problem/feature was raised in 3 presentations, and will
be identified as a separate work-item. There seemed to be some
consensus that port aggregation could be achieved with minimal (possibly zero)
new MIB objects, by creating new 'dataSource' values.
The WG Editor introduced the term 'test-point' to indicate a monitoring
point for a virtual probe, (as if) internal to the switch. The WG will
explore the specification of test-points, so an NMS may determine the
aggregation/monitoring capability of a switch-based probe, and possible
NMS-configuration of test-points. The 2 basic approaches (internal test-points
or external port aggregations) will be discussed at length on the mailing list.
(4) RMON for 100 MBit Ethernet
==============================
The application of RMON to high-speed Ethernet has been a WG priority for some
time, and the issue was raised again at this meeting. The WG will use the mailing
list to discuss/propose MIB definitions for the following issues:
* ifTable representation of full-duplex ports (impact on RMON dataSource)
* impact of 10/100 (auto-sensing) port speeds on RMON data collection
* application of RFC 1757
- HC counter for etherStatsOctets, etherHistoryOctets
- modification of bandwidth utilization calculation in description of
etherStatsOctets
(5) Consensus reading for new WG scope
======================================
Very little time was spent discussing WG consensus, since there was little
controversy in this area (and details of actual MIB objects are not yet known).
Unless there is strong objection raised on the mailing list, the scope of work for
the next round of RMON development will be limited to RMON PI extensions, high-speed
counter support (includes 100 MBit ethernet), port aggregation, and the application
of RMON to switching devices.
The WG will now begin evaluating specific solution proposals in these areas.
WG members are strongly encouraged to submit proposals (e.g., new PI macros,
comments on SMON) to the mailing list as soon as possible.
Consensus for the existing proposals and any new proposals will be
determined on the mailing list during the next 4 months. The group will
attempt to transition the individual proposals into WG-owned documents
by the end of the next IETF meeting.
It was agreed that work should proceed at quickly as possible,
and individual work-item deliverables should be released as soon
as they are ready (e.g., HC counters, PI macros, and SMON released
independently), which may require multiple concurrent documents.
Document structure will be proposed by the WG Editor and discussed
on the mailing list.
(6) Bulk Transfer Mechanisms
============================
Some WG members have developed MIB-based bulk transfer mechanisms, in order
to increase the transaction throughput for RMON-2 applications. There is
strong WG consensus that this problem is general in nature, and should be
addressed by a different WG. But since so many RMON vendors seem to be affected
by this problem, some meeting time was spent discussing the issue.
The Concord/Bay Networks' GetTable mechanism was presented and discussed. Several
separate issues were raised as a result of this discussion:
* MIB vs. protocol-based design
* OID compression
* data compression
* bulk transfer mechanisms (SNMP and non-SNMP)
* lexi-next ordering requirement
* distributed polling schemes (in addition or instead of bulk transfer)
* standardization strategy
The WG agreed that a BOF at the next IETF would be the appropriate next step
in standardizing a bulk transfer mechanism, which would hopefully result in the
formation of a working group devoted to this issue.