EditorŐs note: These minutes have not been edited. SUMMARY OF ACTION ITEMS: ------------------------------------------------------------------ Jeff Johnson - - write up the proposed changes to RFC 1650 for 100BASE-T ------------------------------------------------------------------ Monday 3/4/96 7:30-10:00pm ------------------------------------------------------------------ Meeting agenda (from Dan R's slide): --implementors' survey --topology proposal --open issues in Hub MIB draft --open issues in MAU MIB draft --RFC1650 changes IMPLEMENTORS' SURVEY (Dave Perkins) ------------------------------------------------------------------ Dave presented slides of the conclusions from his implementor' survey, and noted that hardcopies of the complete results would be available later. The conclusions he reached included the following: Hub MIB: 8 agent reports returned, 4 app reports returned (2 device vendors, 2 independents) Summary--keep: rptrReset, rptrOperStatus, rptrGroupObjectID, rptrGroupOperStatus (or remove because of Entity MIB?), rptrGroupPortCapacity, rptrPortAdminStatus, rptrPortAutoPartitionState, rptrPortOperStatus, rptrMonTxCollisions, (all port counters), (addrTrack objects) --remove: rptrNonDisruptTest, totalPartitionedPorts, rptrGroupDescr, rptrGroupCapacity, rptrHealthText, rptrGroupLastOperStatusChange, rptrMonitorGroupTotalxxx [Editor's note: These conclusions do not entirely agree with the results of our work so far. In the latest draft, we had deprecated all of the objects in Dave's suggested "remove" list, except for rptrGroupDescr and rptrGroupLastOperStatusChange, which are still listed at "current" status.] SourceAddrChanges is not implemented correctly in 2 out of 8 agents. Dave concluded that we should loosen up the description. Others present indicated that those implementations are not compliant with 802.3. [Conclusion: we will discuss this on the mailing list.] Traps -- According to Dave's survey, the applications only display traps; they don't base decisions on them, therefore traps should be removed from the MIB. Others had doubts about this approach. Chuck Black (HP) indicated that upcoming applications may depend more on traps. The issue of the usefulness of this MIB in general was revisited. Dan listed 3 reasons why RMON has taken off and the Hub MIB hasn't: 1) lack of support for multiple repeaters; 2) competition between vendors kept people from testing interoperability; 3) RMON had new technology (alarms, topN). Dan believes there is still value in doing this MIB at this time. Bob Stewart: RMON is a MIB for a high-level app; this MIB is for low- level devices. The two MIBs are aimed at different levels of the network. TOPOLOGY PROPOSAL (slides from John Flick and Chuck Black, Hewlett-Packard) ------------ ------------------------------------------------------ (This proposal was first sent to the mailing list before the December IETF, and John had made a presentation on it in Dallas. At this meeting, the subject was revisited, with the discussion being fueled by a presentation by Chuck Black of HP, who works on applications which use this MIB.) The proposal includes a per-repeater table, by which a manager tells the device to watch for a given source address (on all ports). It is useful for deducing repeater topology. Chuck presented slides describing, in fairly specific terms, the algorithm that could be followed by an application using this MIB to do topology mapping. A manager uses the MIB to configure the device to "listen" for a particular address. The manager then causes several packets to be sent from the desired MAC address to/through the target device. Finally, the manager queries the device through this MIB to find out what port the packets with that source address came in on. The agent does NOT need to have a MAC address per repeater (it works for multiple repeaters managed by the same agent--i.e., our current draft). Chuck didn't know of any configurations where this approach doesn't work. It works for subnets (stops at routers). Dan questioned whether this presents a problem with customers since it requires traffic generation on the network. He noted that the RMON WG had an issue with traffic generation. However, that was a replay issue. In addition, this MIB is not specifying any traffic generation; the manager itself must still cause the traffic to be generated. Kathy noted that this approach requires write access to the hubs in order to map the topology (it's not a passive approach). Agent requirements for implementation of this MIB: John F. explained that HP had first implemented this entirely in firmware, so it is possible to do. He knows of at least two chipsets that have a search address register already. Anybody who has the address table implemented very precisely should be able to do this; also some chipsets have a sourceAddressChange interrupt. Worst case would be that the NMS must poll the lastSourceAddress object. With 100BASE-T, topology mapping may not be as involved, since the two-repeater-hop limit means not much cascading anyway. This MIB is applicable to VG as well; it's already part of the 802.12 standard. John would like to put this in the VG MIB by having the VG MIB reference the table in the repeater MIB. Patent issues: HP is to put together an informational RFC. John has already submitted a document to Deirdre Kostick, the NM Area Director, with this info; the IESG lawyers are currently reviewing it. Currently there is no word on the expected timeframe for approval. Dan asked if those present had any issues with putting this proposal into the next draft, and there were none. [Conclusion: put it into next draft -- 1 month from now -- and see how the legal issues shape up. We are hoping to have the next draft be the one to go forward as an RFC, but if there are any legal issues with this then we'll take it out and forward the rest of the MIB as an RFC. Double-check with Deirdre about putting it into the draft (Dan?).] OPEN ISSUES --------------------------------- -- rollover time for portTopN counters (there is currently no text in the draft; this is the same approach as RMON takes) [Consensus: continue to be silent; the draft is ok as is, in this respect.] -- use of AUGMENTS in 100BASE-T tables, ifMauAutoNegTable (not 1- 1?) [Kathy understands the edits, and will fix this.] -- remove rptrInfoNonDisruptTest? The input from Dave's survey is that agents don't really implement it. [Consensus: remove it] -- MAU MIB Compliance problems? (both MIBs need 100BT objects in separate group) [Kathy understands the edits, and will fix this.] -- auto negotiation/jack MIB? No outstanding issues from those present; the current draft appears to be ok. Kathy mentioned that we still need to enumerate the jack types; suggestions should be sent to the list ASAP. -- Counter64? The group is satisfied with the current state of the draft (Counter32/Counter32 pair PLUS Counter64 in a separate compliance statement.) -- Should we add rptrMonitorPortSymbolErrors into the rptrMonitorPortTotalErrors counter? Bob S: add it to description of totalErrors, but it's not necessary to deprecate the old total. It's not an interoperability issue to add it to the total that is already defined. [Consensus: use the old total, and change the description] -- general issue with deprecated objects: the description field should be updated when the status changes. Also, use big letters in the descriptions to make the change obvious readers. (Put it first in the description) [Kathy to fix this in the next draft.] Our expected schedule is: we'll allow 2-3 weeks to discuss our new (short?) list of open issues, then issue a new draft. RFC 1650 changes -------------------------------- Dan had sent a request to Deirdre to allow changes to 1650. He received her approval for this; however, she would like to know about any implementation experience, for the proposed new object(s). This may become an issue when the Ethernet-like MIB is considered for promotion to draft status. The changes we need to make are as follows: -- Add 1 new object: dot3StatsSymbolErrors. -- Change wording for sqeTestErrors. -- Add compliances for 100BASE-T -- Add chipset definitions for 100BASE-T. [Jeff Johnson will draft the changes.] It was determined that this group did not need another working session at this IETF, and the meeting adjourned, with all other business to be finished on the mailing list (no sessions planned for Montreal).