[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RE: LLDP port ids
HI,
First, ifAlias came before ptopo. It was a manual way to tell you
what is on the other end and/or the circuit that you are using.
Can you describe situations that explain "depend upon the dynamic
nature of the link". Also, you say "not all links are point-to-point,
so there may be many things on the other end". Would you describe
how LLDP would cope with this situation.
Would you describe the problems with using ifName.
Thanks,
/david t. perkins
At 10:27 AM 2/25/2004 -0800, CONGDON,PAUL (HP-Roseville,ex1) wrote:
>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
>> > >>
>> > >>
>> >
>> >
>>