Subject: RE: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic"

From: "Robert Snively" <[email-masked]>
Date: Tue, 4 May 2004 10:49:24 -0700

This has become far-reaching over the last few contributions.

I believe an IANA registry would be a straightforward mechanism
to allow rapid authorized updates of port types, eliminating
whatever need might actually exist for the undefined port type
"dynamic".  I see no downside to this.  I agree with David that
the number of contributions per year would be low, but the
necessity for rapid update independent of an RFC action would
be high, making the registry an attractive solution.

I believe that the "otherFixed" and "otherDynamic" could be
eliminated as a result of this, since "other" would exist as
a temporary denomination for ports not yet defined in the
registry or for ports that are proprietary and never will make it
to the registry.  I see no benefit in distinguishing them,
since simply by their "otherness" they must be identified
by mechanisms outside the MIB.  Once the "otherness" is
identified, it will quickly become clear whether they are
dynamic or not.

I believe that a significant number of the so-called
"Port Types" mentioned below (perhaps including the
trunked ports and the tagged ports) should really be
considered as a "port type" plus a "port capability".
The port type is negotiated early on, and the resulting
port type (E_Port or F_Port) then gets to negotiate one or more
additional capabilities (say tagging and/or trunking) at
a higher level, essentially turning on or off one or more
"port capabilities".  Essentially, this is like a menu.
You want pancakes (E_Ports), then you want syrup or 
sauce on top (trunked or tagged).  Otherwise, you have
to have a separate IANA registry for an E_Port, a trunked E_Port,
a tagged E_Port, and a trunked and tagged E_Port, all of
which were defined by two levels of negotiation from 
a G_Port.  Not a pretty scene.

Bob Snively

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On 
> Behalf Of Keith
> McCloghrie
> Sent: Tuesday, May 04, 2004 10:10 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]
> Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove
> "dynamic"
> 
> 
> David,
> 
> Thank-you.
> 
> I have already given my input on the questions you ask.  I'm happy to
> leave you to determine the consensus on these issues.
> 
> Keith.
> 
> > ----- IANA registry
> > 
> > > In other words, I believe whether or not to have a
> > > IANA registry for a particular enumerated value in a MIB is a
> > > trade-off:  worthwhile only if the rate of new 
> assignments is high.
> > > 
> > > In this case, Bob and Mike are in a much better position to know
> > > whether the rate of defining new port types is liable to be high.
> > 
> > I like the idea of an IANA registry, but for a couple of reasons
> > other than a potentially high rate of defining new port types:
> > 
> > (1) Fast turnaround: A new port type could be added to an IANA
> > 	registry in a matter of weeks after T11 determines that
> > 	it is appropriate.  Publishing a revised RFC takes months,
> > 	even under ideal conditions, and conditions have not been
> > 	ideal lately ...
> > (2) Proper review: As part of setting up the registry, we can
> > 	define the process for adding entries, allowing us to give
> > 	IANA explicit written instructions on how to obtain T11's
> > 	concurrence on allocations of new entries.  This would be an
> > 	aspect of Expert Review (cf. RFC 2434), and I would also impose
> > 	a Specification Required requirement that can be satisfied
> > 	by a T11 working version of a standard under development,
> > 	(but not a proposal - I think it's fair to require that T11
> > 	have voted to incorporate the proposed new port type).
> > 
> > I would expect a relatively low rate of new port type definitions
> > (handful per year at most).
> > 
> > If this makes sense, Elizabeth, Bob and I are at the T10 meetings
> > in Monterey, and can easily work out how IANA should interact with
> > T11 in the next few days.
> > 
> > ----- MIB types
> > 
> > The distinction between otherFixed and otherDynamic (otherNegotiate)
> > may be useful because:
> > 
> > - otherFixed means that the port type is not on the list and
> >       the port will not auto-negotiate to become some other type
> > 	(and specifically won't become one of the known types on
> > 	 the list).
> > - otherDynamic (or otherNegotiate) means that the port type is
> > 	not on the list, but can auto-negotiate, which could result
> > 	in it becoming one of the listed types (or some 
> otherFixed type).
> > 
> > Assuming that virtual fabric trunking/tagging goes forward in T11,
> > two examples of port types that are likely to exist are:
> > 
> > - a trunked tagged E_Port (like an E_Port, but carries traffic
> > 	that's tagged with virtual fabric tags).  This would be
> > 	an otherFixed prior to its addition to the enumeration.
> > - a new type of G_Port that could become a trunked E_Port, in
> > 	addition to all the other things that an existing G_Port
> > 	can become.  This would be an otherDynamic (otherNegotiate)
> > 	prior to its addition to the enumeration.
> > 
> > Do people think this distinction is useful?  If it's useful, then
> > we'd need to change "dynamic" to "otherDynamic" and "other" to
> > "otherFixed".
> > 
> > Thanks,
> > --David
> > ----------------------------------------------------
> > 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: Tuesday, May 04, 2004 9:42 AM
> > > To: [email-masked]
> > > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > > [email-masked]; [email-masked]; [email-masked]
> > > Subject: Re: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to 
> > > remove "dynamic"
> > > 
> > > 
> > > Hi Elizabeth,
> > >  
> > > There are a couple of cases where IANA assigns enumerated 
> values in
> > > a MIB, e.g., 
> http://www.iana.org/assignments/ianaiftype-mib lists the
> > > latest version of the IANAifType TC which includes all 
> the latest IANA
> > > assignments (including the last one of 'fcipLink' which I 
> believe was
> > > requested by this WG.)
> > > 
> > > Having IANA do this is necessary when the rate of new 
> assignments is
> > > relatively high (e.g., there are now 224 values defined for 
> > > IANAifType),
> > > but it has the downside that it increases the number of 
> steps required
> > > to locate the latest assignments.  To find the above URL, 
> the primary
> > > author of that MIB had to go to the IANA web-page and 
> figure out how
> > > to navigate through several web-pages in order to find 
> it.  It's much
> > > simpler for network adminstrators and/or management application
> > > writers to find the assignments when they are listed in the RFC's
> > > version of the MIB.  In other words, I believe whether or not 
> > > to have a
> > > IANA registry for a particular enumerated value in a MIB is a
> > > trade-off:  worthwhile only if the rate of new 
> assignments is high.
> > > 
> > > In this case, Bob and Mike are in a much better position to know
> > > whether the rate of defining new port types is liable to be high.
> > > 
> > > Keith.
> > > 
> > > > Hi all,
> > > > 
> > > > Instead of using a numerated list directly embedded in the 
> > > MIB, could we
> > > > address this issue through the creation of an IANA registry?
> > > > 
> > > > Essentially, what this discussion comes down to is how do 
> > > we future-proof
> > > > the MIB.  I believe that thru the use of a registry we may 
> > > be able to
> > > > accomplish Keith's goal without creating a MIB type that 
> > > does not have a
> > > > definition in today's T11 standards.  Once new port types 
> > > are defined by
> > > > T11, a new port type could be assigned in the registry to 
> > > correspond to that
> > > > type for use in this MIB.
> > > > 
> > > > I am not yet sure about the precedence for use of IANA 
> > > registries with MIBs,
> > > > and that is something I would need to consult with the 
> transport and
> > > > operations Area Directors, but is this an acceptable 
> > > solution to everyone?
> > > > 
> > > > Thanks,
> > > > 
> > > > Elizabeth Rodriguez 
> > > > 
> > > > -----Original Message-----
> > > > From: Keith McCloghrie [mailto:[email-masked]] 
> > > > Sent: Monday, May 03, 2004 11:07 AM
> > > > To: [email-masked]
> > > > Cc: [email-masked]; [email-masked]; [email-masked]; 
> > > [email-masked];
> > > > [email-masked]
> > > > Subject: [T11.5] Re: [imss] RE: 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.
> > > > 
> > > > But it does, and you do gain information.  Obviously, I am still
> > > > failing to make you understand.  Perhaps it's the word "fixed"
> > > > which is now the problem; so, let me try again:
> > > > 
> > > >  'otherFixed' -- a type which is known to the agent a priori and
> > > >                  the port does not perform on-the-wire
> > > >                  determination/negotiation, and is not 
> one of these
> > > >                  types: 'nPort', 'nlPort', 'fPort' 
> 'flPort', 'ePort'
> > > >                  or 'bPort'.
> > > >  'otherNegotiate' -- the port type is determined via on-the-wire
> > > >                  determination/negotiation, and is not 
> one of these
> > > >                  types: 'gPort', 'glPort', 'fnlPort'.
> > > > 
> > > > Note: one of these is via on-the-wire determination/negotiation
> > > >  and  one is not.  By definition, they ARE different.
> > > >  
> > > > > "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.
> > > >  
> > > > No, no, no.  Please don't read vendor-specific into 
> this; it is not
> > > > relevant.  You didn't answer my question on whether the new 
> > > types have
> > > > been approved by T11 Ballot yet.  Let me assume that they 
> > > haven't, and
> > > > that someone objects to adding them on that basis, then 
> such ports
> > > > would have to be represented by 'otherNegotiate' not by 
> > > 'otherFixed'.
> > > > So, no, 'otherNegotiate' is not vendor-specific.
> > > > 
> > > > Keith.
> > 
> > [... snip ...]
> > 
> 
> 
> _______________________________________________
> imss mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/imss
> 
> 

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

---

From: "Larry Hofer" <[email-masked]>
Date: Tue, 4 May 2004 14:00:57 -0600

Bob brings up an interesting point about capabilities. It seems to me, that it needs to be well understood whether the information in this (these) particular field(s) are just for reporting the topology or more than that.  Are actions to be taken by software based on what the capabilities are (or what the current operating state of the port is)?  Are capabilities distinguishable from current operating state? Port states today would be "offline, online, failed, etc." Or might a new capabilities' operating state also be, "active or inactive"? It would make sense to me to separate capabilities from current operating state of a capability, as both may be useful.

So seems like what the TYPE, CAPABILITIES, and CAPABILITY OPERATING STATE are would be different questions. And that an application might be interested in answering all those questions. For example, port speeds report current operating state (which speed) when that type of capability information is queried. 

Larry Hofer

-----Original Message-----
From: Robert Snively [mailto:[email-masked]]
Sent: Tuesday, May 04, 2004 11:49 AM
To: Keith McCloghrie; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: [T11.5] Re: [imss] RE: Re: [Ips] Proposal to remove "dynamic"

Bob Snively

> > > > So, no, 'otherNegotiate' is not vendor-specific.

To Unsubscribe:
mailto:[email-masked]?subject=subscribe

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)