[ovs-discuss] Open vSwitch Open Source Days at OpenStack Summit Boston, May 8-11: call for participation

[Ben Pfaff]

On Thu, Feb 02, 2017 at 08:05:25AM -0800, Ben Pfaff wrote:
> [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, 

Do you mean, as opposed to container systems, or as opposed to something
else?  OVN is meant to support both VMs and containers, in essentially
the same way, so probably when we design the tutorial we should cover
both.

> > and 2) ecmp / routing still needs to be defined/implemented.

I guess that you do not mean this comment for logical networks, since
OVN already supports logical routing and because ECMP does not really
make sense at the logical level.

So I guess that you must be talking about ECMP and routing at the
physical level.  What support do you think that we should add?  Or do
you mean that we should explain in the tutorial how they interact with
OVN?

> > 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, ....

Until now, OVN has not interacted much with the physical network.  It's
generally considered as a black box.  The idea is that OVN simply
addresses a tunnel packet to an IP address and the physical network is
responsible for delivering it to that IP address in a robust, efficient
manner.  It sounds like you'd like OVN to support being more tightly
bound to the physical network.  Probably, you should say more about how
you want that to happen.  I do wonder whether it's really something that
needs to be integrated into OVN at all, because I think that most of the
possibilities could be implemented without OVN's participation, but
certainly that's just a question and not a conclusion.

> > 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.

Would you like to propose a talk?  I'd love to hear a talk on the topic.