[ovs-discuss] MVRP in OVS

Joe Stringer joestringernz at gmail.com
Fri Mar 28 00:26:58 UTC 2014


Ah, so on 2.0 I think that instant_stats_run() would go through and
transact the latest status for the modules every 100ms or so, regardless of
whether anything changed.


On 28 March 2014 12:29, Howard Tsai <htsai at skytap.com> wrote:

> 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/20140328/2cb2cbe4/attachment-0002.html>


More information about the discuss mailing list