CURRENT_MEETING_REPORT_ Reported by Robin Iddon/AXON Networks Minutes of the Remote LAN Monitoring Working Group (RMONMIB) Slides presented by the chair can be found at: ftp://ftp.cisco.com/ftp/rmonmib/minutes/andyb-danvers-slides.ps Agenda o Agenda bashing o Solution proposal evaluation criteria o 7-layer protocol monitoring and filtering if time permits: o Data reduction reporting mechanisms o Solution proposals not related to 7-layer statistics or filtering Agenda Bashing The agenda was not changed. Solution Proposal Evaluation Criteria The working group agreed on the following list of criteria for evaluating each solution proposal, in no particular order: o Usefulness of feature for intended application(s) o Accuracy of information (no ambiguity) o Ease of information retrieval o Ease of configuration o Implementation costs for agent o Implementation costs for NMS o Multiple manager robustness o Applicability to high-speed networks 7-Layer Protocol Monitoring and Filtering Application Monitoring There was concern that RMON-2 will not contain enough support for application monitoring. Even though a great deal of time has been spent on upper-layer monitoring proposals, there are some people concerned about the increase in resources needed (i.e., cost) to provide this level of detail. Working group consensus seems to be that application monitoring is needed, even though it will be expensive to provide. Current proposals fall into four basic camps: (Related documents in ftp://ftp.cisco.com/ftp/rmonmib/danvers.) o 7-layer stats, host, matrix and enhancements ecam2-mib.txt dickw-proto-id-mib.txt anil-ecam2-changes.txt o 7-layer host, matrix, history, hostTopN, matrixTopN drilldown1-mib.txt o Network layer statistics, address mapping, host, and matrix stevew-rmon2-draft-mib.txt o 7-layer statistics and filtering danh-filter-mib.txt Protocol Directory Issues Three modes of protocol directory population must be supported. 1. Agent supplied (from configuration, NVRAM, etc.). 2. NMS supplied (most likely one user-defined port number added to the end of a protocol identifier OID known to the agent). 3. Discovered by the agent. Protocols should not be added directly into the directory. An NMS should screen additions to the protocol directory. Robin Iddon and Steve Waldbusser presented their agreed protocolDirectory from ecam2-mib.txt and stevew-rmon2-draft-mib.txt. It is based on a hierarchical OID representation of the entire protocol layering (formally called a protocol vector). Actual protocol identifier values (e.g., etherType, port) are used in the OID. There seemed to be working group consensus to accept this proposal. Dan Hansen presented the Network General protocol directory proposal (danh-filter-mib.txt). This has the ability to insert a ``garbage'' padding layer with pointers to well known next layer protocols; proposal integrates filtering and protocol definitions. Allows user-defined protocols by layer, using the exist bit-wise filter mechanism. The bit-wise filters are expanded to allow a filter per protocol layer, as well as channel `ANDing'. Greg Bruell described Bay Networks' Packet Description Language (PDL). This is a C-like syntax for describing protocol header fields with support for many existing protocols. The working group liked the idea of using PDL in a companion document, coupled to the Protocol Directory companion document, to precisely describe the protocol decodes supported by a probe. PDL could be used to support an arbitrary mix of user-defined and agent-known protocols. There was agreement that this was useful, but no agreement that it was worth the cost. The PDL documents need to be posted (and released as an Informational RFC) before the proposal can be considered further. Rmon-2 Draft There was general agreement to take Steve's draft (stevew-rmon2-draft-mib.txt) forward and import good technology from other proposals as we go. Application monitoring, History, TopN, and Filtering will (likely) be added in some form. Agreement was reached on protocolOID -- both encoding and counting methodology. There was agreement that the proposed (limited) extensibility was valid. It was not agreed that this extensibility is the only mechanism required. The indexing will likely be changed to use an arbitrary index, which must stay constant between agent reboots. Application Monitoring Tables The group discussed table structures which were possible. There was much discussion about topN/history of matrix. Dispute over memory size/application usage of the tables. A possible method of table size control was discussed. A proposal to construct a matrix of applications and their usage of the probe data was made. It was agreed that more accurate data should be submitted before judgement be made on the cost of application monitoring. The pros and cons of history and sampling were discussed. The need for matrix history was disputed because the optimized retrieval was not really needed by the NMS. Proposals for matrix history will still be considered however. Interim Meeting An interim meeting will be held in the middle of May in Santa Clara for three days to discuss the draft-in-progress. An announcement will be made as soon as possible regarding meeting details.