> > > 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ discuss mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-discuss
