[nmrg] Residual configurations

[Dean Bogdanovic <[e-mail]>]

Hi,

During last NMRG virtual meeting on Sep 25, we touched base about 
residual configuration issues in networks. Network device configurations 
are getting bigger and often operators don’t know why certain parts of 
the config are there. One such use case that contributes to config 
growth are debugging sessions. Network operator enters the device and 
starts editing configuration. After the debug session is over, it is not 
unusual for that debug config information to stay in the config 
indefinitely.
Some operators have created central databases that contain all the 
network configuration and act as systems of record. If anything is to 
persist in the network, it has to be entered in the central database, 
but there is still an issue between on device persisting configurations 
and central configuration database.
One of the ideas was to keep the persistent configuration at minimum on 
the device and in the central database. All network services are 
generated on demand and are ephemeral.
The network topology would look something like this

![](cid:[e-mail] "Screen Shot 
2020-10-07 at 12.07.41 PM.png")

 From physical perspective, there are two networks, an optical transport 
and a packet switched network. All devices receive basic connectivity 
configuration that (could) persists on the device, you can call them 
Level 1 virtual networks (maybe glorified management networks). Those 
networks provide most basic connectivity between devices within a single 
management domain. That information could be also provided via ZTP.
On top of each network higher level networks are overlaid. All the 
network configuration for higher level networks is ephemeral. The higher 
level networks can (IMO, should be) different management domains, which 
creates clear demarcation lines in the network provisioning data

Such approach would create a (small) well defined starting configuration 
with all other services built as part of higher level networks. The 
residual config problem would be limited to each domain and with higher 
level networks being ephemeral, it should be easily reprovisioned by 
replaying the provisioning information from a central location.

As said, this an interesting problem to me, as the residual configs also 
eat data plane resources, which are quite expensive.

Dean