Dear Dave, Here, at Babel Towers, we are busy working on Babel, working on babeld, lecturing undergrads, correcting exams, writing papers, and protesting against the stupidity of the current state of emergency. We have all but given up on having a life outside of work.
You will therefore doubtless understand that we must be very selective in our choice of things to do with Babel and babeld. My policy, which has served us well, is to concentrate on features requested by people who actually are trying to solve a problem in deployment, and to ignore things that would be cool to have but are not actual issues impeding deployment. My current plans are, in order of urgency: - tweak things until Kosko (Jernej) and Mitar tell me they're running unpatched babeld in their mesh, then release the result as 1.7.0; - add a configuration interface that suits the Nexedi people, so they can abandon their local hacks; - integrate the babeld/hncpd pair into Debian so that one can do "apt-get install hncpd" and have a working Homenet router; - find a chair and prepare a Babel IETF meeting for Buenos Aires. Please keep this in mind when reading my answers below. > ** Working channel diversity selection based on the current linux wireless api Yes, but that's some tedious work. Patches gratefully accepted. > ** Correct channel diversity for 802.11ac No idea what needs to be done. > ** Fast channel switching in light of a DFS changeover That's not babeld's job -- babeld asks the kernel for link layer parameters, but doesn't tweak the link layer itself. > ** Channel selection integration support with hncpd Interesting idea. Probably an open research problem, though. > ** full debian/ubuntu/fedora/arch support L'intendance suivra. > ** clean restarts and other reconfiguration Yes, this will happen. A lot of tedious work, unfortunately. > *** openwrt procd support > *** systemd support Nothing needs to be done -- babeld is a single process that doesn't daemonise by default, it works fine from inittab, runit, procd and other sane init systems. (There is no need for explicit notification, socket activation or other gratuitious complexity, whatever the self-nominated Linux experts claim.) > ** Version output in the monitoring interface Yes, this will happen. Matthieu mentions it whenever he gets a chance. > ** similar to existing useful on olsr plugins or interfaces to babel's > monitoring interfaces, whatever they are Huh? > ** more unicast instead of multicast > lower the load on wifi Easy to implement, but difficult to test. Who'll do the testing? > ** short haul metrics based on rtt and congestion > I know, I know, I keep wanting to do this but it is stuck on per > station queuing working at all in any wifi driver which is my big job > next year Baptiste implemented everything you asked for, Dave, we'll still waiting for your testing results. > ** Bird version finished > *** IPv4? Unfortunately, that's not possible until we get support for an IPv4 data plane in bird6. Please start a discussion on bird-devel, I'll chime in. > ** Atomic route updates > example patch for quagga: http://patchwork.quagga.net/patch/1435/ Who'll do the testing? > ** ECN and rate control for larger networks We've discussed this before -- ECN is the wrong thing to use here. We'll hopefully get some data from our Slovene friends that will show whether we need better rate control. > ** Covering/collapsing routes and interdomain routing Automatic aggregation is tricky -- as far as I know, nobody's ever managed to pull it off. You want to speak with Sobrinho. > ** what can be learned from BGP? I'm reasonably familiar with BGP, Dave, and Babel already integrates a number of good ideas from BGP. > ** Faster dead link detection with switches that support it A lot of work, and a lot of testing. Who'll do the testing? > ** Koruza support Koruza is a purely physical layer device -- it appears as a plain Ethernet, and uses a standard Ethernet transceiver. Nothing needs to be done -- and nothing can be done. > ** many radio types (802.11ad, lte, bluetooth, 802.14 etc) supported > sanely at the same time (6 radios, say...), gradual route optimization > over such Who'll do the testing? > ** Homeplug vs ethernet routing selections Homeplug appears as an Ethernet to the upper layers, you need to send proprietary 802.2 frames to find out that there is one. You probably want to speak with Barbara Stark. > ** Rebuild quagga patches for babel based on GPL sources (from bird?) No way. I'm not going to try to work with the Quagga crooks again. Let's give up on Quagga, as much of the routing community appears to have done. > ** source specific routing tested at more scale with things like tinc Who'll do the testing? > ** ns2/ns3 support Yes, we need that. That would be a good fourth year project if I find two students that are good enough. > ** rfc7298 support in everything Yes. > ** Testing over WPA encrypted and other sorts of semi p2p networks > like, for example the 24ghz airmax products Who'll do the testing? > ** Better dhcp/babel integration for hosts that wish to participate Doesn't that happen automatically when using hncpd or hnetd? > ** better mobility for hosts running a stubby babel Yeah, sbabeld needs some love. > ** Babel fuzzer and more testing of misaligned data Yes. > ** A pony A ratel, an aardvark, even a mule would do, but certainly not a pony. -- Juliusz _______________________________________________ Babel-users mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users
