lib,pimd,zebra: Add pim6 route-type

[davischw]

Add a separate route-type for PIM IPv6 routes to enable zebra to distinguish between a pimd and pim6d client.

current master:

frr-10-build-debian-13-amd64# show zebra client summary 
Name      Connect Time    Last Read  Last Write      IPv4 Routes           IPv6 Routes
------------------------------------------------------------------------------------------
pim           00:00:13     00:00:13    00:00:13          0/0                   0/0         
system        00:00:13     00:00:13    never             0/0                   0/0         
pim           00:00:13     00:00:13    00:00:13          0/0                   0/0 <--- This is actually pim6d, but registered as an IPv4 pimd client
system        00:00:13     00:00:13    never             0/0                   0/0         
static        00:00:13     00:00:13    00:00:13          0/0                   0/0         
Routes column shows (added+updated)/deleted

with changes:

frr-10-build-debian-13-amd64# show zebra client summary 
Name      Connect Time    Last Read  Last Write      IPv4 Routes           IPv6 Routes
------------------------------------------------------------------------------------------
pim           00:03:47     00:03:47    00:03:47          0/0                   0/0         
system        00:03:47     00:00:47    00:00:47          0/0                   0/0         
pim6          00:03:47     00:01:21    00:01:21          0/0                   0/0 <--- Now pim6d is registered as an IPv6 client with its own route type.
system        00:03:47     00:00:47    00:00:47          0/0                   0/0         
static        00:03:47     00:03:47    00:03:47          0/0                   0/0         
Routes column shows (added+updated)/deleted

[davischw]

@mjstapp We are not redistributing PIM/PIM6 routes, so no change to the proto_redistnum function in lib/log.c seems to be needed.

[davischw]

ci:retry

[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.

[davischw]

@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.

[riw777]

I don't know that these lints need to be fixed (?) ... but they should be looked at to make certain

[riw777]

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.

[davischw]

Closing this PR, as problem intended to fix has been solved in other ways.