On Monday 22 August 2011 16:30:56 Javier Cardona wrote:
> Which brings me to the main point of my e-mail:  is anyone out there
> interested in porting batman's path selection algorithm into
> open80211s?

Which one? There are ~5 revisions of the algorithm (not implementations). The 
newest iteration is B.A.T.M.A.N. V and is currently in the research and 
prototyping phase. The algorithm described in the RFC draft was B.A.T.M.A.N. 
III

...but I am not interested in implementing it for 802.11s. Maybe there is 
somebody else. Most people are currently focused on batman-adv. So I will 
write this response with batman-adv in mind.

> The benefits:

I only see benefits mentioned by you, but were are the disadvantages? I don't 
think that a marketing mail is a good start for a serious discussion.

> 1. By being based on a standard, you'll know you won't be colliding
> with other layer 2 technologies (for instance, no need to define your
> own ethertype)

At least batman-adv is quite happy about the fact that it is based on a widely 
used standard technology. And defining another identificator instead of an 
ethertype doesn't make a big difference to me.

But why are we colliding with any other layer 2 technologies? It sounds like 
"uh, you are so bad. you kill cute bunnies", but I don't see the "colliding" 
problem here. Maybe you mean the missing ethertype registration (anyone got 
$2500 for us?).

> 2. You can leverage most of open80211s, from test tools to wireshark
> patches.

batman-adv also has wireshark integration (already upstream) and test tools.

> 3. By being integrated in the kernel's 802.11 stack, you can take
> advantage of the development that's taking place there, from encrypted
> management frames to HT support.

Aren't all those things part of the layer _below_ batman-adv? Why should we 
care about it when the stuff we use has to deal with it.

> 4. You can reach out to a larger development community and raise
> awareness about batman.

What larger development community? At least the open80211s community seems to 
be a lot more silent.

> 5. A big problem in mesh adoption on Linux is not the mesh protocol
> itself but the absence of simple to use configuration tools (e.g. no
> mesh support in ConnMan, NetworkManager, etc.).  By providing a
> unified wireless mesh framework we increase the likelihood of having
> some support at the distro level.

Hm, maybe we have a different target audience. batman-adv is made for 
routers/APs and not for desktop systems. Thats why it has client mac 
propagation, bridge loop avoidence and roaming announcements (and many more 
things with funny names). And we already have a relative good distro 
integration for our target group...

> and last, but not least...
> 6. You'll be able to say authoritatively that batman is X times more
> efficient than HWMP (pick any X greater than 1 :)

And this is important because... And can be measured by... And uses the normed 
scale...

Maybe you should visit a Wireless Battle of the Mesh and tell them how such a 
benchmark is correctly done.

Greetings,
        Sven

Attachment: signature.asc
Description: This is a digitally signed message part.

Reply via email to