Subject: [Hubmib] Open issues in MAU-MIB

From: John Flick <[email-masked]>
Date: Tue, 04 Dec 2001 21:35:32 -0800

Hi,

The following is my list of open issues for the current MAU-MIB draft,
draft-ietf-hubmib-mau-mib-v3-00.txt.  These issues will be discussed
at the WG session in SLC, with the hopes of driving them to resolution,
so come prepared.  Of course, mailing list discussion before the
meeting is very welcome and encouraged.

1. In London, we discussed the idea of replacing the current method
   of configuring speed and duplex on an Ethernet interface with a
   simple enumeration that more closely reflects what vendors are
   actually implementing.

   Currently, there are several objects that are involved in this
   issue, depending on whether autonegotiation is supported and/or
   enabled.

   If autonegotiation is not supported (ifMauAutoNegSupported is
   'false'), ifMauTypeListBits indicates the possible MAU types
   supported by the MAU, ifMauType reflects the current MAU type, and
   ifMauDefaultType is used to configure the MAU type from among the
   possible supported MAUs.

   If autonegotiation is supported (ifMauAutoNegSupported is 'true'),
   both ifMauTypeListBits and ifMauAutoNegCapabilityBits indicate the
   possible MAU types supported by the MAU.  When autonegotiation is
   running (ifMauAutoNegAdminStatus is 'enabled'), the set of
   capabilities that autonegotiation will advertise can be controlled
   using ifMauAutoNegCapAdvertisedBits (which can set or clear bits
   included in ifMauAutoNegCapabilitiesBits, but cannot set bits not
   included in ifMauAutoNegCapabilitiesBits).  ifMauType reflects the
   current MAU type resolved by autonegotiation.

   When autonegotiation is not running (ifMauAutoNegAdminStatus is
   'disabled'), ifMauDefaultType is used to configure the MAU type
   from among the possible values in ifMauTypeListBits.  If
   autonegotiation was running and is dynamically disabled, the MAU
   is supposed to revert to the type configured in ifMauDefaultType,
   regardless of what may have previously been determined by
   autonegotiation.  As always, ifMauType reflects the current active
   MAU type.

   PAUSE negotiation adds yet another dimension to the fun.

   Some vendors that I am aware of have chosen to ignore all this
   complication by just defining a single object for configuring the
   speed/duplex mode.  What I proposed in London is that we take the
   hint, and simplify this.  Here is a more concrete proposal:

   - Deprecate ifMauDefaultType
   - ifMauAutoNegCapAdvertisedBits and ifMauAutoNegCapReceivedBits
     are still useful for determining exactly what is being sent and
     received, but should be read-only.
   - Add the following object:
       ifMauAdminType OBJECT-TYPE
           SYNTAX      INTEGER {
                           auto(1),
                           half10(2),
                           full10(3),
                           auto10(4),
                           half100(5),
                           full100(6),
                           auto100(7),
                           fullGig(8),
                           halfAuto(9),
                           fullAuto(10),
                           lan10Gig(11),
                           wis10Gig(12),
                       }
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION "Text needs work.

                       auto     - allow autonegotiation to determine
                                  speed and duplex
                       half10   - force to 10Mbit half duplex
                       full10   - force to 10Mbit full duplex
                       auto10   - force speed to 10Mbit but allow
                                  autonegotiation to determine duplex
                       half100  - force to 100Mbit half duplex
                       full100  - force to 100Mbit full duplex
                       auto100  - force speed to 100Mbot but allow
                                  autonegotiation to determine duplex
                       fullGig  - force to 1000Mbit full duplex
                       halfAuto - force duplex to half duplex but allow
                                  autonegotiation to determine speed
                       fullAuto - force duplex to full duplex but allow 
                                  autonegotiation to determine speed
                       lan10Gig - force 10Gig MAU to 10GigBaseR mode
                       wis10Gig - force 10Gig MAU to 10GigBaseW mode

                       Allowable values for a particular MAU
                       determined by ifMauTypeListBits."
           ::= { ifMauEntry 14 }

   - Need to determine what to do with ifMauAutoNegAdminStatus.
   - Need to determine how this effects dot3PauseAdminMode in
     EtherLike-MIB.

2. Need to document what happens with ifStackTable when changing
   between 10GigBaseR and 10GigBaseW.  I had assumed that this
   was an issue for the WIS MIB, but the decision should probably
   either be documented in the MAU MIB, or have a pointer to the
   relevant text in the WIS MIB.

If there are any other issues that are not on my open issues list or
my list of edits that I sent out earlier this evening, please submit
them now.  We would like to spin this document soon after SLC and
go to WG last call shortly thereafter, so if you have issues, please
raise them now.

John

_______________________________________________
Hubmib mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/hubmib

---

From: "McTague, Charles" <[email-masked]>
Date: Thu, 6 Dec 2001 11:49:36 -0500

We didn't submit our implementation report for MAU-MIB and EtherLike-MIB, 
but I agree that the mechanism for configuring Speed and Duplex in the 
current MAU-MIB is cumbersome.  We (Enterasys) had our own 
proprietary MIB for this functionality (primarily to add support for 
Gigabit) prior to RFC 2668 being released, but have now cut over to 
RFC 2665 and RFC 2668.  What I am wondering is if solving this problem 
requires as much change as is proposed below?  

I think enumerating the speed-duplex combinations is the way to go, 
but I'm not sure it is a good idea to add auto-negotiation 
enumerations as well.  In general, the auto-negotiation 
implementation in MAU-MIB maps well to IEEE 802.3, and is fully 
functional.  I would advocate that this portion of MAU-MIB 
requires no change (except addition of new capabilities as 
necessary).  Additionally, the functionality of forcing a 
speed and auto-negotiating the duplex (or vice-versa) goes against 
the whole spirit of auto-negotiation.  If both sides of a link do 
auto-negotiate (which one would expect if you are going to enable 
auto-negotiation), then forcing the speed/duplex to resolve to a 
specific value is a simple matter of setting the advertised bits 
correctly.  Am I missing something?

The primary problem with ifMauDefaultType is that it takes into 
account not just speed and duplex but the actual MAU type which 
to configuration is more or less irrelevant.  For instance, where 
many 1000BASE-X  implementations utilize GBICs, Mini-GBICs, or 
some other hot swappable media, does it make sense to separately 
enumerate LX, SX, CX, and plain old X?  My feeling is no, and that 
changing these on the fly as connectors are hot-swapped (keeping 
in mind that these are writeable leaves) makes agent implementations 
and NMS applications for this leaf overly complicated.  That being 
said, the ifMauType leaf should remain since it is read-only and 
represents the current operational mode (i.e. speed/duplex) and the 
attached MAU type.  

If we strip out the auto-negotiation options (as discussed in 
paragraph 2 above) the enumerations could look more like this:

       ifMauDefaultAdminType OBJECT-TYPE
           SYNTAX      INTEGER {
                           half10(1),
                           full10(2),
                           half100(3),
                           full100(4),
                           fullGig(5),
                           lan10Gig(6),
                           wis10Gig(7)
                       }
           MAX-ACCESS  read-write
           STATUS      current
           DESCRIPTION 
               "The administrative mode requested by management for the
speed and duplex 
                of this port. 

                       wis10Gig - force 10Gig MAU to 10GigBaseW mode"
           ::= { ifMauEntry 14 }

Thanks,
chuck

---------------------------
Charles McTague
Principal Firmware Engineer
Enterasys Networks, Inc.
[email-masked]

-----Original Message-----
From: John Flick [mailto:[email-masked]] 
Sent: Wednesday, December 05, 2001 12:36 AM
To: [email-masked]
Subject: [Hubmib] Open issues in MAU-MIB

Hi,

The following is my list of open issues for the current MAU-MIB draft,
draft-ietf-hubmib-mau-mib-v3-00.txt.  These issues will be discussed at the
WG session in SLC, with the hopes of driving them to resolution, so come
prepared.  Of course, mailing list discussion before the meeting is very
welcome and encouraged.