27 Jul
2013
27 Jul
'13
11:54 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Well, this kind of discussions is what I was trying to avoid... but it
is my fault for starting it.
On 28/07/13 01:30, Mitar wrote:
Ask yo AlterMesh guys who are starting having problems with
scalability. Can you imagine which is the total amount of ARP packages
in a 1000 nodes bat-adv cloud? (just to put an example)
Quagga is a suit which includes several routing protocols. Quagga
could be used to federate bat-adv and bmx6. But if you are speaking
about use static routing, I would just say it is a big mistake (what
happens when you have to paths to the same cloud?).
I agree with your approach about compare overhead and routing changes.
However I can say this test was made during the WCW-Berlin. The
scenario was around 15-20 nodes (ask UFO to to know it better) in a
mobile scenario (it means someone moving nodes). All protocols were
running at same time in different VLAN (see battlemesh firmware in
github) so all of them were in the same situation. Just to give you
another detail, the tested protocol which showed more difference
between moving and not moving environment was Babel.
By the way, the conclusion of this tests was: BATMAN based protocols
are better in the overhead-mobile test.
Hi!
It is exactly what we are doing. Please see our repositories you will
find lime-packages which is an OpenWRT feed.
The idea is to make a meta-firmware which can be
used as basis
to create specific community firmwares. The project is named
libre-mesh [5].
To throw a ball back at you: why another meta-firmware? We already
have OpenWrt. Why libre-mesh cannot be just one package for
OpenWrt, which configures and depends on anything you believe
should be there? Then other communities can just fork that package
and adapt it. Or just add additional packages. Because I don't see firwmare anything more than
just a list of
packages + configuration + few small scripts. I don't see this as
such big additional split of work as you are describing. Or is
there more to firmware development?
Well, I would not say "few small scripts", it is a bit more than that.
I don't know about which firmware are you speaking about but in my
experience if you want to end up in a stable, powerful and flexible
system you need more than "few small scripts".
Batman-adv is
very nice, but you cannot have a single collision
domain cloud for all the nodes because it does not scale.
Have this been proven/shown anywhere? Aren't there Batman-adv mesh
nodes with 1000 nodes in existence (or in fact in Batman-adv you do
not care so much about the nodes, but about number of individual
MAC addresses in the mesh, including clients and anything bridged
to the mesh)? So, the
network have to be splitted in several clouds. To
federate them a layer3 routing protocol is needed, so here is
where we use BMX6 [7].
Why would you need to use BMX6 to federate them? Isn't just Quaga
with Batman-adv on both sides enough on a gateway node between
clouds? Or are you saying that BMX6 should run on top of Batman
clouds on all nodes and not just on gateways? Why? because
BMX6 (100% rewritten fork of Batmand with native
IPv6 support) is very powerful and produces a very low overhead
(see [6]).
But how does this overhead compare with speed of convergence
(adaption to the changes in the mesh). Because overhead is in
general inversely related to speed of convergence. More packets you
send around, higher the overhead is, faster you can inform
everybody that there was a change in topology. So this graph
without a related graph of speed of how fast the routing protocol
adapted nodes is not really useful. So I am interested in a
scenario where somebody is actively talking to a node which is
moving around. If my connection to the node stays working while in
all cases, but one routing protocol has lower overhead to achieve
this, then this is a better routing protocol.
Mitar
Cheers, Mitar. Hope to see you in October.
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9F2YAAoJEAX7rWpc+YnN2/UH/2Jo0bujrjXBwGwN2vP5oi+q
5O5w5jQZ6uQEaeruwEXrmtNeucY1p9yNkXLhxDnSFWYQup4Qt4KvAdJPOQ+/pjBf
7khnwvHgD9Pupce/F8dLbmgrdUTlmThZdrug1EQHPnHwekTHwPO6/DraDYgf6Pzf
NPu0QGQDFi0zk1sBbWxXeizvcmxXhgbID9yptp6p+XIn4wvJkAVw1d3N2jHcUDRe
fg/KBQeUsCqViwMnclylOwS6Q73UpJ6yW4wVAiphwS7KpZHYn+X/yYK0NbD8kQfL
3EtUufaUxoAUgfan1qQJcP8ItEV24ylrnkJTueV06/DP65NS3O2RykfOPwM6Tyo=
=skVf
-----END PGP SIGNATURE-----