Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/hubmib/hubmib-minutes-95jul.txt

Text File | 1995-10-18 | 9KB | 238 lines

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.