[j-nsp] Network automation vs. manual config

[adamv0025 at netconsultings.com]

> Of Antti Ristimäki
> Sent: Sunday, August 19, 2018 4:17 PM
> To: juniper-nsp
> Subject: Re: [j-nsp] Network automation vs. manual config
> 
> Hi,
> 
> Thank you all for your comments both on and off the list. A lot of food for
> thoughts. I can see that many of you have been evidently thinking about the
> same dilemmas. Niall, yes it is Funet we are talking about, although not
> directly conneted go Geant but to NORDUnet instead. I might contact you
> unicast later.
> 
> There has been some comments about using (or not using) apply-groups for
> managing and organizing the configuration. As discussed earlier, they might
> cause quite some confusion when used incorrectly. 
>
Automation is a huge project and it would be a pity to tailor all your automation around a specific vendor niche. 
Same applies for the service building block templates -I think it's better to have these defined in openconfig format and push as such or translate to vendor specific format for non-standardized models.  

> One more comment. Depending on which tools are being used, it might be
> rather easy to add new configuration to the network, but the system should
> also support removing unnecessary elements from the configuration. This is
> where replacing the entire configuration or at least entire configuration
> hierarchy helps, as the unused configuration won't be added to the config in
> the first place and no separate cleaning task is needed.
> 
That would be handled by the config reconciliation routine, where the operational data store is compared to the config/intent data store and operator is presented with a choice to copy oper.>intent or vice versa.
Also its better if the tool applies just the delta not the whole config.
And also it's nice to have the option to perform the operation as atomic (i.e. successful on all nodes otherwise rollback)    

adam

netconsultings.com
::carrier-class solutions for the telecommunications industry::