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)

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

   Allow some part of validation to be done per process. (ex required)

   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 to apply configuration.

5. Each process should have single IPC to centralized management.

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

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

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

9. Support for notifications/push/telemetry.

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

11. Support for open config yang or IETF config.

    There are two ways we can support open config yangs.

    Maintain two yang data models.

    Support conversion of OC yang to FRR native yang. (performance issues and complex)

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

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

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

• = support from additional person/contributor)

1. AAA for all connection
2. Yang access control list (RFC 8519)/NACM support
3. Multiple config/operation readers session via multiple interface.
4. Multple config write session (Open for discussion?)