[Mesh] From libre-mesh

Sun Jul 28 15:09:19 PDT 2013

We will all have to take our approaches and see what shakes out. Competition/forks/different approaches are what its all about! :)

Mitar <mitar at tnode.com> wrote:
>Hi!
>
>> BMX routing between batman-adv domains is the way to go. It's a
>> fairly standard network design pattern (l2 edge/l3 agg/dist/core).
>
>This is what you say but I simply cannot agree with that. It is a
>stupid
>approach, if I understand it correctly (running L3 routing protocol
>over
>L2 routing protocol). Write to the Batman mailing list and get
>confirmation that they agree this is the way to go.
>
>> It will become the standard as the FreedomStack sees widespread
>> deployment over the coming months.
>
>I really doubt FreedomStack will see widespread deployment if your
>networking stack will be such a combination. From what I know them,
>nobody will move to that (except those who are already using BMX). :-)
>But good luck making such a standard. Standard is not made by defining
>one, but by using one. Currently, you are not really convincing. When
>asked about some whitepaper explaining your rationale and architecture,
>you are saying that we should call each other and talk. If this is your
>approach to making your firmware popular, then even if the firmware
>scales, your way of promoting it will not scale.
>
>I really hate solutions where people think that because they like
>features of A and features of B, let's just use both at the same time
>and we will have features of A+B. Invest time to or move features from
>Batman you like into BMX or to move features from BMX you like to
>Batman. This is how the progress is done. Don't be afraid to code and
>steal good ideas. This is what open source is about. This is what
>happens between FreeBSD and Linux. Stealing (or rather, should I say
>sharing - because none loses anything) from each other. But if somebody
>would come and say, run FreeBSD and Linux at the same time and you will
>have features of both ... Ehm ... In theory, this is doable. You can
>have multiple kernels loaded at the same time. But how will this
>interact? How much more complications will you have? What is the right
>approach is to take features from one and put it into another.
>
>
>Mitar
>
>> Pau <pau at dabax.net> wrote:
>> On 28/07/13 02:50, Mitar wrote:
>>>>> Hi!
>>>>>
>>>>>> Well, this kind of discussions is what I was trying to avoid...
>>>>>> but it is my fault for starting it.
>>>>>
>>>>> No no. It is important to discuss this things. You cannot just
>>>>> believe that people would just take some firmware without trying
>to
>>>>> understand it and reasons for why something is like it is and not
>>>>> some way around? So don't see this as a flame but more as a way to
>>>>> teach/show.
>> 
>> Of course people should ask and understand before choosing some
>> specific existing solution. But I did not want to start this kind of
>> discussion here (in this post). I just wanted to let you know about
>> libre-mesh project.
>> 
>> Also I feel like you are trying to find some "week points" in our
>> approach to be able to say "it does not work for us" and I have to
>> defend it to convince you. I don't feel comfortable doing this, I
>just
>> wanted to let you know about libre-mesh because I have seen in your
>> WiKi many points in common with us. But of course the decision is
>> yours.
>> 
>>>>>> It is exactly what we are doing. Please see our repositories you
>>>>>> will find lime-packages which is an OpenWRT feed.
>>>>>
>>>>> Great!
>>>>>
>>>>> This maybe means that talking about "firmware" is not the right
>>>>> word. But more about a set of packages? Because then it is easier
>>>>> to imagine that another community network takes few of those
>>>>> packages and add few theirs and maybe even then put them all
>>>>> together in one feed for later community network to build upon.
>> 
>> I like "firmware" more than "set of packages" because at the end
>> libre-mesh will be a firmware (software for embedded devices). But
>OK,
>> it is just a way to refer to the same thing.
>> 
>>>>> So I think the most important thing is not to see firmware as one,
>>>>> but to learn which problems/issues you already solved with which
>>>>> packages and see how to build upon that and contribute back, no?
>>>>>
>>>>>> 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".
>>>>>
>>>>> Can you maybe just show us few examples of such scripts? Just so
>>>>> that it is easier to imagine what kind of things one have to think
>>>>> about when developing a firmware?
>> 
>> It is not yet done in Libre-Mesh because it is in development. But
>you
>> can surf over the qmp.cat git repository to see the amount of code we
>> have (just the luci-based web iface is more than a "few scripts").
>> 
>> If you want to do a generic solution (like libre-mesh) you need a lot
>> of code to adapt to any scenario. But of course, if you want to have
>a
>> solution just for your network, the amount of code could be quite
>> small.
>> 
>>>>>> 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)
>>>>>
>>>>> So only ARP packets are the issue. Other broadcast packets you can
>
>>>>> simply drop with a ebtables firewall rule. You can still use
>>>>> ZeroConf, because it is multicast and not broadcast.
>> 
>> Using ebtables is dirty and a patch to solve something that layer3
>> solves. And have you thought about IPv6? It does not have broadcast
>> but multicast link-local domains which can end-up in a big storm too
>> (RA announcements and requests).
>> 
>>>>> And for ARP packets Batman could probably provide some fake proxy,
>>>>> where the node would answer them directly instead of broadcasting
>>>>> them around. Or maybe tunnel them directly to the node who can
>>>>> answer them. (Because Batman knows exactly where any MAC address
>in
>>>>> the network is. You do not really have to broadcast around to get
>>>>> this.) In a similar way that Batman currently handles DHCP by
>>>>> intercepting the packets and responding itself.
>> 
>> Hey Mitar, would you try to layer2 bridge all the Internet? Or even
>> just your city? Collision domain is for small sets of computers, the
>> networking stack we are using based on MAC/IP is not ready to have 1k
>> computes in the same domain. Broadcast storms, ARP problems
>(including
>> poisoning!), huge overhead just to mention some of the problems you
>> would have. IMHO trying to patch it by modifying batman-adv is a
>> mistake. Layer3 routing is exactly done to solve these situations.
>> 
>>>>> So I am not sure that it is smart to add another layer (another
>>>>> routing protocol) of complexity to the networking stack, where we
>>>>> could just learn and build upon existing tools. As you said, if I
>>>>> paraphrase, not yet another routing protocol. Cannot we have just
>>>>> one and all contribute to that one? So if Batman works in most
>>>>> cases, let's fix those cases where it does not.
>> 
>> Guido already answered you and I agree with what he said. We had
>> several meetings with the Batman-adv guys and everybody accepted it
>> was a problem which has to be fixed using a second routing protocol.
>> It is complex to explain, if you want we can organize an audioconf.
>> 
>>>>>> 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?).
>>>>>
>>>>> So are you saying that BMX should be run over whole mesh on layer
>3
>>>>> with Batman below on layer 2? Or are you saying that it should be
>>>>> used only on gateways. I am not sure what exactly you are saying
>>>>> here. Do you have some more concrete example/presentation of this
>>>>> idea? So how does one packet travels around the network in your
>>>>> topology of BMX + Batman?
>>>>>
>>>>>> I agree with your approach about compare overhead and routing
>>>>>> changes. However I can say this test was made during the
>>>>>> WCW-Berlin.
>>>>>
>>>>> For others, WCW is a yearly mesh-related even in Berlin, Wireless 
>>>>> Community Weekend:
>>>>>
>>>>> http://wiki.freifunk.net/Wireless_Community_Weekend_2013
>>>>>
>>>>> More locally targeted for the whole Freifunk community to get
>>>>> together from all around the country, once a year. (So most of the
>>>>> stuff you will find will probably be in German. :-) )
>>>>>
>>>>>> 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.
>>>>>
>>>>> Is there any description of the scenario? So if they were just
>>>>> moving the nodes around without communicating with the node at the
>>>>> same time, then this data is useless.
>> 
>> Mitar, you have been in the BattleMesh before. You know this is not a
>> perfect research environment. But Axel, Henning, Jow, Simon, Elektra
>> etc... were there supervising the experiments so I want to believe
>the
>> results obtained are relevant since the elite of the mesh networking
>> was there.
>> 
>>>>>> Just to give you another detail, the tested protocol which
>>>>>> showed more difference between moving and not moving environment
>>>>>> was Babel.
>>>>>
>>>>> This might be just that Babel adapts in a smart way to the moving
>>>>> and starts sending more updates. :-)
>> 
>> I don't think so. Babel acts as a static protocol when the network is
>> not moving, but when it moves it produces a very very high overhead
>> (compared to other distance-vector protocols). I don't see this very
>> smart since for static deployments you could do the same using BGP or
>> OSPF.
>> 
>>>>>> By the way, the conclusion of this tests was: BATMAN based
>>>>>> protocols are better in the overhead-mobile test.
>>>>>
>>>>> Yes. Their ways of updating the information about the network
>>>>> topology is really interesting and charming. But sadly the
>overhead
>>>>> is not the only thing which matters. Speed of convergence to new
>>>>> topology, no routing loops, and no disruptions in service are
>other
>>>>> which are important as well. Personally, I would not really care
>so
>>>>> much if routing protocol has bigger overhead if this means it
>works
>>>>> for people.
>> 
>> Of course it is not the only important thing. However in the last
>> BattleMesh, BMX6 was the better in coverage time and in best-path
>> selection. You have the results raw data in the battlemesh web page.
>> 
>>>>> And in general nodes do not really move around so much. Clients do
>
>>>>> (Batman has roaming support for them), but nodes, not really. At
>>>>> least until we have nodes installed on cars and bikes. Nodes do
>>>>> come up and down and at that time it is not so important how fast
>>>>> new topology converges, that is true.
>> 
>> It will depend on the environment. The scope of libre-mesh is cover
>> any kind of deployment.
>> 
>>>>>> Cheers, Mitar. Hope to see you in October.
>>>>>
>>>>> Sadly, I will not have time to attend the summit this time. :-(
>>>>>
>> 
>> Let me ask you something now. Is there any other "hacker" in this
>> project which knows about mesh networking? How many people do you
>have
>> working on firmware? I hope this conversation is useful for someone
>> else because at the end we are always the same people discussing the
>> same things (I did not know you were involved here!).
>> 
>> Cheers
>> 
>>>>> Mitar
>>>>>
>> 
>>> _______________________________________________
>>> mesh mailing list
>>> mesh at lists.sudoroom.org
>>> http://lists.sudoroom.org/listinfo/mesh
>> 
>
>-- 
>http://mitar.tnode.com/
>https://twitter.com/mitar_m

-- 
Charles N Wyble (818) 280-7059
CTO/Cofounder Free Network Foundation
http://www.thefnf.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sudoroom.org/lists/private/mesh/attachments/20130728/ef8899dc/attachment.html>