Hi Andreas,
Thanks for your detailed information. They are very helpful!
On 4/22/17, 7:36 AM, "Andreas Schultz" aschultz@tpip.net wrote:
No. lw-tunnel use netlink attributes to store the tunnel destination. The netlink attributes can then be attached to a routing entry. That way it becomes possible to have tunneling information in the routing table or pass them into the kernel module from another source, e.g. from a OpenFlow rules in OpenVSwitch. This would make it possible to use OF rules to put traffic into GTP tunnels.
The existing genl interface could be added to iproute2 with or without libgtpnl and is completely independent from the lwt support.
My understanding is that the netlink attributes used by lw-tunnel are natually supported by iproute2 or Openvswitch, e.g.
ip route add 40.1.1.1/32 encap vxlan id 10 dst 50.1.1.2 dev vxlan0
The genl interface is customized for libgtpnl. Having one of two interfaces should be enough to manage GTP tunnels from userspace. Is there a reason that we prefer one over the other? Specifically, why do we use genl instead of netlink, and why use a customized userspace library instead of iproute2?
The last time I tried to push those change upstream they got rejected by Pablo. One of the reasons is that I had to change the API ever so slightly. Still, this violates the rule that kernel API can not be changed, never, ever.
Is the “kernel API” referring to the genl interface?
The other thing is that is has become clear that Pablo's idea of how the GTP implementation should work in terms of APIs is completely different from my ideas. Pablo's (and other kernel developers) seem to prefer a implementation where static tunnels can be configured. That mean the kernel own's the GTP tunnels and the interfaces and operates completely independent from the user space control interface. The user space entity could then be restarted without loosing the tunnels.
I believe that the user space entity should own the sockets and tunnels and that a termination of the user space control instance should automatically remove all existing GTP tunnels (having GTP forwarding without the control context is IMHO not a valid state for any of the 3GPP GTP gateways).
In my opinion, both design looks reasonable as long as one entity owns all the state, either it’s the kernel or a user space control process. However, I believe that GTP is just one of the many tunneling protocols supported by Linux. Thus, it should have consistent behaviors comparing with other tunnels. Seems for most tunnels, the kernel maintains the state and expose management interface to userspace programs; control processes are mostly stateless.
Nevertheless, “a termination of the user space control instance should automatically remove all existing GTP tunnels” is a valid point. I think this could be implemented in the exiting procedure or destructor of the control process, while carefully taking care of the process crashing case.
Regards Andreas
Regards, Jiannan