Hi Maria, On Sun, Feb 26, 2023 at 07:34:06PM +0100, Maria Matejka wrote: > > I don't think RFC8966 is really framed in bird's "multi protocol" mindset > > so it's unclear to me whether this is something we have to fix or > > not. Section 3.8.2.1. says: > > > > > A node that has lost all feasible routes to a given destination but still > > > has unexpired unfeasible routes to that destination MUST send a seqno > > > request; > > > > I could for example read this as the above mentioned static route > > constituting a feasible route received from a bird "internal" babel > > neighbour which would make the behaviour described above perfectly fine, > > no? > > From my point of view, this is perfectly fine.
I did just do another reivew on the knock on effects of interpreting it like that and I do tend to agree it all looks fine. The (!best) thing I mentioned actually works in our favor here since getting rt_notifi'ed of another protocols route will then still trigger the 3.8.2.2, as it should, if we receive an unfeasible update. > > @Bird folks: can anyone think of a way to be notified of any and all > > changes in rt_notify? I assume it's not possible from some light reading of > > the nest code but figured I might as well ask. > > You may set channel ra_mode to RA_ANY, getting called rt_notify() for all > route updates. > > Or in BIRD 3, you can override the channel logic at all and if you don't > mind calling your filters yourself, you can just request "on any change, > give me all the routes for one prefix at once" and do whatever you want with > the routes. Yet these changes most probably won't get backported to BIRD 2. Hmm RA_ANY might actually be just fine if it comes to that, I'd still prefer not having to do it tho :) Thanks, --Daniel
