RE: LLDP port ids

["Harrington, David" <dbh@enterasys.com>]

Hi,

I was not involved in the original PTOPO discussions, and was not
involved in the design of ifAlias and ifName. Because I don't feel
comfortable with my knowledge of the ifAlias vs ifName tradeoffs, I have
also forwarded the question to the IETF mib doctors mailing list for
further input. 

(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.)

In my reading of RFC2863 and 802.1ab_d6, it looks to me like there are
tradeoffs to be considered.

I agree that Marc has some valid points. Then, so does Dan.

An SNMP-writable object will not necessarily remain constant for all
LLDP frames while the connnection remains active (depending on what
active means). The read-only ifName may be more likely to remain
constant, assuming the agent does not change it. However, it is to the
benefit of an administrator to set ifAlias to a unique value and leave
it set, so the likelihood of its changing will typically be limited to
changing it from its initial undefined state to a unique value (or
changing it when a device moves, to encapsulate some location-specific
information in the naming, or similar administrative approach).

The initial value of ifAlias is not unambiguous, but then neither is
ifName, since RFC2863 explicitly says there may be no local name, and
the object will contain a zero-length string. With ifAlias, an
administrator can provide a unique name via an SNMP SET, something an
administrator cannot do via SNMP for ifName. In either case, if the
portID is not unique, then discovery will be impacted. I would expect
that all discoverable ports within a device should have an agent-defined
ifName, while ifAlias would need to be set by an administrator.

There can be multiple interfaces per port, and ifAlias was added to
allow each interface to be uniquely named. Ifname was added to the
if-mib explicitly to make it easier to map between interfaces and
physical ports, by providing a mechanism to identify a many-to-one
interfaces-to-port relationship. IfAlias doesn't necessarily make it
easy to identify the port associated with multiple uniquely-named
interfaces.

ifAlias can be made unique within the managed domain, while ifName is
likely to only be unique within a device, since a device agent typically
does not have visibility of the complete managed domain and thus cannot
ensure uniqueness as easily as an administrator could do. If the first
LLDP TLV is guaranteed to be the Chassis ID and will always be present,
then the portID TLV can be relative to the chassis ID, and the portID
does not need to be unique within the administrative domain, only within
the chassis.  

ifAlias is non-volatile once set; the same does not appear to be true of
ifName. An agent may change the ifName of an interface when the device
is rebooted, but the ifAlias will remain constant once set (unless an
administrator or manager application changes it). Note that ifName
appears to have no constraints about reusing an ifName for a different
interface following a reboot; where a chassis may gain or lose
ports/blades/etc, it may make sense within the device to rename the
interfaces, just as it makes sense to renumber the interfaces. ifAlias
is designed to ensure that the interface naming remains consistent
across reboots, even if the interfaces are renumbered (and presumably
renamed). So for improved interoperability between agent and manager
across device reboots, ifAlias seems the more stable choice of
identifier. 

The question of "active" does need to be resolved. If an interface is
considered active between reboots, then the ability to change the value
with an SNMP SET may be problematic. If rebooting a device causes the
interface/port to stop being "active" then keeping the identifier
consistent across reboots may not be important for LLDP. 

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.

David Harrington            
dbh@enterasys.com
Director, Network Management Architecture
Office of the CTO, Enterasys Networks

> -----Original Message-----
> From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com] 
> Sent: Monday, February 23, 2004 12:17 AM
> To: 'Romascanu, Dan (Dan)'; CONGDON,PAUL (HP-Roseville,ex1); 
> Harrington, David
> Subject: RE: LLDP port ids
> 
> 
> Dan, 
> 
> I trust your interpretation of the arguments in the past.  
> Nonetheless, I
> feel a little exposed here and would be happy to hear more 
> from you MIB
> doctors...    How should I respond?   Marc had some very specific
> explanations of his interpretations.  Were they simply wrong?  
> 
> Paul
> 
> > -----Original Message-----
> > From: Romascanu, Dan (Dan) [mailto:dromasca@avaya.com] 
> > Sent: Sunday, February 22, 2004 6:52 AM
> > To: CONGDON,PAUL (HP-Roseville,ex1); Harrington, David
> > Subject: RE: LLDP port ids
> > 
> > 
> > Paul,
> > 
> > IMO, the answer is no. 
> > 
> > The argument in the mail below seems more related to the 
> > specific interpretation of the meaning of ifName and ifAlias 
> > in the Foundry implementation. There is no requirement for 
> > uniqueness for any of them in RFC 2863, and actually the fact 
> > that ifName is read-only will make changing its value by a 
> > network manager in order to make it unique impossible. 
> > Moreover, the definition of ifName has a local (device) 
> > semantic, while the definition of ifAlias has a network-wide 
> > semantic, the later seems more appropriate for the LLDP goals. 
> > 
> > I do recognize some value for displaying ifName in parallel 
> > with ifAlias, but I think that replacing one by the other 
> > would be wrong.
> > 
> > The issue of ifAlias and ifName was quite widely discussed in 
> > the SNMP community a few years ago. If you would like to hear 
> > more opinions from other 'mighty MIB doctors' we could 
> > forward this question to the SNMP MIB doctors list. 
> > 
> > Regards,
> > 
> > Dan
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: CONGDON,PAUL (HP-Roseville,ex1) [mailto:paul.congdon@hp.com]
> > > Sent: 20 February, 2004 11:36 PM
> > > To: Romascanu, Dan (Dan); 'Harrington, David'
> > > Subject: FW: LLDP port ids
> > > 
> > > 
> > > 
> > > Oh mighty MIB doctors...
> > > 
> > > The fellow from Foundry makes a pretty good point below about
> > > our use of
> > > ifAlias and entPhysicalAlias in LLDP.  The history is that we 
> > > simply took
> > > what the PTOPO group was working on and never questioned it.  
> > > The protocol
> > > they were developing for PTOPO had the same Chassis-ID + 
> > > Port-ID concept we
> > > have in LLDP and they recommended using ifAlias as the value 
> > > for Port-ID.
> > > Should we be changing this to use ifName and entPhysicalName?
> > > 
> > > Thanks,
> > > 
> > > Paul
> > > 
> > > -----Original Message-----
> > > From: Marc Lavine [mailto:mlavine@foundrynet.com]
> > > Sent: Friday, February 20, 2004 1:20 AM
> > > To: CONGDON,PAUL (HP-Roseville,ex1)
> > > Cc: Val Oliva; Ron Lau
> > > Subject: Re: LLDP port ids
> > > 
> > > 
> > > Hello Paul,
> > > 
> > > I'm on the network management team at Foundry, and I've
> > > recently implemented
> > > automated network topology discovery in our management 
> > > application (based on
> > > collecting data from our Foundry Discovery Protocol, which is 
> > > similar to
> > > Cisco's CDP).  I've read portions of the D7 draft of the LLDP 
> > > spec, and I
> > > have some concerns about the types of port IDs which are 
> > > supported.  Perhaps
> > > I'm misunderstanding something, so I'd greatly appreciate it 
> > > if you could
> > > comment on the issues I'll describe below.  (Sorry it's so 
> > late in the
> > > process...)
> > > 
> > > I'm having some difficulty in understanding why ifAlias is
> > > offered as a port
> > > ID type rather than using ifName.   The LLDP spec says "The 
> > > chosen port
> > > shall be identified in an unambiguous manner", and "The port 
> > > ID shall remain
> > > constant for all LLDP frames while the connection remains 
> > > active".  Assuming
> > > a straightforward definition of "active", it seems as though 
> > > ifAlias isn't a
> > > good match, since its value can be changed at any time.  
> > > Perhaps this all
> > > hinges on the definition of "active", but the LLDP spec 
> > > doesn't define it. I
> > > think it would be good for the spec to define what "active" means.
> > > 
> > > The LLDP spec also says "The chosen port shall be 
> identified in an 
> > > unambiguous manner", however, I don't think ifAlias values are 
> > > required to be unique.  (Do most implementations require 
> > uniqueness?  
> > > As one data point,
> > > ours doesn't.)  Additionally, the definition of ifAlias 
> > > states that "On the
> > > first instantiation of an interface, the value of ifAlias 
> > > associated with
> > > that interface is the zero-length string", so the required 
> > > default values
> > > would be useless as LLDP port IDs.  I could see that perhaps 
> > > the rationale
> > > for using ifAlias is that if it has a non-null value, it 
> > > could be nice as a
> > > user-friendly ID, but a strict reading of the constancy 
> > > requirement for the
> > > port ID would seem to preclude its use.  (Am I reading it too 
> > > strictly?)
> > > 
> > > Another option for the port IDs is to use entPhysicalAlias.
> > > This could
> > > provide a greater likelihood of having a non-null string, 
> since the
> > > definition says that for the initial value, the agent "...may 
> > > set the value
> > > to a locally unique default value, instead of a zero-length 
> > > string."  If
> > > entPhysicalAlias is writable, though, it seems to have the 
> > > same conflict
> > > with the constancy requirement that ifAlias does.
> > > 
> > > So, if we were implementing LLDP on Foundry's routers, for
> > > example, and
> > > deciding what to use as port IDs, the available choices seem 
> > > quite limited.
> > > From my perspective, the primary purpose of LLDP is to enable 
> > > automated
> > > discovery of a network's topology, so the uniqueness of port 
> > > IDs and the
> > > ability to correlate the values between neighboring devices 
> > is my main
> > > concern.  Here's how I view the possible types of port IDs 
> > > that we could
> > > use:
> > > 
> > >     - local - not useful for generic multi-vendor 
> topology discovery
> > >     - agent circuit ID - same as for local, since the value
> > > has no strict
> > > semantics
> > >     - network address - not useful for ports with a shared 
> > > network address
> > >                                 (as with our virtual router 
> > interfaces
> > > inside a port VLAN)
> > >     - MAC address - not useful for Foundry's port VLANs 
> > with a shared
> > > network address,
> > >                                 since we also make the MAC 
> > > addresses on
> > > those ports be the same.
> > >     - entPhysicalAlias for backplane components - doesn't 
> > > seem to apply for
> > > us
> > >     - entPhysicalAlias for ports - not guaranteed constant or 
> > > unique unless
> > > we disallow
> > >                                 writing and provide unique values
> > >     - ifAlias - not guaranteed constant or unique
> > > 
> > > So, the only practical option for us that would appear to
> > > guarantee that the
> > > port IDs would be unambiguous would be to use 
> > > entPhysicalAlias for ports,
> > > providing unique values, and disallowing writing.  Having 
> > to disallow
> > > writing to entPhysicalAlias seems undesirable since the main 
> > > purpose of the
> > > aliases is to have them be user-settable.  I suppose another 
> > > possibility
> > > would be to prevent the user from setting any non-unique 
> > > entPhysicalAlias
> > > values, but this adds complexity, and could potentially 
> > > render some of a
> > > customer's existing port aliases invalid.  Attempting to 
> > > strictly abide by
> > > the constancy requirement would be more complicated (for 
> > > example, if a user
> > > wished to move an existing alias value from one port to 
> > > another it would
> > > seem that the connection on the original port would first be 
> > > required to
> > > temporarily become "inactive" (whatever that means ;-)).
> > > 
> > > It seems to me that ifName and entPhysicalName would be more
> > > suitable for
> > > use as port IDs than ifAlias and entPhysicalAlias, even if 
> > > they might be
> > > less meaningful to users (they could still be more 
> > meaningful than MAC
> > > addresses).  Though the definitions of ifName and 
> > > entPhysicalName don't
> > > explicitly say that their values must be unique, the 
> > > description does seem
> > > to imply this, and since these variables are not writable, it 
> > > should be
> > > straightforward for an implementation to ensure their 
> > > uniqueness, at least
> > > for values used with LLDP.  Providing ifName and/or 
> > entPhysicalName as
> > > options for port ID types would avoid the issues with port 
> > > aliases for LLDP
> > > implementers for whom MAC and network addresses do not 
> > provide unique
> > > identifiers.  Also, if LLDP implementers use the port alias 
> > > options for port
> > > IDs without giving careful consideration to the uniqueness 
> > > and constancy
> > > requirements, the result could be implementations which would 
> > > not provide
> > > reliable topology information in certain circumstances.  The 
> > > probability of
> > > making those mistakes with the port name options seems likely 
> > > to be lower to
> > > me, and thus would seem to make it easier for LLDP 
> > implementers to get
> > > things right.  Ideally, I would replace ifAlias and 
> > > entPhysicalAlias with
> > > ifName and entPhysicalName, but if one of the latter were 
> > > simply added, it
> > > would at least provide an alternative that would avoid the 
> > problems I
> > > described here.  (Also, if the more user-friendly port 
> > > aliases were not used
> > > as port IDs, they could still be optionally conveyed via a 
> > > separate TLV
> > > entry, preferably a standard one.)
> > > 
> > > I've also noticed a shortcoming in the definition of MAC
> > > addresses as port
> > > IDs.  Since the ability to correlate port ID values is 
> essential for
> > > automated topology discovery, it's important that the LLDP 
> > > spec indicate
> > > what MIB variables can be used for this correlation.  In the 
> > > case of network
> > > addresses, this might be considered "obvious", at least for 
> > > IP addresses.
> > > With MAC addresses, however, it's a little less obvious in 
> > > cases where a
> > > hardware-provided MAC address is reprogrammed by software.  
> > > An example that
> > > I cited above is Foundry's port VLANs with a virtual router 
> > > interface.  We
> > > reprogram all the ports in the VLAN to share the same MAC 
> > > address.  For LLDP
> > > purposes, a naive implementation might use the hardware MAC 
> > > addresses, since
> > > they'd be guaranteed to be unique. That would probably render 
> > > it unsuitable
> > > for automated topology discovery, since the obvious place to 
> > > look for a MAC
> > > address is in the ifPhysAddress MIB variable, but that would 
> > > be likely to
> > > contain the software-programmed MAC address.  So, I think 
> > > that the LLDP spec
> > > should state that when a MAC address is used as a port ID, 
> > > the value should
> > > be the ifPhysAddress value for the port (unless ifTable isn't 
> > > implemented,
> > > in which case it's a moot point anyway).  (If there was a 
> > standard MIB
> > > variable that provided the hardware MAC address, that would 
> > be a nice
> > > alternative, but I'm not aware of one.)
> > > 
> > > Well, that about wraps it up, and I look forward to your feedback.
> > > 
> > > Thanks,
> > > Marc
> > > 
> > > ----- Original Message -----
> > > From: "Val Oliva" <voliva@foundrynet.com>
> > > To: "Marc Lavine" <mlavine@foundrynet.com>; "CONGDON,PAUL
> > > (HP-Roseville,ex1)" <paul.congdon@hp.com>
> > > Sent: Thursday, February 19, 2004 8:41 PM
> > > Subject: RE: LLDP Now Ready for final Approval
> > > 
> > > 
> > > >
> > > > Paul, we've got some questions about LLDP. Mark feel
> > > > free to ask Paul your questions.
> > > >
> > > > Thanks. Val Oliva
> > > 
> > 
>