New subject: [Mesh] From libre-mesh

29 Jul 2013

-----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-clou… 
   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(a)lists.sudoroom.org http://lists.sudoroom.org/listinfo/mesh

- -- 
./p4u
...PGP SIGNATURE...
-----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----- 

Re: [lime-dev] [Mesh] From libre-mesh