FRR Centralized Management Requirements

1. Make it possible to manage FRR as a whole instead of managing individual daemons

2. Running DB and Candidate DB should be part of centralized management. (Centralized DB - data and processing)

   Things like 'show running-config' should be handled by the centralised management daemon and backend should not contacted.

3. Functions like validation and rollback should be part of centralized management.

   Allow some part of validation to be done per process. (ex required) Validations based on YANG model specifications should be handled in the interface or this centralised management DB. Having passed the YANG model specifications individual configurations should be sent to corresponding NB backend process for final validation. Allow process candidate data be changed. (ex required)

4. Each process should be stateless w.r.t configuration as much as possible.

   An IPC landing at process should trigger proper callback function for final verification and apply of corresponding configuration.

5. Each process should have single set of IPC channels to centralized management.

   Preferably separate ones for configuration and operational state display.

6. Centralized management should have multiple plugins to rest of the interface (CLI, RESTCONF, NETCONF, gNMI, etc). (+)

   While the central management daemon should allow only one of the plugin to configure (and thereby write to the Candidate and Rubbing DB), it should be able to handle operational data requests from multiple plugins parallely.

7. Feedback of any backend issues during apply stage needs to be passed to centralized management. (+)

   Validation error from any process for any part of the configuration being committed should result in commit failure for the entire set of configuration being attempted to commit.

8. Configuration and operational state (NMDA) support. (+)

   Get any datastore (Candidate DB).

9. Support for notifications/push/telemetry.

10. Replay of configuration after process restarts. (General handling of process restarts)

11. Allow for different YANG models for same information, e.g., Native (possibly different versions over time/releases), OC, IETF, customer-specific etc.

12. Support for multiple daemons supporting a single NB transaction (e.g., maps)

    Support for transactions needs to be extended throughout, right from the interface to the central management daemon and the NB backend daemon.

13. Support for batching and pagination for display of large sets of operation data.

    Interface plugins API provided by centralised management should support fetching of large sets of operational data in multiple batches of reasonably limited size. Same support for batching needs to be supported in the NB plugin interface to be implemented by each backend process. The size of each individual batch should depend on the size of each entry in the given dataset being displayed and should be a implementation choice of the backend process. The interface(s) needs to be designed to take note of this batched approach and should take care of displaying data in batches (as and when they are received back from centralised management daemon) rather than displaying only after receiving the whole dataset.

14. Default DB and interfaces supported in CI and recommended configuration

15. AAA for all connection

16. Yang access control list (RFC 8519)/NACM support

17. Multiple config/operation readers session via multiple interface.

18. Multple config write session (Open for discussion?)

• = support from additional person/contributor)