Re: [nmrg] Residual configurations


On 7 Oct 2020, at 12:44, Alexander Clemm wrote:

> 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.
Happy we are in agreement :)

>
> 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.
Think about substrate network as providing core routing and access to 
management system. Nothing else. All other services are created as 
overlay networks.

> 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)?
To speak in specific vendor terms, logical system or logical routers are 
created for each overlay network. Those logical router/systems are 
ephemeral as are their configurations. In case something happens to the 
network, as after restart of any network service or the logical 
router/system, the restarted service/system can’t know what is the 
state of the network. So, why boot a service that might be out of sync 
with the rest of the network. Replay it from the central database, as 
all the changes should be reflected in the central database.


> Just as a method to garbage-collect configurations made by 
> administrators on devices directly?
Yes, but also think about enabling customers to change network services, 
and cleaning up after them.

>
> (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?)
IMO, the system of record should always be the central database, never 
the device. Except in the very first boot up sequence, when call home 
for basic provisioning is executed.
It is not just config file size, it is to prevent unnecessary 
provisioning of potentially stale config data.

Dean

>
> Thanks
> --- Alex
>
> From: nmrg <nmrg-bounces@irtf.org> On Behalf Of Dean Bogdanovic
> Sent: Wednesday, October 7, 2020 9:27 AM
> To: nmrg@irtf.org
> 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:image001.png@01D69C8D.BDE74360]
>
> 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


> _______________________________________________
> nmrg mailing list
> nmrg@irtf.org
> https://www.irtf.org/mailman/listinfo/nmrg