Thanks for your feedback. My work is currently based on 2.0.0 so I didn't see the work on connectivity_seq. I will reconsider the design.
On Thu, Mar 27, 2014 at 4:22 PM, Joe Stringer <[email protected]> wrote: > 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
