Open davischw opened 1 week ago
@mjstapp We are not redistributing PIM/PIM6 routes, so no change to the proto_redistnum
function in lib/log.c
seems to be needed.
ci:retry
From my perspective I don't understand the need here. Can you give me a bit better understanding of why we need to distinguish this? I see no need here for the added complexity here.
@donaldsharp
From my perspective I don't understand the need here. Can you give me a bit better understanding of why we need to distinguish this? I see no need here for the added complexity here.
This is a preparation for BFD support on PIM6 enabled interfaces. BFD is using the route-type registered with zebra to identify the daemon (pimd
/pim6d
). We are doing the same thing for ospfd
and ospf6d
at the moment. As for complexity it's a change of ~10 lines.
I don't know that these lints need to be fixed (?) ... but they should be looked at to make certain
this is a no from me until I have a better understanding of what is going on. It's not clear to me what bfdd is trying to differentiate (afi or is it process id? )
If it's process id -> I would like to see an understanding of the communication method that is handles the pim case as well as the ospf instance case.
I would also like to see how bfdd would handle multiple connections from the same daemon requesting bfdd interactions down different connections to zebra
If it's afi I would like to understand better how we successfully communicate afi. It's perfectly possible that a single daemon has both v4 and v6 families sent down(does bfdd really care ). I would also like to make sure that I understand how / what bfdd handes this with this change.
Finally it's possible that an existing daemon can get new afi's that it will attempt tracking on. EIGRP can get v6 knowledge( and can use 1 connection ala bgp ) or ospfv3 daemon could suddenly start transporting v4 addresses.
I would prefer that we not have to have special case code here, it should just work as new stuff comes in without having to touch bfdd.
I thought I understood this until our discussion today ... now I really don't understand the purpose, so we should wait a explanation of the purpose here.
Add a separate route-type for PIM IPv6 routes to enable zebra to distinguish between a
pimd
andpim6d
client.current master:
with changes: