Subject: Comments on fcmgmt 06

From: "Lee Darrow" <[email-masked]>
Date: Mon, 09 Apr 2001 14:40:54 -0700

Ok, here's a retry of the message I tried several times to send to this
list last week.

Lee

-------- Original Message --------
Subject: Comments on fcmgmt 06
Date: Wed, 04 Apr 2001 15:52:24 -0700
From: Lee Darrow <[email-masked]>
To: [email-masked]

I've got several comments, questions and issues regarding the most
recently published fcmgmt MIB, draft-ietf-ipfc-fcmgmt-int-mib-06.txt.
The order is basically as they appear in the MIB.

I'm really sorry about the length.

1)  The description of fcConnUnitModuleId is confusing to me.  I take it
that all the members of the connunit would set their fcConnUnitModuleId
to the value of the fcConnUnitId of the module connunit.  The
description in the MIB doesn't exactly say this, but it's the only way I
could see it working.

2) fcConnUnitFabricID.  If unknown, the description says to set it to an
empty string, but fcConnUnitFabricID is OCTET STRING (SIZE(16)), which
must be 16 bytes long.  It would probably be better to say
fcConnUnitFabricID is all 0's or 1's in the event it is unknown.

3) FcGlobalId.  The description is as follows: "Represents the Worldwide
Name (WWN; IEEE 124-bit variety) associated with a Fibre Channel (FC)
entity."  While it is true that the IEEE registered extended (124-bit,
NAA=6) format may be used, my semi-educated guess is that it will be the
exception rather than the rule.  Normally, I would expect this to be the
Node_Name or the Port_Name of the element in question, and at least on
the FC wire, they are all the 8 byte variety.  The way the description
above reads, it sounds like it must be the NAA=6 format.

4) FcNameId Vs. FcGlobalId.  I'm confused as to why we have both.  They
both must be in one of the FC-PH/PH3 formats.  The only difference is
that FcGlobalId allows NAA=6 and FcNameId doesn't.  Their usage is also
inconsistent.  fcConnUnitPortWwn is a FcGlobalId, but
fcConnUnitSnsPortName is a FcNameId, and even worse
fcConnUnitLinkPortWwnX is an OCTET STRING (SIZE(16)).  I have not
thought this through, but my initial thought would be to change all
references to what should be a WWN  to FcGlobaldId.

5) fcConnUnitLinkTable header comment.  There is what I assume to be a
search-and-replace-o.  The second to last paragraph begins "This table
is MAX-ACCESSed either".

6) fcConnUnitLinkTable header comment.  The last paragraph is as
follows:  "For an entry to be considered to be valid, both the X (local)
and the Y (remote) need to have one valid value."  I would just remove
this paragraph.  It contradicts the last sentence in the third paragraph
stating "the information MUST include either a nonzero connUnitNodeId-
or a nonzero connUnitPortWwn- for each end of the link."  Personally, I
prefer the less restrictive one, but it's not worth the discussion.

7) The link table again.  I can't remember the reason why we named what
FC calls the Node_Name for the X side fcConnUnitLinkNodeIdX instead of
fcConnUnitLinkNodeWWNX or fcConnUnitLinkNodeNameX.  I think it was done
this way because we wanted to reference this field back to a
connunitid.  My preference would be to force this to be a WWN, and not
make it a connunitid.  A management app can't tell from looking at a
connunitid whether it's a WWN or not, so it must go back to the connunit
table and read the fcConnUnitGlobalId.  It would be nice if a single
link table row was "self describing" about that like, and not require
information from other parts of the MIB.

8) fcConnUnitLinkNodeIdX/Y again.  The MIB says it's OCTET STRING
(SIZE(64)).  There's that 64 bytes again.  It won't go away.  Someone
really wants this sucker to be 64 bytes long.  Per my previous comment
4) and 8), I think it should be a FcGlobalId which must be an 8 or 16
byte WWN.

9) fcConnUnitLinkAgentAddressTypeY.  It would be nice to explicitly
specify what to put in here if fcConnUnitLinkAgentAddressY is unknown.
>From a MIB implemeneters point of view, it was hard to figure out what
to put here when there was no agent address.  Not that it really makes
any difference.  I bring this up because the obvious unknown value is 0,
but that's listed as "Reserved" as an IANA address family number.  If we
changed this to an integer, we could use -1.

10) fcConnUnitLinkAgentMask.  I don't understand what this is.  Please
help.

11) fcConnUnitLinkAgentPortY.  Same issue as
fcConnUnitLinkAgentAddressTypeY.  What do you put in here when
fcConnUnitLinkAgentAddressY is unknown?

12) Port Statistics table.  All of the counters are Counter64, yet in
the table comment header it says to set the most significant bit to 1 if
the counter is not supported.  I do not know this for sure, but I don't
think that is a valid use of Counter64.  Does anyone know?  If not, we
might want to put it back to an 8-byte octet string.

13)  SNS Table.  I'm confused as to why fcConnUnitSnsMaxRows is down
under fcMgmtConfig, but fcConnUnitSnsTable is up a level under
fcMgmtObjects.

14) fcConnUnitSnsPortIdentifier.  What is it used for and how is it
different than fcConnUnitSnsPortName?

15) fcConnUnitSnsNodeIPAddress and fcConnUnitSnsPortIPAddress.  What are
these the IP address of?  Is it for management of that node or port, or
is for operational use?

16) fcConnUnitSnsPortType.  It's currently shows as a single byte
octet.  I'm not sure that it's big enough, and the description doesn't
say how it's encoded.

17) fcConnUnitSnsHardAddress.  It's defined as an FcGlobalId, but the
description says that it's a hard ALPA.  I'm not sure what that means.

18) The top of the MIB tree is currently mib-2.8888.  Is that where it's
really going to go?

19) I noticed that there was no version information in the MIB.  Why was
that removed?

Again, sorry for the length.

If anyone would rather discuss any of these items with me vocally rather
than e-mail, please feel free to call.

Lee Darrow
Vixel Corporation
425-806-4516