Message-ID: <CAKLmikPUo9JTrarmkG66FLurLS2TAwbhDNJA9RB+cFDo7odpFg@mail.gmail.com>
Date:	Sat, 10 Mar 2012 19:08:29 -0800
From:	Mitar <mmitar@...il.com>
To:	Benjamin LaHaise <bcrl@...ck.org>
Cc:	netdev@...r.kernel.org, Nejc Skoberne <nejc@...berne.net>,
	Jernej Kos <kostko@...matrix-one.org>, gw.2012@...de.com
Subject: Re: Ethernet-over-UDP virtual network interface

Hi!

On Sat, Mar 10, 2012 at 9:06 AM, Benjamin LaHaise <bcrl@...ck.org> wrote:
> To be honest, I don't see any new stateless protocol actually being widely
> supported.

Yes, I agree. This is probably because our use case is quite specific:
using consumer low-price range network equipment without any dedicated
network chips and so on. So simplicity is much more important to use
than, for example, security (which we do not care much on VPN links
because we already have everything open in the mesh so anybody can
capture or inject packets already, so there is no big reason why to do
any encryption or authentication (on the link level) on VPN links.

> Building a completely proprietary solution (regardless of it
> being open source or not) that isn't supported by any common hardware or
> software networking platforms will paint yourself into a corner when it
> comes time to upgrade the network with additional capacity.

That's why I am trying to coordinate our efforts with at least Linux
kernel to be included in the kernel. And also, for example, OpenWrt
distribution. Then we will mostly cover all our target devices.

I am not sure what problems do you have in mind for when upgrading our
network with additional capacity?

> If you're using Linux as a router, I'd probably lean towards a VLAN based
> protocol, as anything exotic won't be supported by common nic's hardware
> checksum offloading.

I do not understand what VLANs have with tunneling over the Internet?
We are building a mesh network, we parts of this network, which do not
see each other wirelessly, to connect through VPN tunnels. Because we
have cheap hardware we want simplest (CPU light) VPN solution to
connect those parts over existing infrastructure (read: ISPs).
Furthermore, because nodes are deployed in chaotic and uncoordinated
fashion by volunteers those tunnels have to be self-configuring (or
zero-configuring). We can provide few VPN servers and all nodes then
connect there, connecting nodes connected to them to the rest of the
network.

> Stateless != robust.  To deal with failed links you need some sort of state
> that is maintained by the system to switch over to backup links.

No. This we do on L3 with dynamic routing protocol (like OLSR) which
we are already using because of the wireless nature of our network
(and because nodes are coming up and down as volunteers' mothers pull
out nodes' power supplies when they are vacuuming). So we just need L2
links. If they work (are not firewalled, VPN servers are online, ...)
or not then determines L3 routing protocol and setup routes
accordingly.

> Existing options (MPLS, GVRP, L2TP) can
> all be configured with a minimum amount of state, are widely used for the
> scenario you're describing, and have migration paths when you need to
> upgrade to higher capacity switches/routers.

Will have to check this a bit more. I admit I do not know much about
MPLS and GVRP. But true, state is not so big problem if tunnels can
still be:

- kernel space only
- no encryption
- zero or auto configuration
- one server can accept multiple connections
- using UDP (and not IP) for transport
- of course, supported in Linux kernel


Mitar
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Powered by blists - more mailing lists