|
List Info Thread: MIB Last Call Results and Fabric Config Server MIB Design Issue
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
MIB Last Call Results and Fabric Config Server MIB Design Issue |
|
List Info Thread: MIB Last Call Results and Fabric Config Server MIB Design Issue
[1]
|
||||||||||||
|
about | contact Other archives ( Real Estate discussion Medical topics ) |
||||||||||||
ietf.org
Cc: Black, David
Subject: MIB Last Call Results and Fabric Config Server MIB
Design Issue
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
black_david