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

From: Andrew Smith <[email-masked]>
Date: Wed, 20 May 1998 14:55:40 -0700

John,

> -----Original Message-----
> From:	John Flick [SMTP:[email-masked]]
> Sent:	Monday, May 18, 1998 5:18 PM
> To:	Andrew Smith
> Cc:	Keith McCloghrie; [email-masked]
> Subject:	RE: draft-ietf-hubmib-etherif-mib-05.txt
> 
> 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?)  
[Andrew Smith]  My point was "why do you want to know?". If it is for
utilisation calculations then you need to know more about the interface
than just 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.  
	[Andrew Smith]  The behaviour of the interface *at the MAC
layer* is fundamentally different but it is also a fundamental part of
the IEEE802 model that anyone above the MAC layer should not care. So
the IF-MIB is, in my mind, the wrong place for this object since that
MIB is supposed to be MAC-independent.

> 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.
	[Andrew Smith]  I still do not understand what these other "many
apps" are.

> 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.
	[Andrew Smith]  You need different utilization formulae for
FDDI, Ethernet and Token-Ring: and for different PHY types within those.
Shared gigabit is supported by the standard (and by some vendors I
believe) so we should probably not pass judgement on it here.

>  > 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".
> 
> 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.)
> 
	[Andrew Smith]  OK, then we should include a flag in the
Ether-like MIB to indicate which of these counters are incrementing
when, just as the 802.3 spec did. Whether this flag should be read-write
or read-only is a separate debate: I don't see the utility of having two
places for setting the same thing and it is already settable in the MAU
MIB.
> John
	Andrew

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

---

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

> utilisation calculations then you need to know more about the interface

IF-MIB has several "generic" counters.  These counters are meaningless 
unless you know whether the interface you are looking at is
half-duplex or full-duplex.  Many management platforms out there do a
"rough" utilization calculation based just on ifInOctets, ifOutOctets
and ifSpeed.  It is not completely accurate.  However, it does give a
10,000-foot-level idea of interface health.  You cannot do this unless 
you know whether ifInOctets and ifOutOctets should be added together
or not, and for that you need to know whether the interface is
full-duplex or not.  Please see Brian O'Keefe's reply for a
platform-level viewpoint here.

 > MIB is supposed to be MAC-independent.

This is a pretty IEEE802-centric viewpoint - interfaces come in more
flavors than just LANs.  Duplex-mode is something that applies to many 
different types of interfaces.  IF-MIB was an attempt at distilling
out common features that apply across many interface types, and I
think duplex is such a feature.

 > FDDI, Ethernet and Token-Ring: and for different PHY types within those.

See above.  For a high-level view of interface health, you really
don't want to have to know all the details.  For an example of such an 
application, see Keith & Marshall's book, "How to Manage Your Network
Using SNMP", Section 4.3.1.  There, they use ifType, and the
assumption that serial interfaces are full-duplex and lan interfaces
are half-duplex.  The sample source code would always default to
assuming half-duplex for an unknown ifType.  These assumptions
obvously no longer apply.

 > believe) so we should probably not pass judgement on it here.

I don't know of any vendors who are doing half-duplex shared gigabit
(which is the only case where burst mode is supported and which has a
different slotTime and uses extension bits).  In LA, we had the chair
of 802.3 and the chair of the Gigabit task force tell us that they
knew of no vendors doing this, and that they viewed it as an accademic
exercise.  There are vendors doing "gigabit hubs".  These are not
repeaters. They are a device called a "buffered distributor", which is
a cross between a repeater and a really cheap switch.  In particular,
they operate in full-duplex mode on each port, using PAUSE frames for
flow control.  This means that they do not support burst mode and
extension bits, since those are half-duplex-only.

 > places for setting the same thing and it is already settable in the MAU

The feedback I have heard from developers, both of apps and agents, is 
that they hate the current scheme in the MAU MIB.  I guess I'm saying
that we need to be open to feedback from implementors if we expect to
see apps actually use these MIBs.  Otherwise, we wind up with vendors
continuing to do their management and config thru private MIBs, only
usable by their own apps.

John