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
