Re: [nmrg] Residual configurations

[Alexander Clemm <[e-mail]>]

Hi Dean,

I agree that having a database acting as a system of record, from which device configurations can be regenerated as needed, makes a lot of sense.  Whenever the two were to get out of sync, you could also reprovision the network as needed.

I am not quite clear what you are suggesting regarding the distinction between overlay networks and substrate network and was wondering if you could clarify this.  Clearly, the same principle would apply there as well (database acts as system of record).  But why would you mandate it being it being ephemeral (versus non-ephemeral for the substrate)?  Just as a method to garbage-collect configurations made by administrators on devices directly?

(I do understand that there will be a problem if device configuration entered by an administrator and configuration kept at an external system were to diverge, in particular, when it is not clear which one is the actual system of record.  But this seems to be not an issue here – just the size of the configuration file?)

Thanks
--- Alex

From: nmrg <[e-mail]> On Behalf Of Dean Bogdanovic
Sent: Wednesday, October 7, 2020 9:27 AM
To: [e-mail]
Subject: [nmrg] Residual configurations


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]74360]

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