home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / hubmib / hubmib-minutes-96mar.txt < prev   
Text File  |  1996-06-03  |  9KB  |  194 lines
  1. Editor╒s note:  These minutes have not been edited.
  2.  
  3.  
  4. SUMMARY OF ACTION ITEMS:
  5. ------------------------------------------------------------------ Jeff Johnson -
  6. - write up the proposed changes to RFC 1650 for 100BASE-T 
  7.  
  8. ------------------------------------------------------------------ Monday 
  9. 3/4/96 7:30-10:00pm
  10. ------------------------------------------------------------------ 
  11.  
  12. Meeting agenda (from Dan R's slide):
  13.  
  14. --implementors' survey
  15. --topology proposal
  16. --open issues in Hub MIB draft
  17. --open issues in MAU MIB draft
  18. --RFC1650 changes
  19.  
  20.  
  21. IMPLEMENTORS' SURVEY (Dave Perkins)
  22. ------------------------------------------------------------------ Dave 
  23. presented slides of the conclusions from his implementor' survey, and 
  24. noted that hardcopies of the complete results would be available later. 
  25.  
  26. The conclusions he reached included the following: 
  27.  
  28. Hub MIB: 8 agent reports returned,
  29. 4 app reports returned (2 device vendors, 2 independents) 
  30.  
  31. Summary--keep: rptrReset, rptrOperStatus, rptrGroupObjectID, 
  32. rptrGroupOperStatus (or remove because of Entity MIB?),
  33. rptrGroupPortCapacity, rptrPortAdminStatus,
  34. rptrPortAutoPartitionState, rptrPortOperStatus,
  35. rptrMonTxCollisions, (all port counters),
  36. (addrTrack objects)
  37. --remove: rptrNonDisruptTest, totalPartitionedPorts, 
  38. rptrGroupDescr, rptrGroupCapacity, rptrHealthText,
  39. rptrGroupLastOperStatusChange, rptrMonitorGroupTotalxxx
  40.  
  41. [Editor's note:
  42. These conclusions do not entirely agree with the results of our work so 
  43. far. In the latest draft, we had deprecated all of the objects in Dave's 
  44. suggested "remove" list, except for rptrGroupDescr and 
  45. rptrGroupLastOperStatusChange, which are still listed at "current" 
  46. status.] 
  47.  
  48. SourceAddrChanges is not implemented correctly in 2 out of 8 agents. 
  49. Dave concluded that we should loosen up the description. Others 
  50. present indicated that those implementations are not compliant with 
  51. 802.3. [Conclusion: we will discuss this on the mailing list.] 
  52.  
  53. Traps -- According to Dave's survey, the applications only display 
  54. traps; 
  55. they don't base decisions on them, therefore traps should be removed 
  56. from the MIB. Others had doubts about this approach. Chuck Black 
  57. (HP) indicated that upcoming applications may depend more on traps.
  58.  
  59. The issue of the usefulness of this MIB in general was revisited. 
  60.  
  61. Dan listed 3 reasons why RMON has taken off and the Hub MIB hasn't: 
  62. 1) lack of support for multiple repeaters; 2) competition between 
  63. vendors kept people from testing interoperability; 3) RMON had new 
  64. technology (alarms, topN). Dan believes there is still value in doing 
  65. this MIB at this time. 
  66.  
  67. Bob Stewart: RMON is a MIB for a high-level app; this MIB is for low-
  68. level devices. The two MIBs are aimed at different levels of the 
  69. network. 
  70.  
  71.  
  72. TOPOLOGY PROPOSAL
  73. (slides from John Flick and Chuck Black, Hewlett-Packard) ------------
  74. ------------------------------------------------------ (This proposal was 
  75. first sent to the mailing list before the December IETF, and John had 
  76. made a presentation on it in Dallas. At this meeting, the subject was 
  77. revisited, with the discussion being fueled by a presentation by Chuck 
  78. Black of HP, who works on applications which use this MIB.)
  79.  
  80. The proposal includes a per-repeater table, by which a manager tells 
  81. the device to watch for a given source address (on all ports). It is useful 
  82. for deducing repeater topology. Chuck presented slides describing, in 
  83. fairly specific terms, the algorithm that could be followed by an 
  84. application using this MIB to do topology mapping. 
  85.  
  86. A manager uses the MIB to configure the device to "listen" for a 
  87. particular address. The manager then causes several packets to be sent 
  88. from the desired MAC address to/through the target device. Finally, 
  89. the manager queries the device through this MIB to find out what port 
  90. the packets with that source address came in on. 
  91.  
  92. The agent does NOT need to have a MAC address per repeater (it works 
  93. for multiple repeaters managed by the same agent--i.e., our current 
  94. draft). Chuck didn't know of any configurations where this approach 
  95. doesn't work. It works for subnets (stops at routers). 
  96.  
  97. Dan questioned whether this presents a problem with customers since it 
  98. requires traffic generation on the network. He noted that the RMON 
  99. WG had an issue with traffic generation. However, that was a replay 
  100. issue. In addition, this MIB is not specifying any traffic generation; the 
  101. manager itself must still cause the traffic to be generated.
  102. Kathy noted that this approach requires write access to the hubs in 
  103. order to map the topology (it's not a passive approach). 
  104.  
  105. Agent requirements for implementation of this MIB: John F. explained 
  106. that HP had first implemented this entirely in firmware, so it is 
  107. possible to do. He knows of at least two chipsets that have a search 
  108. address register already.
  109. Anybody who has the address table implemented very precisely 
  110. should be able to do this; also some chipsets have a 
  111. sourceAddressChange interrupt. Worst case would be that the NMS 
  112. must poll the lastSourceAddress object. With 100BASE-T, topology 
  113. mapping may not be as involved, since the two-repeater-hop limit 
  114. means not much cascading anyway. 
  115.  
  116. This MIB is applicable to VG as well; it's already part of the 802.12 
  117. standard. John would like to put this in the VG MIB by having the VG 
  118. MIB reference the table in the repeater MIB. 
  119.  
  120. Patent issues: HP is to put together an informational RFC. John has 
  121. already submitted a document to Deirdre Kostick, the NM Area 
  122. Director, with this info; the IESG lawyers are currently reviewing it. 
  123. Currently there is no word on the expected timeframe for approval. 
  124.  
  125. Dan asked if those present had any issues with putting this proposal 
  126. into the next draft, and there were none. [Conclusion: put it into next 
  127. draft -- 1 month from now -- and see how the legal issues shape up. We 
  128. are hoping to have the next draft be the one to go forward as an RFC, 
  129. but if there are any legal issues with this then we'll take it out and 
  130. forward the rest of the MIB as an RFC. Double-check with Deirdre 
  131. about putting it into the draft (Dan?).] 
  132.  
  133.  
  134. OPEN ISSUES
  135. ---------------------------------
  136.  
  137. -- rollover time for portTopN counters (there is currently no text in the 
  138. draft; this is the same approach as RMON takes) [Consensus: continue 
  139. to be silent; the draft is ok as is, in this respect.] 
  140.  
  141. -- use of AUGMENTS in 100BASE-T tables, ifMauAutoNegTable (not 1-
  142. 1?) [Kathy understands the edits, and will fix this.] 
  143.  
  144. -- remove rptrInfoNonDisruptTest?
  145. The input from Dave's survey is that agents don't really implement it. 
  146. [Consensus: remove it]
  147.  
  148. -- MAU MIB Compliance problems? (both MIBs need 100BT objects in 
  149. separate group)
  150. [Kathy understands the edits, and will fix this.] 
  151.  
  152. -- auto negotiation/jack MIB? No outstanding issues from those present; 
  153. the current draft appears to be ok. Kathy mentioned that we still need 
  154. to enumerate the jack types; suggestions should be sent to the list ASAP. 
  155.  
  156. -- Counter64? The group is satisfied with the current state of the draft 
  157. (Counter32/Counter32 pair PLUS Counter64 in a separate compliance 
  158. statement.) 
  159.  
  160. -- Should we add rptrMonitorPortSymbolErrors into the 
  161. rptrMonitorPortTotalErrors counter? Bob S: add it to description of 
  162. totalErrors, but it's not necessary to deprecate the old total. It's not an 
  163. interoperability issue to add it to the total that is already defined.
  164. [Consensus: use the old total, and change the description] 
  165.  
  166. -- general issue with deprecated objects: the description field should be 
  167. updated when the status changes. Also, use big letters in the 
  168. descriptions to make the change obvious readers. (Put it first in the 
  169. description)
  170. [Kathy to fix this in the next draft.]
  171.  
  172. Our expected schedule is: we'll allow 2-3 weeks to discuss our new 
  173. (short?) list of open issues, then issue a new draft. 
  174.  
  175.  
  176. RFC 1650 changes
  177. --------------------------------
  178. Dan had sent a request to Deirdre to allow changes to 1650. He received 
  179. her approval for this; however, she would like to know about any 
  180. implementation experience, for the proposed new object(s). This may 
  181. become an issue when the Ethernet-like MIB is considered for promotion 
  182. to draft status. 
  183.  
  184. The changes we need to make are as follows: -- Add 1 new object: 
  185. dot3StatsSymbolErrors. -- Change wording for sqeTestErrors.
  186. -- Add compliances for 100BASE-T
  187. -- Add chipset definitions for 100BASE-T. 
  188.  
  189. [Jeff Johnson will draft the changes.]
  190.  
  191. It was determined that this group did not need another working session 
  192. at this IETF, and the meeting adjourned, with all other business to be 
  193. finished on the mailing list (no sessions planned for Montreal).
  194.