What is a configuration template?

Overview

A configuration template is a reusable set of parameter values that implements a configuration based on the associated intent type configuration form. The intent type and the configuration form must be created before the template can be created.

You can create a template for each configuration form in each intent type, or create templates for different use cases.

Note: If a user has multiple versions of an intent type and a template is created for each, the same target object can be created under each template, which will cause the target configurations to overwrite each other in the network.

Templates can be fixed or flexible. A fixed template has preset or default values for all parameters. A flexible template includes parameters that can be changed by the operator at deployment time.

Note: Validation of parameters is performed by the NSP when a template is deployed. However, for MTU in particular, non-numerical values cannot be detected by NSP due to an HTML5 behavior.

You can deploy a configuration template from the configuration templates list by clicking (Table row actions), Deploy to Network, or from the deployments list, see How do I create a logical configuration deployment? and How do I create a logical configuration deployment?.

NSP supports up to 20 000 deployments per configuration template.

Parameters

In NSP you can create configuration templates for physical configuration such as card or port configuration, or logical configuration such as QoS, LAGs, and routing policy configurations. Configuration templates are based on configuration intent types. The template inherits some properties defined in the intent type, and others are defined as part of template configuration.

The following table shows the Configuration Template parameters.

Parameter	Predefined values	Notes
Name	—	—
Description	—	If no description has been configured, the Description column displays a dash. The Description column can only be filtered on configured contents.
Life Cycle	draft	The template can be edited but cannot be deployed to the network.
	released	The template is active. It can be used to deploy configuration to the network. The template cannot be edited or deleted. The status of the template cannot be changed to draft if it has been deployed.
	obsolete	The template is inactive and cannot be used to deploy new configurations to the network, but maintains existing configuration instances.
Target Labels¹	—	The target-label values configured in the `icm_descriptor` resource file in the configuration intent type Target labels, combined with device scope, filter template targets by NE.
Intent Type	—	The configuration intent type the template is based on
Intent Type version	—	The version number of the intent type
Config Form	—	The intent type schema form the template is using. The intent type can have one or more schema forms: a template incorporates one form.
Config Form State	Up-to-date	The config form in use by the template matches the schema form in the intent type.
	Outdated	The config form in use by the template is no longer aligned with the intent type as a result of an intent type update. Operational actions, such as audits, will be performed against the previous version, not the updated version. The template can be cloned with the new values to create a copy of the template that incorporates the new schema form.
	Detached	The schema form used to create this template is deleted or otherwise unusable by the template. The template can still be audited or aligned, but it cannot be cloned, and new deployments cannot be created, including by migration.
	Processing	An update to the config form state is ongoing.
Role	Physical	The target is a physical object such as a port.
Role	Logical	The target is a configured object such as QoS.
Category¹	—	The type of physical or logical object being configured.
Device Scope¹	SROS Model	The template is intended for model driven SR OS devices.
	SROS Classic	The template is intended for classically managed SR OS devices.
	SROS Classic and Model	The template can be used for both classic and model driven SR OS devices.
	SRL Only	The template is intended for SRL devices.
	Wavence	The template is intended for Wavence devices.
	Third Party	The template is intended for non-Nokia NEs.
	All	The template can be used for any device or management type.
Flexible	True	A flexible template includes parameters that can be changed by the operator at deployment time.
Flexible	False	If all parameters are read only and have default values, the Flexible parameter is set to False.
Last Updated	—	The date and time of the most recent modification or operation performed.

Notes:

This parameter is defined in the icm_descriptor resource file in the configuration intent type.

Target filtering

When a template is deployed, the available targets are filtered based on the device-scope, target-xpath and target-labels parameters, respectively. The parameters are configured in the icm_descriptor resource file in the configuration intent type; see Descriptor resource file. Each of these parameters is optional, but at least one must be configured for the target list to be filtered.

Device scope

The Device Scope value shown in the Device Management, Configuration Templates view is based on the value of the device-scope parameter in the icm_descriptor file. The device scope parameter filters based on management type: classic or MDM.

Target x-path

Nokia predefined intent types often include a target x-path in the icm_descriptor file.

The target x-path value can be any valid network inventory x-path. For example, /nsp-equipment:network/network-element[product = '7750 SR' or product = '7450 ESS' or product = '7950 XRS'] specifies that the target must be an SR OS NE.

Target label

The target label value is not set in Nokia predefined intent types.

The target label defines the NE type, product, and version to show in the targets list.

For example:

"target-labels": {"type": "7750 SR-12", "product": "7750 SR", "version": "TiMOS-C-20.5.R2"}

When a template created from the intent type is selected and the user opens the Add Target form, the list of available targets is filtered to show only 7750 SR-12 NEs, running version 20.5 R2.

Partial strings are supported: for example, "type": 7750 SR will show 7750 SR-1 and 7750 SR-12 NEs, if present. It is not required to configure all three components, for example, if version is not configured, all 7750 SR-12 NEs are shown.

The target-xpath parameter takes precedence over the target-labels parameter: if target-xpath is configured, target-labels is ignored.

Combining parameters to create a filtered list

Filtering of targets in Device Configuration is based on the combined values of device-scope and target-xpath or target-labels, as described in the following table. The device scope parameter filters based on management type: classic or MDM. The target list is then filtered based on the target-xpath if available, or, if target-xpath is not configured, target-labels.

If the target filtering parameters are not configured correctly for your needs, the filtering may return undesired targets. For example:

if the device-scope parameter is third-party but the target-labels includes "product": "SR Linux", the filtered target list will include SR Linux NEs, although SR Linux is not a third party NE.
if the target-xpath states [product = '7750 SR'] and the target-labels states "product": "7950 XRS" the filtered target list will include only 7750 SR NEs because target-xpath takes precedence.

device-scope parameter in icm_descriptor	target definition in icm_descriptor	Targets shown
mdm	`"product":` includes SR OS NEs, such as 7750 SR	Model driven SR OS devices
classic	`"product":` includes SR OS NEs, such as 7750 SR	Classically managed SR OS devices
mdm_and_classic	`"product":` includes SR OS NEs, such as 7750 SR	Classic and model driven SR OS devices
srl	`"product": "SR Linux"` is included in the value	SRL devices
wavence	`"product": "Wavence SA"` or `"product": "Wavence SM"` is included in the value	Wavence devices
third-party	`"product":` includes non-Nokia products, for example, `"product": "Cisco"`	Devices with the specified product names, for example, Cisco
all	not configured	No filtering - all NEs are available to select

Template options

Select a template and click (Template Details) to view information about the template.

From the (Table row actions) menu, you can:

View/Edit the template

If the template Life Cycle status is draft or obsolete, it can be opened for editing from the Table row actions menu. If it is in released status, a read-only View page can be opened.
View the list of deployments using the template
Migrate deployments to another template
Deploy the template to the network
Associate the template to the network
Audit/Align deployments:
- Audit all config
  
  Audit deployments for configuration drift that may occur over time
- Align config
  
  Realign the network configuration back to the intended and defined configuration
- Align misaligned only
Delete

Delete the template. Note: the template cannot be deleted if the Life Cycle status is released.
Open in Network Intents

Open the template intent type in Network Intents to make any changes required

Attention: Be cautious when invoking bulk actions at the template level with many thousands of configuration instances as this may take many hours to complete.

Differences between classic NEs and model-driven NEs

If you are using Nokia predefined intent types audits will behave differently between classic SR OS and MD SR OS NEs.

In the case of classic SR OS targets, only those attributes defined in the associated configuration form and with a user entered value will be audited. In the case of MD SR OS targets, all attributes in the target configuration tree are audited and attributes not even in the intent type YANG tree are checked.

For example, if the deployment has two targets:

with classic SR OS NEs: the configured values of the user entered attributes on each target are checked to verify whether they match the configuration form. The alignment status is based on this check.
with MD SR OS NEs: the values of all attributes on each target are checked to verify whether they match the configuration form and each other. The alignment status is based on matching both the configuration form and the other target.

Alignments also behave differently between classic NEs and MD NEs. For MD NEs, an alignment is marked misaligned if the NE is unreachable. For classic NEs, the alignment operation checks the configuration in the NFM-P database. If the database matches the deployment configuration, the status will be aligned, regardless of the NE’s reachability.