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. 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. 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. But, if you have a good solution to the first problem while letting ovs create the interface, I'm not at all opposed to it (although I'm not sure I'll be the one to implement it). Thanks, Jiri -- Jiri Benc _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
