Subject: [Hubmib] WIS Managment options

From: John Flick <[email-masked]>
Date: Fri, 09 Mar 2001 17:23:26 -0800

Our biggest decision for 10Gig management is how to handle management
of the WAN Interface Sublayer (WIS).

My first reaction was to try to just use the existing SONET MIB
(RFC 2558) and the ifStackTable, and represent these interfaces as
an Ethernet interface stacked over a SONET interface.  After all, that
is what the stack table is there for.  However, the mapping between
oWIS in 802.3ae and RFC 2558 isn't quite one-to-one.

  Objects that almost map cleanly:

    aSectionStatus      sonetSectionCurrentStatus
    aSectionSESs        sonetSectionCurrentSESs
    aSectionESs         sonetSectionCurrentESs
    aSectionSEFs        sonetSectionCurrentSEFs
    aSectionCVs         sonetSectionCurrentCVs
    aLineStatus         sonetLineCurrentStatus
    aLineSESs           sonetLineCurrentSESs
    aLineESs            sonetLineCurrentESs
    aLineCVs            sonetLineCurrentCVs
    aFarEndLineSESs     sonetFarEndLineCurrentSESs
    aFarEndLineESs      sonetFarEndLineCurrentESs
    aFarEndLineCVs      sonetFarEndLineCurrentCVs
    aPathStatus         sonetPathCurrentStatus
    aPathSESs           sonetPathCurrentSESs
    aPathESs            sonetPathCurrentESs
    aPathCVs            sonetPathCurrentCVs
    aFarEndPathSESs     sonetFarEndPathCurrentSESs
    aFarEndPathESs      sonetFarEndPathCurrentESs
    aFarEndPathCVs      sonetFarEndPathCurrentCVs

The problem with these mappings is that the 802.3 objects are just
a traditional counter, whereas the SONET MIB objects represent
only the current 15 minute interval, and use the interval tables
to represent past counts.  802.3 explicitly makes the interval
tables not required for 802.3 WIS management, whereas the object
groups in the SONET MIB make them mandatory.  Also, the Status
objects latching semantics in 802.3 WIS is not reflected in the
SONET MIB Status objects.

The following WIS counters do not have equivalent objects in the
SONET MIB:
    aSectionSESthreshold
    aJ0ValueTX
    aJ0ValueRX
    aLineSESthreshold
    aPathSESthreshold
    aJ1ValueTX
    aJ1ValueRX
    aFarEndPathStatus
    acClearSectionStatus
    acClearLineStatus
    acClearPathStatus

Other options we have available:

  - Define a new Ethernet WIS MIB document which augments the existing
    documents.

  - Add a WIS section to one of the existing documents (probably MAU
    MIB).  This would have the effect of preventing that document
    from advancing to Draft Standard.  However, splitting management
    of Ethernet interfaces over several documents may cause some
    confusion as to what needs to be implemented for a given
    interface.  Our experience with the current Ethernet/MAU MIB split
    has been that several vendors have not implemented the MAU MIB
    because they were not aware it is required.

Comments and additional options are of course welcome.

John

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