Subject: Re: [Hubmib] Open issues in MAU-MIB

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. 

                       half10   - force to 10Mbit half duplex
                       full10   - force to 10Mbit full duplex
                       half100  - force to 100Mbit half duplex
                       full100  - force to 100Mbit full duplex
                       fullGig  - force to 1000Mbit full duplex
                       lan10Gig - force 10Gig MAU to 10GigBaseR mode
                       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.

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.

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 6 Dec 2001 13:13:25 -0800 (PST)

> represents the current operational mode (i.e. speed/duplex) and the

Allow me to point out that separate enumeration of the various combinations
is something that the IEEE has carried forward not just in the Clause 30
MAU-related managed objects but also in the MDIO interface.  Specifically,
the P802.3ae 10G PMA/PMD MDIO Control 2 register (clause 45.2.1.6)
separately enumerates all seven of the supported 10GBASE interfaces and
provides the means to select any of them.  Here is an excerpt from
P802.3ae D3.4:

        Table 45-7-10G PMA/PMD Control 2 register bit definitions

Bit(s)     Name                                 Description             R/W

1.7.15:3   Reserved                 Value always 0, writes ignored      R/W

1.7.2:0    PMA/PMD type selection   2 1 0                               R/W
                                    1 1 1 = 10GBASE-SR PMA/PMD type
                                    1 1 0 = 10GBASE-LR PMA/PMD type
                                    1 0 1 = 10GBASE-ER PMA/PMD type
                                    1 0 0 = 10GBASE-LX4 PMA/PMD type
                                    0 1 1 = 10GBASE-SW PMA/PMD type
                                    0 1 0 = 10GBASE-LW PMA/PMD type
                                    0 0 1 = 10GBASE-EW PMA/PMD type
                                    0 0 0 = Reserved

Writing to PMA/PMD type selection bits would have the effect of setting
ifMauDefaultType to one of dot3MauType10GigBaseSR, dot3MauType10GigBaseLR,
dot3MauType10GigBaseER, dot3MauType10GigBaseLX4, dot3MauType10GigBaseSW,
dot3MauType10GigBaseLW, or dot3MauType10GigBaseEW.

Now, of course the MDIO registers are optional, and some implementations
may not have the PMA/PMD registers.  But those implementations could
implement the WIS or PCS MDIO registers, and either the WIS Control 2
register (clause 45.2.2.6) or the PCS Control 2 register (clause 45.2.3.6)
could be used to control the PCS type.  Here are the relevant excerpts
from P802.3ae D3.4:

        Table 45-16- 10G WIS Control 2 register bit definitions

Bit(s)     Name                                 Description             R/W

2.7.15:4   Reserved                 Value always 0, writes ignored

2.7.3      Test pattern             1 = Square wave test pattern
                                    0 = Mixed frequency test pattern

2.7.2      Receive test pattern     1 = Enable test pattern mode        R/W
           enable                           on the receive path
                                    0 = Disable test pattern mode
                                            on the receive path
2.7.1      Transmit test pattern    1 = Enable test pattern mode        R/W
           enable                           on the transmit path
                                    0 = Disable test pattern mode
                                            on the transmit path
2.7.0      PCS type selection       1 = Select 10GBASE-W PCS type       R/W
                                    0 = Select 10GBASE-R PCS type

        Table 45-33- 10G PCS Control 2 register bit definitions

Bit(s)     Name                                 Description             R/W

3.7.15:2   Reserved                 Value always 0, writes ignored      R/W

3.7.1:0    PCS type selection       1 0                                 R/W
                                    1 1 = Reserved
                                    1 0 = Select 10GBASE-W PCS type
                                    0 1 = Select 10GBASE-X PCS type
                                    0 0 = Select 10GBASE-R PCS type

Writing to the PCS type selection bits in one of these registers would
have the effect of setting ifMauDefaultType to one of
dot3MauType10GigBaseW, dot3MauType10GigBaseX, or dot3MauType10GigBaseR.
Presumably the purpose is to select the PCS type without saying anthing
about the PMA/PMD (except that it needs to be compatible).

>                 speed and duplex of this port.
>

The above enumeration (apart from the omission of 10GBASE-X) is performing
a function analogous to that of the PCS type selection in the WIS and/or
PCS Control 2 registers.

In the 10Gb/s case it seems to me that the purpose of the simplified
enumeration would be just as well served by restricting the values
that may be written to ifMauDefaultType to one of dot3MauType10GigBaseW,
dot3MauType10GigBaseX, or dot3MauType10GigBaseR -- which is something
that the document could say the implementation is allowed to do.  That
would achieve the goal of simplification without the downside of
deprecating ifMauDefaultType and losing the ability to represent the
capabilities of the P802.3ae PMA/PMD Control 2 register.

Now, the $64000 question is whether someting similar could be done for
the other speeds by defining dot3MauType OIDS analogous to the
enumerations listed above.

Mike

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

---

From: "C. M. Heard" <[email-masked]>
Date: Thu, 6 Dec 2001 13:13:25 -0800 (PST)

Mike