RE: LLDP port ids

["C. M. Heard" <heard@pobox.com>]

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