home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rmonmib / rmonmib-minutes-95apr.txt < prev    next >
Text File  |  1995-05-27  |  5KB  |  164 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Robin Iddon/AXON Networks
  5.  
  6. Minutes of the Remote LAN Monitoring Working Group (RMONMIB)
  7.  
  8. Slides presented by the chair can be found at:
  9.  
  10.  
  11.      ftp://ftp.cisco.com/ftp/rmonmib/minutes/andyb-danvers-slides.ps
  12.  
  13.  
  14.  
  15. Agenda
  16.  
  17.    o Agenda bashing
  18.    o Solution proposal evaluation criteria
  19.    o 7-layer protocol monitoring and filtering
  20.  
  21.  
  22. if time permits:
  23.  
  24.  
  25.    o Data reduction reporting mechanisms
  26.    o Solution proposals not related to 7-layer statistics or filtering
  27.  
  28.  
  29.  
  30. Agenda Bashing
  31.  
  32. The agenda was not changed.
  33.  
  34.  
  35.  
  36. Solution Proposal Evaluation Criteria
  37.  
  38. The working group agreed on the following list of criteria for
  39. evaluating each solution proposal, in no particular order:
  40.  
  41.  
  42.    o Usefulness of feature for intended application(s)
  43.    o Accuracy of information (no ambiguity)
  44.    o Ease of information retrieval
  45.    o Ease of configuration
  46.    o Implementation costs for agent
  47.    o Implementation costs for NMS
  48.    o Multiple manager robustness
  49.    o Applicability to high-speed networks
  50.  
  51.  
  52.  
  53. 7-Layer Protocol Monitoring and Filtering
  54.  
  55. Application Monitoring
  56.  
  57. There was concern that RMON-2 will not contain enough support for
  58. application monitoring.  Even though a great deal of time has been spent
  59. on upper-layer monitoring proposals, there are some people concerned
  60. about the increase in resources needed (i.e., cost) to provide this
  61. level of detail.  Working group consensus seems to be that application
  62. monitoring is needed, even though it will be expensive to provide.
  63.  
  64. Current proposals fall into four basic camps:
  65.  
  66. (Related documents in ftp://ftp.cisco.com/ftp/rmonmib/danvers.)
  67.  
  68.  
  69.    o 7-layer stats, host, matrix and enhancements
  70.      ecam2-mib.txt
  71.      dickw-proto-id-mib.txt
  72.      anil-ecam2-changes.txt
  73.  
  74.    o 7-layer host, matrix, history, hostTopN, matrixTopN
  75.      drilldown1-mib.txt
  76.  
  77.    o Network layer statistics, address mapping, host, and matrix
  78.      stevew-rmon2-draft-mib.txt
  79.  
  80.    o 7-layer statistics and filtering
  81.      danh-filter-mib.txt
  82.  
  83.  
  84. Protocol Directory Issues
  85.  
  86. Three modes of protocol directory population must be supported.
  87.  
  88.  
  89.   1. Agent supplied (from configuration, NVRAM, etc.).
  90.  
  91.   2. NMS supplied (most likely one user-defined port number added to the
  92.      end of a protocol identifier OID known to the agent).
  93.  
  94.   3. Discovered by the agent.  Protocols should not be added directly
  95.      into the directory.  An NMS should screen additions to the protocol
  96.      directory.
  97.  
  98.  
  99. Robin Iddon and Steve Waldbusser presented their agreed
  100. protocolDirectory from ecam2-mib.txt and stevew-rmon2-draft-mib.txt.  It
  101. is based on a hierarchical OID representation of the entire protocol
  102. layering (formally called a protocol vector).  Actual protocol
  103. identifier values (e.g., etherType, port) are used in the OID. There
  104. seemed to be working group consensus to accept this proposal.
  105.  
  106. Dan Hansen presented the Network General protocol directory proposal
  107. (danh-filter-mib.txt).  This has the ability to insert a ``garbage''
  108. padding layer with pointers to well known next layer protocols; proposal
  109. integrates filtering and protocol definitions.  Allows user-defined
  110. protocols by layer, using the exist bit-wise filter mechanism.  The
  111. bit-wise filters are expanded to allow a filter per protocol layer, as
  112. well as channel `ANDing'.
  113.  
  114. Greg Bruell described Bay Networks' Packet Description Language (PDL).
  115. This is a C-like syntax for describing protocol header fields with
  116. support for many existing protocols.  The working group liked the idea
  117. of using PDL in a companion document, coupled to the Protocol Directory
  118. companion document, to precisely describe the protocol decodes supported
  119. by a probe.  PDL could be used to support an arbitrary mix of
  120. user-defined and agent-known protocols.  There was agreement that this
  121. was useful, but no agreement that it was worth the cost.  The PDL
  122. documents need to be posted (and released as an Informational RFC)
  123. before the proposal can be considered further.
  124.  
  125.  
  126. Rmon-2 Draft
  127.  
  128. There was general agreement to take Steve's draft
  129. (stevew-rmon2-draft-mib.txt) forward and import good technology from
  130. other proposals as we go.  Application monitoring, History, TopN, and
  131. Filtering will (likely) be added in some form.
  132.  
  133. Agreement was reached on protocolOID -- both encoding and counting
  134. methodology.  There was agreement that the proposed (limited)
  135. extensibility was valid.  It was not agreed that this extensibility is
  136. the only mechanism required.  The indexing will likely be changed to use
  137. an arbitrary index, which must stay constant between agent reboots.
  138.  
  139.  
  140. Application Monitoring Tables
  141.  
  142. The group discussed table structures which were possible.  There was
  143. much discussion about topN/history of matrix.  Dispute over memory
  144. size/application usage of the tables.  A possible method of table size
  145. control was discussed.
  146.  
  147. A proposal to construct a matrix of applications and their usage of the
  148. probe data was made.  It was agreed that more accurate data should be
  149. submitted before judgement be made on the cost of application
  150. monitoring.
  151.  
  152. The pros and cons of history and sampling were discussed.  The need for
  153. matrix history was disputed because the optimized retrieval was not
  154. really needed by the NMS. Proposals for matrix history will still be
  155. considered however.
  156.  
  157.  
  158. Interim Meeting
  159.  
  160. An interim meeting will be held in the middle of May in Santa Clara for
  161. three days to discuss the draft-in-progress.  An announcement will be
  162. made as soon as possible regarding meeting details.
  163.  
  164.