As Toke said, OSPFv3 is a fine protocol. OSPFv2 was already pretty good, and the designers of OSPFv3 fixed the two significant flaws in OSPFv2. But of course I'd be delighted if you could experiment with Babel.
>> routes). I'm simplifying wildly here, and I'm sure Juliusz will jump in >> and point out all the ways this simplification is wrong :) It's a good summary. I cannot at the same time claim that Babel is simple and object to simple explanations :-) > I'm not quiet sure I get the filtering part. Could you give me an > example please? What it means that Babel, just like BGP, can drop routes arbitrarily at any point of the network, while OSPF and IS-IS can only drop routes at area boundaries. Suppose that you have the following topology: B / \ / \ Internet --- A C \ / \ / D Suppose further that, for some reason, you don't want to carry C's traffic to the Internet through D (say, because D is a battery operated node). However, you want C to be able to reach D directly, so dropping the C-D link is not an option. You want the following behaviour: * C to A follows C-B-A * C to D follows C-D With OSPF, you have two solutions: 1. you increase the cost of the link D-A; 2. you put D in a separate area, so you can filter at the area border. Solution 1 is tricky and error-prone (you need to increase the cost of the link D-A, but not too much, otherwise traffic from D to A risks going through D-C-B-A). Solution 2 works fine (OSPF can do arbitrary filtering at area boundaries), but it involves planning (where to put the area boundaries) and a good understanding of the constraints on OSPF areas. With Babel or BGP, you just write a single filtering rule at C that drops the forbidden route C-D-A, and you're done. No tricky tweaking of metrics, no areas, just a single filtering rule. This cuts both ways, of course. OSPF imposes discipline: you need to carefully think about your network's structure, so you can have a uniform policy within each area. BGP and Babel allow fairly arbitrary routing policies, so it's easy to hack around issues with no understanding of the network topology: we give you powerful tools, and if you cut yourself, you're on your own. My feeling is that OSPF is well-suited to managed networks with a single central authority, while BGP and Babel are more adapted to chaotic networks with no central administration. While I certainly wouldn't want to use OSPF in a community mesh network, it'd be my first choice in a large, stable network where all links are fast and all nodes are powerful. > And yes IPv4 NLRI via IPv6 NH is just such a great achievement. Yeah, I like it too :-) > I have to admit: I think I need to re-read this chapter in my version of > "IPv6 essentials"... I'm certainly biased, but I rather like the introduction to https://arxiv.org/pdf/1403.0445.pdf > Does it start with using multicast and later/after it knows about its > neighbors, it switches automatically to unicast? Or how does it work? Babel (the protocol) is carefully designed so that the implementation can choose whether to send routing data over multicast or unicast. By default, both babeld and BIRD use primarily multicast, but occasionally use unicast to solve emergency situations ("I'm about to loose a route, probably due to packet loss"). Babeld has a mode where it uses multicast for discovery only and user unicast for all other communication, as you suggest, but I don't think that Toke has implemented it in BIRD yet. (Babeld was used to design the Babel protocol, and we experimented with a lot of features, many of which turned out to be useless, and which we've been busy removing over the last years. Toke had the benefit of our experience, so he could implement just the features that have been proven to be useful. In addition, Toke is a better programmer than I am, so the result is a much cleaner implementation, and one that is slowly getting to feature parity with babeld. I recommend using BIRD in production in preference to babeld, since the code is so much better; however, I intend to keep maintaining babeld for the foreseeable future.) > Maybe I should just set it up and see "how it feels". Please? -- Juliusz