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 Area Advisor (& WG Editor): Steve Waldbusser ____________________________________________________ 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.