On Thu, Oct 1, 2015 at 11:22 PM, Jiri Benc <jb...@redhat.com> wrote: > On Thu, 1 Oct 2015 22:19:10 -0700, Pravin Shelar wrote: >> On Thu, Oct 1, 2015 at 9:08 AM, Jiri Benc <jb...@redhat.com> wrote: >> > This is for IPv4 only at this point. Only vxlan is recognized for now. >> > >> > The usage is as follows: >> > >> > ip l a type vxlan metadata dstport 4789 >> > ovs-vsctl add-port ovsbridge vxlan0 >> > >> > Now, the encapsulation can be specified using ovs-ofctl, e.g.: >> > >> > ovs-ofctl add-flow ovs0 'in_port=2 >> > actions=set_field:2->tun_id,set_field:192.168.1.1->tun_dst,1' >> > ovs-ofctl add-flow ovs0 'in_port=1,tun_id=2 actions=2' >> > >> >> Existing ovs-vsctl add-port command for tunnels should work with >> lwtunnel inetrfaces. So tunnel vport create needs to switch between >> compat vport and lwtunnel interface according to the kernel support. > > I admit one of the intents of this patch was to provoke a discussion. > I expected a similar comment and thought about this; several things are > not clear to me: > > 1. Such interface would have completely different lifespan than the > corresponding ovsdb entry. After reboot, ovsdb entry for the tunnel > is present but not the interface. Who should create it? It can > hardly be ovs-vswitchd, because on ovs-vswitchd restart, the > interface is still there. Trying to recreate it if it doesn't exist > doesn't work either because of name spaces and because there may be > an unrelated interface with the same name but different parameters > (port, especially) created meanwhile. Note this is very different to > internal ports which are created by the kernel datapath. >
I do not think we need to worry about devices in other namespace here. About name conflict I see it as general issue not specific to lwtunnels support. Anyways I do not see problem if interface is already created by external process. I just wanted to point out that existing tunnel port should work with new lwtunnel interface. > 2. How to distinguish whether the kernel supports IPv6 metadata based > vxlan? Kernel 4.3 will include lwtunnel support but ovs IPv6 tunnel > support will be only in 4.4. That means that under 4.3, the creation > of the vxlan lwtunnel succeeds (and would actually do a wrong thing > for IPv6 from the ovs point of view due to patches that are not > going to be in 4.3), yet it won't work for IPv6. > I do not think it is really related to the issue. we need to solve this in any case. > The second point is solvable by introducing a new netlink attributes > that allow user space to query capabilities of the kernel data path. > The question is whether it's worth it, as I don't currently see any > reliable solution to the first problem. > > On the other hand, delegating creation of the vxlan interface to the > user/admin/network startup scripts solves both problems. The current > way of configuration will still work, because the kernel compat nor > user space compat code is not going to go away. The current setups will > still work and those who need new features (like IPv6 support) will > need to switch to the new way of configuration, and that would be > creating the tunnel interface manually. I actually don't see any > problem with that. > Even though the compat code is not going away, I do not expect new features additions to new compat interface, e.g. IPv6 support is not available using compat interface. So we need to use lwtunnel interface for tunnel port. second issue with this approach is there would two VXLAN vports in the datapath if someone configure tunnels using existing and proposed mechanism. This is really confusing when these two interface do not have same features. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
