CURRENT_MEETING_REPORT_ Reported by Kathy de Graaf/Chipcom Corporation Minutes of the IEEE 802.3 Hub MIB Working Group (HUBMIB) Monday's Session The HUBMIB Working Group reconvened at the Stockholm IETF to discuss the question of management for 100BASE-X technology. The first issue to arise was that of a charter: the charter of the group that resides on the IETF server has not yet been updated to reflect the 100BASE-X work, nor does it include a formal mention of whether or not this group is to take on the issue of management for 100BASE-X interfaces. In the absence of the working group chair (Donna McMaster of Bay Networks), Dan Romascanu of LANNET stood in to run the meeting. Agenda o Agenda bashing o Review implementation experience with RFCs 1515 and 1516 o 100BASE-X proposals (Turcotte, de Graaf/Lui) o Generic repeater proposal (Johnson) Implementation Experience Several vendors reported on their implementation experience with the current RFCs: o Chipcom -- Implemented objects from the RFCs, also added repeater ID as index under proprietary name space. o Cisco Systems -- Implemented RFC 1516 as is (no repeater ID); suggested the addition of security objects. o Hewlett Packard -- Implemented RFCs 1515 and 1516 as is. o Xyplex -- Implemented RFCs 1515 and 1516; had to handle multiple repeaters, but ``did not do it well.'' They also added some objects that ``might be useful'' but could not quote specifics (redundant port configuration? security?) so it was suggested that these ideas be sent to the mailing list. o Lannet -- Had to implement multiple addresses on a single port for address tracking, as well as other tricks to get around the multiple repeater problem. o Bay Networks (Synoptics) -- Implemented RFC 1516 (repeater MIB) in some products, but not in others because of problems with the layout of objects (not a repeater ID problem). Found that the group monitor table and group traps were not useful. Backplane segments and local segments do not map well into MIB, and a replacement structure is needed. (There was some disagreement among the Bay representatives on this point.) The problem described is with a stack configuration, where each box in the stack can have multiple slots. One solution is to associate a text name (e.g., through NMS naming capability) with a group (like group 5 = ``3rd floor closet stack, hub 3, slot 5'') to provide the necessary mapping. Regarding security, there was some mention that 3Com may already have a patent on a particular approach to security. Dan Romascanu agreed to look into this, as it could be a factor in standardization of security features in this area. Regarding use of RFC 1516 vs. RMON (RFC 1757), it was generally agreed that the Repeater MIB has not reached the same level of interoperability as RMON, but that RMON does not cover everything that the repeater MIB does and that the repeater MIB is still cheaper to implement (and therefore, valuable). More input regarding management implementations is needed. The only ones mentioned were SNMP-Tcl, CastleRock (SNMPc), and Bay Networks' repeater MIB interface, which was tested only against their own hubs. It was decided that we need to follow up on the mailing list to see which companies have implemented which objects, with the goal of finding out what is really used in the field (that is, should some objects be removed?). Current Proposals o IF MIB There is an outstanding proposal for 100BASE-X interface management from Maurice Turcotte, who has previously presented it to the IFMIB Working Group (but before the IEEE work in this area was standardized). o Repeater and MAU MIBs There are proposals for 100BASE-X repeater and MAU MIBs drawn up by Kathy de Graaf and Mike Lui (Chipcom), both of which are based on the earlier RFCs plus the IEEE 802.3 work. The repeater MIB proposal currently includes only 100BASE-X objects but the authors felt that it should probably be modified to include 10BASE-T as well. Generic Repeater MIB Issues Jeff Johnson's slides on this topic can be found at the following FTP site: ftp://ftp.cisco.com/jjohnson/hubmib/hubmib.ps and newhubmib.ps Jeff's proposal is for a MIB that can cover generic ``hubs'' in a way similar to that used for the IF MIBs; that is, a basic MIB that includes objects common across media types, and multiple media-specific MIBs. He based his proposal on RFC 1516, the Lui/de Graaf draft, and the 100VG draft. During the discussion, the question of folding the repeater management objects into the transmission-specific Interfaces MIB was raised, but not conclusively decided (this would bring us back to the question of whether a repeater port should be considered an interface, for management purposes). Wednesday's Session The Wednesday evening session opened with a continuation of comments, issues, and questions for Jeff Johnson on his ``generic'' repeater MIB proposal, now called ``real'' hub MIB (referring to a combination of FDDI rings, repeaters, and other hub-type configurations). Jeff presented some new slides, the gist of which was that the work on the Hub MIB threatens to overlap with that of the entity MIB and the interfaces MIB, that we can use the entity MIB for inventory, and that we should forget about adding repeater ID in favor of an implementation-defined indexing approach, based on OIDs as instance indices, to get you down to the port level (which is where a good deal of the interesting management information resides). This would allow handling of different kinds of hardware configurations: o Fixed configuration boxes with port numbers o Dynamically configured boxes with card and port numbers o Stacks (box/card/port) o Other configurations not yet conceived In addition, this abstract indexing scheme would allow a vendor to attach counters wherever they wish in the containment, e.g.: hubFruId.3.2: card 2 in unit 3 hubFruId.3 : unit 3 There was some disagreement over whether or not this abstract indexing is legal, but a great deal of enthusiasm for the flexibility it promises. Jeff also suggested adding a timestamp of lastAddrChange, a port-to-repeater (configuration) assignment capability, and removing groupChange (an entity MIB rather than a Hub MIB issue). (The acting working group chair read from the current charter, which specifically does not allow for changing the ``conceptual model'' from IEEE -- that is to say, the group was originally chartered to manage repeaters and not all hubs. Obviously, the charter needs to be changed if we want to take on this work.) Dave Perkins presented some slides describing the IEEE definition of repeater, ``isolated'' ports, and the possibility of getting statistics from isolated ports (there was some argument over whether or not to think of an isolated port as a repeater); more dimensions have since been added by various vendors to the original IEEE concept, mostly along the lines of stack configurations (interconnect segments, submodules). There was some discussion over whether or not this group should take on the wider task of managing heterogeneous hubs vs. just 802.3 devices. The majority seemed to agree that there is a need (or at least a good use) for a MIB that knows about different media types, if such a thing is possible. However, it was pointed out that there are potential difficulties as well as expenses involved in implementing multiple media agents, and to this, also, there was general agreement. There was a lot of enthusiasm for the use of a variable-length OID as an index. The NMS developers present expressed support for it on the basis that it would help in delving down to the end leaf in looking for problems (no need to download from all ports and then do a serial search), but it was premature to estimate the implementation cost. Additionally, if we were to leave out the concept of cards/groups altogether, we are still faced with how to map from each vendor's numbering scheme to a physical layout. It seems there are two separate issues to be addressed by this working group: 1. Instrumentation -- this does not seem controversial: it was not even discussed at either session. 2. Addressing -- this took up almost all the time of the meetings. It is generally thought that 1516 is not widely implemented/used because of addressing limitations (repeater ID and more). Conclusions o We have the 100BASE-X I/F MIB under our umbrella, too (permission was given by the Area Director). o We will post the current proposals as Internet-Drafts as a basis for discussion of instrumentation. o Regarding the addressing issues, a charter update is needed, as well as milestones. Whether or not to take on a generic hub MIB before, after, or at the same time as an instrumentation MIB should be addressed in the charter (``at the same time'' is probably not practical). o RFCs 1515 and 1516 cannot proceed on the standards track (they are too broken). o There will be an estimated two iterations/IETF meetings before any completion of anything is likely. o The group should be thinking about an interim meeting, probably in the September/early October timeframe.