Subject: RE: [Ips] Request from T11.5 for editorial cleanup

From: "Robert Snively" <[email-masked]>
Date: Fri, 26 Mar 2004 14:58:48 -0800

Keith,

Internal review by Brocade specialists has identified the following 
questions and suggestions about revision 5 of the document.

1)  Fabric Name:

	In FC-SW-3, Clause 7.3, Principal Switch Selection states:
 
		"The Switch_Name of the Principal Switch shall be 
		used as the Fabric_Name."

	In the MIB (fcmInstanceFabricId), it states: 

 		"The globally unique Fabric Identifier which identifies
the
            fabric to which the Fibre Channel entity/entities managed by
            this management instance are connected, or, of which they
            are a part.  This is typically the Node WWN of the principal
            switch of a Fibre Channel fabric."

	The text should be changed to align with FC-SW-3 and indicate
	that the Fabric Identifier SHALL be the Node WWN of the
principal switch. 

2)  Definition of port types under FcPortType:

	In FC-SW-3 two additional Port Types are defined, G_Port and
GL_Port.  
	In FC-GS-4 a third Port Type of F/NL_Port is defined.

	Other collective ports are also defined by FC standards
	documents, but those are for documentation purposes 
	only, rather than defining functionality.
	Such ports include:  Nx_Port (any port with N_Port or NL_Port
	capability) and FC_Port (any port capable of transceiving
	Fibre Channel frames).  While those are actually specified
	as port types in FC-GS-4, that is probably an error that
	should be corrected in the next revision of that document.
	
	The MIB has added the port type "dynamic", not defined by any
	of the T11 documents.  It is suggested the "dynamic" port type
	be removed and that "gPort" and "glPort" be used in its place, 
	since that is the likely intent of the word "dynamic", 
	referring to a port which has not quite yet decided what it is 
	going to be, but has a defined protocol to make that
determination.

	Use a port type of "unknown" when you cannot identify the port
	according to a standard.

	An additional port type of F/NL_Port ("fnlPort") should be 
	defined for applications that have that requirement.

	For reference, FC-SW-3 defines the G and GL_Ports as follows:

		3.1.45 G_Port: A generic Fabric Port that may 
				function either as an E_Port, or as an
F_Port.
		3.1.46 GL_Port: A generic Fabric Port that may 
				function either as an E_Port, or as an
Fx_Port.

	For reference, FC-GS-4 defines the F/NL_Port as follows:

		3.2.19 F/NL_Port: An NL_Port that detects OPN(00,x) 
				and provides Fibre Channel services in
the
				absence of an FL_Port (see FC-AL-2).

Thank you very much for your attention,

Sincerely,

Robert Snively

Brocade Communications Systems, Inc.
1745 Technology Drive
San Jose, CA 95110

+1 408 333 8135
[email-masked] 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of Keith
> McCloghrie
> Sent: Thursday, March 25, 2004 11:13 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Subject: [Ips] Request from T11.5 for editorial cleanup
> 
> 
> Hi,
> 
> As you will have seen from recent messages to this list, a few changes
> are required to draft-ietf-ips-fcmgmt-mib-04.txt as a result of the
> IESG Expert Review process.
> 
> Meanwhile, I received the message below from Roger on behalf of T11.5.
> Your WG chairs and I agree with Roger that these are purely editorial
> clarifications, and that consistency with FC-SWAPI is a good thing.
> So, I've taken the liberty of updating the draft as requested.
> 
> The latest draft can be found at:
> 
>   ftp://ftpeng.cisco.com/ftp/kzm/pub/draft-ietf-ips-fcmgmt-mib-05.txt
> 
> In due course, I will be submitting the latest draft as a new I-D.
> If you have any concerns, please speak up.
> 
> Thanks,
> Keith.
> --------------
> Forwarded message:
> > From: Roger Cummings <[email-masked]>
> > Message-ID: <8BE017CC8923D511A00A0008C78605EE0906084C@LMOXCH04>
> > To: Keith McCloghrie <[email-masked]>
> > Cc: Elizabeth Rodriguez <[email-masked]>, 
> [email-masked]
> > Subject: Issues with FC Management MIB
> > Date: Fri, 12 Mar 2004 15:14:41 -0500
> > 
> > Keith,
> > 
> > At a recent conference call reviewing Letter Ballot 
> comments on one of the
> > T11.5 API projects, called FC-SWAPI, it was noted that 
> clarifications of the
> > definitions of several of the objects defined in the API 
> should probably be
> > reflected in the FC Management MIB. 
> > 
> > The specific SWAPI objects, and their clarified definitions are :
> > 
> > 1) SWAPI_STATS_LBL_RLRS
> > 
> > Count of Link resets. This is the number of Link Reset (LR) 
> Primitive
> > Sequences received.
> > 
> > 2) SWAPI_STATS_LBL_TLRS 
> > 
> > Count of Link resets. This is the number of Link Reset (LR) 
> Primitive
> > Sequences transmitted.
> > 
> > 4) SWAPI_STATS_LBL_ROLS
> > 
> > Count of Offline (OLS) Primitive Sequences received at this port.
> > 
> > 5) SWAPI_STATS_LBL_TOLS
> > 
> > Count of Offline (OLS) Primitive Sequences transmitted by this port.
> > 
> > 
> > The corresponding definitions in 
> draft-ietf-ips-fcmgmt-mib-04.txt are:
> > 
> > fcmPortRxLinkResets OBJECT-TYPE
> >    
> >     DESCRIPTION
> >             "The number of Link resets (LR primitives) received."
> > 
> > fcmPortTxLinkResets OBJECT-TYPE
> >         DESCRIPTION
> >             "The number of Link resets (LRs primitive) transmitted."
> > 
> > fcmPortRxOfflineSequences OBJECT-TYPE
> >     
> >     DESCRIPTION
> >             "The number of Offline Primitive OLS received 
> at this port."
> > fcmPortTxOfflineSequences OBJECT-TYPE
> >     
> >     DESCRIPTION
> >             "The number of Offline Primitive OLS transmitted by this
> >             port."
> > 
> > The problem here is that all of these objects are defined 
> as the number of
> > primitives, but LR and OLS are Primitive Sequences and not 
> primitives. This
> > was not at all clear in earlier versions of SWAPI, and I 
> suspect that may
> > have been what you based the definitions on. Primitive 
> Sequences are already
> > referenced in the MIB in the fcmPortPrimSeqProtocolErrors 
> object type.
> > 
> > To make SWAPI & the FC Management MIB consistent, our 
> suggestions would be:
> > 
> > fcmPortRxLinkResets OBJECT-TYPE
> >    
> >     DESCRIPTION
> > 
> > "The number of Link Reset (LR) Primitive Sequences received."
> > 
> > 
> > fcmPortTxLinkResets OBJECT-TYPE
> >         DESCRIPTION
> > 
> > "The number of Link Reset (LR) Primitive Sequences transmitted."
> >     
> > 
> > fcmPortRxOfflineSequences OBJECT-TYPE
> >     
> >     DESCRIPTION
> > 
> > "The number of Offline (OLS) Primitive Sequences received 
> at this port."
> > 
> > 
> > fcmPortTxOfflineSequences OBJECT-TYPE
> >     
> >     DESCRIPTION
> > 
> > "The number of Offline (OLS) Primitive Sequences 
> transmitted by this port."
> > 
> > 
> > I think that this can be regarded purely as editorial 
> clarification, because
> > LR & OLS are clearly defined as Primitive Sequences in 
> FC-FS. Is it too late
> > to make these changes to the MIB? Do you need me to submit 
> these changes
> > "officially" as T11.5 Chair during IESG last call?
> > 
> > Regards,
> > 
> > 
> > 
> > 
> > Roger Cummings
> > Chair, TG T11.5
> > 
> > [email-masked]
> > 
> 
> 
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 
> 

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

---

From: Keith McCloghrie <[email-masked]>
Date: Mon, 29 Mar 2004 10:47:18 -0800 (PST)

>  		"The globally unique Fabric Identifier which identifies the

How about, I change the last sentence to be:

   FC-SW-3 requires this to be the Node WWN of the principal switch
   of the Fibre Channel fabric.

> 	In FC-SW-3 two additional Port Types are defined, G_Port and GL_Port.  
> 	going to be, but has a defined protocol to make that determination.
>
 
Thanks for the information. 

I agree that "gPort" and "glPort" together represent one example
of a "determined dynamically" scenario defined by the 'dynamic'
enumeration.  However, I suggest that we want this MIB to support
multiple versions of the FC-SW specification, such that as and when
switches compliant to FC-SW-4 start shipping in the future, that this
same MIB will simultaneously support both FC-SW-3 switches and FC-SW-4
switches.  If I understand correctly, "gPort" and "glPort" were added
in SW-3 (i.e., they were not present in SW-2), and thus I would
speculate that there's a non-zero possibility that other types of
dynamic determination could be added in SW-4 or SW-5.  In other words,
I believe this MIB must not say: "you will comply with FC-SW-3", but
instead, it needs to say: "a switch compliant to FC-SW-3 will do xxx"
(for example, see the proposal I made above wrt. Fabric_Name).
That is, this MIB needs to be a superset of FC-SW-3.

Given this, then we should definitely add enumerations for a
"F/NL_Port" port, and for "gPort" and "glPort" as defined in SW-3,
but I suggest that we retain "dynamic" as well in order to give this
MIB the best chance of accommodating the future.  (Note that it has
taken many years for the IETF to get this far with this MIB.  With T11
already having started work on SW-4, let's not make any assumptions
about how long after SW-4 is approved there will be an update to
this MIB.)

Keith.