OPS Area RMONMIB WG Meeting Minutes IETF #55 November 18, 2002 Minutes by Andy Bierman Review Material --------------- (A) draft-ietf-rmonmib-framework-02.txt (B) draft-siddiqui-rmonmib-raqmon-framework-00.txt (C) draft-siddiqui-rmonmib-raqmon-pdu-00.txt (D) draft-siddiqui-rmonmib-raqmon-mib-02.txt (E) draft-bakke-dhc-snmp-trap-01.txt Minutes ------- 1. RFC 2613 Advancement The implementation report for the SMON MIB was presented and advancement of this MIB was discussed by the group. All MIB objects in RFC 2613 have been implemented by at least two independent development efforts. The RMONMIB WG believes the requirements for advancement of the MIB in RFC 2613 to Draft Standard have been met. Two minor issues did arise: 1) smonDataSource values Not all possible values of the smonDataSource object have been implemented by at least two developers. This is not considered a significant issue because each mode is specific to a different hardware platform environment, and different vendors used the values appropriate for their hardware platform(s). 2) portCopy modes The portCopyTable can be populated in three different ways (using the same MIB objects). The difference in each mode is related to associated rows in the portCopyTable. For example, the 'N:1' mode implies there are at least two rows in the table with the same port copy destination. Not all possible modes have been implemented by at least two developers. This is not considered a significant issue because all MIB objects in this table have been implemented in a consistent and interoperable manner by at least two developers. The 'N:1' and 'N:M' modes are dependent on the capabilities of the hardware platform. 2. RFC 2074 Advancement The implementation report for the RMON Protocol Identifiers was presented and advancement of this document was discussed by the group. RFC 2074 defines the Protocol Identifier macro format and is used for the index structure of the RMON protocol directory defined in RFC 2021. MIB walks of the protocolDirTable for multiple independent implementations indicate consistent representation of protocol encapsulations. In addition, multiple independent software tools have been developed which parse the RMON protocol identifier macro. These tools are used to assist in the protocol decode engine development for an RMON-2 agent. The RMONMIB WG believes the requirements for advancement of the Protocol Identifier Macro specification in RFC 2074 to Draft Standard have been met. At least two independent implementations of all RMON protocol identifier features exist, however there is one minor feature that was not fully verified by the implementation reports. Only one returned survey indicated that all protocol parameters were implemented. These parameters identify protocol decoding capabilities that are considered to be beyond the core feature set of RMON-2 agents. 3. RFC 2021 Advancement The implementation report for the RMON-2 MIB was presented and advancement of this MIB was discussed by the group. The primary statistical object groups seem to be widely implemented. There were some implementation issues raised, such as: - dropped frames counters not always correct due to limitations in the HW or device driver. - resource limitations constrain number of control entries that may be created and/or number of related protocol entries in the protocolDirTable. - flexible configuration of the protocol directory and complex protocol encapsulation representation makes agent implementation too complicated. None of these issues are considered critical, but they do indicate that the RMON-2 design and functional requirements are too complicated in some areas. There are several secondary statistical objects and configuration objects which are not widely implemented. The lack of implementation experience for these objects indicates that they are not widely useful or applicable to current market requirements for RMON-2 agent technology. A significant design flaw was exposed in the process of collecting implementation reports. The defined behavior of the TimeFilter textual convention (used in many statistical data tables) is quite sub-optimal for SNMP GetNext and GetBulk protocol operations. Basically, TimeFilter causes simple mibwalks to continue without end, and GetBulk response PDUs to contain lots of duplicate information. As a result, many vendors have relaxed the specification for TimeFilter and automatically 'wrap' the lexinext retrieval of tables that include a TimeFilter index, such that duplicate entries are not returned. There is no benefit whatsoever to the official behavior of the TimeFilter. The RMONMIB WG has decided that an attempt should be made to fix the TimeFilter specification such that duplicate entries are not returned by the agent during lexinext retrieval of a table that uses a TimeFilter index. Due to the numerous unimplemented MIB objects and the problem with tables using a TimeFilter index, the RMONMIB WG believes that RFC 2021 is not ready for advancement at this time. The RMONMIB WG will attempt to fix the TimeFilter issues and cycle the RMON-2 MIB at Proposed Standard. 4. RMON Framework The RMON Framework draft (A) was discussed by the group. Some minor issues remain which should be resolved before a WG Last Call for this document can begin. Some minor issues were resolved at the meeting: - an overview of the RAQMON work should be included - change the term 'standards' to 'documents' - tips on RMON usage should be done, but this should be in a separate document (perhaps an Applicability Statement) - the document title should change from 'RMON Framework' to something like 'An Introduction to the RMON MIB Modules' There are some problems with the diagram showing the relationship between different RMON MIB modules, such as: - TPM not just at application layer - SSPM looks like RMON-1 is supported but that's not true Some solutions were discussed, such as: - could change diagram or use table approach instead - could use 2 tables: metrics and bucketization The criteria for classification was discussed. Perhaps the concept of bucketization really means "is the protocol directory supported?" Perhaps the classification reflect monitoring requirements, and can be divided into three groups: - L2 only: RMON-1 - Protocol decode required: RMON-2, DSMON - Flow decode required: APM, TPM The issues with this diagram will be resolved by the document authors. A new version of the document addressing all known issues will be published soon. 5. RAQMON The three RAQMON drafts (B,C,D) were discussed by the group, and some issues were raised. These drafts will be reissues as WG baseline drafts soon. The RAQMON Data Source (RDS) can choose to send data formatted as an SNMP notification. There is some concern about how the RDS notification receiver list is configured. An RDS is not likely to have a command responder application supporting the standard MIBs for this purpose. There is interest in using the mechanism defined in the draft 'DHCP Option for SNMP Notification' (E) for this purpose. The RAQMON Framework draft (B) does not make a clear distinction between one way delay and round trip delay. The draft needs to be more specific about metric methodology details. An issue was raised about the way metrics are defined for inclusion in the RAQMON report. Currently the draft defines a hard-wired list of possible metrics and a bit-mask in each report to identify which metrics are actually present. There is interest in using a different approach which allows for an open list of metrics. The RDS would need to send (at least once) the list of metrics supported. This requires that the metrics be registered (possibly with IANA) and identified somehow (possibly OBJECT IDENTIFIERs). If this approach was used, it is likely that the Application Specific form of the RAQMON PDU would not be needed. There is some ambiguity about the interval of aggregation for RAQMON data. Is this data cumulative or not. E.g., does the RDS send data for interval 0 to 1, then 0 to 2, then 0 to 3, or does it send data for interval 0 to 1, then 1 to 2, then 2 to 3? This behavior needs to be specified more clearly in the draft. A number of minor open issues with the RAQMON MIB (D) were discussed. Refer to the RAQMON MIB slides for more details on this subject. An issues list has been started on the WG mailing list, and the WG will address these issues on the mailing list over time.