Subject: 41st IETF HubMIB WG Minutes

From: John Flick <[email-masked]>
Date: Wed, 15 Apr 1998 16:37:19 -0700 (PDT)

Minutes of the HubMIB Working Group at the 41st IETF
Los Angeles, CA, USA 4/30/98
Reported by: John Flick ([email-masked])
----------------------------------------------------

The meeting began with administrative info and agenda bashing.  The
agenda was accepted as presented.

The chair asked if there were any last minute problems that would
prevent the current draft of the Ether-like interface MIB from being
advanced to Proposed Standard.  There were none.

The chair then initiated a discussion of how best to handle gathering
implementation experience for RFC 2108 and RFC 2239.  He pointed out
that during the last round, a questionnaire was issued, and the results
were compiled by an independent party who did not work for a hub or
switch vendor.  He asked how many people in the room had implementation
reports for these RFCs.  Five people raised their hands.  He next asked
if any of those people would have a problem with sending those reports
to an individual who works for a repeater or switch vendor.  No one
felt that this would be a problem.  The working group agreed to try to
put together implementation reports by June.

Next, we looked at the status of recent and current efforts in the IEEE
that may potentially affect this working group.

    - IEEE 802.3-1996 and 802.3u are currently covered by our RFCs and
      the Ether-like draft that is in IESG last call.

    - 802.3x and 802.3y approved 11/97.  Not currently covered by our
      work.  Covers 100BASE-T2 and full-duplex Ethernet, including flow
      control.

    - 802.3z ballot closed 1/98.  Covers Gigabit Ethernet.  Currently
      doing sponsor ballot recirculation.  Not currently covered by our
      work.

    - 802.3ab covers 1000BASE-T.  All management-related issues are
      covered in 802.3z.

    - 802.3ac WG recirculation ballot closed 3/98.  Covers changes for
      VLANs, including changing the definition of max-packet.

    - Trunking study group - may affect us and IFMIB, but this work is
      currently in the very early stages.  Too early for us to consider
      at this time.

Howard Frazier, chair of 802.3z, indicated that 802.3z should be
completed by June.  Also pointed out that any changes to management
needed by 802.3ab have already been anticipated in 802.3z.  When asked,
802.3 chair Geoff Thompson indicated that clause 30 of 802.3z has the
most up-to-date management information for 802.3.

The issue was raised of how we are affected by the change to max-packet
in 802.3ac.  The concern was that a management station can't tell
whether an agent is incrementing that counter at 1519 bytes or at 1523
bytes.  This is a potential interoperability problem.  It was suggested
that we should add an object that indicates what that agent considers
to be an oversize packet.  A similar thing was done in the
DataSourceCapabilities table in SMON.  It was pointed out that with
max-packet at 1522, an oversize frame less than 1523 bytes long that
does not contain a VLAN header is still an error, but is not counted
as one.  It was felt that it wasn't worth the extra expense of requiring
the agent to examine the header to determine if a tag was present before
incrementing this counter.

We discussed some ideas for how this working group can maintain closer
contact with IEEE 802.3.  We can encourage members of 802.3 to join
our mailing list, encourage members of this working group to join the
802.3 mail reflector.  Howard Frazier indicated that he had no problem
with providing members of this working group with the password to access
the 802.3z web site to get updated copies of their document.  WG members
can either contact him ([email-masked]) or Geoff Thompson 
([email-masked]) for access information.

Andrew Smith then gave a presentation about changes to the MAU MIB
needed for 802.3x and 802.3z support.  There are no new objects needed,
but it does need new OIDs, bit values, and enumerations.  In addition,
several DESCRIPTION clauses need to be updated to include mention
of gigabit.

We determined that we need to add new MAU types for the various flavors
of Gigabit Ethernet MAUs for both half and full duplex.  We decided that
we do not need MAU types for unknown duplex.  However, we do need MAU
types for unknown PMD, since there is no standard way to identify the
PMD in the IEEE standard.

We decided to deprecate the ifMauTypeList object.  This object was
defined as an Integer32, and we now need more than 32 bits.  It should
have been defined as BITS, and we decided to deprecate the old object
and define a new one of type BITS.

We need to extend the enumerations for ifMauAutoNegStatus to include
new status values defined in 802.3x.

We need to add new bit definitions for ifMauAutoNegAdvertizedCaps,
ifMauAutoNegCapabilities, and ifMauAutoNegReceivedCaps for the new
MAU types and for PAUSE negotiation.  Decided that we should also
deprecate these objects and define new ones of type BITS.

For FAULT negotiation, we decided that instead of packing these into
the ifMauAutoNeg* BITS objects, we would define a separate enumerated
integer object.  There was some discussion about whether the
corresponding bits in the ifMauAutoNeg* BITS objects should be marked
as reserved.  Deferred to the mailing list.

John Flick then presented changes needed to the Ether-like Interface
MIB for Gigabit and flow control support.  There was some discussion
about whether counters that are not used in full-duplex mode should
cease to exist when the interface is in full-duplex mode, or should just
not increment.  In the past, we have just said that those objects should
retain there values and not increment when the interface is in a mode
where they are unused.  The IEEE documents state that their values are
undefined in this case.  There was considerable debate, with one camp
arguing that they should just retain their value to avoid the
discontinuity, and another saying that loss-of-link should always be
considered a possible discontinuity.  The conclusion seemed to be that
we should just state that they should not increment, but we need to
be careful to word this such that it is clear that this behavior is
different from that defined by IEEE.  The alternative was felt to be
too much of a semantic change to the existing counters.  Final decision
deferred to the mailing list.

John then proposed some additional counters for flow control
instrumentation.  These counters were proposed in 802.3x, but as rather
late ballot comments.  The concern there was that they did not fit the
802.3x layering model, and it was too late in the process to fix it.
There was considerable concern expressed about adding counters that
required hardware instrumentation not specified in the IEEE spec.
Also, some present felt that if the PAUSE frame counters were 
incrementing at all that this indicated that congestion was occurring,
and this was sufficient.  Discussion was deferred to the mailing list.

The chair then asked if we wanted to tackle Gigabit Repeater management
at this time.  It was felt that it would be simple to do, but why?
There do not appear to be any implementations in the market or in
development.  Decided this work can be deferred.  It was felt that
no new work is needed on the Repeater MIB, unless something shows up as
a result of the implementation experience and interoperability reports.

We then discussed logistics for the updates to the Ether-like and MAU
MIBs.  Should we change the current document, or try to keep the
changes in a separate document so the current documents can advance
to Draft.  It was felt that separating the new stuff would be awkward.
The feeling was that getting the MIB objects right was more important
than advancing to Draft.  We decided that discussing this was
premature.  We need to get implementation reports for the current
documents before we can determine if advancing the current documents
is even an option.

We next moved on to a discussion of the charter updates needed for this
new work.  Dan proposed changing the working group name to reflect the
fact that we are working on more than just hubs.  Dave Perkins suggested
changing it to cover 802 LANs, in particular, Token Ring.  It was
pointed out that IEEE 802.5 is already doing their MIBs in SMIv2 format
instead of GDMO, so there is less need for a working group in IETF for
802.5 management.  In addition, there is little commonality between
the new 802.3 and 802.5 work.  When asked whether there were any 802.5
experts in the room, no one raised their hands.  The suggestion was
withdrawn.

Steve Owen volunteered to contact the chairs of the IEEE 802.5 Committee
and see if they are interested in coordinating with this WG or some other
WG in the IETF.

We agreed that we would like the new name of the WG to be  'IEEE 802.3 
Interfaces and Hub MIB WG", and we would like to modify the description
of the working group to read:

    The Ethernet Interfaces and Hub MIB WG is Chartered to define a set
    of managed objects that instrument devices (repeaters, MAUs,
    interfaces) that conform to the IEEE 802.3 standard for Ethernet.

    This set of objects should be largely compliant with, and even draw
    from IEEE 802.3, although there is no requirement that any specific
    object be present or absent.

    The MIB object definitions produced will be for use by SNMP and will
    be adequately consistent with other SNMP objects, standards and 
    conventions.

The following schedule was presented and agreed to:

    April-June 1998  Gather implementation feedback on RFC 2108 and
                     RFC 2239

    June 1998        Post internet-drafts for Full Duplex and Gigabit
                     Ethernet MIB extensions

    August 1998      Meet at 42nd IETF to discuss internet-drafts and
                     implementation feedback

    September 1998   Post revised internet-drafts

    October 1998     Working Group last call

    November 1998    Submit internet-drafts to IESG for consideration
                     as Proposed Standards

---

From: Andrew Smith <[email-masked]>
Date: Thu, 16 Apr 1998 13:45:43 -0700

John,

One minor correction:

> -----Original Message-----
> From:	John Flick [SMTP:[email-masked]]
> Sent:	Wednesday, April 15, 1998 4:37 PM
> To:	[email-masked]; [email-masked]
> Subject:	41st IETF HubMIB WG Minutes
> 
> 
	[Andrew Smith]  It's actually if/rpMauMediaAvailable that needs
the new values. I stated wrongly in my presentation that it was
if/rpMauStatus. Your minutes state wrongly that it is
ifMauAutoNegStatus. But we all get the general idea ....

	Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 863-2821
Extreme Networks                          fax: +1 (408) 342-0990
10460 Bandley Drive
Cupertino CA 95014               em:  [email-masked]
****************************************************************