> 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?
This is an interesting case which probably deserves discussion on
brussels-dev. How many of these global configuration items do you have?
Are they really link properties which must be the same across all links,
or are they service properties that you've chosen to model via dladm?
> 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?
I don't believe so.
> 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.
It's fine to have link properties which only apply to specific classes of
links; see the existing prop_table[] in linkprop.c.
> 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.
Right, a "phys" class link remains one regardless of whether it's placed
into an aggregation.
--
meem
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
