On Tue, Mar 10, 2009 at 2:12 AM, Peter Memishian <[email protected]> wrote: > > > > 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 > > Most of those seem pretty low-level; do you think an administrator will > need to tune them? Under what situations? How will they know how to > properly set them? Does the standard require they be tunable? As you > probably noticed, with Brussels we're trying to reduce the number of > fiddly tunables for a variety of reasons.
The standard implies they should be tunable (and in fact requires they be exposed via the LLDP MIB), though I really can't see a huge need to adjust them. The only real scenarios I can come up with is where something is depending on the information and wants quicker convergence than the default 30 seconds, or if someone has a large number of hosts connected to a dumb switch (that doesn't have the intelligence to not forward on the packets) and wants less frequent updates. However, some of the other discussions have brought up a related point. There are some things that probably should be tunable that would be global in nature. For example, the system description should probably be something that an administrator can override the system default, but should be global. Another example that might come up in the future (I'm not planning to implement this initially, but might do so as an follow-on project) is the LLDP MED extensions for VOIP -- they define a number of bits such as asset tag values, asset location, etc. that should be global in nature but cannot easily (if at all) be derived using existing interfaces -- they more or less have to be administrative set (thus need an administrative interface to manage them). > > -- > meem > _______________________________________________ storage-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/storage-discuss
