On Mon, Mar 9, 2009 at 6:48 PM, Peter Memishian <[email protected]> wrote:
>
> > 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?
There are currently 5 of them -- they probably could be classified as
service properties:
tx_interval -- How often packets are transmitted
tx_delay -- The minimum amount of time between successive
transmissions (any changes to
a link's configuration can trigger the transmission of a new packet --
to prevent a flood of packets)
notify_interval -- Minimum amount of time between notification events
(for clients)
tx_hold_multiplier -- Used to compute the ttl value (multiplied by
tx_interval to produce the ttl)
reinit_delay -- Amount of time to wait after a link transitions from
down to up before sending a packet
While in theory these could all be made per link, the problem is the
standard strongly implies they should be global. The LLDP MIB defined
in the standard (which while not being implemented for this project, I
might do as a later follow-up -- unless someone else feels like
tackling it :) ) actually requires this to be the case (as it exposes
those values).
If we add a custom system description string, that'd be 6. The
proposed design is that they all live in a single SMF property group,
so the could be managed there. The thinking though was to allow dladm
to be able to manage all of it.
>
> > 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
