Subject: proposal for changes to fibre channel management MIB

From: "steven blumenau" <[email-masked]>
Date: Fri, 16 Apr 99 12:49:00 -0400

The following is broken into two different sections. One
is for errors that need to be fixed in the MIB. The second
is proposals for changes. I am planning on putting out
a new copy of the MIB next week that incorporates these
changes to help in evaluating them as part of the proposal.
This is simply to help in evaluation and is not a new
revision. It is easier to see them as part of a whole
solution. Note, object IDs will change as they are
incorporated into the MIB.
Steven Blumenau

### Changes needed because of errors and compiler compatibilies

1. A number of changes need to be made to make sure the MIB compiled cleanly
   in the following group of compilers
       windriver
       us software
       smic
       adventnet
       hp openview
       epilogue
       mg-soft
       SNMPc
       Interworking Labs
   This included dealing with parenthesis, spaces, comments, spelling, etc.
   This also included changes to some of the descriptions to make them more
   exact in definition.  I am not going to go through them but will
   incorporate them into the next revision of the MIB. A content change that
   needed to be made was to change all the enumerations so they started with
   '1' rather than '0'. Another content change was the need to change the
   range value for indexs from 4294967295 to 2147483647. The final content
   change was in the definition of connUnitStatusChange trap. The variable
   needed to be changed to connUnitStatusChangeTime as it was intended.

### Proposals for comment

2. change FCMON to FCMGMT

3. add support for revision of the MIB

        revisionNumber OBJECT-TYPE
                SYNTAX DisplayString (SIZE(4))
                ACCESS read-only
                STATUS mandatory
                DESCRIPTION
                        "This is the revision number for this MIB. The
                        format of the revision value is as follows
                                (0) = high order major revision number
                                (1) = low order major revision number
                                (2) = high order minor revision number
                                (3) = low order minor revision number
                        The value will be stored as an ASCII value. The
                        following is the current values.
                                (0) = '0'
                                (1) = '1'
                                (2) = '5'
                                (3) = '0'
			This defines a revision of 1.5
                        "
                ::= { connSet 6 }

4. add new type to connUnitType of "storage-subsystem(11)". This is to
   support describing a storage subsystem as different than a disk.

5. using the current MIB definition, the intent was to poll the
   topologychangetime object and monitor the appropriate trap. It turns
   out that there are problems with this approach. Some examples were if
   an deletion and addition were done between polls (assuming a trap got
   lost) or with a deletion, what should be specified in the trap. To solve
   this problem, the following defines new traps to track changes
   to the connUnitTable. Along with these, connUnitTopologyChange and
   connUnitConfigurationChange traps will be deleted. The intent is to
   follow up with a new set of traps that are more specific as to what
   they are reporting.

	connUnitAddedTrap TRAP-TYPE
                ENTERPRISE emc
                VARIABLES { connUnitId
                                }
                DESCRIPTION
                        "An event is generated when an entry is added to
                        the connUnitTable."
                ::= 11

	connUnitDeletedTrap TRAP-TYPE
                ENTERPRISE emc
                VARIABLES { connUnitId
                                }
                DESCRIPTION
                        "An event is generated when an entry is deleted from
                        the connUnitTable."
                ::= 12

   This will also include a new object at the top level

        connUnitTableChangeTime OBJECT-TYPE
                SYNTAX TimeTicks
                ACCESS read-only
                STATUS mandatory
                DESCRIPTION
                        "The sysuptime timestamp in centiseconds at which
                        the last connUnit Table change occurred for any
			members of the set."
                ::= { connSet 3 }

6. Use connUnitId as the index for the table. The goal is to create a globally
   unique Id space for all connUnitIds. connUnitId is a WWN, including
   the leading NAA, in any FC-PH authorized format.  This requires that you
   have to have an IEEE OUI (vendor id) to assign connUnitIds. Once you have
   supplied the NAA and OUI, you as a vendor are completely free as to how you
   assign the rest of the bits, other than to assure they are unique.  There
   is some merit, though not a requirement, that the WWN used as connUnitId be
   the same as that of (one of) the permanently attached FC/LAN interface(s).
   Whether it is or not, it must be unique. As an example, if your agent runs
   in a host and the host has an HBA, it is quite possible that agent, host,
   and HBA will all be distinct connUnits, so the host and agent can not use
   the WWN of the HBA. Another example...If your hub has a built-in Ethernet
   port, it might be reasonable for the hub to use its LAN address (prefixed
   with the with appropriate NAA) as its connUnitId. But if the Ethernet was
   a replaceable PCCard, the hub should have an independent ID. The following
   are some references for more information.

   http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html 
   http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html 

7. To handle modules as discussed at the Minn meeting, add a new type to
   connUnitType of "module(12)" and also the following variable which allows
   the table to still stay simple and flat but allows grouping of modules
   into a single unit.

                connUnitModuleId OBJECT-TYPE
                        SYNTAX OCTET STRING (SIZE(16))
                        ACCESS read-only
                        STATUS mandatory
                        DESCRIPTION
                                "This is a unique id that does not need to
                                 be persistent between boots. It is used
                                 to group a set of modules together into
                                 a single connUnit."
                        ::= { connUnitEntry 20 }

---

From: "Barb Sterling" <[email-masked]>
Date: Mon, 19 Apr 1999 12:18:46 -0600

Hello,

McDATA has a problem with the "globally unique" requirement for the connUnitId that is in the current
proposal.  McDATA is implementing a "Proxy Agent" of sorts on our server platform.  Each server
can manage up to 36 connUnits (FC switches).  The configuration of what switches the server
manages is configured by a person.  Based on previous requirements we chose to concatenate the 
connUnit's product_type Id with its  instance number as understood by the "Proxy Agent"
to form the connUnitId.

We can, if needed, format our current connUnitId into something that looks like a WWN.  This 
Id will however not be "globally unique."  If a management application were to have two EFC Servers 
(our Proxy Agents) in its network, then there would be overlap in connUnitIds across the two Agents.
Is this bad?  A connUnit (in our case) can only be managed by one Proxy Agent at a time.  The 
management station can distinguish between the connUnits given the IP address of the Proxy Agent
and the connUnitId.  We cannot use the connUnit's WWN for the Id because the Agent can know
about the existence of a connUnit without being able to communicate with it about its WWN.

This brings me to a question as to what we are trying to accomplish with the proposed connUnitId
format.  It seems to me that we are attempting to encode information into the connUnitId that might 
be better provided through separate MIB variables in the connUnitTable.  I believe that the connUnitId 
should be a simple way for the management station and agent to communicate about a particular connUnit
across reinitializations of the agent.  If we want to a human to know the vendor of the connUnit then maybe
we should add a vendorId object.  If we want the connUnit to be identifiable by a human at a management console, then maybe we should also provide a name object.

Barbara Sterling
303-460-3128
[email-masked]
www.mcdata.com

---

From: "Nixon, Bob" <[email-masked]>
Date: Mon, 19 Apr 1999 18:16:08 -0700

I accidentally posted this to the wrong reply community...

----------

Barb, although there has been an ongoing debate about how to satisfy the requirement, connUnitId was always specified as a unique and persistent identification for the associated connUnit.  Here are the opinions which led me to support the current proposal:

- We are developing a standard for long-term and industry-wide application.  It must do its job well.  Our current products in development may not be compliant with our final standard since our current products may be a lot closer to "done" than the standard.  This should not cripple the standards-making process.

- Uniqueness should be universal.  Any assumptions based on the scope of today's managers and agents may be obsolete in a month.

- Uniqueness can not be assured by vendors operating in isolation, so things like product serial numbers, by themselves, don't work.

- Uniqueness can not depend on unspecified vendor cooperation.  This would require n-to-n cooperation where the size of n is unknown.  The standard must specify how vendors can easily and reliably assure intervendor uniqueness.

- Uniqueness should NOT depend on kludging together values for multiple OIDs.

- The IEEE vendor ID is a widely accepted means of establishing intervendor uniqueness with n-to-1 cooperation (ie, each vendor independently with IEEE).  It is NOT used in order to embed additional information.

- WWNs are already a FC-community accepted way of formatting universally unique identification based on IEEE vendor IDs.

- Those of us with N-port deprived products don't mind using the WWN form which embeds an IEEE MAC address (remember, these are just my opinions!).

- Other than requiring an IEEE vendor ID and limiting the bit length, the WWN definition allows a great deal of vendor freedom.  Some variants of the WWN allow up to 100 bits to be assigned completely at the discretion of the vendor (other than that the vendor must assure they are unique within the scope of his vendor ID).  The proposal does not require use of the WWN of an N-port or LAN interface associated with the connUnit, but only recommends that it often will be appropriate.  In the case you raised, the proxy agent need not be told the WWN of the switch.  It could create a WWN by assuming the IEEE vendor ID for McData and assigning a unique suffix for each switch by means proprietary to McData.
 
Regards,
   - Bob

Replying to:

----------
From: 	Barb Sterling
Sent: 	Monday, April 19, 1999 11:18 AM
To: 	[email-masked]; [email-masked]
Subject: 	Re: proposal for changes to fibre channel management MIB

Hello,

Barbara Sterling
303-460-3128
[email-masked]
www.mcdata.com