How is service stitching accomplished?
Service stitching
When an MD-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 like service management or object troubleshooting. In order for NSP to see these services, MD service stitching must be performed. Visit the Nokia Network Developer Portal for more information.
Managing and unmanaging nodes
When MD nodes are managed, the following is required for stitching:
The sites must be discovered in alternate tables. This is achieved using the following APIs:
Either auto-stitch or manual stitching must be triggered for service stitching. This will create an entry in operational model tables.
After stitching, the user can mark the services as 'intent aware' and associate them with intents.
After a node is unmanaged, 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:
-
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.
© 2024 Nokia. Nokia Confidential Information
Use subject to agreed restrictions on disclosure and use.