CURRENT MEETING REPORT Minutes of the IEEE 802.3 Hub MIB Working Group (HUBMIB) Reported by Kathy de Graaf, Chipcom Corporation SUMMARY OF ACTION ITEMS o Dan Romascanu-tell the directorate that we plan to cycle the Ethernet-like MI B (RFC 1650) at proposed status in order to add the 100BASE-T objects. o Dave Perkins-collect and correlate responses to implementors' questionaire before the end of the year. New archive location: ftp.rose.hp.com/pub/hubmib/ AGENDA ITEMS: 1. Agenda bashing 2. Revised WG Charter and Schedules 3. Review of new repeater MIB I-D 4. Review of new MAU MIB I-D 5. Status of 100BASE-T Interfaces MIB 6. Hub MIB Implementors Questionaire (from Dave Perkins) 7. Topology MIB proposal (John Flick) 8. Auto-Negotiation 9. Relationship with Entity MIB Implementors' Questionaire Dave sent this out on e-mail to the list on Sunday night. Responses should be sent to the mailing list or to Dave Perkins privately. Responses received by Wednesday will be tallied and discussed on Wednesday evening. Revised Charter Should we keep or drop "IEEE 802.3" as part of the WG name? What is our relationship with 'other repeaters' (802.12)? John Flick noted that 802.12's charter is to copy the structure defined for 802.3 hubs; whether or not to use the actual objects is their business. It was concluded that we keep 802.3 in the name. We will change the charter wording to read that other Working Groups might use the model, but we won't specifically reference any use of the objects. We hope that we will not need to have further structural discussions after this meeting. Relationship with Entity MIB The tradeoff that we face is the problem of duplicating some of the info in the Entity MIB versus the risk of not having any MIB coverage for multiple repeaters. There was previous agreement among our Working Group participants that the major bug in the earlier repeater MIB was lack of support for multiple repeaters. At the Santa Clara interim meeting, we agreed to put in the necessary definitions ourselves in order to be sure it gets done this time. Additionally, the Entity MIB is more expensive to implement than our single one port table, in order to solve the problem. Brian O'Keefe: We're defining management for pluggable modules, with potentially different agents. Are hubs likely to have (down the road) the problems with Entity definition that the Entity MIB is trying to solve? Dan: The repeater MIB won't solve all the problems, but will solve repeater problems, which are simpler. Most repeaters have a single agent. Maria Greene: suggest using same indexing for repeater ID as for logical entity table. (this would be a problem if the Entity MIB ends up using Johnson indexing). Jeff Case: stay away from gratuitous increases in cost for low-end products (don't require implementation of the Entity MIB in order to support the repeater MIB). Brian: add a string description field for repeaters? (This was discussed on the e-mail list, but with no resolution?) Auto-Negotiation Kathy presented two slides explaining the approach for configuring auto-negotiation that she put in the MAU MIB draft. In addition, she noted that she changed the indexing in the latest draft, to index MAUs from groups rather than from repeater/port or interface, as in RFC 1515, and defined a one-to-one relationship between jacks and MAUs. This model didn't cover the case where two external jacks map to the same MAU, and the concensus was that we need to be able to index jacks from MAUs to allow for this case. Even if we end up folding the two MAU tables into one, we still need a way to make the connection between a MAU and an interface (jackInternalConnection might be used for this? but not if jacks don't correspond one-to-one with MAUs). Issues raised: Bob S.: The jack/auto-negotiation MIB objects, as proposed, are all read-only and there are no current implementations; does it make sense to standardize it yet?? Kathy/Paul: The IEEE has standardized auto-negotiation and there are products in the planning stage that have it, but IEEE didn't solve the connectivity problem within the box as a whole. Further discussion tabled to mailing list. Topology MIB Proposal (John Flick) (John presented an slide, and handed out copies of the MIB fragment.) John: lastSrcAddress is not sufficient for solving topology problems. HP has been implementing this topology MIB fragment for about 4 years now. HP OpenView uses this method. It is currently covered by an HP patent, which they will release if the WG is interested in standardizing this. This approach is less RAM intensive than keeping "last N source addresses" per port. It could be used instead of, OR in addition to, the rptrExtAddrTrackTable. Jeff Johnson noted that this MIB only allows for one search per repeater. John explained that this was done in order to keep it cheap. Dan: Does this break backwards compatibility--that is, does it require implementation in silicon? John -- HP has software implementations as well, which proves it IS possible. Paul Woodruff and Bob Stewart : is there any reason to tie this to repeaters? John: No, HP implements it in other devices as well. But bridges alreay have an address table which is easier to use than this. If an address shows up in multiple ports on a single repeater, then this is evidence of a misconfiguration in the network (loop or duplicate MAC address). Discussion to be continued at Wednesday evening's session. Wednesday 7:30-10pm Implementors' Questionaire There were not enough responses to Dave Perkins's questionaire to discuss at this point. (We should look for responses on the mailing list before the end of the year.) There was a typo on one question (two choice "b"s) which has been fixed on the version posted at HP. Status of 100BASE-T Interfaces MIB There was no official status on Jeff Johnsonf's action item from Santa Clara to find out about adding 100BASE-T objects to the Interfaces MIB. However, there were several members of the directorate present at this meeting. It was noted that the I/F MIB is a full standard, which presents a problem for us in updating it. Bob Stewart noted that it should be possible to keep the current standard and just extend it. Dave Perkins suggested that we issue a short RFC with only the new objects (there are just a couple of them, after all) under the existing MIB module name, and add a compliance statement that includes these objects plus the objects in the full standard. In other words, use the "augments" feature. Keith McCloghrie suggested the same, except that we use a new MIB module, with a new MIB module name. Dave pointed out that the definitions of compliances require that the object-types be in the same MIB module as the compliances. There was some surprise that this is so, but the rationale appears to have been reasonable--to discourage the spurious definition of new compliances for an existing MIB module. This means means we have no choice but to edit the interface MIB. Text will be needed to explain that the new compliance is just for implementations which are supporting 100BASE-T. John Flick noted that RFC 1650 is currently at proposed, because it uses the V2 SMI, and suggested that we could therefore cycle that document at proposed. Action to Dan: Tell the directorate that we plan to do this and see if they have any objection. Also tell them that we consider these changes minor enough that they will not interfere with the advancement of 1650 from proposed to draft. Review of Repeater MIB I-D Keith suggested that we use a per-address timestamp in the rptrExtAddrTrackTable instead of rptrAddrTrackReset object, with the reasoning that read-write objects are more expensive to implement than read-only. Jeff Johnson raised the issue of a general concern about the addition of so many new objects to this MIB. The concensus is to keep rptrAddrTrackReset for now. TopN Andy Bierman: what about the inclusion of a port in the topN for a repeater, if the port has moved from one repeater to another? We need a clarification of the behavior in this case. Andy suggested that an agent should go ahead and include those counts in this case, but this is a burden on implementations, as it requires them to keep a history of the port's counts after it moves to a new repeater.) Dan: Can we stay silent on this, or does it affect interoperability? Since port timestamp provides some info in this case. In Santa Clara we had decided to ignore ports that change repeaters. This seems the easiest approach, although the danger then is that important information (a port with significant errors that changes repeaters, etc.) will be missed. Dave Perkins brought up another issue: it's possible to set the duration longer than the rollover time for some counters. This is true in RMON as well; can we clean up the wording to close this loophole? This discussion item was added to the agenda. TopN in general to be discussed again later. RFC 1516 objects Should we obsolete or deprecate the scalar repeater objects? Conclusion: we will deprecate ALL the scalars; new implementations should use the rptrInfoTable. Particular objects: rptrInfoHealthText--after a lengthy discussion, there was no agreement; we will wait for results of Dave's survey and abide by them. Some people think it is fairly useful, others think it is useless. rptrInfoNonDisruptTest--out rptrGroupCapacity--Dave Perkins noted that this should be obsolete as it is useless for stackables. Keith: obsolete means don't implement, deprecate means implement for backwards compatibility. We had agreed in Santa Clara that compatibility with existing implementations was important. Dan listed three levels of backwards compatilibity: 1) no silicon changes required to claim conformance with new standard -- requirement 2) no agent code changes required (to claim conformance with new standard) -- goal 3) new apps can manage old agents using the new MIB -- goal rptrInfoId unsigned vs. signed--Keith: don't use unsigned32 because there's currently an ambiguity with unsigned32 in the current drafts. Jeff Johnson noted that rptrInfoId should be named rptrInfoIndex to be consistent in naming [editor: change this] Numbering algorithm for rptrInfoId, rptrMonitorGroupIndex, etc. Dave Perkins: suggest removing it and putting it in either an appendix or the front text of the RFC. Jeff Johnson noted that there are two issues here. One is the numbering scheme, the other is the persistence or lack thereof. First item: put the numbering scheme into an appendix as a suggestion to implementors. Second item--Bob Stewart: This is the ifIndex problem all over again. We could try the same approach as in the I/F MIB: use something akin to ifAlias to keep track of repeaters, instead of numbers. Kathy: it's wiser to stay silent. We could recommend persistence, but let's not require it. [Conclusion: Keep the text as is, and bring other objections to the e-mail list.] rptrMonTable Should we keep this table? Concensus: Yes, for the time being. Kathy: we need either this OR a TopN, to locate problems with minimum queries. Does the use of 'delta' values affect existing implementations? The concensus was that it definitely does. [Editor: Remove the paragraphs which use "delta" wording, in order to remove the requirement for the counters to zero upon discontinuity.] The paragraph which begins "a discontinuity may occur" already allows for both implementation options (zeroed or non-zeroed counters). PortTopN Is this really useful enough to include? Jeff Johnson: this is inappropriate for small repeaters, so at a minimum it should be optional. Maria Greene: agreed, make it optional (it IS useful). Some people noted that this is more like a mid-level manager function. Dan: since this can be an expensive feature, can we write a separate compliance for "cheap" repeaters that excludes it? Brian O'Keefe: this is useful for network capacity planning, one of the most useful features of all. [note--he later retracted this; he was thinking we were referring to a matrix table]. [Consensus--keep it but make it optional] Maria noted that Xyplex has a "last N" table in their MIB, and offered to look it up for this group. John Flick: If this feature were more generic then it could go into another MIB somewhere. (Not enough time to discuss that possibility.) For lack of additional meeting time, we will have address other items on the mailing list. Dan will send out the list of these open items with a summary of their status. The existing drafts are to be published as Internet Drafts right after this meeting; we will wait and discuss open items on the list before issuing a new draft sometime in January.