RE: RE: LLDP port ids

["CONGDON,PAUL (HP-Roseville,ex1)" <paul.congdon@hp.com>]

Using ifAlias to describe the other end seems to have two other problems.
First, it is suppose to be non-volatile, and what is on the other end would
certainly depend upon the dynamic nature of the link and shouldn't be
non-volatile.  Second, not all links are point-to-point, so there may be
many things on the other end. It seems like you are using ifAlias to replace
what ptopo was doing. If you already have ptopo (or better yet, LLDP MIB)
telling you what is on the other end of the link, there is no reason to also
load ifAlias with this.

Paul

> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
> Sent: Wednesday, February 25, 2004 12:26 AM
> To: David T. Perkins; Harrington, David; CONGDON,PAUL 
> (HP-Roseville,ex1)
> Cc: mreview@ops.ietf.org; mlavine@foundrynet.com
> Subject: RE: RE: LLDP port ids
> 
> 
> DaveP,
> 
> I believe that DaveH was correct. Your response does not 
> provide a serious evidence that such a usage is common in the 
> industry. Neither does the text that you are quoting. It 
> looks like your interpretation, or the way the application 
> you describe is using ifAlias is specific, and was not 
> intended by the authors of the Interfaces MIB. The definition 
> says clearly that "This object is an 'alias' name for the 
> interface as specified by a network manager, and provides a 
> non-volatile 'handle' for the interface." and nothing 
> substantiates your interpretation as a ""scratchpad" for 
> storing, typically, information about the "other end" of the "cable"".
> 
> Moreover, there is no need to use LLDP to gather the 'ifName' 
> on the other side in order to populate 'ifAlias'. The LLDP 
> MIB which replaces ptopo has tables for both the local 
> handler and the remote handler values. What we are looking 
> for is a unique and non-volatile handler of the interface on 
> the device that can be represented on the local information 
> table, and send to the other side of the link to fill in the 
> remote identifier object. ifName does not seem to meet these 
> requirements, ifAlias does. 
> 
> Obviously, this discussion is still open, and other folks are 
> welcome to jump in with opinions and advice one way or the other. 
> 
> Regards,
> 
> Dan
> 
> 
> 
> > -----Original Message-----
> > From: David T. Perkins [mailto:dperkins@dsperkins.com]
> > Sent: 24 February, 2004 10:18 PM
> > To: Harrington, David; CONGDON,PAUL (HP-Roseville,ex1);
> > Romascanu, Dan (Dan)
> > Cc: mreview@ops.ietf.org; mlavine@foundrynet.com
> > Subject: RE: RE: LLDP port ids
> > 
> > 
> > HI,
> > 
> > I didn't hear any response after my message, so I sent a
> > follow up to DBH.
> > 
> > It and the follow up are shown below.
> > 
> > 
> > I'm very concerned about the use of ifAlias, again, since I 
> would use 
> > the results of ptopo to populate the values of ifAlias. 
> That is, for a 
> > direct connect environment, such as a LAN, the value my management
> > app would store in ifAlias would be the "other end" of the 
> connection,
> > such as bb2-p4-0.sf.myisp.com. If I was using a circuit provided
> > by a third party, I would include both it and the other end, such
> > as so2-p4-0.sf.myisp.com;pb-23245.
> > 
> > Do we have a misunderstanding as to what the object ifAlias 
> should be? 
> > I also believe the issue of changing ifName value is a diversion 
> > intended to distract attention from the real issue. And by saying it
> > can change,
> > and therefore it cannot be used is faulty logic. Maybe the 
> problem is
> > the description of ifName says that multiple instances can have the
> > same value? If so, the question is would this occur in a ptopo
> > environment?
> > 
> > But again, the real question is the "cause and effect" one of how 
> > ifAlias and ifName values would be populated.
> > 
> > Here are the relevant text quotations from the IF MIB:
> >    In contrast, the existing ifDescr object is intended to contain a
> >    description of an interface, whereas another new object, ifAlias,
> >    provides a location in which a network management application can
> >    store a non-volatile interface-naming value of its own 
> choice.  The
> >    ifAlias object allows a network manager to give one or more
> >    interfaces their own unique names, irrespective of any interface-
> >    stack relationship.  Further, the ifAlias name is 
> non-volatile, and
> >    thus an interface must retain its assigned ifAlias value across
> >    reboots, even if an agent chooses a new ifIndex value for the
> >    interface.
> > 
> > 
> > ifAlias   OBJECT-TYPE
> >     SYNTAX      DisplayString (SIZE(0..64))
> >     MAX-ACCESS  read-write
> >     STATUS      current
> >     DESCRIPTION
> >             "This object is an 'alias' name for the interface as
> >             specified by a network manager, and provides a
> > non-volatile
> >             'handle' for the interface.
> > 
> >             On the first instantiation of an interface, the value of
> >             ifAlias associated with that interface is the 
> zero-length
> >             string.  As and when a value is written into an
> > instance of
> >             ifAlias through a network management set 
> > operation, then the
> >             agent must retain the supplied value in the 
> > ifAlias instance
> >             associated with the same interface for as long as that
> >             interface remains instantiated, including across all re-
> >             initializations/reboots of the network 
> management system,
> >             including those which result in a change of the 
> > interface's
> >             ifIndex value.
> > 
> >             An example of the value which a network manager
> > might store
> >             in this object for a WAN interface is the 
> > (Telco's) circuit
> >             number/identifier of the interface.
> > 
> >             Some agents may support write-access only for interfaces
> >             having particular values of ifType.  An agent
> > which supports
> >             write access to this object is required to keep 
> > the value in
> >             non-volatile storage, but it may limit the length of new
> >             values depending on how much storage is already 
> > occupied by
> >             the current values for other interfaces."
> >     ::= { ifXEntry 18 }
> > 
> > 
> > ifName OBJECT-TYPE
> >     SYNTAX      DisplayString
> >     MAX-ACCESS  read-only
> >     STATUS      current
> >     DESCRIPTION
> >             "The textual name of the interface.  The value of this
> >             object should be the name of the interface as 
> assigned by
> >             the local device and should be suitable for use
> > in commands
> >             entered at the device's `console'.  This might be a text
> >             name, such as `le0' or a simple port number, 
> such as `1',
> >             depending on the interface naming syntax of the 
> > device.  If
> >             several entries in the ifTable together 
> represent a single
> >             interface as named by the device, then each 
> will have the
> >             same value of ifName.  Note that for an agent 
> > which responds
> >             to SNMP queries concerning an interface on some other
> >             (proxied) device, then the value of ifName for such an
> >             interface is the proxied device's local name for it.
> > 
> >             If there is no local name, or this object is 
> otherwise not
> >             applicable, then this object contains a
> > zero-length string."
> >     ::= { ifXEntry 1 }
> > 
> > 
> > 
> > At 02:38 PM 2/24/2004 -0500, Harrington, David wrote:
> > >Hi Dave,
> > >
> > >I think everybody had already decided that ifAlias sounded 
> like the 
> > >right choice when you spoke up, and we were looking for a 
> good reason 
> > >not to use it, or confirmation of the choice.
> > >
> > >I am personally unaware that people use ifAlias in the way
> > you said, and
> > >the RFC certainly doesn't lead one to believe that was the planned 
> > >usage. I don't think you'll dissuade the IEEE from using
> > ifAlias based
> > >on your comment, unless you can provide some serious
> > evidence that such
> > >a usage is common in the industry, or get others to concur 
> with your 
> > >analysis.
> > >
> > >dbh
> > >
> > >> -----Original Message-----
> > >> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> > >> Sent: Tuesday, February 24, 2004 1:09 PM
> > >> To: Harrington, David
> > >> Subject: Fwd: RE: LLDP port ids
> > >> 
> > >> HI,
> > >> 
> > >> Ok, did I provide clarity, or something else. All 
> chatter stopped.
> > >> 
> > >> /david t. perkins
> > >> 
> > >> >Date: Mon, 23 Feb 2004 09:25:31 -0800
> > >> >To: "C. M. Heard" <heard@pobox.com>, "Romascanu, Dan (Dan)"
> > >> <dromasca@avaya.com>
> > >> >From: "David T. Perkins" <dperkins@dsperkins.com>
> > >> >Subject: RE: LLDP port ids
> > >> >Cc: "Harrington, David" <dbh@enterasys.com>, "CONGDON,PAUL
> > >> (HP-Roseville,ex1)" <paul.congdon@hp.com>, mreview@ops.ietf.org
> > >> >
> > >> >HI,
> > >> >
> > >> >Here are short descriptions of ifName and ifAlias:
> > >> >ifName - the name of an interface used in CLI and other
> > configuration
> > >> >         commands for the device
> > >> >ifAlias - a "scratchpad" for storing, typically, 
> information about
> > >> >          the "other end" of the "cable".
> > >> >Given these definitions, I would use ifName, since the
> > results from
> > >> >ptopo would possibly be used to populate the value of ifAlias.
> > >> >
> > >> >At 09:00 AM 2/23/2004 -0800, C. M. Heard wrote:
> > >> >>On Mon, 23 Feb 2004, Romascanu, Dan (Dan) wrote:
> > >> >>> To make the scope of the discussion more clear - the 
> choice in 
> > >> >>> the discussion that we are having with the LLDP folks
> > is between
> > >> >>> ifAlias and ifName as an unique identifier for topology 
> > >> >>> connections. I agree with you that it is impossible 
> for these 
> > >> >>> requirements to be met by ifAlias unless the user (via 
> > >> >>> management software) makes them happen. As you say, the 
> > >> >>> user/management software must assign a unique ID to
> > ifAlias when
> > >> >>> a link layer connection is nailed up, and must not 
> change that 
> > >> >>> ID for as long as the link layer connection 
> persists. However, 
> > >> >>> in my opinion ifAlias seems a better choice than 
> using ifName, 
> > >> >>> which has by definition a semantics limited to 
> device context, 
> > >> >>> and does not allow to be modified by SNMP MIB operations.
> > >> >>
> > >> >>Yes, I understood that, and I agree:  ifName is
> > unsuitable for this
> > >> >>purpose, and ifAlias is a much better choice.  The 
> concern that I 
> > >> >>wanted to raise is that there is a loophole in the 
> definition of 
> > >> >>ifAlias that allows an agent to refuse writes and 
> always return a 
> > >> >>zero-length string.  That could be a problem, 
> depending on what 
> > >> >>fielded agents actually do.
> > >> >>
> > >> >>Mike
> > >> >Regards,
> > >> >/david t. perkins
> > >> 
> > >> 
> > 
> > 
>