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

From: Keith McCloghrie <[email-masked]>
Date: Mon, 3 May 2004 11:30:12 -0700 (PDT)

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
> 
> 

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

---

From: "John Crandall" <[email-masked]>
Date: Mon, 3 May 2004 11:14:28 -0700

Kieth,

The text is:

John

-----Original Message-----

Bob

To Unsubscribe: