NED Internals

A NED has a version associated with it. A version consists of a sequence of numbers separated by dots ('.'). The first two number defines the major and minor version number, the third number defines the maintenance version number and any following numbers are patch release version numbers.

For instance, the 5.8.1 number indicates a maintenance release (1) on the minor release 5.8 and 5.8.1.1 indicates a patch release (1) on the maintenance release 5.8.1. Any incompatible YANG model change will require the major or minor version number to change, i.e. any 5.8.x version is to be backward compatible with the previous.

When a NED release is replaced with a later maintenance/patch release with the same major/minor version, NSO can do a simple data model upgrade to handle stored instance data in CDB. There is no risk that any data would be lost by this sort of upgrade.

On the other hand when a NED is replaced by a new major/minor release this becomes a NED migration. These are non trivial since the YANG model changes can result in loss of instance data if not handled correctly. With CDM the first and most important feature in NED migration is that both the old and new NED releases can be loaded at the same time and analysis of the YANG models and instance data can be performed before NED migration is attempted.

Figure 1. NED Version Scheme

Backward Incompatibilities

NED Settings

NED settings are YANG models augmented as config in NSO that controls behavior of the NED. These setting are augmented under /devices/global-settings/ned-settings, /devices/profiles/ned-settings and /devices/device/ned-settings. Traditionally these NED settings have been accompanied by a when expression specifying the ned-id for which the settings are legal. With the introduction of CDM such when expressions on specific ned-ids are not recommended since ned-id will change with NED releases.

Instead there is a need to introduce a 'family' identity that becomes base for all NED releases for a certain family. The when expressions can then use derived-from syntax to be legal for all NED releases in the family.

Schema Traversals in NED Java code

As stated above schema traversal works as before until a mount-point is reached in the path. At that point a lookup of the current mount-id (ned-id) is necessary to resolve any ambiguities in module name, prefix or XML namespace. Since the NED by definition works on devices under a NED any schema traversal in NED code falls under the latter case.

Pre CDM retrieving a CSNode from the Maapi Schema for a path was as simple as calling the findCSNode(Namespace, Path) function.

private  MaapiSchemas.CSNode getCSNode(String path) throws MaapiException {
  return schemas.findCSNode(Ncs.uri, path);
}

With CDM the original findCSNode(Namespace, Path) still exists for backward compatibility but in the NED code case all paths are under a mount-point and hence this function will return an error that a lookup cannot be performed. The reason for this is that a maapi call to the NSO service is necessary to retrieve the mount-id for the device. This is accomplished with a mount-id callback MountIdCb(Maapi, Th) which takes a Maapi instance and optionally a current transaction.

private  MaapiSchemas.CSNode getCSNode(String path) throws MaapiException {
  return schemas.findCSNode(new MountIdCb(this.mm, -1), Ncs.uri, path);
}