The packet format encodes intervals in centiseconds, so it would make sense to allow any fractional Hello interval down to 0.01 seconds.
since the internal Bird timers run at a granularity of seconds only there's not much point in having the ability to configure smaller values.
That's uncool.
I do seem to have forgotten to generate a new hello when reconfiguring (RFC section 3.4.1: "Equivalently, a node SHOULD send an unscheduled Hello immediately after increasing its Hello interval.").
It's not a big issue -- any well-implemented neighbour should recover after the next Hello (see the bit about « undoing history »), but it's an easy fix.
I remember running into this. What happens here is that babeld sends an update without a preceding router_id TLV, with a wildcard address, but flag 0x40 set (meaning "infer the router ID from the address"). While I'm not sure what the purpose of this is (a null update with a null router ID with infinity metric and interval?) it *is* technically in spec.
No, it isn't. Earlier versions of babeld allowed a retraction (update with infinite metric) without a router-id. This is not allowed by RFC 6126. Current versions of babeld no longer send such retractions, but still honour them when received. The plan is to explicitly allow such retractions in RFC 6126-bis, but they are clearly not allowed by RFC 6126. -- Juliusz