<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Hello,<div><br><div><div><div>Am 19.05.2013 um 12:40 schrieb Simon Wunderlich:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Hello yanosz,<br><br>On Sun, May 19, 2013 at 10:52:01AM +0200, Jan Lühr wrote:<br><blockquote type="cite">Hello folks,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I'd like to give some thought's for the upcoming batman-adv release, especially on compat version 15. This somewhat summarizes my discussion with T_X on the wireless community weekend (WCW -- 2013-05-10 - 2013-05-12).<br></blockquote></div></blockquote><div>(...)</div></div><div><blockquote type="cite"><div><blockquote type="cite">It's not my intention to bash on batman-adv in general or to start flame-wars (like: batman-adv vs. olsr or something else) - I'd like to provide some statement on the impact of the upcoming protocol changes.<br></blockquote><br>Thanks for your feedback. Yes, we are preparing a compat bump (actually for a long time now) and it's good to discuss it. :)<br></div></blockquote><div><br></div><div>Thanks for your detailed answer - I'll cut some parts for better readability.</div><div><br></div><blockquote type="cite"><div><br><blockquote type="cite"><br></blockquote><blockquote type="cite">1. The upcoming protocol change appears to be painful - we have no suitable migration strategy.<br></blockquote></div></blockquote>(...)<br><blockquote type="cite"><div><blockquote type="cite">13 nodes in the next months - by that, we'll probably have some compat 13 ones for at least 1/2 year. There is no way of telling newer nodes to use compat version 13. Since some "supernodes" (dedicated servers) are part of the batman-adv cloud, we need twice the servers as well.</blockquote><blockquote type="cite">Upgrading to compat version 15 will require a huge amount of work: New infrastructure (servers) must be deployed and nodes meshing with each other must be upgraded in parallel.<br></blockquote><br><br>Btw, it's interesting that you use compat version 13 - only one release had that included, and we are<br>on compat 14 for quite some time ...<br></div></blockquote><blockquote type="cite"><div>[1] <a href="http://www.open-mesh.org/projects/batman-adv/wiki/Compatversion">http://www.open-mesh.org/projects/batman-adv/wiki/Compatversion</a><br></div></blockquote><div><div><br></div></div><div>(...) - yes, I know. Theses nodes are quite old. I guess this somewhat illustrates the upcoming situation.</div><br><blockquote type="cite"><div><blockquote type="cite"><br></blockquote><blockquote type="cite">2. Backwards-compatilibilty doesn't seem to be a design target.<br></blockquote><br>Actually, that is one of the main design targets. We are aware that with our current packet type design,<br>we cannot change even parts of the protocol without breaking compatibility. This has bothered us for quite<br>some time and we have worked on solutions to prevent compat bumps as good as possible. We have introduced<br>different means [2,3] to be able to add new features, change features, let sub-features update their<br>protocols (by using TVLVs) without breaking the rest and ensure compatibility on their own [3], route even<br>yet unknown packets on their own [2], ... Actually the TVLV thing is pretty similar to other protocols<br>(e.g. IEEE 802.11) which use that to ensure backwards compatiblity for years. The goal is to keep the<br>compat bump stable for at least a decade now, if not longer. No guarantees of course, but this compat<br>bump is made to CREATE backwards compatiblity. :)<br><br>Note that the compat bump is not released yet but still only in our development branch.<br><br>[2] <a href="http://www.open-mesh.org/projects/batman-adv/wiki/Packet-types">http://www.open-mesh.org/projects/batman-adv/wiki/Packet-types</a><br>[3] <a href="http://www.open-mesh.org/projects/batman-adv/wiki/TVLV">http://www.open-mesh.org/projects/batman-adv/wiki/TVLV</a><br></div></blockquote><div><br></div><div>Thanks for the details. I understand your reasons for changing the protocol - and I'm perfectly fine with that. I know that manets are an area of active research. </div><div>Bit this won't be a problem at all, if upcoming batman-adv versions are capable if "speaking" older compat versions. If done so, we (as in Freifunk-KBU) would be able to simple "choose" the compat version for our network - and pick a newer one if needed.</div><div><br></div><blockquote type="cite"><div><blockquote type="cite">Since batman-adv depends on the kernel (old batman-adv versions won't build with recent kernels) using 14 will not be an option in a few months: If some router hardware requires recent Kernel / OpenWRT releases version 14 might no longer be used.<br></blockquote><br>I think it would be possible to maintain older releases of batman-adv and add compatibility code for<br>newer kernels. We are doing the same now to provide compatibility for older kernels [4]. We would<br>be happy if someone (you?) would take over that job, I guess it would mostly mean to test new kernels<br>and add a little bit of compat code like we do for the old kernels. You are welcome to contribute<br>such "stable" versions. :)<br><br>[4] <a href="http://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/compat.h">http://git.open-mesh.org/batman-adv.git/blob/refs/heads/master:/compat.h</a><br></div></blockquote><div><br></div><div>Hmm... well, I'm not into kernel development, but I could maintain some CI services for testing. I'll ask some our folks on our next community meeting.</div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font><blockquote type="cite">-> We're aware, that we cannot use version 14 in some months<br></blockquote><blockquote type="cite">-> At the point, when 14 becomes unusable (introduced into OpenWRT Kernels / release we need -- or Debian), we will almost certainly discontinue batman-adv and go one with sth. else. (Due to kernel deps it's easier to run batman-adv / olsr in parallel than two different version of batman-adv)<br></blockquote><br>I don't see that by releasing batman-adv with the new compat version, suddenly your network breaks<br>- in Debian you usually keep the same kernel for YEARS, and in OpenWRT you can just keep the batman-adv<br>package at the desired version number. The only problem you might run into is that newer kernels might<br>not work, as stated above.<br></div></blockquote><div><br></div><div>Actually, it has consequences: About 5-8 months ago (don't remember the details). 2011.2 didn't build on Attitude Adjustment (12.09) (OpenWRT issue? Kernel Issue? I don't remember ...), while newer TP Link 1043nd models needed 12.09 (brick, otherwise). At that time we're eager of deploying compat 14 releases - succeeding about 3,5 months ago. </div><div>But in the aftermath of it, we noticed that we did not succeed in upgrading the whole network - since upgrading some nodes is still impossible because of organizational issues. Some people complained about the effort needed - for valid reasons, imho (although we provided free vodka at our release party ;-) )</div><div><br></div><div>To be honest: I don't like to be stuck at this, again. With compat 15 on the horizon, we're in the need of finding adequate strategies. </div><div>Do you have something in your mind?</div><div><br></div><blockquote type="cite"><div><blockquote type="cite">-> Maybe, some future version of batman-adv addresses backwards-compatibility. Maybe, in 2018 we will have a look at batman-adv again - noticing, that batman-adv remained stable (or migratable) over the last years and start using it again. Maybe, batman-adv will fit our needs, then.<br></blockquote><br>You are free to use whatever you want. I think I've made a clear point that this compat bump is designed<br>to address the compat issues we had. What you roll out then is up to you (personally I'd be interested<br>what you'll use instead) - but I guess you'll miss a lot of very nice features of batman-adv. ;)<br></div></blockquote><div><br></div>Yeah - I guess I'll miss some features - and there is no decision yet (not even candidates).</div><div>However - in retrospect - kernel-dependencies will be taken into account this time.</div><div><br></div><div>Greetz,</div><div>yanosz</div><div><br><br></div></div></div></body></html>