Subject: RE: draft-ietf-hubmib-etherif-mib-05.txt

From: Andrew Smith <[email-masked]>
Date: Mon, 18 May 1998 16:43:50 -0700

The argument that I seem to recall (was it DC or before?) was that the
main reason people wanted a "duplex" object was to work out a
"utilisation" statistic. But, without knowledge of the media type/frame
format/media-access characteristics/physical layer etc. etc. you cannot
calculate an accurate statistic for this (see e.g. Dave Perkins' mail).
So, you can only work out this statistic if you know the MAU type
exactly and, for example, if you read some vendor-specific OID from
ifMauType then you had better know something more about the interface
before calculating a utilisation statistic.

So, are there other uses for a "duplex" object? If not then I think it
falls under the category of "duplicate info that can be derived from
other objects".

Andrew (just trying to reconstruct the argument - I don't really mind
either way).

***************************************************************
Andrew Smith
tel +1 408 863 2821
Extreme Networks
fax +1 408 342 0990
10460 Bandley Drive
[email-masked]
Cupertino CA 95014
http://www.extremenetworks.com
***************************************************************

	-----Original Message-----
	From:	John Flick [SMTP:[email-masked]]
	Sent:	Monday, May 18, 1998 1:28 PM
	To:	Keith McCloghrie
	Cc:	[email-masked]
	Subject:	Re: draft-ietf-hubmib-etherif-mib-05.txt

	Keith McCloghrie writes:
	 > In draft-ietf-hubmib-etherif-mib-05.txt, it says:
	 > 
	 > >      ifSpeed                    The current ...
	 > >                                 ...   The correct object to
use
	 > >                                 to determine the duplex
mode of the
	 > >                                 interface is the ifMauType
object in the
	 > >                                 802.3 MAU MIB.
	 >  
	 > ifMauType is an OID, which can take many values, and will no
doubt have
	 > new values defined for it in the future.  It seems to me that
this is
	 > rather a clunky method for an NMS to use to determine the
duplex mode.
	 > I had thought we were going to have an additional object
defined,
	 > either in this MIB or in the MAU MIB, to indicate the duplex
mode ??

	The IEEE added this object in 802.3x.  We agreed several months
ago
	that we would finish and publish the updated version with the
802.3u
	changes before starting on the modifications for 802.3x, y, and
z.
	(Full-duplex itself is defined in 802.3x).  We still need to get
this
	draft published before we can start new work.

	(And yes, I agree that using the OID to try to determine duplex
mode
	is pretty clunky.)

	John

---

From: John Flick <[email-masked]>
Date: Mon, 18 May 1998 17:17:55 -0700 (PDT)

> before calculating a utilisation statistic.

I think this was the way the discussion went.  I dropped the argument
pretty quickly (mainly because I wanted to get this document out).
Actually, I think I was actually suggesting adding a flag to the
IF-MIB, since duplex mode would seem to effect more than just
Ethernet.  (How does one figure out if an unrecognized ifType is half-
or full-duplex?)  However, it seems like it is still desirable to be
able to easily figure out whether the interface is half- or
full-duplex without having to make the management station know every
existing and future (possibly proprietary) value of ifMauType.  The
behavior of the interface is pretty fundamentally different at full-duplex
vs. half-duplex, and the management station should have an easy way of
distinguishing between the two.  Yes, individual PHY types do behave
differently also, and if a management app wants that level of detail
it needs to be able to understand MAU type, but for many apps, that
level of detail really isn't necessary - but knowing duplex mode often
is.

Besides, I think the only case where the utilization calculation
really needs additional info is with shared Gigabit, which is a pretty
rare (if not unheard-of) case.

 > falls under the category of "duplicate info that can be derived from

For example, many of the counters in the Ether-like MIB are only
relevant for half-duplex interfaces.  Some of the new ones (when we do
the 802.3x stuff) will only be relevant for full-duplex mode.  It may
be nice if an app could easily figure out whether to pay attention to
the collision counters or the PAUSE frame counters.

802.3x adds two objects here:

    aMACCapabilities - indicates the duplex capabilities of the MAC
                       (rather badly named, I think).  We would
                       probably make it an enumeration with
                       halfDuplexOnly, fullDuplexOnly, halfOrFullDuplex.
    aDuplexStatus    - a GET returns the current mode of operation,
                       halfDuplex, fullDuplex, or unknown.  A SET
                       operation changes the mode of operation to the
                       indicated value.  (Note that this would mean
                       adding our first settable object to the
                       Ether-like MIB.)

John

---

From: "Brian O'Keefe" <[email-masked]>
Date: Wed, 20 May 1998 12:30:14 -0600

Speaking from an NMS perspective...

John Flick wrote:
> Ethernet.

I concur.  The intent of the IFMIB is to hold information and
statistics that is common about all types of interfaces.  The
duplex mode of the interface is one such common characteristic.
An NMS shouldn't have to switch on ifType and grovel N different
interface specific MIBs to determine the duplex mode for the 
various interfaces on a system.

Yes, it is very desirable to have the ability to compute such
things as utilization, from a general health pespective, for
each of the interfaces on a system WITHOUT having to undestand
the ifType specific details of each interface. Afterall, isn't
that what having the common ifTable and ifXTable statistics are
intended for?

> However, it seems like it is still desirable to be
> existing and future (possibly proprietary) value of ifMauType. 

I concur again; and as noted above, the same is true in general,
not just for 802.3 interfaces.

> The
> distinguishing between the two. 

Absolutely!

> Yes, individual PHY types do behave

Exactly.

>                        adding our first settable object to the

Seems like this latter object is the one to make more generalized
in the IFMIB; e.g., "ifDuplexMode" with enum values halfDuplex, 
fullDuplex and unknown.  Make the object MAX-ACCESS R/W and
MIN-ACCESS R/O (in the conformance spec).

At what point should this thread get cross-posted to the IFMIB WG?

......

Getting back to ifMauType... I've got a question.  
Isn't the ifMauType object simply identifying which one of 
the mau types listed in ifMauTypeList is the active mau type?
If so, why are two different conventions (OID vs enum-looking
integer) for identifying a mau type used by attributes in the 
same mib table?  This feels very wrong to me!

Shouldn't ifMauType simply be an enumerated integer (potentially
maintained by IANA like ifType) and ifMauTypeList be a BIT-STRING
instead of a SUM to allow for more than 32 mau types?  Or, if you
insist on oids for mau types to allow unregistered vendor-specific,
then the ifMauType list should be a separate table where the
possible mau types are identified by OID there as well?

Regards,
bok

---

From: John Flick <[email-masked]>
Date: Wed, 20 May 1998 16:16:54 -0700 (PDT)

> At what point should this thread get cross-posted to the IFMIB WG?

I guess we can do that at any time.  The reason I didn't push it in
IFMIB earlier had to do with process.  IF-MIB was just forced to
recycle at Proposed because it added 3 objects.  Since there are
several transmission MIBs that are trying to go to Draft and depend on 
IF-MIB, it would be nice if it didn't have to recycle again.  Adding
this to IF-MIB would probably also require adding an ifOutSpeed, and
verbage about treating ifSpeed as ifInSpeed, since there are
interfaces (cable modems, for example) that have different speeds in
each direction.

 > the mau types listed in ifMauTypeList is the active mau type?

Yes.

 > same mib table?  This feels very wrong to me!

ifMauType predates ifMauTypeList.  ifMauType was in RFC 1515, and was
carried forward unchanged.  ifMauTypeList was added in RFC 2233, when
instrumentation for auto-negotiation was added.  I don't know why
ifMauType was an OID in the first place (1515 predates my involvement
in this WG).  I don't remember any discussion in the WG about what the 
SYNTAX of ifMauTypeList should be (though, as you point out below, we
did get it wrong).

 > possible mau types are identified by OID there as well?

We decided in L.A. to deprecate ifMauTypeList and replace it with a
BITS object (mainly because we were running out of bits in the
Integer32).  See draft-ietf-hubmib-mau-mib-v2-00.txt.  There
definitely are issues with implementing the bits objects, whether
using BITS or Integer32 bit-sums, when you need to represent
unregistered MAU types (as we, and probably everyone else, has run
into for gigabit MAUs today, since they are not registered yet).

I guess I would like to hear some more discussion about this before
deciding if we need to change anything here.

John

---

From: Kathy de Graaf <[email-masked]>
Date: Thu, 21 May 1998 11:16:24 -0400

>SYNTAX of ifMauTypeList should be (though, as you point out below, we

I can add a little more history here.  The reason those objects were sums
and not BITS in RFC2239 is so that the numbering for individual values could
be the same across the various objects (ifMauTypeList, ifMauAutoNegCapability,
et al.) and also match the ifMauType leaf values, many of which were already
defined in RFC1515.  So for instance, dot3MauType10BaseTHD is defined as
{ dot3MauType 10 }, and the bit which corresponds to 10BaseT half duplex
in the ifMauTypeList object is bit 10.  Ditto for ifMauAutoNegCapability,
CapAdvertised, and CapReceived.  Now, some mau types  (e.g. FL) don't
autonegotiate so keeping the numbering the same would have meant that
the BITS values were non-contiguous, which is not allowed.

The new draft has the values renumbered in order to use BITS, so it seems
that the idea of keeping the numbers the same was probably more confusing
than useful, but it wasn't arbitrary.

--Kathy

--------------------------------------------------------
 Kathy de Graaf             Phone: (978) 486-0665 x163 
 Argon Networks             Fax:   (978) 486-9379 
 25 Porter Road             mailto:[email-masked]
 Littleton, MA 01460        http://www.argon.com
--------------------------------------------------------