Thorvald - Hi! I'm Donald Sharp, I'm working on FRR, I'm discussing with you this PR: https://github.com/FRRouting/frr/pull/1350 First I'd like to apologize for the slow response to your enquiries on the PR. I decided to reach out directly to you because I feel like email might be a bit better medium to talk about what our plans are and to describe what I see the future of zebra is. Our plans are not currently set in stone but we do have some broad strokes of what we want to accomplish: 1) Separate the south bound API in such a manner that we use a starting function call. Currently both the FPM interactions and zebra/rt.h are our south bound interfaces As an example rib_install_kernel does this: rib_install_kernel hook_call (rib_update) -> FPM interactions kernel_route_rib -> Rib install for kernel we are working on. if (success) Set some values We want it to do this: rib_install_kernel kernel_route_rib -> List of hooks to call: FPM Interactions Rib install for kernel we are working on Anything else we add as a rib_update hook if (success) Call kernel_route_rib_success() function Now rinse/repeat this for all rt.h southbound api's. 2) Separate processing of southbound api into it's own true pthread( not lib/thread.h ): Currently the FPM has a TAILQ_ENTRY(rib_dest_t_) in rib_dest_t(rib.h) to track and process FPM install/deletes/whatever.. I would like to convert this data structure to the control point for what has been communicated south bound. Then allow the southbound api's to bundle the installation into whatever however they would like to do so in a timeframe that it would like to do so as well. I think this would allow us to do things like bundling of netlink messages to the kernel. Kernel insertion on linux as it stands is absurdly slow and needs to be sped up. 3) Arbitrary hook levels: We would also like the ability for FPM interactions and Rib install hooks have the ability to have sub hooks as well if they would like to as well. As an example the rib interactions could have a route-map application hook before passing to the kernel. 4) Allow which hooks to be used via a control mechanism( this is what you were really asking for ) to control who get's called. As you noticed it would be nice to have a way to control which soutbound hooks are actually installed and used. Now where to start? I personally think we need to start with #1. #2 and #4 will flow from that imo. donald PS - If you would like more immediate access than email, we use a public slack (frrouting.slack.com) if you would like an invite please let me know.