Subject: SNIA recommendations for changes to the FC Mgmt MIB

From: "Marjorie Krueger" <[email-masked]>
Date: Tue, 25 May 1999 11:23:53 -0700

The following are recommendations for changes to the fibre channel 
management MIB compiled by the SNIA SNMWGFC working group:

The FC Mgmt MIB lacks the notion of a "module" to group units.  The FC-IC
MIB had a hierarchical structure which enforced the organization of 
enclosure -> module -> port.  The FC Mgmt MIB has a flat structure which
doesn't force any grouping, but also doesn't allow for the representation
of a grouping.  The flat structure of the FC Mgmt MIB is seen as more 
flexible, allowing for a common representation that encompasses a 
variety of physical relationships, but this caused some confusion for 
those of us that were more familiar with the FC-IC MIB hierarchical 
representation.  We discussed the proposed changes to the FC Mgmt MIB 
that were posted to the IPFC reflector on Friday, April 16, 1999, 
specifically the addition of a connUnitType of `module' and an object 
in the connUnitTable of connUnitModuleID.  This seemed acceptable, 
although the term `module' caused confusion and should be changed to 
`container'.  The term 'module' is also used in the connUnitPortModuleType
object.
       
-  The FC Mgmt MIB has no read/write objects, so it will not allow for 
management of devices, only monitoring.  The MIB should specify some 
minimum set of read/write objects, with the understanding that each
vendor will make the decision to allow writes to these objects in their
own devices.  The following minimum read/write objects were proposed:
        
connUnitReset OBJECT-TYPE
    SYNTAX    INTEGER {
                  noReset   (1),    -- value of this object on a read
                  resetWarm (2),    -- SET of this value causes a warmstart
                  resetCold (3),    -- SET of this value causes a warmstart
              }

    ACCESS    read-write
    STATUS    optional
    DESCRIPTION     
             "A SET of this object causes the Unit to perform a coldstart or
              warmstart."
    ::= { connUnitEntry nn }

portAdminState OBJECT-TYPE
    SYNTAX    INTEGER {
                  enabled  (1),    -- port enabled for normal operation
                  disabled (2)     -- port is disabled for use by the 
                                   -- management software
              }

    ACCESS    read-write
    STATUS    optional
    DESCRIPTION     
             "This object allows the port to be put in an offline
              state by the management software."
    ::= { connUnitPortEntry nn }

-  In addition, the trap table should have a structure that allows for 
modifications thru the FC Mgmt MIB.

- The question was raised whether the link table is intended to contain
links to remotely discovered devices (devices not directly connected to 
this unit, but accessable thru other links).  If so, there doesn't appear
to be enough objects to fully represent this relationship.

Our understanding of the purpose of the link table is for a management 
station to discover the physical topology of the SAN.  From this point 
of view, the FC Mgmt MIB Link Table provides no means of representing 
multiple links between nodes, and no way to express "unknown endpoints".

It was suggested that the object names in the link table should have 
`local' and `remote' replaced by `x' and `y' to remove the implications 
of those names and support the view of the link table as a list of 
connections between endpoints.

It should also be clear from the Description clauses whether this table
contains links to indirectly linked endpoints, or only to directly
connected endpoints.

-  Some objects need to be renamed to avoid confusion over different
uses of terms in the  FC Mgmt MIB - suggest connUnitModuleID be 
changed to connUnitContainerID.  The term `module' is associated 
with a physical relationship and causes confusion.  There is also 
an object in the port table called connUnitPortModuleType which 
has no association with the connUnitModuleID, causing further 
ambiguity.

-  The following miscellaneous changes were suggested:

    connUnitType should have an additional enumeration for 
    storage-device' to encompass tape, CD, etc.  This objects
    (and many other objects in this MIB) also needs a much more 
    descriptive DESCRIPTION clause, providing examples, etc. For
    instance, what is the difference between a 'host' and an 
    'hba' type?
    
    connUnitPortType - add enumerations for escon, lan, wan, nPort, 
    nlPort.
    
    The following objects are suggested additions to the connUnitTable:

    connUnitName OBJECT-TYPE
        SYNTAX    DisplayString (SIZE(40))
        ACCESS    read-write
        STATUS    mandatory
        DESCRIPTION     
                "A display string containing a name for this unit.  
                This item should be persistent across coldstarts."
        ::= { connUnitEntry nn }

    connUnitInfo OBJECT-TYPE
        SYNTAX    DisplayString (SIZE(256))
        ACCESS    read-write
        STATUS    mandatory
        DESCRIPTION     
                "A display string containing location information or
                 comments on this unit.  This item should be 
                 persistent across coldstarts."
        ::= { connUnitEntry nn }

- There is no way to select a connUnit level event severity to control
logging to the event table.  Suggest adding 

connUnitEventFilter     OBJECT-TYPE
                        SYNTAX INTEGER { 
                                unknown(1),
                                other(2),
                                informational(3), 
                                warning(4), 
                                critical(5), 
                                failure(6),
                                init(7)
                        } 

        ACCESS          read-write
        STATUS          mandatory
        DESCRIPTION
                        "Events of this severity and above will
                        be logged in the event table."
        := { connUnitEntry nn } 

-  connUnitPortConnector is missing enumerations for 
                     longWaveLaserNoOFC,
                     shortWaveLaserNoOFC,
                     longWaveLED
                     
-  connUnitPortModuleType needs to have enumerations for gbicWithSerialID,
and gbicNoSerialId                      

- replace connUnitSensorName with connUnitSensorType so that management agents
can programmatically detect the sensor type.

connUnitSensorType    OBJECT-TYPE
                      SYNTAX INTEGER {
                            temperature (1),
                            fan         (2),
                            power-supply(3),
                            voltage     (4),
                            pressure    (5),
                            battery     (6)
                      }
                      ACCESS        read-only
                      STATUS        mandatory
                      DESCRIPTION
                        "The type of sensor represented by this table entry."
                      ::= { connUnitSensorEntry 3 }
                      
-   recommend adding traps for sensor state change and port state change.

**********************************************************
Marjorie Krueger 
Senior Design Engineer          Phone: (949) 753-9480
Vixel Corporation               Fax:   (949) 753-9500
15245 Alton Pkwy South          Email: [email-masked]
Suite 100
Irvine, CA 92618-6328

---

From: "Marjorie Krueger" <[email-masked]>
Date: Tue, 25 May 1999 12:46:39 -0700

My apologies for not making it clear what the abbreviations stand for -

SNIA = Storage Network Industry Association
SNMWGFC = Storage Network Management Working Group - Fibre Channel

---

From: Kha Sin Teow <[email-masked]>
Date: Thu, 27 May 1999 14:35:09 -0700

Hi,

a few more comments ...

> management MIB compiled by the SNIA SNMWGFC working group:
...
> -  connUnitPortConnector is missing enumerations for
I would also suggest that the variable name be changed to
connUnitPortTxType or connUnitPortTransmitterType (if you like long name)
This would make it consistent with FC-PH terminology and Fabric Element MIB
name.

> -  connUnitPortModuleType needs to have enumerations for gbicWithSerialID,
Should also add 'sff'

>                       ::= { connUnitSensorEntry 3 }

Not sure why 'voltage' is necessary since we have 'power-supply'?

-- 
----------------------------------------------------------------------
Kha Sin Teow				[email-masked]
Brocade Communications Systems		Tel: 408-487-8180
1901 Guadalupe Parkway			Fax: 408-487-8090
San Jose, CA 95131			http://www.Brocade.Com
----------------------------------------------------------------------