Joe, thank you for your clarification, it will significantly reduce ovs tunnel implementation dependency on Linux kernel if we just use udp tunnel in kernel, anyway userspace tunnel implementations are also some duplicates of kernel tunnel implementations less or more:-)
I think it will simplify ovs tunnel implementation and maintenance if we use generic encap & decap framework to do tunnel encap & decap and move such processing into OpenFlow pipeline. -----Original Message----- From: Joe Stringer [mailto:[email protected]] Sent: Thursday, July 6, 2017 10:25 PM To: Yang, Yi Y <[email protected]> Cc: Wieger IJntema <[email protected]>; [email protected] Subject: Re: [ovs-dev] GTP support to OVS upstream On 5 July 2017 at 03:54, Yang, Yi Y <[email protected]> wrote: > I remember OpenFlow 1.6 spec (not finalized) proposes to use OpenFlow actions > to do GTP-u encapsulation and decapsulation, current OvS tunnel > implementation can't support the third kind of use case (don't encap & decap, > just parse, match and forward), MEC (ETSI Molibe/Multi-access Edge Computing) > the third kind of use case. > > I'm wondering if it is feasible to implement a generic UDP tunnel in OvS, let > Openflow do encap /decap/parse&match, now ovs master has fully supported L3 > tunnel port and PTAP(Packet type aware pipeline), we have posted out generic > encap & decap actions implementation, once ovs officially merges them, ovs > can support generic encap & decap action, we can base on them to implement > GTP-u encap & decap, then it will be better if we can implement a generic UDP > tunnel, ovs can add UDP tunnel ports with different UDP port to handle > different tunnel protocol, I think this will be the best way to handle the > aforementioned three kinds of use cases. When it comes to the OVS userspace datapath, this seems like it maps pretty well to how things are already being done. When it comes to kernel APIs though there's a bunch of considerations around minimizing code duplication with the rest of the code, restricting scope/size creep of the module, and expectations of how long the API is supported. I think further discussion is necessary in that space to determine whether the OVS kernel module should really follow this model or not. _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
