[ovs-discuss] MVRP in OVS

[Howard Tsai]

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 <joe at wand.net.nz> 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 <htsai at skytap.com> 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 <blp at nicira.com> 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
>> discuss at openvswitch.org
>> http://openvswitch.org/mailman/listinfo/discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://openvswitch.org/pipermail/ovs-discuss/attachments/20140327/d3b744fe/attachment-0002.html>