Subject: [imss] RE: [Ips] Proposal to remove "dynamic" port type for FcPortType

From: [email-masked]
Date: Fri, 30 Apr 2004 11:22:08 -0400

> Thanks for raising this.  I believe that as editor, I do need the
> WG's approval to make any additions or deletions to:
> draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress.
> 
> So, if the WG approves the addition of these three recently-defined 
> new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the
> FcPortType TC, then I can go ahead and add them.

With WG co-chair hat on, unless someone objects to these additions
on the list, the editor should assume the that rough consensus of the
ips WG is to make these additions.  This is a relatively minor change
(adds elements to an existing enumeration), and better aligns the MIB
with Fibre Channel standards.

As to the possible removal of the "dynamic" port type, the issue appears
to boil down to whether a "dynamic" type is justified in addition to
"other" and "unknown".  Let me encourage further comments to focus on
this specific issue, and I offer the following advice:

- I think Keith is correct that not having a standard to reference is
	insufficient to remove "dynamic", as this would also entail
	also removing "other" and "unknown", which does not appear to
	be a desired outcome.
- It would be useful to see an explanation of how "dynamic" improves
	"future proofing" over and above "other" and "unknown".  I think
	there's rough consensus that some form of "future proofing" is
	needed, and the disagreement centers on whether "other" and
	"unknown" are sufficient.

The current MIB text is:
                   unknown(1),
                   other(2),    -- none of the below
                   dynamic(3),  -- determined dynamically
where the "below" list contains N, NL, F, FL, E and B ports (and will
contain G, GL and FNL ports, assuming no objections to their addition).

Note that if we were to remove "dynamic", its value in the
enumeration would be reserved in order to avoid renumbering
other port types or accidental reuse in the future.

Thanks,
--David (ips WG co-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
----------------------------------------------------

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Keith McCloghrie
> Sent: Thursday, April 29, 2004 6:40 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]
> Subject: Re: [Ips] Proposal to remove "dynamic" port type for 
> FcPortType
> 
> 
> Bob,
> 
> Thanks for raising this.  I believe that as editor, I do need the
> WG's approval to make any additions or deletions to:
> draft-ietf-ips-fcmgmt-mib-04.txt at its current stage of progress.
> 
> So, if the WG approves the addition of these three recently-defined 
> new types: 'gPort', 'glPort' and 'fnlPort' as new enumerations of the
> FcPortType TC, then I can go ahead and add them.
> 
> As regards 'dynamic':
> 
> - it is obviously needed in the MIB's current state (to represent
> G_Ports, GL_Ports and F/NL_Ports), and if the WG decided to defer the
> addition of the three new types, then it would continue to be needed.
> 
> - to characterize the retention of 'dynamic' as unnecessary "future
> proofing" is to ignore history.  Specifically, 'dynamic' was 
> defined in
> the original version of the draft-ietf-ips-fcmgmt-mib, more than two
> years ago, and hindsight shows us that was a smart move, because (as
> I said above) it is needed in the MIB's current state, it would
> continue to be needed if we deferred adding the three new types, and
> there are good chances it will be needed yet again in the future, even
> after we add the three new types.
> 
> - the first of those good chances is currently being debated in T11 in
> regard to (virtual-fabric) "trunking".  It seems to me that while T11
> has not yet reached the stage of debating of whether "trunking" is a
> characteristic of a port type, it likely is because a result of the
> layer-2 negotiation (that you mention) will be the port 
> becoming either
> a trunking port or one of the already-defined values of 
> FcPortType, i.e.,
> it's a type just like the existing ones are.  The other 
> (non-)types you
> mention are completely different because they will not be the subject
> of a layer-2 negotiation, and thus I agree that those others are not
> port types at layer-2 (and this is a layer-2 MIB).
> 
> - and finally, to remove 'dynamic' because:
> 
>     There is no referent for a "dynamic" port.
> 
> doesn't make any sense to me because there is no referent for an
> "unknown port" and no referent for an "other port".  Since we're not
> going to throw out 'unknown' or 'other' for this reason, then neither
> should we throw out 'dyanmic'.
> 
> Thanks,
> Keith.
> 
> 
> > I apologize for the cross posting, but the breadth of expert
> > knowledge and breadth of responsibility for this particular 
> > subject extends across all four reflectors.
> > 
> > The history is:
> > 
> > Snively:
> > 
> > 	Proposed including:
> > 		gPort
> > 		glPort
> > 		fnlPort
> > 
> > 	Proposed removing:
> > 		dynamic
> > 
> > 	Because:
> > 		All known "dynamic" ports are either G_Ports or
> > 		GL_Ports (which dynamically change to F_ or E_Ports)
> > 		or F/NL_Ports (which provides fabric services when
> > 		no FL_Port is available).
> > 		All other ports (if known) are "other", 
> > 		whether dynamic or not.
> > 
> > McCloghrie:
> > 
> > 	Agreed to add:
> > 		gPort
> > 		glPort
> > 		fnlPort
> > 	
> > 	Proposed retaining:
> > 		dynamic
> > 
> > 	Because:
> > 		There might be some future ports defined that had
> > 		mechanisms that would select the final port type
> > 		using previously undefined mechanisms.
> > 		In a sense, this was a future proofing.
> > 
> > Crandall:
> > 
> > 	Proposed removing:
> > 		dynamic
> > 
> > 	Because:
> > 		Unless some clear definition of the port were
> > 		created or referenced in a standard, it was
> > 		equivalent to "unknown".
> > 
> > My final proposal would be:
> > 
> > 	Remove:
> > 		dynamic
> > 
> > 	Because:
> > 		There is no referent for a "dynamic" port.  
> > 
> > Further explanation:
> > 
> > 	All Fibre Channel Ports have an associated type.  That type
> > 	is determined absolutely either by the port being set to or 
> > 	designed to be compliant with a particular type or by 
> > 	being designed as a specified type of multi-function port
> > 	that uses a certain standard algorithm to determine which
> > 	port type will be agreed upon.
> > 
> > 	Ports with knowable types (as opposed to "unknown" types) 
> > 	that do not behave according to those rules are "other"
> > 	and might as well be labeled as such.  Future revisions
> > 	of a MIB may add additional types to the list as new port types
> > 	are defined or may use other mechanisms (manufacturer and model)
> > 	to define the actual use of an "other" port until such changes
> > 	can be made in the MIB.
> >
> > 	Note that PortType does not tell everything there is to know
> > 	about a port.  As an example, FcPortType nPort may be 
> implemented
> > 	as an FCP SCSI initiator port, an FCP SCSI target port, or
> > 	an IPv6 over SCSI port, none of which is presently 
> defined in the
> > 	MIB.  Similarly E_Ports may have different capabilities such
> > 	as trunking that are not presently defined in the MIB.  Many of
> > 	these capabilities are also dynamic, requiring negotiations and
> > 	login operations to actually enable them.  However, 
> these capabilities
> > 	do NOT define a different port type.  
> > 
> > 	I believe there are probably a number of solutions to the
> > 	"future proofing" suggestion that do not require us to
> > 	make up a definition for a port type.
> > 
> 
> _______________________________________________
> Ips mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ips
> 

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

---

From: "Robert Snively" <[email-masked]>
Date: Fri, 30 Apr 2004 09:57:36 -0700

Using David Black's consensus call, I will focus on 
the "dynamic" question.

I am in agreement with Mike O'Donnell's 
analysis of "unknown" and "other".  I support his
conclusions on "dynamic" (i.e. that it should be
removed as a port type).

Keith McLoughrie indicates that dynamic is useful
for future proofing.  I believe that the most effective
mechanism for future proofing would be to remove
"dynamic" as a type, then provide a certain number
of pre-specified type values for future assignment
by INCITS TC T11 standards.  That way, the MIB can remain unchanged and
the
values be picked up by future T11 standards if they
are ever required.  The number of such values should
be small, since any large number of future variants would
probably require modification to the MIB anyway.

That allows both for future definition of ports with a 
negotiation algorithm and ports with a pre-established 
fixed type, something that "dynamic" does not.

Robert Snively

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

+1 408 333 8135
[email-masked]

---

From: [email-masked]
Date: Fri, 30 Apr 2004 14:39:22 -0400

Mike,

I'm trying not to take sides in this discussion.  From your message,
I understand your view to be that "unknown" and "other" are sufficient
to cover all the cases in which the port type is not one of the specific
values in the enumeration (N, NL, F, etc.), and hence that "dynamic"
should not be part of that enumeration.  Consider that view noted.

Someone who is in favor of "dynamic" will need to address your question
about how it improves future-proofing.

Thanks,
--David

> From: Mike O'Donnell [mailto:[email-masked]] 
> Sent: Friday, April 30, 2004 12:06 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" 
> port type for FcPortType
> 
> 
> 
> David,
> 
> I beg to differ...
> 
> >"I think Keith is correct that not having a standard to reference is
> "Other" and "Unknown" are (as is stated) used to indicate 
> that (for the case of 'other') the agent can determine the 
> port type and it is NOT any of those types identified in the 
> MIB.  "Unknown" indicates the agent is unable to ascertain 
> its type (be it any of those identified or other).  It is an 
> accepted mechanism in MIB's to provide an agent a mechanism 
> to report it as such. 
> 
> Based on the above, I don't accept the logic that because 
> 'other' and 'unknown' are not specified in any standard and 
> that dynamic is ALSO not specified in any standard then 
> "other" an "unknown" should also be removed from the MIB. 
> 
> As for the use of dynamic, it is my opinion that if the 
> specified states of a port can be determined (and documented 
> in the MIB), then dynamic has no value.  And, from an 
> implementor's perspective, if dynamic is added to the MIB, 
> when does one report "dynamic" versus G-port, GL_port, 
> FNL_port (or other specified port types)?
> 
> If it is to 'future-proof' the MIB, what does 
> 'future_port_type' (aka 'dynamic') tell me that 'other' does 
> not?  Help me understand.  Maybe someone can point to where 
> this has been successfully implemented (not just documented) 
> in other MIBs so we can use this as a model for 
> future-proofing our FC MIB's.  As an application vendor, 
> "dynamic" doesn't add any additional value as specified today.
> 
> Mike O'Donnell
> 
> ====================== 
> Michael E. O'Donnell 
> Director Software Architecture 
> McDATA Corporation 
> 4 McDATA Parkway 
> Broomfield, Colorado 80021 
> 720.558.4142 (office) 
> 303.570.3631 (cel) 
> [email-masked] 
> ======================
> 
> 
>  
> 
> 
> 
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, April 30, 2004 9:22 AM
> To: [email-masked]; [email-masked]
> Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for
> FcPortType
> 
> 
> INCITS T11.5 Mail Reflector
> ********************************
> 
> To Unsubscribe:
> mailto:[email-masked]?subject=unsubscribe
> 
> 
> SPECIAL NOTICE 
> 
> All information transmitted hereby is intended only for the 
> use of the 
> addressee(s) named  above and may contain confidential and privileged 
> information. Any unauthorized  review, use, disclosure or distribution
> of confidential and privileged information is prohibited. If 
> the reader of
> this message is not the intended recipient(s) or the employee 
> or agent 
> responsible for delivering the message to the intended recipient, you
> are hereby notified that you must not read this transmission and that
> disclosure, copying, printing, distribution or use of any of the
> information contained in or attached to this transmission is STRICTLY 
> PROHIBITED.
> 
> Anyone who receives confidential and privileged information 
> in error should 
> notify us immediately by telephone and mail the original 
> message to us at the
> above address and destroy all copies.  To the extent any 
> portion of this
> communication contains public information, no such restrictions 
> apply to that information. (gate01)
>

---

From: "Mike O'Donnell" <[email-masked]>
Date: Fri, 30 Apr 2004 10:06:24 -0600

David,

I beg to differ...

>	also removing "other" and "unknown", which does not appear to

"Other" and "Unknown" are (as is stated) used to indicate that (for the case of 'other') the agent can determine the port type and it is NOT any of those types identified in the MIB.  "Unknown" indicates the agent is unable to ascertain its type (be it any of those identified or other).  It is an accepted mechanism in MIB's to provide an agent a mechanism to report it as such. 

Based on the above, I don't accept the logic that because 'other' and 'unknown' are not specified in any standard and that dynamic is ALSO not specified in any standard then "other" an "unknown" should also be removed from the MIB. 

As for the use of dynamic, it is my opinion that if the specified states of a port can be determined (and documented in the MIB), then dynamic has no value.  And, from an implementor's perspective, if dynamic is added to the MIB, when does one report "dynamic" versus G-port, GL_port, FNL_port (or other specified port types)?

If it is to 'future-proof' the MIB, what does 'future_port_type' (aka 'dynamic') tell me that 'other' does not?  Help me understand.  Maybe someone can point to where this has been successfully implemented (not just documented) in other MIBs so we can use this as a model for future-proofing our FC MIB's.  As an application vendor, "dynamic" doesn't add any additional value as specified today.

Mike O'Donnell

====================== 
Michael E. O'Donnell 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, April 30, 2004 9:22 AM
To: [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for
FcPortType

The current MIB text is:
                   unknown(1),

Thanks,

To Unsubscribe:

SPECIAL NOTICE 

All information transmitted hereby is intended only for the use of the 
addressee(s) named  above and may contain confidential and privileged 
information. Any unauthorized  review, use, disclosure or distribution
of confidential and privileged information is prohibited. If the reader of
this message is not the intended recipient(s) or the employee or agent 
responsible for delivering the message to the intended recipient, you
are hereby notified that you must not read this transmission and that
disclosure, copying, printing, distribution or use of any of the
information contained in or attached to this transmission is STRICTLY 
PROHIBITED.

Anyone who receives confidential and privileged information in error should 
notify us immediately by telephone and mail the original message to us at the
above address and destroy all copies.  To the extent any portion of this
communication contains public information, no such restrictions 
apply to that information. (gate01)