[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RE: LLDP port ids
HI,
Would someone with knowledge of cisco's CDP help out here. I believe
that CDP returns ifName value. If so, I don't understand why that
this is not workable. I haven't heard why ifName is not workable.
regards,
/david t. perkins
At 10:26 AM 2/25/2004 +0200, Romascanu, Dan (Dan) wrote:
>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
>> >>
>> >>
>>
>>