[ovs-dev] OVN to-do list

[Jesse Gross]

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? :)