Initially I expect every OVN hypervisor in a deployment will have to speak all the tunnel protocols used anywhere in that deployment. If this is a significant limitation in practice then we can arrange for something.
On Mon, Feb 23, 2015 at 03:05:30AM +0000, Elzur, Uri wrote: > Will there be a mechanism to negotiate the Tunnel used? Is a GW > between diff tunnels part of the architecture? > > Thx > > Uri (“Oo-Ree”) > C: 949-378-7568 > > -----Original Message----- > From: dev [mailto:dev-boun...@openvswitch.org] On Behalf Of Jesse Gross > Sent: Saturday, February 21, 2015 12:18 PM > To: Ben Pfaff > Cc: dev@openvswitch.org > Subject: Re: [ovs-dev] OVN to-do list > > On Sat, Feb 21, 2015 at 1:17 AM, Ben Pfaff <b...@nicira.com> wrote: > > On Fri, Feb 20, 2015 at 06:23:32PM -0800, Jesse Gross wrote: > >> On Fri, Feb 20, 2015 at 4:36 PM, Ben Pfaff <b...@nicira.com> wrote: > >> > On Fri, Feb 20, 2015 at 04:03:21PM -0800, Jesse Gross wrote: > >> >> On Fri, Feb 20, 2015 at 3:46 PM, Ben Pfaff <b...@nicira.com> wrote: > >> >> > *** Tunnel encapsulation to publish. > >> >> > > >> >> > We can probably default to GRE. VXLAN is more modern but it only > >> >> > has a 24-bit key. STT has a 64-bit key but it's not ubiquitously > >> >> > available. > >> >> > >> >> What does ubiquitously available mean in this context? Of the > >> >> tunnels we have available (GRE, VXLAN, STT, Geneve), GRE seems a > >> >> bit of an odd choice since I think for most sets of constraints > >> >> you could choose one that is a better fit. (Even Microsoft is > >> >> moving away from it for network virtualization.) > >> > > >> > I only mean that people have to compile a new kernel module to use > >> > STT. > >> > > >> > What tunnel type do you recommend? > >> > >> I guess it depends on how important absolute maximum performance is > >> on the majority of existing hardware. If we're trying to really push > >> things to the limit, then it's hard to beat STT. Personally, I hope > >> that given where we are in the evolution of things and that OVN is > >> still a little future looking that STT isn't really necessary. > >> Possibly an option but not the default. > >> > >> GRE seems suboptimal to me due to the lack of ECMP support and not > >> great hardware support (even if it is present in the chip, it is less > >> exposed externally). > >> > >> VXLAN vs. Geneve are pretty much the same for the basic feature set > >> including hardware offload and ECMP. Obviously Geneve gives you more > >> space and choice for future extensibility. It's not quite ubiquitous > >> yet but the next release of Ubuntu will have kernel support out of > >> the box and expanded OVS userspace support should hopefully be > >> fleshed out more shortly, so I think all of that is OK for the OVN > >> timeline. > >> > >> But you already knew what I was going to say, right? :) > > > > Yeah ;-) > > > > We want OVN to support hardware VTEPs. Has there been any work with > > hardware switch vendors toward Geneve support? Do you think it's > > likely? > > Yes, it's coming. It will take another revision of switch chips though, so it > will be a couple of years. Realistically, VXLAN is the only choice for VTEPs > today. However, I think that VXLAN is probably too limiting for what we want > to do in software, so it seems like we will end up with two protocols in use > for the time being. > > I'm actually not really trying to push my own stuff that much. > However, I think that unless the most important factor is maximum performance > on deployed hardware (STT) or running a single protocol everywhere (VXLAN), > Geneve can match or exceed other protocols on most dimensions. And that's > with what's available today; it will continue to close the gap in the other > areas as time goes on. > _______________________________________________ > dev mailing list > dev@openvswitch.org > http://openvswitch.org/mailman/listinfo/dev _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
