[ovs-discuss] Open vSwitch Open Source Days at OpenStack Summit Boston, May 8-11: call for participation
Ben Pfaff
blp at ovn.org
Thu Feb 2 16:05:25 UTC 2017
[redirecting to ovs-discuss]
Raymond Burkholder <ray at oneunified.net> writes:
> Ben Pfaff <blp at ovn.org> writes:
> > The Open vSwitch project is participating in Open Source Days at
> > OpenStack Summit Boston. During the summit, Open vSwitch will have
> > dedicated use of a room for a full day. We are seeking
> > participation for talks and tutorials for this event.
>
> I went through Dustin Spinhirne's OVN Tutorial. It helped immensely in
> understanding OVS/OVN interactions. And also highlighted some of the
> shortcomings.
>
> Of many, two, possibly related, questions/ideas come to mind. 1) OVN seems
> to be more focused on the hypervisor side of things, and 2) ecmp / routing
> still needs to be defined/implemented.
>
> As a solution, I have been thinking along the lines of adding additional
> smarts to the OVN controller.
>
> I don't quite understand the communication
> mechanisms/lines-of-responsibility between the OVN controller and OVS
> switch, but in talking about this, maybe things will be more clear.
>
> In looking at techniques in Ryu where LLDP and link state can be
> communicated back to a controller so it effectively has an idea of the
> topology of the network. It would be interesting to re-code the Ryu
> examples into an OVN/OVS context.
>
> The topology meta-information could be used to perform some
> max-flow/min-cost calculations. This information could be communicated back
> to the local OVN agent, which could be used to influence the
> routing/flow-control in the local OVS instance.
>
> This then gets OVN/OVS integrated into the over-all network, helps with
> over-all routing decisions (which is known to be lacking), and may help
> resolve some known resiliency/redundancy shortcomings.
>
> Is there general community interest in accepting such a solution? If so, I
> would be willing to start on working on details. If there are members of
> the community who are familiar with the max-flow/min-cost calculations as
> they relate to network flow control, I would really like to hear from them
> about implementation gotchas, improvements, alternatives, ....
>
> Perhaps the Boston Summit could be used to: 1) make a general call to action
> in a talk, and 2) talk in the hallways about the techniques required to
> implement a solution.
More information about the discuss
mailing list