[ovs-dev] OVN to-do list

Elzur, Uri uri.elzur at intel.com
Mon Feb 23 03:05:30 UTC 2015


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-bounces at openvswitch.org] On Behalf Of Jesse Gross
Sent: Saturday, February 21, 2015 12:18 PM
To: Ben Pfaff
Cc: dev at openvswitch.org
Subject: Re: [ovs-dev] OVN to-do list

On Sat, Feb 21, 2015 at 1:17 AM, Ben Pfaff <blp at 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 <blp at 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 <blp at 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 at openvswitch.org
http://openvswitch.org/mailman/listinfo/dev


More information about the dev mailing list