Subject: RE: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for FcPortType

From: "Mike O'Donnell" <[email-masked]>
Date: Mon, 3 May 2004 18:15:32 -0600

Keith,

Your request is reasonable.  We can review such a requirement in GS-5 (gs-4 is all but complete and work is now underway in GS-5).  

But after a quick inspection of GS-4, the reason port type of G and GL are not specified is that in the GS-4 context they have no meaning (and I'm certain any of my GS-4 counterparts will correct me if I'm wrong!).  Operations in GS-4 are relative to the negotiated state of a port (i.e. F_port, E_Port, B_port...etc); not the potential state of a port (G or GL).  For example, you can't register a G_port (and even if you could, I'm uncertain what any client would do with that information in the GS-4 context).  Hence this why there is no definition needed in GS_4 (or GS-5).  If we need to add them for completeness we can discuss.  

Having said that, we can return to the orginal discussion on the need for 'Dynamic'.

Regards,

Mike O

-----Original Message-----
From: Keith McCloghrie [mailto:[email-masked]]
Sent: Monday, May 03, 2004 12:30 PM
To: John Crandall
Cc: Keith McCloghrie; [email-masked]; [email-masked];
[email-masked]; [email-masked]; Robert Snively
Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for
FcPortType

INCITS T11.5 Mail Reflector
********************************

Hi John,

I see them now (and I'll assume the GS-4 editor has an action-item
to do the corresponding update to reflect the new values).

Thanks,
Keith.
 
> Kieth,
> 
> The definition of G and GL port are in FC-SW-3 (the latest revision).
> 
> The text is:
> 
> 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.
> 
> John
> 
> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Robert Snively
> Sent: Monday, May 03, 2004 10:04 AM
> To: Keith McCloghrie
> Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
> Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for
> FcPortType
> 
> 
> INCITS T11.5 Mail Reflector
> ********************************
> 
> The point is that it provides absolutely no information
> that is not present in the "other" category.  If you don't know
> in what sense it is dynamic and what resolutions and algorithms
> are necessary to resolve its dynamic behavior to some other
> behavior, you have gained no information about the port.
> 
> "vendor specific other" might be a more useful value than
> dynamic, because that indicates that there is a mechanism
> to determine the "otherness" of the port through vendor 
> specific behaviors, where the vendor and model are known from other
> information in the MIB.  "Dynamic" does not even have that
> grace.
> 
> Bob
> 
> > -----Original Message-----
> > From: [email-masked]
> > [mailto:[email-masked]]On Behalf Of Keith 
> > McCloghrie
> > Sent: Sunday, May 02, 2004 10:57 AM
> > To: Robert Snively
> > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > [email-masked];
> > [email-masked]
> > Subject: [T11.5] Re: [Ips] Proposal to remove "dynamic" port type for
> > FcPortType
> > 
> > 
> > INCITS T11.5 Mail Reflector
> > ********************************
> > 
> > Bob,
> > 
> > No, a MIB is not just a specification of syntax; a MIB is required 
> > to define the semantics of objects also.  Otherwise, the MIB has no
> > value to a management application.  So, a MIB with your "pre-specified
> > type values" *would* undergo a change (in semantics) as and when T11
> > defined the semantics.
> > 
> > However, I agree with your recognition of the future need for:
> > 
> > a) "ports with a negotiation algorithm", as well as
> > b) "ports with a pre-established fixed type".
> > 
> > Since we cannot (see above) pre-define such types, if we removed
> > 'dyanmic' then both of these categories would have to be lumped
> > together under 'other'.  The reason to retain 'dynamic' is to allow a
> > management application to distinguish between these two 
> > types.  I don't
> > understand the strong opposition to allowing such a distinction.  How
> > can anyone object to giving a management application more accurate
> > information ??
> > 
> > Perhaps the problem is that I've failed to define/explain them
> > properly, or perhaps it's the word "dynamic" that you don't like.
> > So, how about we take the two current enumerations 'other' 
> > and 'dynamic'
> > and replace them with these two:
> > 
> > 'otherFixed' -- a fixed type (known to the agent) which is not one of
> >        these types: 'nPort', 'nlPort' 'fPort' 'flPort' 
> > 'ePort' or 'bPort'.
> > 'otherNegotiate' -- a type (known to the agent), which is subject to
> >        on-the-wire determination (e.g., by negotiation), but which is
> >        not one of these types: 'gPort', 'glPort', 'fnlPort'.
> > 
> > Keith.
> > 
> > PS. I can't locate the definitions of 'gPort' and 'glPort'.  I note
> > that 'fnlPort' is defined in sections 3.2.19 and 6.2.3.3.2 (Table 127)
> > of GS-4, and I would have expected to find G_Port and GL_Port in the
> > same/corresponding sections, but they're not.  Please can you provide
> > me with a document name and section number reference for these two.
> > Or, am I mistaken in assuming that these new types have been approved
> > by T11 Ballot ??
> > 
> > 
> > > 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] 
> > > 
> > > 
> > > 
> > > 
> > > 
> > 
> > 
> > 
> > To Unsubscribe:
> > mailto:[email-masked]?subject=unsubscribe
> > 
> > 
> > 
> 
> 
> To Unsubscribe:
> mailto:[email-masked]?subject=subscribe
> 
> 

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)

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

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 4 May 2004 06:21:26 -0700 (PDT)

Mike,
 
You raise a good point.  It is natural for any "negotiation" to happen
as part of the first flurry of messages on a link.  That is, by the time
the port is exchanging messages with the Fabric Config Server it will have
finished any negotiation (and/or other determination).  For example, I
note that SW-3 says:  "A G_Port determines through Port Initialization
whether it operates as an E_Port or as an F_Port."

In the case of the MIB, we have both fcmPortAdminType and fcmPortOperType.
My expectation is that fcmPortAdminType will reflect the fact that the
port is a G_Port or GL-Port, even after the "negotiation", but
fcmPortOperType will reflect the result of the "negotiation".  If you
agree, I would propose to add a few words to the DESCRIPTIONs which
note that.

In the case of GS-4, its text doesn't seem to distinguish whether the
specified values are for PortOperType or PortAdminType (and it's
unclear to me whether a port is only ever registered by itself, or
whether it can be registered via some other port).

Thus, I'm happy to leave the issue of whether GS-4 represents AdminType
and/or OperType as as an item for T11 to discuss, but my input would be
to ask for some text in the document to be added to explain the issue,
even if no new values are defined.

Thanks,
Keith.
 
> Keith,
> 
> Your request is reasonable.  We can review such a requirement in GS-5
> (gs-4 is all but complete and work is now underway in GS-5).
> 
> But after a quick inspection of GS-4, the reason port type of G and
> GL are not specified is that in the GS-4 context they have no meaning
> (and I'm certain any of my GS-4 counterparts will correct me if I'm
> wrong!).  Operations in GS-4 are relative to the negotiated state of a
> port (i.e. F_port, E_Port, B_port...etc); not the potential state of a
> port (G or GL).  For example, you can't register a G_port (and even if
> you could, I'm uncertain what any client would do with that information
> in the GS-4 context).  Hence this why there is no definition needed in
> GS_4 (or GS-5).  If we need to add them for completeness we can discuss.
>