home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / hubmib / hubmib-minutes-92mar.txt < prev    next >
Text File  |  1993-02-17  |  12KB  |  278 lines

  1. This is only a rough draft - Megan 04/20/92
  2.  
  3. Minutes of IETF 802.3 Hub MIB Working Group
  4.  
  5. 18 March 1992 meeting in San Diego
  6.  
  7. The meeting was called to order at 9:30 by co-Chairs Donna McMaster 
  8. and Keith McCloghrie.
  9.  
  10. Agenda
  11. IETF SNMP Hub MIB Working Group
  12. 18 March 1992, San Diego, CA
  13.  
  14. 1.  IEEE 802.3 Repeater Management Report
  15. 2.  Outstanding Issues from Chapter 8 of latest Draft
  16. 3.  Issues from Mailing List
  17. 4.  Any other issues on latest Internet Draft
  18. 5.  Discussion of MAU MIB
  19. 6.  MAU MIB Strategy
  20. 7.  Plans for Progression of Document(s)
  21.  
  22. A new (March 6) version of the Repeater MIB draft was distributed.  
  23. This incorporated the text, updated in light of IEEE 802.3 Repeater 
  24. Management Task Force's February meeting, and previously distributed 
  25. to the working group's mailing-list.  
  26.  
  27. IEEE REPORT
  28.  
  29. Donna presented the following report on the progress of the IEEE 802.3 
  30. Repeater Mgmt Task Force (formerly known as "Hub Mgmt TF"):
  31.  
  32. -------------------------------------------------------------------------
  33. IEEE 802.3 Rptr Mgmt Progress
  34.  
  35. -  Confirmation ballot closed Jan 31
  36. -  82 comments, primarily requesting clarification
  37. -  At interim meeting Feb 24-26, rewrote section "Port Functions to Support 
  38.    Mgmt," provided initial resolution for all comments
  39. -  At IEEE 802 plenary last week, minor tweaks, sending results for 2nd 
  40.    confirmation ballot, prognosis is very good
  41. -  March 6 draft of SNMP Repeater MIB is based on output of interim
  42. -  For next draft, editors plan to do "tweaks" from last week's plenary 
  43.    along with other changes that come out of this meeting 
  44. -  MAU MIB is now the hot topic
  45. -------------------------------------------------------------------------
  46.  
  47. Geoff Thompson reported on the minor "tweaks" from the IEEE meeting in 
  48. Irvine the previous week.  These edits will be incorporated into the next 
  49. draft of the Repeater MIB.  
  50.  
  51. OUTSTANDING ISSUES FROM CHAPTER 8
  52.  
  53. The meaning of the enumerated value notPresent for the MIB object 
  54. rptrGroupOperState was discussed.  It was questioned whether the 
  55. "has been physically removed" wording used in the document implied 
  56. that the removal must have occurred since the last reboot.  Lengthy 
  57. discussion identified numerous suggestions, including:  
  58.  
  59. a. delete the word "physically"; 
  60. b. change "has been" to "is"; 
  61. c. delete the notPresent state and have the instance not appear in 
  62.    the MIB when the group was not present;
  63. d. allow implementation flexibility; 
  64. e. add more enumerations to distinguish: "physically present and logically 
  65.    notPresent", "physically notPresent and logically notPresent", 
  66.    "physically can't ever be present", and "physically can't be present 
  67.    at the moment";
  68. f. add more definitive/instructive text;
  69. g. purposely be vague in the text.
  70.  
  71. After several votes, a consensus eventually emerged to add more definitive/
  72. instructive text while leaving the enumerations as they were.  In order 
  73. to make progress, two attendees volunteered to draft additional text 
  74. while the next item was discussed.
  75.  
  76. The next item was whether rptrPortAutoPartitionState should be combined 
  77. with rptrPortOperState into a single MIB object.  After some discussion 
  78. the MIB objects were left as being separate.  
  79.  
  80. Discussion of the seriousness of autoPartition and the overhead in polling 
  81. every port's autoPartition state on a regular basis.  We do not want to 
  82. issue a trap when this happens.  Instead the group agreed to add a new 
  83. repeater-level object "total partitioned ports" with syntax of Gauge.  This 
  84. object will represent the total number of ports in the repeater that are 
  85. currently enabled and present but autoPartitioned.  
  86.  
  87. On the issue of Total Counters, it was agreed that while a total counter
  88. was redundant in the sense that it was a sum of other counters already
  89. represented as MIB objects, it was most beneficial in reducing the
  90. amount of network traffic, particularly on repeaters with many (e.g.,
  91. over a hundred) ports.
  92.  
  93. Two such counters were suggested: one was Total Errors per port, as
  94. suggested by the editors in the draft.  It was agreed that the errors
  95. included in this total would be:
  96.  
  97.     rptrMonitorPortFCSErrors, rptrMonitorPortAlignmentErrors
  98.     rptrMonitorPortFrameTooLongs, rptrMonitorPortShortEvents
  99.     rptrMonitorPortLateEvents, rptrMonitorPortDataRateMismatches
  100.     and rptrMonitorPortVeryLongEvents
  101.  
  102. The other total counter was the number of frames across all ports.
  103. The difficulty was observed of how this counter would behave when 
  104. one or more of the ports were removed.  A decrease in the counter's 
  105. value was not consistent with the syntax of Counter.  Various 
  106. suggestions were made:
  107.  
  108. a. count the total number since the last group (re-)configuration, 
  109.    adding a timestamp to record when that occurred; 
  110. b. add a 'virtual port' which would conceptually be a promiscuous 
  111.    monitor on all ports.
  112. c. have a total counter per group rather than per repeater.
  113.  
  114. The consensus emerged to have three total counters associated with each 
  115. group: 
  116. -  groupTotalFrames
  117. -  groupTotalOctets
  118. -  groupTotalErrors
  119.  
  120. On the issue of counting FramesTooLong and VeryLongEvents, the consensus
  121. was to align with IEEE, and count them all.
  122.  
  123. The new text from the two volunteers for rptrGroupOperState was reviewed.
  124. The consensus was that either would be acceptable.  A slight majority
  125. preferred the following text:
  126.  
  127. "notPresent(x) indicates that the group is temporarily or permanently 
  128. physically and/or logically not a part of the repeater.  It is an 
  129. implementation-specific matter as to whether the agent effectively removes 
  130. notPresent entries from the table."
  131.  
  132. The group also agreed to change rptrGroupUpTime to be 
  133. rptrGroupOperStateLastChange (or some abbreviation of this) with the 
  134. customary semantics.  
  135.  
  136. DISCUSSION OF MAU MIB 
  137.  
  138. A first draft of the MAU MIB was distributed.  (This document was also 
  139. mailed to the hubmib mailing list on Friday, March 13.)  Donna presented the 
  140. following overview of MAU management status and issues:  
  141.  
  142. -------------------------------------------------------------------------
  143. IEEE 802.3 MAU Mgmt
  144.  
  145. -  802.3 Medium Attachment Unit (MAU) attaches repeater port or Ethernet-
  146.    like interface to the local network medium
  147. -  MAU types include 10BASE5 (thick coax), 10BASE2 (thin coax), 10BASE-T 
  148.    (twisted pair), FOIRL and 10BASE-F (fiber optic)
  149. -  MIB information includes MAU type, link status, jabbering
  150. -  Discussions in IEEE 802.3 Hub Mgmt group over past year, postponed MAU 
  151.    work to finish Repeater Mgmt
  152. -  Draft proposal brought to interim meeting, well-received, more work 
  153.    done at plenary
  154. -  Draft of SNMP MAU MIB mailed to mailing list last Friday, based on output 
  155.    from IEEE 802.3 plenary
  156. -  Later in today's meeting will discuss how IETF Hub MIB WG wants to handle  
  157.    the MAU MIB
  158. -------------------------------------------------------------------------
  159. MAU MIB Objects
  160.  
  161. 1.  MAU Type
  162. 2.  Admin State (operational, standby, shutdown)
  163.     -  Option to implement as read/write, reset MAU
  164. 3.  Media Available
  165.     -  Link status (link integrity/low light) for link media (10BASE-T or 
  166.        10BASE-F), loopback normal for coax media
  167.     -  Lost media counter indicates stability of medium
  168. 4.  Jabber state, jabbers counter
  169.     -  Jabbering (continuous transmission) indicates serious problem in 
  170.        host, not as interesting for repeater ports
  171. 5.  Jabber trap
  172. -------------------------------------------------------------------------
  173. MAU MIB Questions
  174.  
  175. -  MAU can attach to repeater port or DTE (Ethernet interface), therefore 
  176.    related to both Repeater MIB and Ethernet-like Itfs MIB
  177. -  Most objects are common to both port MAUs and interface MAUs
  178. -  Multiple MAUs can be attached to a single port or interface
  179. -  How to instantiate?  For rptr ports, "group.port.mau" is desireable, for 
  180.    interfaces, "interface.mau".  Stay tuned...
  181. -------------------------------------------------------------------------
  182. MAU MIB Options (none perfect!)
  183.  
  184. 1.  Add MAU tables to Repeater and Ethernet-like Interfaces MIBs:
  185.     -  MAU table in Repeater MIB indexed "group.port.mau"
  186.     -  MAU table in Ethernet-like Ifs MIB indexed "interface.mau"
  187.     -> Destabilizes both drafts, bad timing
  188. 2.  Create new MAU MIB document with MAU table, indexed 1..n. 
  189.     -  Add two tables that give mappings from port -> MAU, interface -> MAU.
  190.     -> Awkward instantiation when using MIB browser
  191. 3.  Create two new MAU MIBs in separate documents (or combine)
  192.     -  Repeater MAU MIB with table indexed "group.port.mau"
  193.     -  Etherlike Ifs MAU MIB with table indexed "interface.mau"
  194.     -> Duplicates much information
  195. -------------------------------------------------------------------------
  196.  
  197. Some discussion.  People agreed that the application of the MAU information 
  198. to Repeaters comes within the charter of this working group.  However, it 
  199. was suggested that we didn't want to slow down the progress of the current 
  200. Repeater MIB draft, and so the meeting agreed to treat this as a separate 
  201. MIB document to be produced by the working group.  
  202.  
  203. With little time remaining in the meeting, the group also agreed to deal 
  204. with MAUs separately for repeaters and for interfaces, but there was no time 
  205. for any other discussion of the MAU MIB at this meeting.  Attendees were 
  206. encouraged to raise any/all issues on the mailing-list.
  207.  
  208. ISSUES FROM THE MAILING-LIST
  209.  
  210. The issue of the interaction between rptrPortOperStatus and 
  211. rptrPortAdminStatus had been raised on the mailing-list since the
  212. meeting in Santa Fe.  All agreed that they should have the same
  213. interaction as MIB-II's ifOperStatus and ifAdminStatus, but there
  214. was confusion of ifOperStatus's semantics.  Explanation that 
  215. ifOperStatus was defined to become 'down' as soon as possible
  216. after ifAdminStatus was set to 'down' resolved the confusion.
  217.  
  218. ANY OTHER ISSUES
  219.  
  220. No other issues were raised.
  221.  
  222. PROGRESSION OF DOCUMENTS
  223.  
  224. The editors were chartered to update the Repeater MIB draft in light
  225. of the agreements at this meeting, and to distribute to the mailing
  226. list within two weeks.  Thereafter, the working group would have two
  227. weeks to review it.  If no concerns were raised on the mailing-list within 
  228. the following 2 weeks (or if all raised concerns were satisfactorily
  229. resolved), then the Repeater MIB would be done, and should be forwarded
  230. to the IESG with a recommendation for being progressed to Proposed
  231. Standard status.
  232.  
  233. Meanwhile, the MAU MIB would be discussed on the mailing-list.
  234.  
  235.  
  236. Attendees
  237.  
  238. Jim Barnes               barnes@xylogics.com
  239. Steve Bostock            steveb@novell.com
  240. Jack Brown               jbrown@huahuca-emh8.army.mil
  241. Niels Ole Brunsgaard     nob@dowtyns.dk
  242. Lida Canin               lida@apple.com
  243. Jeffrey Case             case@cs.utk.edu
  244. Carson Cheung            carson@bnr.com.ca
  245. Dave Cullerot            cullerot@ctron.com
  246. David Engel              david@cds.com
  247. Bob Friesenhahn          pdrusa!bob@uunet.uu.net
  248. Shawn Gallagher          gallagher@quiver.enet.dec.com
  249. Mike Grieves             mgrieves@chipcom.com
  250. Walter Guilarte          70026.1715@compuserve.com
  251. Frank Kastenholz         kasten@europa.clearpoint.com
  252. Manu Kaycee              kaycee@ctron.com
  253. Mark Kepke               mak@cnd.hp.com
  254. Yoav Kluger              ykluger@fibhaifa.com
  255. Dave Lindemulder         da@mtung.att.com
  256. Richie McBride           rm@bix.co.uk
  257. Keith McCloghrie         kzm@hls.com
  258. Evan McGinnis            bem@3com.com
  259. Donna McMaster           mcmaster@synoptics.com
  260. Edison Paw               esp@3com.com
  261. Jim Reinstedler          jimr@sceng.ub.com
  262. Sam Roberts              sroberts@farallon.com
  263. Dan Romascanu            dan@lannet.com
  264. Marshall Rose            mrose@dbc.mtview.ca.us
  265. Rick Royston             rick@lsumus.sncc.lsu.edu
  266. Michael Sabo             sabo@dockmaster.ncsc.mil
  267. Mark Schaefer            schaefer@davidsys.com
  268. Timon Sloane             peernet!timon@uunet.uu.net
  269. Bob Stewart              rlstewart@eng.xyplex.com
  270. Mark Therieau            markt@python.eng.microcom.com
  271. Geoff Thompson           thompson@synoptics.com
  272. Timothy Walden           tmwalden@saturn.sys.acc.com
  273. Steve Wong               wong@took.enet.dec.com
  274. Paul Woodruff            paul-woodruff@3com.com
  275. Brian Wyld               brianw@spider.co.uk
  276. Henry Yip                natadm!henry@uunet.uu.net
  277.  
  278.