home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / rmonmib / rmonmib-minutes-96dec.txt < prev    next >
Text File  |  1997-01-30  |  9KB  |  209 lines
  1. Editor's note:  These minutes have not been edited.
  2.  
  3. Meeting Minutes -- 37th IETF; Los Angeles, CA
  4. Area:  Network Management
  5. Working Group:  rmonmib
  6. Date:  December 9 & 10, 1996
  7.  
  8. WG Chair (& meeting minutes):
  9.     Andy Bierman       <abierman@cisco.com>
  10. Area Advisor (& WG Editor):
  11.     Steve Waldbusser  <waldbusser@ins.com>
  12. ____________________________________________________
  13.  
  14. Summary
  15. -------
  16.  
  17. The RMONMIB WG met in San Jose to further clarify the scope 
  18. of the next generation RMON development effort. 
  19.  
  20. Reading Material 
  21. ----------------
  22. ID-1:
  23. Remote Network Monitoring MIB Protocol Identifiers  
  24. draft-ietf-rmonmib-rmonprot-v2-00.txt
  25.  
  26. ID-2:
  27. Remote Network Monitoring MIB Extensions for Switch Networks
  28. draft-waterman-rmonmib-smon-00.txt
  29.  
  30. ID-3:
  31. Remote Network Monitoring MIB Extensions for ATM Networks
  32. draft-bierman-rmon-atmrmon-01.txt
  33.  
  34. ID-4:
  35. Definitions of Managed Objects for IEEE 802.3 Repeater Devices
  36. draft-ietf-hubmib-repeater-dev-03.txt
  37.  
  38.  
  39. Agenda
  40. ----------
  41.   Agenda bashing
  42.    New RMON-2 Protocol Identifiers
  43.       discussion of ID-1
  44.       scope of protocols left to add for 2nd Rev
  45.    High Speed Interface counter support (Counter64, 32/32 pair)
  46.       different approaches; ID-3 and ID-4
  47.       specific application to RMON-2
  48.       possible application to RFC 1757 for 100-BaseT interfaces 
  49.    Switch-based RMON
  50.       framework for switch-based monitoring; ID-2
  51.       switch port aggregation; ID-3
  52.    Consensus Reading
  53.       determine common ground for new work items; limit
  54.          charter to work that can be finished in two meetings (8 mo)
  55.       determine work effort involved in each new feature
  56.       gauge consensus for proposed solutions 
  57.    Bulk Transfer (time permitting)
  58.       identify general and (possibly) RMON-specific bulk-transfer
  59.          mechanisms
  60.       MIB-based vs. protocol-based approaches
  61.       SNMP vs. FTP/TFTP-based approaches
  62.  
  63. Minutes
  64. -------
  65. (1) RMON-2 Protocol Identifiers (PI) specification
  66. ==================================================
  67.  
  68. The PI macro section will be modified to make machine parsing easier, 
  69. by placing all non-macro text within ASN.1-style comments.
  70. The addition of 'BEGIN' and 'END' keywords will also be considered.
  71.  
  72. The audience was urged to read ID-1 and submit comments
  73. and PI macro additions/corrections to the mailing list.
  74.  
  75. The usage of PI macros (i.e. protocolDirID and protocolDirParamaters
  76. objects) was discussed. There was concern the variance of different
  77. protocol directory (PD) implementations will make it difficult for an NMS
  78. to use RMON-2 data, since there can be many different encapsulations
  79. of a given upper layer protocol.
  80.  
  81. The WG agreed that by convention, the 'anylink' wildcard
  82. mechanism in the base layer encapsulation should be supported by all
  83. implementations. This lowers the expectation of concurrent support for 
  84. specific base-layer encapsulations, but many probes will support both
  85. mechanisms.
  86.  
  87. (2) Addition of high-capacity counters to RMON
  88. ==============================================
  89.  
  90. Counter64 and Counter32 'rollover' counters will be added to all appropriate
  91. RMON-2 data tables, for all RMON-2 octet and packet counter objects.
  92. The exact mechanism (e.g., new columns in existing table, new sparse-augments table)
  93. will be considered on the mailing list.
  94.  
  95. Implementations are expected to follow the rules in RFC 1573 when
  96. creating particular 'high-speed' counter entries. If the data source
  97. indicates an ifEntry, then the associated ifSpeed must be at least
  98. 20 MBits/second for octet counters, and 650 MBits/second for packet
  99. counters. 
  100.  
  101. (3) RMON for Switching Devices
  102. ==============================
  103.  
  104. The SMON MIB (ID-2) was presented and discussed at length.
  105. Several issues were raised during discussion which will be further discussed
  106. on the mailing list. The WG must first determine the proper scope for the SMON
  107. work. 
  108.  
  109. There were a broad range of comments and concerns. Several people commented 
  110. about the inherit difficulty in attempting to standardize a MIB which attempted to
  111. define a generic switch MIB.
  112.  
  113. There were some who felt very strongly that 'switch internals' 
  114. could not be effectively standardized, due to great differences 
  115. between switch architectures, and only the behavior exterior to
  116. the switching could be standardized (i.e., monitor at the ports only).
  117. Some people felt that switch-specific MIB objects should be developed 
  118. by a different standards body (e.g., IEEE for 802.1p/Q instrumentation),
  119. and some felt that the RMONMIB WG could undertake such an effort, in cooperation
  120. with the appropriate standards working groups. 
  121.  
  122. The SMON MIB proposes several potential work-items for the WG,
  123. related to switching devices:
  124.     - agent aggregation
  125.     - port aggregation
  126.     - global statistics 
  127.     - 'local' vs. 'backplane' statistics
  128.     - per-priority (QoS) statistics
  129.     - per VLAN statistics
  130.     - internal 'probe-tap-point' management
  131.  
  132. The WG will further discuss each feature proposal in ID-2 on the mailing list.
  133.  
  134. The port aggregation problem/feature was raised in 3 presentations, and will
  135. be identified as a separate work-item.  There seemed to be some
  136. consensus that port aggregation could be achieved with minimal (possibly zero)
  137. new MIB objects, by creating new 'dataSource' values.
  138.  
  139. The WG Editor introduced the term 'test-point' to indicate a monitoring
  140. point for a virtual probe, (as if) internal to the switch. The WG will 
  141. explore the specification of test-points, so an NMS may determine the 
  142. aggregation/monitoring capability of a switch-based probe, and possible 
  143. NMS-configuration of test-points.  The 2 basic approaches (internal test-points
  144. or external port aggregations) will be discussed at length on the mailing list.
  145.  
  146. (4) RMON for 100 MBit Ethernet
  147. ==============================
  148.  
  149. The application of RMON to high-speed Ethernet has been a WG priority for some 
  150. time, and the issue was raised again at this meeting. The WG will use the mailing 
  151. list to discuss/propose MIB definitions for the following issues:
  152.   * ifTable representation of full-duplex ports (impact on RMON dataSource)
  153.   * impact of 10/100 (auto-sensing) port speeds on RMON data collection
  154.   * application of RFC 1757
  155.      - HC counter for etherStatsOctets, etherHistoryOctets
  156.      - modification of bandwidth utilization calculation in description of 
  157.        etherStatsOctets
  158.  
  159. (5) Consensus reading for new WG scope
  160. ======================================
  161.  
  162. Very little time was spent discussing WG consensus, since there was little
  163. controversy in this area (and details of actual MIB objects are not yet known).
  164.  
  165. Unless there is strong objection raised on the mailing list, the scope of work for
  166. the next round of RMON  development will be limited to RMON PI extensions, high-speed 
  167. counter support (includes 100 MBit ethernet), port aggregation, and the application
  168. of RMON to switching devices.
  169.  
  170. The WG will now begin evaluating specific solution proposals in these areas.
  171. WG members are strongly encouraged to submit proposals (e.g., new PI macros, 
  172. comments on SMON) to the mailing list as soon as possible.
  173.  
  174. Consensus for the existing proposals and any new proposals will be
  175. determined on the mailing list during the next 4 months.  The group will
  176. attempt to transition the individual proposals into WG-owned documents
  177. by the end of the next IETF meeting.
  178.  
  179. It was agreed that work should proceed at quickly as possible,
  180. and individual work-item deliverables should be released as soon
  181. as they are ready (e.g., HC counters, PI macros, and SMON released
  182. independently), which may require multiple concurrent documents.
  183. Document structure will be proposed by the WG Editor and discussed
  184. on the mailing list.
  185.  
  186. (6) Bulk Transfer Mechanisms
  187. ============================
  188.  
  189. Some WG members have developed MIB-based bulk transfer mechanisms, in order
  190. to increase the transaction throughput for RMON-2 applications. There is
  191. strong WG consensus that this problem is general in nature, and should be
  192. addressed by a different WG. But since so many RMON vendors seem to be affected
  193. by this problem, some meeting time was spent discussing the issue.
  194.  
  195. The Concord/Bay Networks' GetTable mechanism was presented and discussed. Several
  196. separate issues were raised as a result of this discussion:
  197.    * MIB vs. protocol-based design
  198.    * OID compression
  199.    * data compression
  200.    * bulk transfer mechanisms (SNMP and non-SNMP)
  201.    * lexi-next ordering requirement
  202.    * distributed polling schemes (in addition or instead of bulk transfer)
  203.    * standardization strategy
  204.  
  205. The WG agreed that a BOF at the next IETF would be the appropriate next step 
  206. in standardizing a bulk transfer mechanism, which would hopefully result in the
  207. formation of a working group devoted to this issue.
  208.  
  209.