When an MDM-managed NE with existing service configurations is discovered, these configurations are not auto-populated into the operational service model, but are instead placed into an alternate table space. This means that these service configurations cannot be seen by NSP functions such as service management or object troubleshooting. In order for the NSP to see these services, service stitching must be performed. NSP uses a service stitching algorithm to stitch these MDM-managed service sites into single service entities based on service type and predefined, corresponding algorithm. These services are persisted in the NSP database, making them visible (read-only) from the NSP’s service management views. Users can then associate the services to a template, which would enable full lifecycle management and CRUD support. Service stitching can be triggered manually using an API, or by enabling auto-stitch.

The following service types and their predefined, corresponding algorithms are supported for service stitching:

Table 4-1: Supported service types and algorithms for stitching

Note: The required artifacts for service stitching are contained in the svc-mgt-artifacts-common bundle, which can be obtained from the artifacts section of the Nokia Support Portal.

Service stitching can be manually triggered using the POST: (https://{{server}}/restconf/data/nsp-service-intent:stitchservices) API. The following is an example of the request body:

{

"input":{

"service-type": <service-type>,

"algorithm": <name-of-algorithm>,

"sites":["2.2.2.2","3.3.3.3]

}

}

where

service-type is either eline, elan, ies, or l3vpn

name-of-algorithm is the name of a supported algorithm that corresponds to the service-type

sites is a list of one or more MDM-managed service sites

Visit the Nokia Network Developer Portal for more information.

By default, the automatic stitching of services is disabled. Users can either stitch a service manually using the service stitching API, or enable auto-stitching of specific service types and predefined, corresponding algorithms using the auto-stitching API. Automatic service stitching can be enabled using the POST: (https://{{server}}/restconf/data/nsp-service-stitch:nsp-service-auto-stitch-configs/nsp-service-auto-stitch-config={{service-type}} API. Setting an algorithm’s admin-state to ‘unlocked’ enables automatic service stitching for that algorithm. The following is an example of the request body, where ‘eline’ was used as the service-type.

{

"nsp-service-stitch:nsp-service-auto-stitch-config": [

{

"service-type": "eline",

"admin-state": "unlocked",

"algorithm-config": [

{

"algorithm": "evi",

"admin-state": "locked"

},

{

"algorithm": "vcid",

"admin-state": "locked"

},

{

"algorithm": "route-target",

"admin-state": "locked"

},

{

"algorithm": "service-name",

"admin-state": "unlocked"

},

{

"algorithm": "local",

"admin-state": "locked"

}

}

]

}

If an MDM-managed NE is unmanaged after service stitching has been successfully performed, the sites/endpoints/tunnel-bindings are deleted from the services, but empty services will persist in the operational model. If a user wants to delete these services, they must do so manually. The sites in the alternate tables are automatically deleted after the node is unmanaged. Should any remain, they must be deleted manually as well.

If the user re-manages the same node, the following behavior will occur:

• The sites will be discovered in alternate tables

• No entry will be made in operational model tables until stitching (automatic or manual) is used to stitch the services

After stitching occurs, there is no guarantee that the same number of services will stitch as when the node was previously managed. This is dependent on the stitching algorithm. The same name is also not guaranteed.

If the empty services were not deleted, there is no guarantee that the newly-stitched sites will attach with those services.