Subject: [imss] MIB Last Call Results and Fabric Config Server MIB Design Issue

From: [email-masked]
Date: Tue, 26 Sep 2006 20:18:13 -0400

The imss WG last call on the Fibre Channel RSCN, Fabric
Config Server, and Zone Server MIBs has certainly been
interesting, and I want to thank Bert Wijnen and Dan Romascanu
for spending time on these MIBs at this juncture - it should
help significantly in dealing with these MIBs after they
leave the WG.

For now, these MIBs are here in the imss WG.  While I saw a
lot of Last Call issues on MIB syntax, I only saw one significant
technical issue on the table structure in the Fabric Config Server
MIB (see below).  That technical issue appears sufficiently
contained (it's about MIB table structure, and does not affect
function) that I don't believe a second WG Last Call will be
needed once a resolution is determined.  So, all three MIBs
are through WG Last call, but new versions of all three MIB
drafts will be needed to check that the significant number of
issues found by Dan and Bert have been addressed.  Those will
probably show up after the T11 meetings next week because ...

We(I) also have some things to address with T11.  The good
news is that not only is FC-GS-5 now a stable reference, but
also based on my discussions with the responsible T11 people,
the "Ugly" issue 3) should be resolved by formal T11 action
next week that should produce an archive document containing
the required FC-SW-5 allocation (which can then be cited in
a REFERENCE clause).  That issue was:

	T11 does not have an IANA equivalent, and
	hence we will need to come up with something to
	formalize the allocation and record it in some-
	thing reference-able prior to FC-SW-5 putting in
	an appearance.

The remaining T11 issue is the status/stability of FC-LS,
and I will report back to the WG on that after the T11
meetings next week.

That leaves one technical issue that needs attention here:

----------------
> Bert Wijnen
Keith McCloghrie

> - SMICng gave a warning about the indexing of
> 
>   t11FcsPortListEntry  OBJECT-TYPE
>     SYNTAX       T11FcsPortListEntry
>     MAX-ACCESS   not-accessible
>     STATUS       current
>     DESCRIPTION
>             "An entry which identifies that the port which has the
>             port name, t11FcsPortName, is in a particular list of
>             ports, which is known to a switch (identified by
>             fcmInstanceIndex and fcmSwitchIndex)."
>     INDEX   { fcmInstanceIndex,  fcmSwitchIndex,
>               t11FcsPortListIndex, t11FcsPortName }
>     ::= { t11FcsPortListTable 1 }
> 
>   I read Keiths explanation, which seemed fine. But now that I am
>   reviewing the MIB module in details and try to understand things,
>   now I am no so sure this is goodness.
> 
>   So, that t11FcsPortname is a value (embedded in the index) that
>   should help me find more detailed info, right?
>   So how do I find that info? I think I need to go to the
>   t11FcsPortTable, which is indexed by:
> 
>     INDEX   { fcmInstanceIndex, fcmSwitchIndex,
>               t11FcsFabricIndex, t11FcsPortName }
> 
>   So assuming that the index values for fcmInstanceIndex,
fcmSwitchIndex,
>   are the same in both tables, I can see that I can pick up 3 index
>   values from the list of t11FcsPortsList in the t11FcsPortsListTable.
>   But I am missing the 3rd index of the t11FcsPortnameTable, namely
>   t11FcsFabricIndex. So how am I going to wuickly pick that up?
>   Or how exactly are the tables connected/linked?
> 
>   Maybe I need to study it deeper... but I'd prefer an explanation of
>   the people who created these tables with the current indexing
schemes.
 
To generate an answer to your question, I needed to re-review the
structure of the tables, and in doing so, I now think that the current
structure is more open-ended/flexible than it needs to be -- having a
less open-ended structure would make the MIB simpler.  Specifically,
the MIB currently has a table whose only purpose is to identify a list
of (not necessarily related) ports.  However,

- each IE is either a virtual IE attached to one virtual Fabric, or
  (if virtual Fabrics are not in use) it's a physical IE.
- each port is either a virtual port attached to one virtual Fabric, or
  (if virtual Fabrics are not in use) it's a physical port.
- GS-5 mentions that an IE has a "port list" and has a dotted line from
the
  "Interconnect Element Object" to the "Port Object" in its "Figure 7 --
  Interconnect Element and Port attributes".
- However, all ports in an IE's port list will be attached to the same 
  Fabric as that IE is attached to.  In other words, the relationship
  between IEs and ports is hierarchical.
- Thus, it would be simpler to:

  - delete the t11FcsPortListTable,
  - delete the t11FcsIePortListIndex object, and
  - insert t11FcsIeName into the INDEX of the t11FcsPortTable, i.e.,
    change the INDEX-ing of the t11FcsPortTable to be:

      INDEX   { fcmInstanceIndex, fcmSwitchIndex, t11FcsFabricIndex,
                t11FcsIeName, t11FcsPortName }

Increasing the INDEX clause from four to five objects makes it a little
more cumbersome, but the length is still far short of the maximum
length.

With these changes, while there will no longer be any explicit mention
of a "port list" in the MIB, the list of ports on an IE will be all
the rows in t11FcsPortTable which have the same values for the first
four index objects, i.e., the value of t11FcsPortName will be the only
index value for which they differ.  So, a "port list" is (implicitly)
a set of adjacent rows in the t11FcsPortTable.

-----------------

This looks like a desirable simplification to me (taking out one
table), but the purpose of this email is to solicit comments from
others on this mailing list.  Please comment within the next week.

Thanks,
--David (imss WG chair)
----------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
[email-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------

_______________________________________________
imss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/imss