[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