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

Text File | 1996-06-03 | 13KB | 315 lines

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.