tinc devel - Apr 2011 - Suggestion: use Open-Mesh/BATMAN to help with layer 2/3 routing?

http://www.open-mesh.org/

Idea #1: is BATMAN worth considering using as part of the layer 2 routing in 
Tinc?
Idea #2: would it be possible to embed BATMAN as an option to avoid having 
to use Quagga for routing v6 subnets?

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20110428/4c42679e/attachment.html>

On Thu, Apr 28, 2011 at 12:07:01AM -0400, Michael Adams wrote:
> http://www.open-mesh.org/
> 
> Idea #1: is BATMAN worth considering using as part of the layer 2 routing
in
> Tinc?
I do not know if it would improve anything. Also, a VPN is an overlay network,
so it works on top of an already existing network, where you can more or less
assume all nodes can already talk to each other (barring NAT and firewalls of
course). Tinc's internal routing protocol, which is similar to OSPF, is used
only as a fallback for when packets cannot be sent directly to the destination.
This is not something other routing protocols take into account AFAIK (mostly
because they are not designed for overlay networks).

An idea I have is to expose the connections to various other nodes as VLANs on
the tap interface, or creating multiple tap interfaces, so you can run any
routing daemon on top of them, without having to hack an existing routing
protocol into tinc.
> Idea #2: would it be possible to embed BATMAN as an option to avoid having 
> to use Quagga for routing v6 subnets?
Why do you need to use Quagga for routing v6 subnets in the first place? And if
you already run a routing daemon on top of tinc, I do not see why you cannot
use BATMAN on it as well without having to embed it?

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL:
<http://www.tinc-vpn.org/pipermail/tinc-devel/attachments/20110428/015bad95/attachment.pgp>