[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RE: LLDP port ids
I've been offline for awhile, so sorry if someone has already answered these
questions...
In my experience, links tend to come up and go down quite often, and they
aren't always connected to the same devices after these events, especially
at the edge of the network. We are covering many more topology cases than
routers connected with point-to-point WAN links. A manual configuration of
'what is on the otherside' has dubious value in these dynamic environments.
LLDP handles shared media cases by creating a remote structure for each
device discovered on a link. The process is very similar to what was being
proposed by the PTOPO group in the PDP drafts that never were progressed.
Paul
> -----Original Message-----
> From: David T. Perkins [mailto:dperkins@dsperkins.com]
> Sent: Wednesday, February 25, 2004 10:41 AM
> To: CONGDON,PAUL (HP-Roseville,ex1)
> Cc: mreview@ops.ietf.org; mlavine@foundrynet.com
> Subject: 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
> >> > >>
> >> > >>
> >> >
> >> >
> >>
>