SONiC, FRR split configuration, a step backwards?

Browsing the YANG files in the SONiC source code I found that it is now possible to enable a new split configuration mode.

leaf docker_routing_config_mode {
                    description "This leaf allows different configuration modes for FRR:
                                - separated: FRR config generated from ConfigDB, each FRR daemon has its own config file
                                - unified: FRR config generated from ConfigDB, single FRR config file
                                - split: FRR config not generated from ConfigDB, each FRR daemon has its own config file
                                - split-unified: FRR config not generated from ConfigDB, single FRR config file";
                    type string {
                        pattern "separated|unified|split|split-unified";
                    }
                    default "unified";

Instead of using the integrated SONiC configuration, this mode splits the configuration of SONiC and the routing component FRR into two configuration mechanism on the same switch.

SONiC’s integrated mechanism parses the SONiC configuration via a configuration model written in Python using Jinja templates into the loaded FRR configuration. The native SONiC cli does not provide any routing functionality, depending upon the FRR VTYSH CLI. This seems reasonable but the routing configuration in the default model is not generalized, more use case focused and combine that with sparse documentation makes using SONiC integrated and default routing configuration model challenging.

Why not just use the FRR VTYSH command set, it’s just like the Cisco CLI? The problem is the default configuration model does not allow a saved VTYSH configuration to be persisted between reboots. Enter split configuration model.

Split configuration allows the use of FRR configuration mechanisms such as VTYSH but still requires a SONiC configuration resulting in two configuration mechanisms.

While this seems like a simple solution (and one that has been attractive to the commercial SONiC providers), split mode creates more problems than it solves.

Instead of a single tool chain for switch configuration and management, split mode requires a tool chain for SONiC and another for FRR that are interdependent.

Every other switch provider uses a single configuration model.

Any new switching infrastructure should be automated and managed programmatically, with few uses for an interactive CLI. This is how SONiC is designed, the CLI is rudimentary and there are an abundance of programmatic mechanisms to manage the switches.

SONiC presents a significant challenge for new users, delve into the source code to understand how to configure routing using a single automation tool chain in integrated mode or use split mode and develop an automation tool chain for SONiC and FRR that accommodates their interdependencies. Neither are good solutions.

I think Split mode and its use by commercial SONiC vendors is a step backwards, postponing the need to address SONiC routing configuration and documentation issues.

A more technical discussion on SONiCs FRR configuration mechanisms is located at sonicnos.net