Minutes of the HUBMIB Working Group at the 42nd IETF Chicago, Illinois USA 27Aug98 Reported by Lynn Kubinec (lynnk@ti.com) ---------------------------------------------------- The chair announced the rechartering and renaming of the working group. The group is now the Ethernet Interface and Hub MIB Working Group. The change reflects the current focus of the work the group is doing as switches are replacing repeaters. In terms of the charter, the group is responsible for three documents. The Repeater MIB, which has seen no significant change recently, and the MAU and Ethernet Interfaces MIBs which have received more emphasis. Mailing List details were posted: General Discussion: hubmib@hprnd.rose.hp.com To Subscribe: hubmib-request@hprnd.rose.hp.com Archive: ftp://ftp.rose.hp.com/pub/hubmib The working group recently faced a SPAM crisis in which a list subscriber threatened to sue the list host over mail received by the subscriber. The incident caused a solicitation on the list from John Flick requesting a new list host. The issue has been resolved, the list subscriber who complained hadn't realized the mail he/she objected to was received from the list forwarding engine and HP will continue to host the list. The chair asked, however, that any suggestions regarding setting up list filters be sent to John Flick and also asked for volunteers to take up the list hosting duties. The chair presented the agenda: 1. Administrativia, Agenda Bashing 2. Results of the Implementation Survey for RFC 2108 and RFC 2239 3. MAU MIB Draft Open Issues - <draft-ietf-hubmib-mau-mib-v2-00.txt> 4. Ethernet Chipsets Registration 5. Ethernet-like Interfaces MIB Changes (1 G, registration, etc.) Agenda was accepted as is. The chair presented the Implementation Survey results: For the Repeater MIB (RFC 2108), four vendors submitted surveys: 3 were agent implementations, 1 was an NMS implementation. For the MAU MIB (RFC 2239), four vendors reported on five implementations. The results of the survey will be used as the basis of an Implementation Status Report to the IESG in order to move the RFCs from Proposed to Draft Standard. In this regard, the results of the survey are disappointing in that two of the three major vendors did not respond to the survey. The AD wondered if these vendors are interested in progressing the standard, the chair was not sure. In addition to the lack of response, it came to light during the Bridge MIB working group meeting that there is another problem with the survey. The chair had done the survey guaranteeing responder anonymity. What was discovered in the Bridge MIB meeting is that at least two implementation survey participants must not be anonymous. The IESG needs names. The new MIB testing procedures were discussed. The chair explained that in addition to the survey, MIB walks of the implementations must be performed in accordance with draft-iesg-odell-mibtest-01.txt. Survey results were presented as posted to the mailing list. The chair presented an analysis of the results: RFC 2108 Items 1, 2, 3, 4, and 6: - rptrGroupTable, rptrPortTable, rptrInfoTable, rptrMonitorPortTable and rptrMonTable All three agents implemented these. Items 5 and 7: 100 Mbps Repeater Objects - rptrMonitor100PortTable and rptrMon100Table Only 1 agent implemented the 100 Mbps repeater related objects. The other two had 10 Mbps only repeaters. Items 8, 9, and 10: Address Searching for Topology mapping - rptrAddrSearchTable, rptrAddrTrackTable, rptrExtAddrTrackTable HP Openview Release 5 (the NMS in the survey) uses this information. It is an open question whether or not the topology related objects arenecessary. Items 11 and 12: Statistics sorting ala RMON - rptrTopNPortControlTable, rptrTopNPortTable Two of the three agents reported implemented these objects Items 13 and 14: Traps - rptrInfoHealth, rptrInfoResetEvent Only one vendor implemented these. Analysis: Only items 1, 2, 3, 4, 6, 9, 11 and 12 have two implementations. At this stage 8 does not meet the requirement. A discussion ensued regarding implementation feedback: Jeff Johnson noted that, in general, there hasn't been a lot of feedback to these surveys at all this week. He asked the AD how groups could get more response, perhaps by widening the scope of those solicited to respond. The AD asked if the chair had clearly stated that response to the survey was needed in order to advance the standard? He also asked if the RFC had only been at proposed for six months. The chair responded that the Repeater MIB had been at Proposed for one and a half years and that perhaps his survey hadn't been worded clearly enough as it was combined with mail on another topic. The AD stated that there is an alternative to progressing on the standards track and that is to make the RFC Informational like the UPSMIB group has decided to do and pointed out that there is no crisis here, there are still six months left of the usual two-year time limit to gather implementation reports. A group member commented that perhaps the lack of responses here was related to VLAN technology, i.e. the market moving away from repeaters to switches. The chair concurred that this is a possibility. Joan Cucchiara asked if an effort had been made to contact the two major Ethernet vendors that had not responded to the survey. The chair responded that no, this had not been done. It is expected that the mailing list participants will be pro-active and make efforts to get a response posted to the group or chair. He pointed out that he has no idea who to contact at a company for the information the group requires. The chair also suggested that he could re-post the survey to the mailing list with a clearer discussion about why it is important for vendors to respond. Joan noted that perhaps an announcement could be sent to the SNMPv3 mailing list. The AD said this approach should be used sparingly, perhaps once. The chair continued the meeting with analysis of the RFC 2239 Implementation Survey. There were five implementations from 4 vendors. Implementations V1', V2, V3 and V4 were for bridge/router/switch products; V1 was for a repeater. Item 1: - rpMauTable Only one vendor and doesn't implement rpMauFalseCarriers Items 2 and 6: - rpJackTable, broadMaubasicTable No implementations (in addition, the rpJackTable caused quite a bit of discussion during initial MIB development). Items 3 and 4: - ifMauTable, ifJackTable Good amount of implementation reported, but ifMauFalseCarrier and ifMauJabberStateEnters not always supported in silicon. These objects could be candidates for deprecation. Item 5: - ifMauAutoNegTable This is a new table; two of the four vendors implement the table as read-only. Perhaps the MIN-ACCESS conformance clause of table variables needs to be changed. Items 7 and 9: - rpMauJabberTrap, ifMauJabberTrap Only one implementation. The AD expressed surprise that no one was saying anything, especially given the initial discussions about the rpJackTable. The chair noted that the participants in those discussions were not at this meeting. The next topic was the Ethernet-Like Interfaces MIB. The new draft adds objects for Gigabit ethernet and describes the relationship of the Ethernet-Like MIB with the Interfaces MIB. In addition, support for full duplex ethernet is added. The new objects are derived from the IEEE 802.3 x and z standards. The draft editor, John Flick, could not attend the meeting. The discussion first addressed the Chip Set Registration issue. The chair gave a short introduction of the topic. The Ethernet-Like MIB has one object that identifies a manufacturer's chip set. The text for this one object takes up more than half the entire draft and is larger than the rest of the MIB module itself. The IESG has asked what will happen if new chips are introduced but the draft doesn't move through the standards process. Can't have the working group alive forever just to update the chip set list. Perhaps IANA should administer the list. The chair stated that IANA may require an intermediary from the working group. Jeff Johnson asked if the chipset information is useful. The chair noted that there are four options: 1.) Use IEEE 802.1F Clause 7.1.1.2 and A.5 structure: ManufacturerOUI, ManufacturerName, ManufacturerProductName, and manufacturerProductVersion 2.) Use IANA 3.) Keep it as it is 4.) Drop It Number three is not seen as a solution. A question about the initial reason for the object was asked. The chair explained that part of the history is the tradition of the working group to use the IEEE standards documents as a basis for MIBs developed. It is an IEEE idea to provide identification for chipsets. The object can provide a very useful way to identify misbehaving chips. Another comment was raised that the network manager would go to the OEM for help with a misbehaving product, not to the chipset manufacturer. Jeff Johnson commented that in his experience outside of Ethernet with micro processors in particular was this it is good to know not only which chipset, but which version of the chipset. This is usually only available by physically inspecting the chips. So as it is defined, this object doesn't carry enough information to be useful. The chair noted that 802.3 committee chair Geoff Thompson had suggested the use of the 802.1F/A5 model. The chair has two problems with this: First the OUI is the first 3 bytes of the MAC address and the chip probably cannot provide the rest of the information. Second, there is an installed base using the current implementation. The chair has done investigative experiments to show this. Changing the registration process now breaks 10 years of implementation. Jeff Johnson noted that current products from his company do return a valid value, but he still questions the usefulness. The products have both the MAC and MAU, and the OID is tied to both when they are really two different products. Lynn Kubinec noted that John Flick had submitted mail to the list asserting that he has used this object in a current product to deal with a MAC that was not operating correctly. The chair noted that his company has also made good use of the object. Especially during periods of transition to new technology, it is very useful. The AD noted that IANA will deal take on the registration given that they have an exact description of what gets registered in the name space and a contact in the working group in case there is a question about registering a product. The chair wanted verification of what is necessary if method 2 (IANA registration) is chosen: - issue document saying the OIDs in RFC 2358 will be removed from that document. - describe new method of registering chipsets with IANA - define what an ethernet chipset is so that IANA only registers ethernet chips - choose a contact for IANA, either the working group chair or the AD. The chair noted that registrations can continue in the current OID name space. Jeff Johnson noted that one submission to the mailing list suggested the enterprise name space. The AD noted that this makes the object less useful than it currently is. A comment was raised about whether this shouldn't be in ifDescr. The chair noted that ifDescr is a logical level above the actual MAC. Jeff Johnson noted that ifDescr is a string and has a non-standard format. Another submission on the mailing list was, if this object is so useful, why is it not in the Repeater and other MIBs? The chair noted that this may be historical. It's been a particular problem for ethernet. A comment was made that if this object is used during transitions, that it is perhaps only useful for R & D and experimental purposes. The chair concluded that the object would be removed from the MIB module and another survey will be made of it usefulness. If the object is kept, then IANA registration will be the method followed. Deadline for deciding is the next IETF meetings. Gigabit ethernet was approved by the IEEE in June and it shouldn't take more than six months to move through the IETF. The final topic for discussion were the Ethernet-Like MIB Issues raised on the list by the document editor, John Flick. This discussion was actually more of a review by the chair. Comments need to be posted to the list. Issue 1: I put the new objects relating to MAC Control and PAUSE into a new table, the dot3ControlTable. Is this the way we want this structured? Should MAC Control and PAUSE be separate tables? Or should we just keep everything in dot3StatsTable? Chair doesn't like this control table as the counters are only related to PAUSE. If a new control function is added, then these counters don't make sense. Should have separate tables for each control function. Issue 2: dot3ControlFunctionsSupported: Is it needed, or is it redundant with ifMauAutoNegCapability? Should it be settable (as in the IEEE doc)? If so, what does it mean to set it? Chair's comment is that this is not redundant. Issue 3: dot3ControlPauseLinkDelayAllowance: Do we need this object? I am a bit unclear as to what it means to set this. It is not mentioned in any of the MAC Control or PAUSE state machines. Chair noted that this is not in the IEEE spec because during those discussions it was thought to be too hard to implement. It turns out that this is not true, so perhaps it would be a good think to manage. Issue 4: I did not include counters for aMACControlFramesTransmitted or a MACControlFramesReceived, since they should be derivable from individual counters for the MAC Control functions. Chair noted that this is rhetorical Issue 5: I added dot3ControlPauseMode, which shows what the priority resolution for PAUSE resolved to. I would rather not depend on the management app to know how priority resolution works. Let me know if there are objections to this object. Chair noted that it is useful information that is not in the IEEE standard. Issue 6: I haven't added a DuplexMode object, since the consensus here seemed to be that it should be in the IF-MIB. I believe Brian O'Keefe was supposed to be submitting a proposal to the ifmib mailing list, but that hasn't happened yet. If IF-MIB doesn't add this object, we should probably add it to this MIB. Jeff Johnson noted that currently the IFMIB cannot be used to determine whether an interface is operating in half duplex mode or not. There is also the question of whether having the duplex information present in the MAU MIB is sufficient. He noted that generic applications only look at the IFMIB to do utilization calculation, so even if the duplex information is added to this MIB, it may not be solving a problem. Group consensus was that it's probably best to put the information here anyway. Note was made that interfaces like xDSL can be full duplex and have different speeds in each direction. This means more work for the NMS, but it is necessary. The chair noted that the only new Gigabit related counter in the IEEE spec was the number of burst frames and in LA the group had decided that it is probably not a necessary counter. There was also a question about error counters. If the rate is greater than 640 Mbps, then probably need High Capacity (HC) counters. The chair proposed that HC counters not be added. The paragraph in the draft regarding relation to the IEEE standard should mention this decision. The charter says we need to be wrapped up by Orlando. There was a comment about a question raised at the last working group meeting about High Speed Token Ring. The DTR MIB was updated for 100 Mb TR and will be posted as an informational RFC to the IETF. The AD was asked about the SPAM problem discussed earlier. The IESG has considered SPAM solutions. Jeff Johnson noted that it would be nice if the IETF could provide mailing list services for all the working groups noting that both filtering and list addressing could be provided in a consistent manner.