Editor's Note: These minutes have not been edited. Minutes - IETF #38 Memphis, TN -------------------------------- WG: RMONMIB Area: OPS Meetings: 8apr97 0900-1130 9apr97 1015-1115 Minutes: Andy Bierman (WG Chair) Summary ------- The goal of the Memphis meeting was the resolution of all issues, (to the greatest degree possible) related to current WG development. The following I-Ds and all WG email since the last meeting were discussed: draft-ietf-rmonmib-rmonprot-v2-00.txt (ID-1) draft-waterman-rmonmib-smon-00.txt (ID-2) draft-ietf-rmonmib-hcrmon-00.txt (ID-3) All issues were resolved, at least in principle. Some features are not documented yet in WG Internet Drafts, so actual resolution is pending such publication. The WG believes completed documents can be submitted to the IESG by August 1997. Deliverables: 3 documents The WG agreed to maintain the current document structure. The WG I-D version of ID-2 will reflect the scope agreed upon at the meeting.. The title is not clear yet, but 'Switch Extensions for RMON' may be appropriate. Detailed Agenda Resolution -------------------------- The following functional components were discussed during the meetings. Individual resolutions represent WG consensus, but are subject to mailing list objection. This is a very detailed account, since every aspect of the work-in-progress was affected by WG decisions made at this meeting. These minutes also serve as editing instructions for the authors of the I-Ds listed above. A: Protocol Directory A.1: review and update ID-1 A.2: Protocol macro parsers No new macros have been posted to the mailing list since the last meeting. The WG concluded this method of document completion was not working, and it was up to the document authors to work amongst themselves to complete the Protocol Identifiers (V2) I-D. Action Item(Editors ID-1): A new version of ID-1 is expected in one month, with new PI macros, the RFC 2074 edits, and sub-section headings within the PI section removed. An off-line phone conference will be planned to discuss potential work assignments. B: 64-bit counters B.1: scope of 64-bit support B.2: SNMPv1 and SNMPv2C support B.3: MIB Logistics -- Table format The High Capacity RMON MIB (ID-3) and all related WG email was discussed in detail: * too much boiler-plate -- some introduction text is copied from the RMON-2 MIB. Action Item(Editor ID-3): Left up to the Editor for change. Text must remain consistent with version in RFC 2021. * 'SPARSE-AUGMENTS' needed instead of real AUGMENTS to allow for a probe with only some interfaces requiring 64-bit counters. The WG concluded that instantiating all columns in all rows would not be a burden on agents, and would make table retrieval easier for NMS applications. Action Item(Editor ID-3): None -- AUGMENTS clause remains. Consider adding text explaining that the agent must instantiate all columns for all configured rows in the augmented table, if any columns are needed out of this table. Add rules for mapping the 32-bit counter to these filler-columns. * keep ID-2 and ID-3 separate. Action Item(Editor ID-3): Remove reference to switch-based RMON instrumentation. This functionality to be moved to WG version of ID-2. * more Counter64 support. The WG wants all etherStats packet-based counters to have 64-bit versions, as well as all appropriate topN and usrHistory tables. Action Item(Editor ID-3): Add missing etherStats extensions. Current SNMP SMI does not support topN or usrHistory (need Integer64, Unsigned64), so these functions will not be added at this time. C: Port Aggregation External port aggregation and internal collection-point monitoring were discussed together, but it was agreed that they are different problems that require different solutions. Discussion of internal collection-point monitoring is located in sections E.2 and E.4. Port aggregation allows an agent to potentially reduce DRAM and CPU collection requirements, and an NMS to reduce polling of redundant monitoring information. C.1: Port Aggregation Mechanism The ifStackTable will be used to represent an RMON port aggregation group. For example, suppose ifEntry.4, 5, 6, and 7 are to be monitored as one collection, and ifEntry.100 exists as a proprietary-virtual 'place-holder' interface, needed only for the following ifStackTable rows: ifStackStatus.4.100 = active(1) ifStackStatus.5.100 = active(1) ifStackStatus.6.100 = active(1) ifStackStatus.7.100 = active(1) An NMS would then set the appropriate RMON dataSource parameter to ifIndex.100 in order to monitor the just-configured port aggregation group. [Ed. note: The WG did not fully consider this issue at the meeting wrt/ dynamic aggregation. For an N-port switch there are (2^^N) - 1 possible port aggregation permutations. If an interface is allowed to appear in 0 or 1 collections, then N top-level proprietary-virtual interfaces must be pre-configured. This issue is considered re-opened and deferred to the mailing list for discussion. The WG should consider how to define port aggregation groups dynamically such that the top-layer virtual interface does not actually have to be present in any IF-MIB tables before it can be used.] Action Item(Editor ID-2): Describe the agreed-upon ifStackTable-based port aggregation framework. Define the dataSource configuration MIB objects. Consider mechanisms for fully dynamic dataSource configuration. C.2: Permutation Rules C.3: Data Reduction Mechanisms C.4: Non-Local Ports No available-dataSource-permutation mechanism will be considered for the ifStack-based aggregation feature at this time. No pre-collection filtering mechanisms will be defined either. All traffic from an identified interface is considered part of the dataSource. Individual VLANs may be identified as dataSources, pending outcome of the features defined in section E.2. Monitoring on non-local ports is considered a distributed management function deferred to the DISMAN WG. D: 100MB/Gigabit Ethernet Ports D.1: High Capacity Counters for Fast Ethernet, Gigabit Ethernet The high speed counter support for these interfaces is discussed in section B. D.2: Full Duplex Ports The WG agreed full-duplex and half-duplex interfaces must be representable by a single dataSource. See section E.2 for functionality defined in this area. D.3: Net Utilization Formula The old network utilization formula defined in RFC 1757 is specific to 10MB Ethernet ports. Formulas for 100MB (half & full-duplex) and GBit Ethernet ports should be defined. Action Item(Editor ID-3): Add appropriate framework text to define calculation formulas for specified ethernet port types. D.4: High speed packet capture The RMON-1 packet capture feature utilizes a packet-arrival-time delta-filter with a granularity of milli-seconds. High speed interface monitoring would benefit from finer granularity monitoring. This feature extension must be backwardly compatible with the existing captureBufferPacketTime object defined in RMON-1. Action Item(Editor ID-3): Define mechanism to augment the captureBufferTable to include the micro-second component of the capture-time-delta. E: Switch Extensions Switch-related RMON features were discussed in general, and the SMON MIB (ID-2) in particular. E.1: VLAN support The WG will add some IEEE 802.1Q VLAN support to ID-2. It was determined that per-VLAN information is much more important in the etherStats group than any other RMON groups. Therefore, only VLAN identification, dataSource identification, and port-level statistics collection will be addressed at this time. The WG will consider per-VLAN-priority as well, but this feature is not required at this time. Action Item(Editor ID-1): Add VLAN encapsulation protocol identifier macros as required. Action Item(Editor ID-2): Consider adding text to ifStack-based dataSource feature explaining use of this mechanism to monitor VLANs. Consider additional mechanism to identify a VLAN itself (regardless of port) using the dataSource capabilities feature. Add control table and data table for 802.1Q VLAN statistics, sparsely-indexed by 12-bit VLAN ID. Consider proper values for dataSource parameter. Data columns are: { ucast, mcast, bcast } * { octets, packets } Consider adding control table and data table of 802.1p statistics for a given dataSource, densely indexed by 3-bit 802.1p priority value. Consider proper values for dataSource parameter. Data columns are: { priority } * { octets, packets } OR { priority } * { ucast, mcast, bcast } * { octets, packets } E.2: Switch Configuration Extensions MIB objects to configure a copy-port function will be defined. The WG considered three levels of functionality: 1) 1 src port to 1 dst port 2) N src ports to 1 dst port 3) M src ports to N dst ports The WG will support option (2), and may support option (3) in the future. A dataSource capabilities mechanism will also be defined, to allow an NMS to better determine probe monitoring capabilities. Mechanisms to alert or prevent copy-port over-subscription problems were discussed, but no features were defined. Action Item(Editor ID-2): Define table allowing arbitrary number of src-portX-to-one-dst-port copy-traffic configurations. Consider adding support for full-duplex interfaces in the dataSource capabilities table(s). Consider extensions required to support level 3 copy-port functionality. Consider adding a dropEvents counter associated with the dst port to help an NMS detect over-subscription problems. Define a dataSource capabilities function, identifying: * OID of dataSource * probeCapabilities bit-mask pertaining to this dataSource only. If present, this overrides the global bit-mask for this dataSource. * indication of dataSource type { ifEntry, ifStack-aggregation, entPhysicalEntry } Consider functionality needed for arbitrary aggregation of these base dataSource types. * indication of promiscuous vs. non-promiscuous monitoring capability of the dataSource * indication of errored-frame monitoring capability; individual error conditions do not need to be identified. * indication of { half-duplex-rx, half-duplex-tx, full-duplex-both } status for full-duplex ports E.3: Switch-specific external instrumentation The WG agreed that no additional functionality was required in this area, since port aggregation, dataSource extensions, and VLAN monitoring are addressed separately. E.4: Switch-specific internal instrumentation The dataSource mechanism in E.2 may support dataSources and dataSource aggregations not identified in the ifTable (e.g., a repeater port). The Entity MIB will be used to identify internal backplanes (and possibly other entPhysicalEntry types) as collection-points. Action Item(Editor ID-2): No new functionality will be considered in this area, but consider adding reference to Bridge MIB to identify statistics for number of forwarded vs. dropped frames per-bridge-port in framework section for switch monitoring. E.5: Per-Connection Statistics TCP connection monitoring was discussed, but this work will not be pursued, since it is considered to be within the scope of the RTFM WG. E.6: Switch-Specific Protocol Directory The WG determined that no switch-specific protocolDirectory replacements or extensions were required. F: Interim Meeting The WG may need an interim meeting to complete the current workload by August. Due to the amazing amount of material covered and resolved in 3.5 hours at the Memphis meeting, an interim was not scheduled at this time. In the event the action items herein are not resolved by May 12, then an interim will be announced around the June 10 time-frame. F.1: Meeting Goals Completion of deliverables defined in the Summary section above. F.2: Meeting Logistics Meeting location does not have to be outside the USA, since it will be held within two months of the Munich IETF (even though the RMONMIB WG does not intend to meet in Munich). The WG will probably choose a non-hosted city, at an airport hub on or near the east coast of the USA. The cities suggested so far: * Washington, DC * Boston G: Late Additions G.1: RMON-2 MIB Bugs The WG discussed the following RMON-2 related issues: * some TCs are defined in terms of other TCs * 1757 version of OwnerString TC now different (maybe obsolete), and perhaps the IF-MIB version or general TC-MIB replacement should be used instead. No resolution was reached in either case, but the WG agreed that the capability to define TCs in terms of other TCs should be supported. G.2: ATM-RMON MIB Status The ATM-RMON MIB counts ATM-specific cells and connections, using data structures similar to those found in RMON-1. The ATM Forum is standardizing this MIB, and a final vote is due soon on document af-nm-test-0080.000. The RMONMIB WG is requested to consider integration of frame-based monitoring of ATM interfaces with the cell-level mechanisms found in the ATM-RMON MIB. Action Item(Editors ID-1): Consider adding appropriate PI macros for AAL-5, LANE, and other ATM-related frame encapsulations. --------------C4675A2A60--