I saw this message go by today: http://www.ietf.org/mail-archive/web/homenet/current/msg05073.html
where the author stated: "If there were a solid specification and second implementation of babel, babel would win on the basis of functionality." A) As for the first, babel is pretty fully documented in a multiplicity of individual submissions and a pair of formal (to-me) looking RFCs. Certainly could use more eyeballs! Does it really need a dedicated working group? B) As for the second part of that statement, there is a second implementation in quagga, but it is indeed from the same people. I have LONG believed in the need for two or more implementations from a specification in order for it to be a good spec. However: 0) Modern protocols are really hard to write down in english. Open C code is generally more clear (at least to me!), as are accompanying documents that can actually incorporate graphs and math. Plain text does not cut it. The IEEE does a bit better job in this regard than the ietf, IMHO. 1) I don't know where the "2 separate implementation" concept is embedded formally in the ietf structures for approval. So far as I know that was an old requirement, long dropped. What rfcs mandate this? Was it mandated for http 2/0, for example? Did that happen? Is it mandated for RPL? Has anyone ever produced an interoperable version of ospf or ISIS solely from the spec? 2) Given the ready availability of very open (MIT licensed source code) I think doing independent code from scratch is a waste of time and a waste of what few valuable resources exist for furthering better routing protocols and routing/kernel software in general. (I would certainly, ultimately, like a version of babel that could be poured into gates and run with a much tighter update interval at 100GigE, but I can leverage the C code for that also. I don´t think an in-kernel version is needed, either. Would a ns3 version of a given routing protocol meet the requirement for a competing implementation? Back in the days when we had to write stuff in assembly, or gates, I tend to think that the two separate implementation requirement made sense, but not in an age where source is so freely available. 3) In the upcoming babel 1.6 release, I hope to see support for atomic route updates, (not present in any linux routing daemon I know of besides olsrd - and I do hope that code gets into quagga bgp in particular when it stablizes), support for openwrt procd init replacement (reliable restarts in case of failure), autodetection of IPV6_SUBTREES at runtime, and a few other features. After babeld-1.6 released, I expect it to be quickly taken up by the entire linux (debian/fedora) ecosystem, as well as bsd, as well as (if it stabilizes soon enough) openwrt chaos calmer, it´s deriviates, buildroot, and yocto. Basic babeld already being available as a standard - and universally identical - package in so many parts of the ecosystem is one of the basic babeld´s advantages over quagga, which has a good dozen competing forks with different behavior and interfaces, and a mess of competing implementations and feature sets in isis, ospf, and bgp. An analogy I would use to favor babel is much like the one that let firefox take over from mozilla - that a small team, no committee, strong maintainer, makes for better software. in babeld 1.7: A) I would hope to see the currently quagga-only https://tools.ietf.org/html/rfc7298 authentication extensions pushed into babel using a modern, safe, well debugged crypto toolkit like nacl, if needed... and some ideas towards partially authenticated routes explored. B) Given the issues with configuring hnetd + dhcp + babel + firewall + dnsmasq, I would like to see all that gain a configuration bus much like dbus, kdbus, or ubus. C) I personally hope to gain the time to finally come up with an RTT based availability, capacity, utilization metric leveraging the unique characteristics of fq_codel (which is the current de-facto queue type for openwrt, and thus homenet, and more or less what is going into make-wifi-fast). What I think I got here will distinguish - without using BFD - between wifi, wireless, homeplug, ethernet, and other forms of connectivity pretty cleanly, I hope, without explicit configuration. But I am unwilling to promise that (been a goal of mine for 18 years!), and certainly there are other things on my plate taking priority. (the math will work out fine for other routing protocols that want to take advantage of the same assumptions) And after that (or during), I would like to see work towards getting ECMP and multicast to work, speedups on solving for wider diameter networks, ability to take advantage of more wireless statistics, etc. All this is stuff building on what already exists, and exhausts what few developers are available *already* on what little funding exists. As I have long noted, it would be awesome to gain more developers working on quagga, babeld, olsr, manet, rpl, etc to actually turn dreams into reality, and make for a deeper awareness of how routing protocols work in the next generation. Certainly the BGP architecture of the internet is creaky and I would dearly appreciate more efforts at QAing existing code against newer versions of the OS, and improving the OS interfaces overall. Routing lookups in modern hardware are very expensive in particular... One last note: I am deeply concerned about the depth and scope of the FIB table updates happening in the linux kernel in the past two (4.0, 4.1) releases. They are comprehensive and invasive, and speed up fib lookups amazingly, but the testing has been lacking for those making tons of routing updates (RCU has been introduced) via daemons that will ultimately be consuming that dogfood. truly spectacular gains - in FIB lookups a factor of 7! here: https://netdev01.org/docs/duyck-fib-trie.pdf Some controversy here: http://lists.openwall.net/netdev/2015/03/11/136 and nobody, so far as I know, using any routing daemon, has been comprehensively testing. I hope to start myself, but jeeze, folk, the fate of the internet relies on BGP, and the one guy doing the work at redhat is just using a couple VMs to write the code on... So to return to the impetus for this overlong email. ... so as usual, I find it ironic and depressing that those at the ietf wish to impose more coding work, when there are far too few coders and nearly zero testers actually on the job of doing what they can to implement what they have to keep holding the internet together as it continues to grow. ... out of fear, I am doing my best to track those updates above and contribute where I can. I sure hope those that rely on any routing protocol working at scale are closely tracking the FIB work also. I would be comforted to know of any, any person, any corporation, besides me, that are doing so. -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
