1 of 10

FRR Centralized Management

2 of 10

Introduction

  • Goal: make it possible to manage FRR as a whole instead of managing individual daemons
  • Managing includes:
    • Configuring the daemons
    • Fetching operational data
    • Calling RPCs and subscribing to notifications
  • Ideally the centralized management should be implemented in the watchfrr daemon since it can spawn/stop other daemons when necessary (e.g. start bgpd when BGP is configured)

3 of 10

Current Architecture

zebra

NB Callbacks

NB Core

zebra YANG modules

NB Plugins

Legacy CLI

bgpd

NB Callbacks

NB Core

bgpd YANG modules

NB Plugins

Legacy CLI

isisd

NB Callbacks

NB Core

isisd YANG modules

NB Plugins

Legacy CLI

vtysh/telnet

4 of 10

Current Architecture

​

  • The northbound layer is present in all daemons, and configuration transactions are per-daemon
  • Each daemon keeps its own copy of the running configuration. The running configuration of all daemons must be combined to form the global running configuration
  • The northbound plugins must be loaded on all daemons, which are then managed independently

​

5 of 10

Future Architecture

zebra

NB Callbacks

zebra YANG modules

bgpd

NB Callbacks

bgpd YANG modules

isisd

NB Callbacks

isisd YANG modules

watchfrr

NB Core

*all* YANG modules

NB Plugins

New CLI programs

NB IPC Layer

NB IPC Layer

NB IPC Layer

6 of 10

Future Architecture

​

  • Northbound layer is removed from all daemons and moved to watchfrr
    • watchfrr holds the global running configuration
  • watchfrr multiplex requests from northbound clients to the appropriate daemons as required
    • Can start/stop daemons as part of processing certain configuration changes
    • Use the publish–subscribe pattern to determine at runtime which daemons implement which YANG modules
  • daemons implement only the required northbound callbacks, which can be called remotely by watchfrr
    • New special-purpose IPC bus for that

7 of 10

Future Architecture

​

  • All northbound plugins (ConfD, Sysrepo, gRPC, etc) are loaded only in the watchfrr daemon
    • Each of them needs to be adapted as necessary
  • CLI is moved to a separate program on top of an existing northbound plugin (e.g. gRPC or something else that doesn’t require a new dependency)
    • vtysh is removed and telnetting to individual daemons is not possible anymore

8 of 10

Transition Architecture

zebra

NB Callbacks

NB Core

zebra YANG modules

Legacy CLI

bgpd

NB Callbacks

bgpd YANG modules

isisd

NB Callbacks

isisd YANG modules

watchfrr

NB Core

*all* YANG modules

NB Plugins

NB IPC Layer

NB Core

Legacy CLI

NB IPC Layer

NB Core

Legacy CLI

NB IPC Layer

vtysh/telnet

9 of 10

Transition Architecture

​

  • ​

10 of 10

Notes from Oct 23 meeting

​

​

  • Top Questions:
    • Process structure (new or existing)
    • IPC mechanisms and format
    • Default yang transports, DB
    • Performance
  • Most prefer new process
    • Not watchfrr or zebra
    • ​
  • ​