On Fri, Sep 23, 2016 at 12:54 PM, Ansis Atteka <aatt...@nicira.com> wrote: > On Fri, Sep 23, 2016 at 1:12 AM, pravin shelar <pshe...@ovn.org> wrote: >> On Thu, Sep 22, 2016 at 11:59 AM, Ansis Atteka <ansisatt...@gmail.com> wrote: >>> >>> >>> On 20 September 2016 at 20:52, Pravin B Shelar <pshe...@ovn.org> wrote: >>>> >>>> OVS IPsec tunnel support has issues: >>>> 1. It only works for GRE. >>>> >>>> 2. only works on Debian. >>>> >>>> 3. It does not allow user to match on packet-mark >>>> on packet received on tunnel ports. >>>> >>>> >>>> >>>> >>>> Therefore following patch provide alternative to completely >>>> disable ipsec-tunnel support by vswitchd command line option. >>>> This way user can use external daemon to manage IPsec tunnel >>>> traffic and stir it using skb-mark match action in OVS bridge. >>>> >>>> >>>> This patch deprecates support for IPsec tunnel port. >>> >>> >>> There are other alternative solutions worth to mention: >>> 1) remove the special meaning of skb_mark bit #0 and update >>> ovs-monitor-ipsec not to depend on harcoded skb_mark value at all (I think >>> this can be done with some trickery); >> >> I am not sure what does this mean. How are you going match on IPsec traffic? >> >>> 2) allow users to chose OVS mode where OVS can be explicitly told to either >>> use skb_mark for its own needs (e.g. IPsec) OR to pass skb_mark to OpenFlow >>> pipeline as-is; >> >> This was basically this patch does but I have sent another patch to >> just deprecate IPsec support. I have mentioned reasoning for the >> change there. >> >> http://openvswitch.org/pipermail/dev/2016-September/079770.html >> >>> 3) leave bit #0 assigned to IPsec and let OpenFlow to match only on bits >>> #1-32. >>> >>> Your solutions is kinda like 2), except it discourages uses to configure OVS >>> in a way where it consumes skb_mark for itself. >>> >>> I think solutions 1) could be implemented even after your patch. Except, >>> maybe then we should not mention that IPsec will be deprecated in the next >>> release. Also, I would need to think how to address corner cases if >>> ovs-monitor-ipsec can't use skb_mark anymore. >>> >>> Solution 3) would be great from ovs-monitor-ipsec perspective because it >>> would not need to change. However, it possibly would make OpenFlow skb_mark >>> matching look weird compared to other fields that OVS can match on. >>> >> >> I do not like solution 3. It does not allows OVS user to use all bits >> of skb-mark even when there is no IPSEC involved which is what linux >> networking stack provide. > > The reason why IPsec needed this one skb mark bit was because, > otherwise, Linux IP stack (in particular "xfrm lookup" hook - > https://upload.wikimedia.org/wikipedia/commons/3/37/Netfilter-packet-flow.svg) > really does not have slightest idea whether GRE packet came from gre > or ipsec_gre port. > > If this bit is taken away from ovs-monitor-ipsec, because we want OVS > users to be able to use all 32 bits of skb mark in an arbitrary > manner, then, yes, ipsec_* tunnel support must be removed, because, > then from Linux IP stack point of view ipsec_gre and gre would look > the same. So let's just move on with your patch then. > I am not objecting to use one bit for IPsec tunnels. That is required to make IPsec tunnel work on linux. My proposal is to let user set skb mark using open-flow pipeline. So that he has complete control over all bits in skb-mark. In this scheme user configure skb-mark and xfrm to implement IPsec tunnels. OVS does not need to support this port type.
> I guess you will send V2 after addressing implementation related > comments that I had? I have posted another patch to deprecate IPsec. http://openvswitch.org/pipermail/dev/2016-September/079770.html _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
