RE: LLDP port ids

["Romascanu, Dan (Dan)" <dromasca@avaya.com>]

Mike,

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. 

Regards,

Dan



> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: 23 February, 2004 4:49 PM
> To: Harrington, David
> Cc: CONGDON,PAUL (HP-Roseville,ex1); Romascanu, Dan (Dan); 
> mreview@ops.ietf.org
> Subject: RE: LLDP port ids
> 
> 
> On Mon, 23 Feb 2004, Harrington, David wrote:
> > (MIB Doctors, this is a discussion of whether ifName or 
> ifAlias should
> > be preferred for use in a link-layer discovery protocol 
> being developed
> > by the IEEE 802.1 working group. See the thread on the end of this
> > message.)
> ...
> > If the information in the reporting mib (e.g. PTOPO) is 
> "rolled up" to
> > higher level managers, however, having portIDs that are not 
> consistent
> > across reboots of managed devices will be potentially 
> confusing; ifAlias
> > would generally provide better interoperability throughout the
> > management system.
> > 
> > Based on this analysis, I recommend using ifAlias.
> 
> The core requirements, if I correctly understand the thread 
> that I have
> snipped, is a port "shall be identified in an unambiguous manner" and
> that a port ID "shall remain constant for all LLDP frames while the
> [link layer] connection remains active".
> 
> It is of course impossible for these requirements to be met by
> ifAlias unless the user (via management software) makes them happen.  
> In particular, 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.
> That would levy some requirements on the user/management software
> in order to use LLDP, but that would not necessarily be wrong.
> 
> However, there is something that does seem to be wrong, and that is
> that an agent is not actually required by RFC 2863 to support
> ifAlias in a meaningful way for any particular interface type.  
> Here is what the object definition in RFC 2863 actually says:
> 
> 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 }
> 
> In view of the last pararaph, it appears to me that there is no
> obligation for an agent to allow ifAlias to be written for any
> particular ifType, and thus could be vacuously compliant with RFC
> 2863 by disallowing all writes to this object and returning a
> zero-length string when it is read, for _all_ interface types.  
> That would make it totally useless for use as a port ID, and if LLDP
> uses ifAlias as such, it would not work with equipment that behaves
> in this manner.
> 
> Mike
> 
>