What is a configuration intent type?

Overview

NSP uses intent types to build configuration templates, which are then used to build configurations. Users can create custom intent types or import predefined intent types into NSP. Nokia provided intent types are available from the Nokia software support download site. Nokia recommends using predefined intent types where applicable.

When an intent type is imported to NSP, it is available in Network Intents, Intent Types. To be used as a configuration intent type, the intent type must be imported to Device Management, Configuration Intent Types.

Note:

The intent type must have the InfrastructureConfiguration label to be used as a configuration intent type.
The first container name in the intent type YANG must be the same as the module name.
View files for predefined intent types can be added or edited in the Network Intents, Intent Types view; see “How do I add or change a View file?” in the NSP Network Automation Guide. No other changes can be made to predefined intent types.

The configuration intent type includes one or more configuration forms, called views or schema forms in Network Intents. Configuration forms define the parameters that will be set when the configuration template is deployed. The configuration form can provide a parameter value or leave the value blank, to be set during deployment. If a parameter is not included in the configuration form, deploying the configuration template will not set that parameter on the target.

The use of multiple configuration forms allows one intent type to be used to create multiple configuration templates with different configuration parameters and different parameter values.

For example, an intent type called access port could include a default configuration form with ten blank parameters, and a simple configuration form with two parameters with set values. All configuration templates created from this intent type will configure access ports. However, you can create multiple templates, for example, one to set the two parameters to predefined values, and one or more to set the ten parameters to values of your choosing.

Device-specific intent type artifacts

Device-specific intent types are created by Nokia for a particular NE release and NE mode. The intent type is designed to configure as many as possible of the attributes supported by the device for a specific area, for example, SAP QoS or Ethernet port configuration. An example intent type artifact is SAP QoS for model-driven SR OS Release 23.7.

If a new NE release offers new features or new or updated attributes in a particular area, a new device-specific intent type will be available.

When an NE is upgraded to a new NE release, you can migrate the NE configurations to a template created from the new intent type; see How do I update an NE configuration to use a newer intent type?.

Descriptor resource file

The configuration intent type also includes a resource file, icm_descriptor.json, that provides parameters for the configuration templates created from the intent type. For intent types with the logical role, this resource file also defines whether the template can be deployed to multiple targets in one deployment, and whether it can be deployed with other templates in one deployment.

The following table describes attributes that can be provided in the icm_descriptor.json file.

Attribute	Mandatory	Default value	Available values	Description
category	Yes	—	Any string, such as Port, Card, or QoS	The category is used primarily for logical grouping of the templates created using the intent type.
role	Yes	—	physical logical	The physical role refers to physical configurations such as ports, while logical refers to logical configurations, such as QoS.
description	No	—	Any string	—
device-scope	Yes	—	mdm classic mdm-and-classic wavence third-party all	The device scope declares the device types the templates are intended for.
select-template¹	No	multiple for logical role single for physical role	multiple single	This parameter declares whether the template can be deployed along with other templates in the same deployment.
select-target	No	multiple	multiple single	This parameter declares whether the user will be able to select single or multiple targets when the template is deployed.
target-xpath	No	NEs for logical role For physical role, the default varies based on category.	Any valid network inventory x-path	The x-path is used to fetch the list of targets during deployment creation.
targets¹	No	—	targets = [ {"NSP", "NSP"}]	The targets parameter allows a target to be provided that differs from the role defaults. For example, for NGE configuration, the target is NSP. The parameter is configured as a key-value pair.
target-labels	No	—	JSON string with target-specific content: target-labels: { "type": “NE type”, "product": "product name", "version": "NE release version" } Example: target-labels : { "type": "7750 SR-12", "product": "7750 SR", "version": "TiMOS-C-20.5.R2, TiMOS-C-22.10.R8"}²	The target-labels parameter allows the targets presented in the deployment creation form to be filtered according to the requirements of the intent type. 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 NEs, running version 20.5 R2.
labels	No	—	String with comma separated values Example: labels: "s168_96_99_acpm, SR-7750, 22.10.R8.AA1, 7750 SR, 7750 SR-12“²	The labels parameter allows the templates presented in the deployment creation form to be filtered according to the requirements of the intent type. Example: `"labels": "7750 SR-12",` When the user selects a 7750 SR-12 NE as a target and opens the Add Template form, the templates created from the intent type will be part of the filtered list of available templates. Templates with no labels will also appear in the list.
isPayloadWithMandatoryAttribute	No	false	true false	This parameter relates to brownfield discovery. If the intent type includes a mandatory value with no default value set, and this parameter is set to true, a computed default value is sent during discovery: For enum, the computed value is one of the available values (usually the first one) For integer, the computed value is the first value in the range(if present) else 0 For string, the computed value is a dummy string in the range(if present) else dummy

Notes:

If the targets parameter is set in the descriptor file, the select-template parameter must be single.
Partial strings are supported: for example, 7750 SR will show 7750 SR-1 and 7750 SR-12 NEs, if present. Wildcard characters are not supported.

See “What are the components of an intent type?” in the NSP Network Automation Guide for more information about configuring intent types, and the Intent Based Networking Framework and Input Forms tutorials on the Network Developer Portal for developer information, including use of resource files.

Target and template filtering

The target-labels and labels parameters allow filtering of targets and templates, respectively, in the deployment creation form.

If both target-labels and labels parameters are configured, filtering is based on the order in which the user selects the target or template:

If the template is selected first, the list of targets is filtered according to the target-labels parameter.

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 NEs, running version 20.5 R2.
If the target is selected first, the list of templates is filtered according to the labels parameter.

Example: "labels": "7750 SR-12",

When the user selects a 7750 SR-12 NE as a target and opens the Add Template form, the templates created from the intent type will be part of the filtered list of available templates.

You can make changes to the label and target label values after the intent type is in use in Device Configuration. After updating the icm_descriptor resource file, re-import the intent type in Device Configuration to apply the changes. Any new templates created using the intent type include the updated parameter values.

Existing templates are updated as follows:

Adding values: re-importing the intent type adds the new values to all existing templates. When the template is deployed, the template labels are update with NE details: ne-id, ne-name, type, product and version. Added details are appended to any details already present in the template labels.
Updating values: re-importing the intent type imports the changed values to the existing templates. Partial updates are allowed, for example, you can change one value in a target-label string. However, each label and target-label will be computed as unique.
Deleting values: if labels, target-labels, or both are removed from the icm_descriptor resource file, re-importing the intent type removes the values from existing templates. If the last deployment with the deleted values is deleted from a template, the labels are removed from the template.

The following limitations apply:

Filtering is not supported when multiple templates or targets are selected.
Label and target label values are learned from the template when a deployment is created or associated with the template. If the deployment is migrated to a different template, the learned values are retained. If label and target label values are present in the new template, they are appended to the learned values.

Intent type configuration form

You can update an intent type to change one of the existing schema forms or add a new schema form. For details, see the viewConfig Forms tutorial on the Network Developer Portal.

If templates were created using the old schema form of the intent type, they will have a Config Form State of Outdated after the intent type is updated and re-imported. If a required schema form has been deleted in NSP, the Config Form State is updated to Detached. Audit or align operations on an outdated or detached template will be performed using the previous values.

The only available operations for a detached template are audit and align: no new deployments can be created, and deployments cannot be migrated to the template.

Intent type details

Select an intent type and click (Intent Type Details) to view information about the intent type.

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

Open the intent type in Network Intents to make any changes required
Remove the intent type from the list of configuration intent types, if it is not in use by a template
Re-import the intent type from Network Intents

Changes to views are automatically imported.

Perform a re-import for any of the following.

To import changes made to an intent type other than changes to views
To import changes of any kind made outside NSP

Re-importing intent types

If a view or schema form in an intent type has been added, deleted, or edited in the Network Intents, Intent Types view, it is automatically updated in the Device Management configuration views.

If other changes have been made to the intent type, for example, a change to the YANG, the intent type is not automatically synched. You need to re-import the intent type to see the changes.

Important! The only changes that are automatically synched are changes made to the view files.

If a change has been made in Network Intents other than a change to a view, or if a change has been made to the intent type code or files outside NSP, for example, in a text editor, you must re-import the intent type to access the changes.