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

From: "Robert Snively" <[email-masked]>
Date: Wed, 28 Apr 2004 11:54:59 -0700

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

---

From: Keith McCloghrie <[email-masked]>
Date: Thu, 29 Apr 2004 15:40:05 -0700 (PDT)

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:

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.