How do I automatically discover cross-domain links?

Note: Automatic cross-domain link discovery is not available for WaveSuite. The feature is supported only with the Ciena Navigator Network Control Suite (fMCP).

For discovery to work, deploy the Ciena T-API mediation package from your Nokia software delivery. The archive name follows the pattern nsp-tapi-ciena-2-5-0-26.4.1-rel.nnn.zip, where nnn is the build identifier for your drop.

Automatic cross-domain link discovery has the following limitations:

Initial CDL creation: This feature primarily supports the automatic creation of CDLs when LLDP data becomes available.
CDL updates on connection changes: Automatic updates to existing CDLs are not supported when LLDP data changes. If a connection between an IP and optical port is altered, the existing CDL for that connection is marked as misconfigured. New CDLs for the revised connections are not automatically created; you must manually run the CDL discovery procedure in such scenarios.
CDL removal: CDLs are automatically removed if their associated IP or optical ports are removed. CDLs are not automatically removed if only the LLDP information is withdrawn from optical notifications.
CDL discovery on new IP ports: CDLs are not automatically discovered when new IP ports are added. After you manage IP nodes, you must manually initiate the CDL discovery procedure to discover CDLs on these new ports.

Automatic discovery identifies potential cross-domain links by analyzing LLDP information or traffic-pattern correlations between router and optical ports. Discovery produces candidate CDLs that can be reviewed and committed. Automatic cross-domain link discovery is disabled by default and must be enabled in configuration before you use the discovery controls in the UI.


1	Enable automatic cross-domain link discovery using one of the following methods: Before or during deployment, set `cdlAutoDiscovery` to `true` under `nrcx.featureSupport` in values.yaml. The default is `false`, which leaves the feature disabled. For example: `nrcx:` `featureSupport:` `cdlAutoDiscovery: true` Note: When you enable or change this flag only in values.yaml, apply the change by upgrading or reinstalling the NSP Helm release using that file, following the procedure in the NSP Installation and Upgrade Guide for your environment. Restarting an individual pod without upgrading or reinstalling the Helm release does not apply new chart values from values.yaml. After deployment, you can enable the feature by editing the NRCX Tomcat ConfigMap in your NSP cluster namespace without changing Helm values. Set `CDL_auto_discovery` to `"true"` in the `FeatureSupport` section (merge the property into the existing block if `FeatureSupport` is already present), for example: `FeatureSupport {` `CDL_auto_discovery = "true"` `}` To edit the ConfigMap from a workstation that has cluster access, you can use a command such as the following (substitute the ConfigMap name and namespace for your deployment): `kubectl edit configmap nrcx_tomcat_configmap_name -n nsp_cluster_namespace` After you save the ConfigMap, continue to the next step to restart the NRCX Tomcat pod. For this method, a pod restart is enough to load the change; you do not need to uninstall, reinstall, or upgrade the Helm release.
2	If you used the ConfigMap method in the previous step, use one of the following approaches to restart the NRCX Tomcat pod so the running application loads the updated configuration. For example, delete the pod and allow Kubernetes to recreate it. The replacement pod mounts the updated ConfigMap (substitute the pod name and namespace for your deployment): Note: If you used the values.yaml method instead, skip this step and complete the Helm-based install, upgrade, or reinstall with the updated values.yaml as described in the NSP Installation and Upgrade Guide. New pods receive chart values from that release; do not use this pod restart in place of upgrading or reinstalling the Helm release when your change is only in values.yaml. `kubectl delete pod nrcx_tomcat_pod_name -n nsp_cluster_namespace` Note: Alternatively, you can restart the NRCX Tomcat workload using the kubectl rollout restart command on the corresponding deployment, if your environment supports it.
3	Open IP/Optical Coordination, Cross Domain Link.
4	Click the Discover Cross Domain Links icon. The Discover Cross Domain Links form opens.
5	Specify one or more LLDP discovery methods.
6	Choose a Context Type and, if required, select one or more Discovery Targets from the displayed list.
7	Click Start and monitor the Discovery Progress until completion. Close the Discover Cross Domain Links form.
8	As required, perform How do I delete cross-domain links? to delete a cross-domain link.
9	As required, click Commit inline with any discovered cross-domain link to commit that link. Note: You can auto commit cross-domain links also. See How do I automatically commit cross-domain links? to auto commit cross-domain links. Note: In a scenario where IP/Optical Coordination was added to an existing NSP deployment, cross-domain links may have been provisioned previously using NFM-P or NSP. A REST API call can be used to migrate these links from the common NSP store to IP/Optical Coordination. For more information, visit the Nokia Network Developer Portal at https://network.developer.nokia.com/api-documentation. End of steps