lib,zebra,sharpd: allow recursive resolution of nexthop-groups

[mjstapp]

Add initial support for recursive resolution of nexthop-groups:

• add a flags field to the nexthop-group zapi message, and assign a RECURSION flag value
• add a "recursive" config option to the nexthop-group config submode
• use the config and zapi changes in sharpd
• in zebra, add code to iterate over a group's nexthops, use the zebra validity-checking logic, and update as necessary. This is driven by daemon-owned nhgs, allowing the use of recursive nexthops in those nhgs.

I'm making this a draft for now, so we can have some discussion. There are still some gaps - sharpd's groups aren't being uninstalled and deleted properly, for example, so I'd like to clean that up. I'm not sure that all necessary changes to a nexthop are being detected in this path. And I haven't exercised these nexthop-group changes in coordination with routes, so there are some questions and TODOs there also.

[mjstapp]

What I want to try is to make an incremental change - and avoided "many other ... elements" on purpose. I think it makes most sense to take some careful steps, learn about the issues and impacts as we go. Most of this PR is pretty obvious - we've been talking about this for a long time. But even this small change has raised questions about threshold for nexthop reinstallation, address-family rules, about zapi messaging, about reporting results, about the "contract" that we would expect to exist between zebra and protocol daemons. As we resolve those questions, I think we'll understand better how to take the next step - to use this path to allow zebra to modify an nhg in-place, under some circumstances.

it is possible to see how to reuse some commits from #16028 ? As discussed yesterday, this extension has not wanted to control the zebra NHGs. The recursive keyword has been introduced, along with testing and many other zebra elements.

[mjstapp]

Pushed an update that should help with CI...

[pguibert6WIND]

What I want to try is to make an incremental change - and avoided "many other ... elements"

I just made what you requested, ie separate BGP from ZEBRA. If you want to continue splitting, then I can actively pursue on the PR16028, and split again. really.

learn about the issues and impacts as we go

I just wan to avoid sending non tested code in the upstream.

[pguibert6WIND]

as said on slack, a similar proposal is done at https://github.com/FRRouting/frr/pull/16947. please review.

[pguibert6WIND]

• please no AFI changes in this pull request. lets focus on recursive only.
• missing topotests

[pguibert6WIND]

• please no AFI changes in this pull request. lets focus on recursive only.

  • missing topotests

no feedback ?

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[github-actions[bot]]

This pull request has conflicts, please resolve those before we can evaluate the pull request.