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.

   Part of validation should also be done at process.

4. Each process should be stateless w.r.t configuration.

   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