14 Mar
2017
14 Mar
'17
2:39 p.m.
On Tue, Mar 14, 2017 at 01:28:25PM +0100, Andreas Schultz wrote:
----- On Mar 14, 2017, at 12:43 PM, pablo
pablo(a)netfilter.org wrote:
[...]
A GTP entity serves multiple local IP endpoints, It
manages outgoing tunnels
by the local APN/VRF, source IP, destination IP and remote tunnel id, incoming
tunnels are managed by the local destination IP, local tunnel id and VRF/APN.
Therefor a PDP context needs the following attributes:
* local source/destination IP (and port - but that's for different series)
* remote destination IP
* local and remote TEID
* VRF/APN
[...]
I'm not sure if this pseudo GTP entity root device
fits well with
other networking concepts. And more over, I can't really see the need
for such an construct.
Some sort of top-level structure that wraps all these objects is
needed, and that can be a new VRF object itself.
You can add a netlink interface to add/dump/delete VRFs, this VRF
database would be *global* to the GSN. At VRF creation, you attach the
socket and the GTP device. You can share sockets between VRFs. PDP
context objects would be added to the corresponding VRF *not to the
socket*, but actually this will result in inserting this PDP context
into the socket hashtable and the GTP device hashtable.
We need to introduce a default VRF that is assumed to always exist,
and that userspace cannot remove, so things don't break backward. If
no VRF is specified, then we attach things to this default VRF.
Actually, look at this from a different angle: the existing driver is
just supporting *one single VRF* at this moment so we just have to
represent this explicitly. Breaking existing API is a no-go.
This explicit VRF concept would also allow us to dump PDP contexts
that belong to a given VRF, by simply indicating the VRF unique id.
Jamal already requested that we extend iproute2 to have command to
inspect the gtp driver we cannot escape this, we should allow
standalone tools to inspect the gtp datapath as we do with other
existing tunnel drivers, no matter what daemon in userspace implements
the control plane.
[...]
I think that the user space control instance should
own the tunnels and
only use the kernel facility to manage them. When the user space instance
goes away, so should the tunnels.
This doesn't allow daemon hot restart for whatever administrative
reason without affecting existing traffic. The kernel owns the
datapath indeed, that include tunnels.
From that perspective, I want to keep the kernel
facilities to the
absolute needed minimum.
If some simple abstraction that we can insert makes this whole thing
more maintainable, then it makes sense to consider it.
This is all about not exposing the internal layout of the
representation you use for a very specific reason: The more you expose
internal details to userspace, the more problems we'll have to extend
things later on in the future. And don't try to be smart and say:
"Hey, I already know every usecase we will have in the future" because
that is not true.