For what it's worth, there's at least some LACP/STP state that is propagated to OVSDB, which is done through the connectivity_seq mechanism. Status changes cause this seq to be updated, then instant_stats_run() fetches the status for various modules and transacts them.
On 28 March 2014 11:32, Howard Tsai <[email protected]> wrote: > Our application doesn't need to expose MVRP state to a controller. > However, my concern of storing MVRP state in OVSDB is that, at least > theoretically, VLAN topology changes can happen frequently (as well as > changes in other MRP participant state, i.e., MMRP, MSRP, once these > MRP-family protocols are implemented.) As ovs-vswitchd is currently > implemented, if I understand it correctly, a change in OVSDB will trigger > reconfiguration of every Open Flow port, which is quite expensive. MVRP > state don't need to persist across switch restart. Moreover, LACP/STP state > are not in OVSDB, either. In this case, is storing MVRP state in OVSDB > still a good choice? > > Thanks, > Howard > > > On Thu, Mar 27, 2014 at 2:36 PM, Ben Pfaff <[email protected]> wrote: > >> On Thu, Mar 27, 2014 at 10:41:40AM -0700, Howard Tsai wrote: >> > One thing I am curious about is the exposure of current VLAN topology >> from >> > ovs-vswitchd. >> > >> > Currently, ofbundle registers a set of callback functions with MVRP. >> MVRP >> > calls these functions to adjust VLAN membership. I.e., OVSDB doesn't >> have >> > the current VLAN topology declared by MVRP. To compensate, I >> implemented a >> > unixctl cmd "mvrp/show" to show MVRP state. >> > >> > My questions are: >> > 1. Is this the preferred way to expose protocol state? Any >> > suggestion/pseudo standard on output formatting? >> >> Is the VLAN topology something that a controller would likely be >> interested in? If so, then I think that exposing it in OVSDB, perhaps >> as a column in the Port or Interface table, would be appropriate. (I >> don't know much about MVRP, so I don't know what is correct >> conceptually.) >> >> If the VLAN topology goes in the database we probably don't need it via >> unixctl. >> >> > 2. It seems that OF-Config should be extended to include MVRP as one of >> > OpenFlow Port Feature and VLAN configuration in OpenFlow Port State. >> Any >> > thought on that? >> >> Do you mean OF-Config or OVSDB? Open vSwitch doesn't include an >> OF-Config implementation. I think we already covered OVSDB, above. >> > > > _______________________________________________ > discuss mailing list > [email protected] > http://openvswitch.org/mailman/listinfo/discuss > >
_______________________________________________ discuss mailing list [email protected] http://openvswitch.org/mailman/listinfo/discuss
