[Mesh] From libre-mesh

[Pau]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

CCed libre-mesh mailing list.

On 29/07/13 12:29, Pau wrote:
> 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
> 
> 
> 
> _______________________________________________ mesh mailing list 
> mesh at lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh
> 

- -- 
./p4u
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (GNU/Linux)

iQEcBAEBAgAGBQJR9oH9AAoJEAX7rWpc+YnN4cUH/2MXqLVEQjQMpkEDifKBeA7C
Rpwd0FfYb3xTRqaykK2O0zfS8g5z6KQKjxqw+HEen0VELPNcedeMu2n5AVvsSdvQ
YPwmBgHMeA5WxQUAM5TO+CsF03+veKTkE26ZynVsp2ZQojv/uCa22BustKYZXiZq
hB2o03Rx03JnM6GFB0b4cLzmw3rHWSApuFGj7Fa7uwrdQRrPIW5k12R72zNDJzWT
0EijNQADhSctIhdB2LRpXeYkLbdaSLcseHuY0oAwTfIblbugsgDFnR96iwffXdF+
YeY2YdGQh2uzZsa2PVD4/1DE2iVQf4/J/UCRBWSZSRBLLLMrS5hRwMFLm/tXU78=
=PcuD
-----END PGP SIGNATURE-----