On Mon, Mar 9, 2009 at 5:28 PM, Peter Memishian <[email protected]> wrote:
>
> > One other thing I've been thinking about more, or rather I'm still not
> > 100% sold on is the naming of the dladm subcommands (
> > http://www.opensolaris.org/os/project/lld/design/commands/ ) I'm
> > wondering if there might be better names (e.g. 'dladm
> > show-neighbo[u]rs'). I think the separation of operations (i.e.
> > having a command to show the data, a command to start, to stop, etc.)
> > is probably alright, just the names of them.
>
> I'm a bit concerned about having multiple property universes. Is there a
> technical issue with using the existing linkprop facility for holding the
> lldp properties (with an appropriate prefix for the properties to make it
> clear what they're for)? Further, offhand it seems like the information
> shown by show-discovery-stats could be displayed by the existing
> "show-link -s" facility.
One issue for the 'show-discovery-config' option (I'm assuming this is
what you're referring to vs. the peer data) is that there is both
global configuration items that cover all links (and would present
issues with things like the LLDP MIB if they were to be made per
link), and then items that are per link. I think putting the per-link
stuff in with the linkprop stuff would be fine, but then what to do
about the global options? Just leave them in SMF and provide no
separate way to manipulate them outside of svccfg / libscf? Would
that be appropriate?
For the stats, I think show-link -s would be fine. I honestly missed
the existance of show-link -s. Since the source of the LLDP stats
would be different from the rest of the stats shown, would it present
any issues?
One other question with using {get,set}-linkprop or show-link -s, is
the behavior wrt aggregations. Since I've never had an opportunity to
use them at all, I don't have a good understanding of some of the
behavior. In the context of LLDP, each link would still send out /
receive LLDP packets (with the information of their specific link).
If configured, they can also advertise the fact they are configured
within an aggregation (and it's id). As such these would only work
for the underlying links in an aggregation and not on the aggregation
itself. While I suspect this doesn't pose an issue (i.e. calling
{get,set}-linkprop on a link that's participating in an aggregation is
no different than when it's not), but confirmation would be good.
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
