[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RE: LLDP port ids
DaveP,
I do not say it is not workable. What I am saying is that it seems to fit less the requirements for a unique and non-volatile handler of the interface on the device that LLDP has. ifName is not defined to be persistent, and as it's MAX-ACCESS is read-only, if there is a uniqueness problem, it cannot be fixed in an SNMP framework.
Of course, you can make ifName persistent, and you can always assume that uniqueness is ensured by initial out-of-band provisioning, but none of these are today defined in the Interfaces MIB.
Regards,
Dan
> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: 25 February, 2004 6:29 PM
> To: Romascanu, Dan (Dan); Harrington, David; CONGDON,PAUL
> (HP-Roseville,ex1)
> Cc: mreview@ops.ietf.org; mlavine@foundrynet.com
> Subject: 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
> >> >>
> >> >>
> >>
> >>
>
>