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.