RE: LLDP port ids

["CONGDON,PAUL (HP-Roseville,ex1)" <paul.congdon@hp.com>]

David and MIB docs,

Thanks for the detailed analysis.  A couple of comments...

What needs to be unique in LLDP is the MSAP identifier which is the
concatenation of the Chassis ID and the Port ID, so the Port ID only needs
to be unique within the chassis, not the entire network.

It would seem appropriate to support the concept of multiple logical
interfaces over a physical interface, so a single physical Port ID would not
be enough

The concept of 'active' relates to the presence of the MSAP identifier in
the remote systems database.  The downside of changing the port ID while
leaving the link connection alive is that a new MSAP identifier will appear
and the old one will simply age out.  This would likely cause an event on a
NMS, but it is by no means a catastrophic issue for network operations.

Being able to set ifAliase also appears to be a strong argument for using it
since there is a way to have an administrator address the problem of
uniqueness.

I vote for ifAliase as well.  I'm assuming the Entity versions of Name and
Alias have similar semantics?

Paul

> -----Original Message-----
> From: Harrington, David [mailto:dbh@enterasys.com] 
> Sent: Sunday, February 22, 2004 11:33 PM
> To: CONGDON,PAUL (HP-Roseville,ex1); Romascanu, Dan (Dan)
> Cc: mreview@ops.ietf.org
> Subject: RE: LLDP port ids
> 
> 
> 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
> > > > 
> > > 
> > 
>