FW: LLDP port ids

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

Hi,

I wasn't involved in the PTOPO discussions on this point, so I'd
appreciate any input from the mib doctors.

Thanks,
dbh

-----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
> > 
>