Re: [PATCHv4] net: Add batman-adv meshing protocol

[Simon Wunderlich <simon.wunderlich-Y4E02TeZ33kaBlGTGt4zH4SGEyLTKazZ@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

Hello,

thank you for your comments. As already said, splitting batman-advanced into
a kernel space part for switching and a user space part for making route
decision is an already discussed idea which is quite interesting. I wouldn't
say that it's completely unusual to decide routing in the kernel, as we see
other mesh protocols like 802.11s/HWMP or STP (not really a mesh protocol)
integrated in the kernel as well. We have discussed a possible openvswitch port
internally with some of the main contributors, and we see the following issues:

Looking at openvswitch, it seems that the target application is very different.
batman-adv is targeted to support 802.11 WiFi networks on low-end hardware, while
openvswitch was designed as switching environment for virtual machines. This
implies different design decisions - batman-adv should be able to run without any
additional userspace applications if needed, while openvswitch comes with quite a
big, rich featured environment required for operation.

Next to this fact, one thing which worries us is that openvswitch seems to
replace quite some standard linux tools/facilities (e.g. the bridge module),
which is often used in most of the APs we have seen, along with ebtables and
the configuration interfaces it provides. Changing to openvswitch would imply
to change the configuration interfaces and firmwares plus educating all our
users which depend on those standard tools.

Porting batman-adv to the openvswitch framework would of course require an
enormous effort itself. batman-adv as a software which is already "finished",
well tested and integrated in various products/firmwares and ready for kernel
integration. Porting to openvswitch would mean a step backwards for our project
as it is not predictable for us when openvswitch will be finished or integrated in
the kernel.

Maybe we should move forward in this direction after openvswitch is settled as
the way to go for layer 2 tunneling/abstraction in the Linux kernel, but
currently we don't see the benefit for us to port it.

best regards,
    Simon    

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]