On Thu, Feb 02, 2017 at 02:51:19PM -0400, Raymond Burkholder wrote: > > > > 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. > > Yes, I can see how it works with both containers and VMs. Examples for both > might be useful, but if time is short, it isn't completely useful. Veth > seems to be a common use scenario, but if something like macvlan or ipvlan > or others are alternate choices, examples with those might be useful. I > havn't quite figured out use-cases for those, if they do exist. > > But that wasn't quite where I was going. I am using OVS in a routing / > switching use-case for the physical network. I am trying to come up with an > appropriate controller solution for the openflow aspects of OVS when using > routers to connect hypervisors together. I'll expand on this more below > where you ask a different question. > > > > > > > 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. > > Yes, ECMP doesn't make sense at the logical level. But at the physical > level it does. Which I'll expand on for one of your other comments. > > > > > 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? > > The support I am thinking of adding is for OVN control of a physical > network. Which couldn't be explained in a tutorial, because I don't think > that exists yet. > > > > > > > As a solution, I have been thinking along the lines of adding > > > > additional smarts to the OVN controller. > > > > > > > > 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 > > It is the 'until now'. Maybe now is good to start thinking about that > interaction. Unless the interaction is not appropriate and operators deal > with in a different way? > > > 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. > > yes > > > 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 > > How do you currently see that happening in networks of today? > > > conclusion. > > I think the key here is that I'm trying to build the innards of the 'black > box' you mention. Ie, openvswitch supports openflow. Openflow can be used > in the physical network to support packet routing/switching from one end of > the network to the other (the black box). But openflow needs some kind of > controller. Either a central one, or a distributed one, or a combo one > (central controller talking to distributed agents for each switch/router, > much like the OVN controller/agent scenario currently implemented for > virtualization). > > I looked at a number of controllers: frenetic, faucet, ryu, ... > > Ryu came closest to meeting my needs, but would require quite a bit of work > to implement a controller/agent strategy. > > But having looked at OVN, and how closely it ties to OVS/openflow, I am > thinking that there might be a way to extend OVN such that it can support > the black-box, ie, the physical network which transports those packets. > > The reason I am bringing this up is that there appear to be various work > arounds to get redundant gateways to the physical network implemented for > OVN. I'm thinking that if we integrate the physical network into the > solution, the redundant/load-balanced gateway problem goes away. > > The way to make it go away is to have the main OVN controller make a > determination of how to load balance traffic, and as part of that, determine > appropriate exit and entry points for traffic. > > For example, if a hypervisor has two routed ports to two layer 3 switches > (for resiliency and redundancy), OVN and its agents can assign certain flows > to one exit port, and other flows to the other port. And then in the core, > more balancing and routing and switching can be performed. And when it > reaches the edge or another hypervisor, the opposite happens. > > So OVN wouldn't necessarily be only about dealing with encapsulation. It > would also be about routing and flow handling end to end. I am thinking > that way because it has already been designed as a controller / agent combo, > which, in itself, provides some safety features: if the controller goes > down, local agents can continue their control based upon the last > information they received. And if a local agent goes down, well, other > agents on other devices are still operational. > > Bottom line, is there room for black box control? How do other operators > handle black box control? > > > > > > > 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. > > Well, the talk would try to flesh out the thoughts about the above. The > above could possibly be the talk proposal ;-) The stuff mentioned above are > ideas still in the conceptual stage. If that is appropriate for this venue.
Thanks for the talk proposal. I've added it to our spreadsheet. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
