Dear all, I've just merged the rfc6126bis branch into master. While we've been running this code for a few months without issues, it's not had quite enough testing yet, so beware. Help with testing will be appreciated.
TL;DR ===== - there's a new revision of Babel called RFC 6126bis; - the code in master is compatible with both revisions; - there will be no flag day, except for source-specific routing; - there will be a flag day for source-specific routing; - it should be safe to upgrade, please test. Long version ============ RFC 6126bis is the successor to RFC 6126, which defines the Babel routing protocol. It doesn't have an RFC number yet, which is why we call it 6126bis. https://tools.ietf.org/html/draft-ietf-babel-rfc6126bis RFC 6126bis mostly consists of clarifications, tightenings and looseings of RFC 6126. However, it introduces three features that are incompatible with RFC 6126: 1. mandatory sub-TLVs; 2. unicast Hellos; 3. unscheduled Hellos. Mandatory sub-TLVs are an important feature, one that makes Babel easier to extend. The new version of Matthieu's source-specific extension depends on mandatory sub-TLVs, as well as Gwendoline's extension for ToS-specific routing, make use of mandatory sub-TLVs. Unicast and unscheduled Hellos are somewhat more specialised features, and might be used to improve link-quality estimation in situations where multicast is either very costly or extremely unreliable. It might also improve the security of the protocol in situations where unicast is cryptographically protected but unicast isn't. The code that I have just pushed into master will properly parse and act upon the new features, but will never send any packets that don't comply with RFC 6126. Hence, it is compatible with both versions: it is safe to use the current master in both RFC 6126 or RFC 6126bis networks. No flag day =========== There will be no flag day if you're not using source-specific routing. The code in master (scheduled to be released as 1.8.1) is compatible with both RFC 6126 and 6126bis, so it should be safe to upgrade. A future version of babeld will break compatibility with RFC 6126, but this is not going to happen too fast. What about source-specific routing? =================================== The new version of source-specific routing is not interoperable with the old version. If you're using source-specific routing in your network, you'll need to upgrade all of your routers. I realise this is unfortunate, but there's really no choice -- the old version of the source-specific extension is a mess, and, accordingly, the code is unmaintainable. The only way we can go forward is by removing the old code and replacing it with the much more maintainable code that speaks the new protocol. The code currently in master still speaks the old version of the extension, so it will not break your network. Future versions of babeld will silently ignore the old extension, so it is safe to upgrade. Please see Matthieu's presentation for some details: https://www.ietf.org/proceedings/99/slides/slides-99-homenet-source-specific-routing-00.pdf What about other implementations of Babel? ========================================== BIRD 2.0 speaks RFC 6126bis. Current sbabeld speaks RFC 6126bis. The FRR version of Babel speaks RFC 6126. That needs fixing. Pybabeld speaks RFC 6126. -- Juliusz _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users