[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
>>
>>