[Mesh] From libre-mesh
Pau
pau at dabax.net
Mon Jul 29 03:29:25 PDT 2013
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi.
First of all, running layer3 protocol over layer2 protocols would be
completely stupid, so just discard this idea.
The Isaac explanation is right. But as said the scope of libre-mesh is
to be compatible with most of the possible scenarios, so what Isaac
said is just one of the models libre-mesh will be able to support.
Another scenario (the one I like more) is having small batman-adv
communities (let's say a building, a neighborhood or maybe a
district). These communities are connected with other communities
using layer3 protocol (such as BMX6). So at the end you can end-up in
a city with 20 bat-adv clous connected all of them with BMX6.
The selection of the border-nodes have to be made automatically (to
scale better and to be as easy as possible for the normal user). So
there will be a mechanism to discover if a node is border-node or not
(if it is connecting with another node which is using anode
batmand-adv ID**). It can be achieved by a very simple protocol based
on ICMPv6.
So, once a node see that he is a border node, it starts BMX6
automatically to start sharing routes between both batman-adv clouds.
Following this approach libre-mesh will be able to cover both
scenarios depending on the user needs:
- - A big bat-adv cloud for all the city (if batman-adv ID is the same
for all nodes).
- - A lot of small bat-adv clouds connected with BMX6 (each small
community decides the batman-adv ID to isolate from other small
communities).
At this point I believe you understand why using a mesh dymanic
routing protocol instead of BGP.
Please, take a look again on the diagrams I included in my first mail,
they are trying to explain it.
** batman-adv ID is the VLAN tag used to isolate clouds
Cheers
On 29/07/13 05:09, Mitar wrote:
> Hi!
>
>> but I don't think you're correct in your assesment of how the
>> system would work.
>
> Probably. :-) I don't have a clear mental picture of it.
>
>> If such a link is persistent, and of a sufficient quality then
>> those node (and only those nodes) would route between
>> communities using bmx.
>
> And why not just BGP? So why using a routing protocol which was
> optimized for wireless links to run over something which is not a
> wireless network anymore (but an abstracted L2 Batman network,
> which might be somewhere deep in a wireless network, but none of
> this is seen to BMX)?
>
> The only thing you need is "network is available"/"network is not
> available" announcements which knows how to read Batman community
> IDs, no? You don't really need packet loss measurements for
> wireless links?
>
> Can Batman on one node participate in multiple communities at the
> same time?
>
> Have you seen this?
>
> http://www.open-mesh.org/projects/open-mesh/wiki/Connecting-Batman-adv-clouds
>
> So I do understand that you need some kind of L3 routing protocol
> on borders between L2 routing domains. But I am not exactly sure
> how this would work as a generic auto-configuring firmware. For
> example, if we have two L2 mesh networks:
>
> ------------ ------------ |
> [gateway1a]--link A--[gateway2a] | | mesh 1 |
> | mesh 2 | | [gateway1b]--link B--[gateway2b] |
> ------------ ------------
>
> I am not sure how could gateway1b and gateway2b be one device, one
> node? And with an auto-configuring firmware?
>
> Both mesh 1 and mesh 2 are big L2 blobs. What I can understand is
> that gateway1a and gateway1b is part of mesh 1. And gateway2a and
> gateway2b part of mesh 2. They have between them each a special
> network link, respectively. So gateway1a/b have their own IPs
> inside mesh 1 and they also have IP inside the peering links. Same
> for gateway2a/b.
>
> So I know how to configure this manually. But I am not sure how
> BMX6 running on gateway nodes can just discover this automatically?
> And even more, how it can know over which link to route traffic?
> Link A or link B? It does not have any special knowledge of how
> well gatewa1a or gateway1b is connected to the rest of mesh 1. But
> even if we ignore that (which is really a hard problem to solve),
> the reason why BMX6 would be useful is because link A and link B
> can be of different link qualities and you want to route over
> better one?
>
> And how does BMX6 then propagate this information that link 1 is
> better than link 2 to clients in the mesh network?
>
> And still, how you configure those links automatically?
>
>> I agree strongly that the way to encourage adoption is to build,
>> use, and demonstrate. At the same time, we will make much more
>> progress if we can find ways to collaborate. I tend to agree with
>> the comments regarding in-person collaboration. Perhaps it would
>> be possible for you to come and talk things over when Pau and
>> Roger are in the states?
>
> I agree that discussion in person can help. But sooner or later we
> have to write something down. If you already have clear image what
> you want to build, then just write this down. Discussions are
> important if we need to create a solution. But in this case you are
> saying that you already have a solution. Can you just write this
> down?
>
>
> Mitar
>
- --
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)
iQEcBAEBAgAGBQJR9kQFAAoJEAX7rWpc+YnNcwkIAIpBZoUfoWj+hylKPITGBMv7
zBh/TUufvPBkCl12Nf5W5dUDT1jqYnpYC07Kp7i/Iujwh3ii5WofIXQ8b3C878ux
WQJ6eVyqjtyAk7oyH8G2UfJBOrK4vsLhXNugUbcaL5gQcHjqTAXQMAdbywW/q9vY
oIAVCjLHvAu65X72VsFfvVFcLB0ZoNY2YJpyfCE/+21nwABsjdKwQHCL8yfH+ctM
raUEJ2KAFkmnCDHsjQj9FTu2eazBVaJ5gnqGS8Z9hWpBbE5gygeymQO724YR2M2E
3lEJPdgsb4/DmGQjnWP0rb5quklK7jZEvlkCwUxc68/JcK3F0qnscTqLavMQ2/I=
=RyzU
-----END PGP SIGNATURE-----
More information about the mesh
mailing list