[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
FW: RE: LLDP port ids
Hi,
I think DP has a good point about the (possible) usage for ifAlias. At a
minimum, we cannot be dependent on ifAlias being a good identifier of
the local port, since its actual usage will be based on administrator
preference. If it is set to the WAN circuit ID or to "the CTO's office",
that won't be very helpful as a portID.
I think that ifName as the portID may be the better choice. ifName is
likely to be initially populated by the agent so it may be more useful
for out-of-the-box discovery. It will be scoped by the ChassisID TLV in
LLDP, so local uniqueness of the PortID is adequate. Any changes are
likely to occur at reboot, while links are inactive, rather than via an
SNMP SET which may occur while a link is active.
Neither is ideal, each having some aspects that may or may not quite
meet current LLDP requirements, depending on some implementation and
deployment decisions, but I think ifName may meet the LLDP requirements
better than ifAlias.
I think we need to do an analysis of the current LLDP requirements and
determine whether we need all the LLDP requirements that are currently
stated, whether ifName or ifAlias best meets the surviving requirements,
and document expected behavior when ifName/ifAlias hit the edge cases.
dbh
> -----Original Message-----
> From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com]
> Sent: Wednesday, February 25, 2004 3: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
> > >>
> > >>
> >
> >
>