Re: [nmrg] Residual configurations

[Dean Bogdanovic <[e-mail]>]

Luis,

On 9 Oct 2020, at 6:15, LUIS MIGUEL CONTRERAS MURILLO wrote:

> Hi Dean,
>
> Thanks for elaborating. After reading some thoughts come to my mind.
>
> I think that Level 1 configuration could evolve in time, e.g. because 
> the network infrastructure evolves along the time (e.g., new nodes, 
> links upgrades, etc).
>
> So it would be maybe necessary to sort out along the time what 
> configurations can be categorized as Level 1 and what other are higher 
> level configurations.

Yes, that is a good suggestion and approach.

>
> Also, if there are dependencies among those higher level 
> configurations it could be convenient to keep track of those, for 
> maybe reverting partially the high level configurations instead of 
> totally.
The presumption is there are dependencies between some configuration 
levels, but it has to be sequential, level 2 can have config 
dependencies on level 1, but not level 3 to level 1.

>
> In summary, this would imply to add some characterization to the 
> configuration actions that are introduced along the time in the 
> network (could this be made maybe but introducing new parameters the 
> YANG models??).
This part I haven’t thought through yet. I have one approach in mind, 
but it is depending on the technology developed by my employer. Another 
approach could be using logical systems/routers, but those has several 
limitations. What you are suggesting is another possibility. Maybe your 
approach could be a good starting point.

Dean

>
> Would be nice to have your feedback on this.
>
> Best regards
>
> Luis
>
> De: nmrg <[e-mail]> En nombre de Dean Bogdanovic
> Enviado el: miércoles, 7 de octubre de 2020 18:27
> Para: [e-mail]
> Asunto: [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@01D69E35.070CC120]
>
> 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
>
> ________________________________
>
> Este mensaje y sus adjuntos se dirigen exclusivamente a su 
> destinatario, puede contener información privilegiada o confidencial 
> y es para uso exclusivo de la persona o entidad de destino. Si no es 
> usted. el destinatario indicado, queda notificado de que la lectura, 
> utilización, divulgación y/o copia sin autorización puede estar 
> prohibida en virtud de la legislación vigente. Si ha recibido este 
> mensaje por error, le rogamos que nos lo comunique inmediatamente por 
> esta misma vía y proceda a su destrucción.
>
> The information contained in this transmission is privileged and 
> confidential information intended only for the use of the individual 
> or entity named above. If the reader of this message is not the 
> intended recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly prohibited. 
> If you have received this transmission in error, do not read it. 
> Please immediately reply to the sender that you have received this 
> communication in error and then delete it.
>
> Esta mensagem e seus anexos se dirigem exclusivamente ao seu 
> destinatário, pode conter informação privilegiada ou confidencial e 
> é para uso exclusivo da pessoa ou entidade de destino. Se não é 
> vossa senhoria o destinatário indicado, fica notificado de que a 
> leitura, utilização, divulgação e/ou cópia sem autorização pode 
> estar proibida em virtude da legislação vigente. Se recebeu esta 
> mensagem por erro, rogamos-lhe que nos o comunique imediatamente por 
> esta mesma via e proceda a sua destruição


> _______________________________________________
> nmrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/nmrg