Network Services Orchestrator (NSO) v5.7
NSO 5.7

Setting up LSA deployments

LSA setup

The purpose of the upper CFS node is to manage all CFS services and to push the resulting service mappings to the RFS services. The lower RFS nodes are configured as devices in the device tree of the upper CFS node and the RFS services are located under the /devices/device/config accordingly.

This is almost identical to the relation between a normal NSO node and the normal devices. However there are differences when it comes to commit-parameters and to the commit-queue and there are also some other specific features that are special to LSA.

In a deployment of an LSA cluster all the nodes can have the same version of NSO running this called Single Version Deployment in contrast to deployments where different versions of NSO are running Multi Version Deployment.

The choice between Single Version Deployment and Multi Version Deployment is dependent on the functional needs. The former is far easier to maintain and is a good starting point. It is always possible to migrate from a Single Version Deployment to a Multi Version Deployment, the opposite is a lot harder.

Only the upper CFS node is affected of the choice between Single Version Deployment and Multi Version Deployment.

RFS node prerequisites

Changes to ncs.conf

Here we expect the lower RFS nodes to be already configured and setup as stand-alone nodes. This implies also that the distribution of devices that each lower RFS node manages are already decided and setup.

Also the actual RFS services need to be implemented and loaded as packages.

All in all the RFS nodes are ordinary NSO nodes managing a certain number of a devices and containing a number of RFS. The only other requirement is that these nodes enable NETCONF communication north-bound since this is how the upper CFS node will interact with the lower RFS nodes. To enable NETCONF north-bound the following config snippet is necessary in ncs.conf on the lower RFS nodes: 

  <netconf-north-bound>
    <enabled>true</enabled>
    <transport>
      <ssh>
        <enabled>true</enabled>
        <ip>0.0.0.0</ip>
        <port>2022</port>
      </ssh>
    </transport>
  </netconf-north-bound>

Single Version Deployment

The lower RFS nodes as devices

In the upper CFS node the lower RFS nodes are configured as devices in the /devices/device tree. These devices are communicating via NETCONF and the ned-id must be set to tailf-ncs-ned:lsa-netconf or ned-id derived from that. This ned-id is set under /devices/device/device-type/netconf/ned-id for each lower RFS node.

The example examples.ncs/getting-started/developing-with-ncs/22-lsa-single-version-deployment illustrates the different steps to set up an LSA cluster.

In the example the upper CFS node is called upper-nso and there are two lower RFS nodes called lower-nso-1 and lower-nso-2 respectively. The device configuration in the upper CFS node is the following: 

admin@upper-nso% show devices device | display-level 4
device lower-nso-1 {
    lsa-remote-node lower-nso-1;
    authgroup       default;
    device-type {
        netconf {
            ned-id lsa-netconf;
        }
    }
    state {
        admin-state unlocked;
    }
}
device lower-nso-2 {
    lsa-remote-node lower-nso-2;
    authgroup       default;
    device-type {
        netconf {
            ned-id lsa-netconf;
        }
    }
    state {
        admin-state unlocked;
    }
}

Note

The RFS nodes has a lot more configuration than what is visible through the RFS NED package, out-of-sync will thus be frequent and must therefore be expected. Hence it is a strong recommendation to accept the lower RFS nodes to be out of sync. The following command will handle this. 

admin@upper-nso% set devices device lower-nso-* out-of-sync-commit-behaviour accept

Device compiled RFS services

On the upper CFS node we need to load device compiled RFS YANG models that comes from the lower RFS nodes. This resembles the way we compile device YANG models in normal NED packages.

For this purpose the ncs-make-package tool has a specific argument --lsa-netconf-ned which creates a basic package that compiles the RFS YANG models with the ned-id tailf-ncs-ned:lsa-netconf as default.

The Makefile of the example uses the tool ncs-make-package to create a NED package in the upper-nso based on the RFS YANG models from the lower RFS node lower-nso-1. 

upper-nso/packages/rfs-vlan-ned:
        ncs-make-package --no-netsim --no-java --no-python           \
            --lsa-netconf-ned package-store/rfs-vlan/src/yang        \
            --dest $@ --build $(@F)

The ncs-make-package tool will in this example create a NED package for the rfs-vlan service.

--no-netsim no netsim is needed in the example as an actual NSO node will be running.

--no-java, --no-python as the services running on the upper CFS node are pure template services so no java or python code needs to be generated.

--lsa-netconf-ned package-store/rfs-vlan/src/yang the package to be generated is an LSA NETCONF NED based on the YANG files of the service on the lower RFS node

--dest $@ the name of the destination directory. The special make variable $@ denotes the target in the Makefile, in this case it will be upper-nso/packages/rfs-vlan-ned

--build build the package after it has been created. This is the same as executing the command: make -C upper-nso/packages/rfs-vlan-ned/src

$(@F) is the name of the package, this is a special make variable meaning the filename of the target, in this case it is rfs-vlan-ned

In the directory upper-nso/packages/rfs-vlan-ned/src you can find the generated Makefile of the package: 

all:	fxs
.PHONY: all

# Include standard NCS examples build definitions and rules
include $(NCS_DIR)/src/ncs/build/include.ncs.mk

SRC = $(wildcard yang/*.yang)
FXS = $(SRC:yang/%.yang=ncsc-out/modules/fxs/%.fxs)
DIRS =  ncsc-out ../load-dir

NCSVER     = $(shell $(NCS) --version | sed 's/\([0-9]*\.[0-9]*\).*/\1/')
CISCO_NSO  = $(NCS_DIR)/packages/lsa/cisco-nso-nc-$(NCSVER)
NED_ID_ARG = --ncs-ned-id tailf-ncs-ned:lsa-netconf

YANGPATH   =$(CISCO_NSO)/src/yang

NCSCPATH   = $(YANGPATH:%=--yangpath %)

fxs: $(DIRS) ../package-meta-data.xml ncsc-out/.done
.PHONY: fxs

$(DIRS):
	mkdir -p $@

../package-meta-data.xml: package-meta-data.xml.in
	rm -rf $@
	cp $< $@;                                           \
	chmod -w $@

ncsc-out/.done:	$(SRC)
	$(NCSC) --ncs-compile-bundle yang                   \
	    --ncs-device-dir ncsc-out                       \
	    --fail-on-warnings                              \
	    --ncs-device-type netconf                       \
	    $(NCSCPATH)                                     \
	    $(NED_ID_ARG)                                   \
	    $(NCSC_EXTRA_FLAGS)
	cp ncsc-out/modules/fxs/*.fxs ../load-dir
	for f in `echo ../load-dir/*.fxs`; do \
	   true; \
	done
	touch ncsc-out/.done

clean:
	rm -rf $(DIRS)
	rm -rf ../package-meta-data.xml
.PHONY: clean

In this makefile we find a variable 

           NED_ID_ARG = --ncs-ned-id tailf-ncs-ned:lsa-netconf

which tells NSO this is an LSA NETCONF NED and will be handled as such. Also note the YANG models are compiled using the --ncs-compile-bundle option this ensures the YANG compiler to compile all the YANG models in the correct order based on dependencies among the models.

Note

When a service YANG model from the lower RFS node is compiled as a NED for the upper CFS node there are caveats correlated to this. The original RFS service YANG model can have dependencies to other YANG models in the lower RFS node that are not present in the upper CFS node.

The solution to this problem is to remove the dependencies in the YANG model before compilation. Normally this can be solved by changing datatype in the NED compiled copy of the YANG model, e.g. from leafref or instance-identifier to string. There will then be an implicit conversion between types, at runtime, in the communication between the upper CFS node and the lower RFS node.

It is only the NED compiled copy of the YANG model in the upper CFS node that needs to change. The lower RFS node YANG model could remain the same.

If there are dependencies on the ncs namespace in the RFS YANG models which cannot be changed a different approach is needed. To handle this configure and set up the LSA cluster as in Multi Version Deployment.

Multi Version Deployment

The lower RFS nodes as devices

In the upper CFS node the lower RFS nodes are configured as devices in the /devices/device tree. These devices are communicating via NETCONF and the ned-id for each such device must be a ned-id from a cisco-nso-nc-X.Y package where X.Y is the two first numbers in the version number of the NSO of the lower RFS node. This ned-id is set under /devices/device/device-type/netconf/ned-id for each lower RFS node.

In the example: examples.ncs/getting-started/developing-with-ncs/28-lsa-multi-version-deployment the upper CFS node is called upper-nso and there are two lower RFS nodes called lower-nso-1 and lower-nso-2 respectively. The device configuration in the upper CFS node is the following: 

admin@upper-nso% show devices device | display-level 4
device lower-nso-1 {
    lsa-remote-node lower-nso-1;
    authgroup       default;
    device-type {
        netconf {
            ned-id cisco-nso-nc-5.4;
        }
    }
    state {
        admin-state unlocked;
    }
}
device lower-nso-2 {
    lsa-remote-node lower-nso-2;
    authgroup       default;
    device-type {
        netconf {
            ned-id cisco-nso-nc-5.4;
        }
    }
    state {
        admin-state unlocked;
    }
}

Note

The lower RFS nodes has a lot more configuration than what is visible through the package cisco-nso-nc-X.Y and through the RFS NED, out-of-sync will thus be frequent and must therefore be expected. Hence it is a strong recommendation to accept the RFS nodes to be out of sync. The following command will handle this. 

admin@upper-nso% set devices device lower-nso-* out-of-sync-commit-behaviour accept

The upper CFS node has to have the same or a newer version than the version running on the lower RFS nodes. In the example all nodes have the same version running but the principle is the same to use cisco-nso-nc-X.Y ned-id to run different versions as well.

The supported versions of the lower RFS node can be seen in the directory $NCS_DIR/packages/lsa.

If the NSO version in CFS is 5.5 or greater, and the NSO version in the RFS is 5.4.x or lower, then the config /ncs-config/logs/trace-id should be set to false in ncs.conf on the CFS node. Setting it to true (or leaving it unspecified, since true is the default value) will lead to commits towards those RFS nodes failing.

Device compiled RFS services

On the upper CFS node you need to load device compiled RFS YANG models that comes from the lower RFS nodes. This resembles how device YANG models in normal NED packages are compiled.

For this purpose the ncs-make-package tool has a specific argument --lsa-netconf-ned which creates a package that compiles the RFS YANG models with the specified ned-id cisco-nso-nc-X.Y.

In the example: examples.ncs/getting-started/developing-with-ncs/28-lsa-multi-version-deployment the Makefile uses the tool ncs-make-package to create a NED package in the upper-nso for the lower-nso-1 RFS YANG model; 

upper-nso/packages/rfs-vlan-nc-5.4:
	ncs-make-package --no-netsim --no-java --no-python           \
	    --lsa-netconf-ned package-store/rfs-vlan/src/yang        \
	    --lsa-lower-nso cisco-nso-nc-5.4                         \
	    --package-version $* --dest $@ --build $(@F)

The ncs-make-package tool will in this example create a NED in upper-nso/packages for the rfs-vlan service.

--no-netsim no netsim is needed in the example as an actual NSO node will be run

--no-java, --no-python as the services running on the upper CFS node are pure template services so no java or python code needs to be generated.

--lsa-netconf-ned package-store/rfs-vlan/src/yang the package to be generated is an LSA NETCONF NED based on the YANG files of the service on the lower RFS node

--dest $@ the name of the destination directory. The special make variable $@ denotes the target, in this case it will be upper-nso/packages/rfs-vlan-nc-5.4. Note as this setup should cater for multiple versions of lower RFS nodes a naming convention needs to be used to distinguish packages compiled for those different versions of NSO.

--build build the package after it has been created. This is the same as executing the command: make -C upper-nso/packages/rfs-vlan-nc-5.4/src

$(@F) is the name of the package, this is a special make variable meaning the filename of the target in this case it is rfs-vlan-nc-5.4

In the directory upper-nso/packages/rfs-vlan-nc-5.4/src you can find the generated Makefile of the package: 

all:	fxs
.PHONY: all

# Include standard NCS examples build definitions and rules
include $(NCS_DIR)/src/ncs/build/include.ncs.mk

SRC = $(wildcard yang/*.yang)
FXS = $(SRC:yang/%.yang=ncsc-out/modules/fxs/%.fxs)
DIRS =  ncsc-out ../load-dir

MNAME      = cisco-nso-nc-5.4
CISCO_NSO  = $(NCS_DIR)/packages/lsa/$(MNAME)
NED_ID_ARG = --ncs-ned-id cisco-nso-nc-5.4:cisco-nso-nc-5.4

YANGPATH   =$(CISCO_NSO)/src

NCSCPATH   = $(YANGPATH:%=--yangpath %)

fxs: $(DIRS) ../package-meta-data.xml ncsc-out/.done
.PHONY: fxs

$(DIRS):
	mkdir -p $@

../package-meta-data.xml: package-meta-data.xml.in
	rm -rf $@
	cp $< $@;                                           \
	chmod -w $@

ncsc-out/.done:	$(SRC)
	$(NCSC) --ncs-compile-bundle yang                   \
	    --ncs-device-dir ncsc-out                       \
	    --fail-on-warnings                              \
	    --ncs-depend-package $(CISCO_NSO)               \
	    --ncs-device-type netconf                       \
	    $(NCSCPATH)                                     \
	    $(NED_ID_ARG)                                   \
	    $(NCSC_EXTRA_FLAGS)
	cp ncsc-out/modules/fxs/*.fxs ../load-dir
	for f in `echo ../load-dir/*.fxs`; do \
	   true; \
	done
	touch ncsc-out/.done

clean:
	rm -rf $(DIRS)
	rm -rf ../package-meta-data.xml
.PHONY: clean

In this makefile we find a variable 

           NED_ID_ARG = --ncs-ned-id cisco-nso-nc-5.4:cisco-nso-nc-5.4

which tells NSO this is an LSA NETCONF NED and will be handled as such. Also note the YANG models are compiled using the --ncs-compile-bundle option this makes the YANG compiler to compile all the YANG models in the correct order based on dependencies among the models.

Note

When a service YANG model from the lower RFS node is compiled as a NED for the upper CFS node there are caveats correlated to this. The original RFS service YANG model can have dependencies to other YANG models in the lower RFS node that are not present in the upper CFS node.

The solution to this problem is to remove the dependencies in the YANG model before compilation. Normally this can be solved by changing datatype in the NED compiled copy of the YANG model, e.g. from leafref or instance-identifier to string. There will then be an implicit conversion between types, at runtime, in the communication between the upper CFS node and the lower RFS node.

It is only the NED compiled copy of the YANG model in the upper CFS node that needs to change. The lower RFS node YANG model could remain the same.

The standard cisco-nso NED LSA package

The NSO release includes packages specifically tailored for LSA to be used by the upper CFS node if the lower RFS nodes are running a version different than the one on the upper CFS node. The packages are named cisco-nso-nc-X.Y where X.Y are the two most significant numbers of the NSO release (the package names changed from tailf-nso-nc-X.Y with NSO 5.4).

The supported packages can be found in the $NCS_DIR/packages/lsa directory. Each package contains the complete model of the ncs namespace for the corresponding NSO version, compiled as an LSA NED. The ned-id matches the package name.

The cisco-nso package needs to be installed in the packages directory of the upper CFS node if the RFS service contains references into the ncs name space or if the ncs namespace needs to be accessed from the upper CFS node.

If there are no such requirements the cisco-nso-nc-X.Y does not need to be installed. However, it is always needed at compile time so the right groupings and data types are used.

Please always use the cisco-nso-nc-X.Y package included with the NSO version of the upper CFS node and not some older variant (such as the one from lower RFS node) as it may not work correctly.

Example 28-lsa-multi-version-deployment

In the README file of the example: examples.ncs/getting-started/developing-with-ncs/28-lsa-multi-version-deployment the different steps how to set up an LSA cluster are described.

First build the example for manual set up. 

$ make clean manual
$ make start-manual
$ make cli-upper-nso

Then configure the nodes in the cluster. This is needed so the upper CFS node can receive notifications from the lower RFS node and prepare the upper CFS node to be used with the commit-queue. 

> configure

% set cluster device-notifications enabled
% set cluster remote-node lower-nso-1 authgroup default username admin
% set cluster remote-node lower-nso-1 address 127.0.0.1 port 2023
% set cluster remote-node lower-nso-2 authgroup default username admin
% set cluster remote-node lower-nso-2 address 127.0.0.1 port 2024
% set cluster commit-queue enabled
% commit
% request cluster remote-node lower-nso-* ssh fetch-host-keys

To be able to handle the lower nso node as an LSA node the correct version of the cisco-nso-nc package needs to be installed. In this example 5.4 is used.

Create a link to the cisco-nso package in the packages directory of the upper CFS node: 

$ ln -sf ${NCS_DIR}/packages/lsa/cisco-nso-nc-5.4 upper-nso/packages

Reload the packages: 

% exit
> request packages reload

e>>> System upgrade is starting.
>>> Sessions in configure mode must exit to operational mode.
>>> No configuration changes can be performed until upgrade has completed.
>>> System upgrade has completed successfully.
reload-result {
    package cisco-nso-nc-5.4
    result true
}

Now when the cisco-nso-nc package is in place configure the two lower nso nodes and sync-from them: 

> configure
Entering configuration mode private

% set devices device lower-nso-1 device-type netconf ned-id cisco-nso-nc-5.4
% set devices device lower-nso-1 authgroup default
% set devices device lower-nso-1 lsa-remote-node lower-nso-1
% set devices device lower-nso-1 state admin-state unlocked
% set devices device lower-nso-2 device-type netconf ned-id cisco-nso-nc-5.4
% set devices device lower-nso-2 authgroup default
% set devices device lower-nso-2 lsa-remote-node lower-nso-2
% set devices device lower-nso-2 state admin-state unlocked

% commit
Commit complete.

% request devices fetch-ssh-host-keys
fetch-result {
    device lower-nso-1
    result updated
    fingerprint {
        algorithm ssh-ed25519
        value 4a:c6:5d:91:6d:4a:69:7a:4e:0d:dc:4e:51:51:ee:e2
    }
}
fetch-result {
    device lower-nso-2
    result updated
    fingerprint {
        algorithm ssh-ed25519
        value 4a:c6:5d:91:6d:4a:69:7a:4e:0d:dc:4e:51:51:ee:e2
    }
}

% request devices sync-from
sync-result {
    device lower-nso-1
    result true
}
sync-result {
    device lower-nso-2
    result true
}

Now for example the configured devices of the lower nodes can be viewed: 

% show devices device config devices device | display xpath | display-level 5

/devices/device[name='lower-nso-1']/config/ncs:devices/device[name='ex0']
/devices/device[name='lower-nso-1']/config/ncs:devices/device[name='ex1']
/devices/device[name='lower-nso-1']/config/ncs:devices/device[name='ex2']
/devices/device[name='lower-nso-2']/config/ncs:devices/device[name='ex3']
/devices/device[name='lower-nso-2']/config/ncs:devices/device[name='ex4']
/devices/device[name='lower-nso-2']/config/ncs:devices/device[name='ex5']

or alarms inspected: 

% run show devices device lower-nso-1 live-status alarms summary

live-status alarms summary indeterminates 0
live-status alarms summary criticals 0
live-status alarms summary majors 0
live-status alarms summary minors 0
live-status alarms summary warnings 0

Now create a netconf package on the upper CFS node which can be used towards the rfs-vlan service on the lower RFS node, in the shell terminal window do; 

$ ncs-make-package --no-netsim --no-java --no-python                \
    --lsa-netconf-ned package-store/rfs-vlan/src/yang               \
    --lsa-lower-nso cisco-nso-nc-5.4                                \
    --package-version 5.4 --dest upper-nso/packages/rfs-vlan-nc-5.4 \
    --build rfs-vlan-nc-5.4

No netsim, java or python is needed as the cfs-vlan running on the upper nso is a pure template service.

The created NED is an lsa-netconf NED based on the YANG files of the rfs-vlan service: 

--lsa-netconf-ned package-store/rfs-vlan/src/yang

the version of the NED reflects the version of the nso on the lower node: 

--package-version 5.4

The package will be generated in the packages directory of the upper nso CFS node: 

--dest upper-nso/packages/rfs-vlan-nc-5.4

and the name of the package will be: 

rfs-vlan-nc-5.4

Install the cfs-vlan service on the upper CFS node. In the shell terminal window do: 

$ ln -sf ../../package-store/cfs-vlan     upper-nso/packages

Reload the packages once more to get the cfs-vlan package. In the CLI terminal window do: 

% exit

> request packages reload

>>> System upgrade is starting.
>>> Sessions in configure mode must exit to operational mode.
>>> No configuration changes can be performed until upgrade has completed.
>>> System upgrade has completed successfully.
reload-result {
    package cfs-vlan
    result true
}
reload-result {
    package cisco-nso-nc-5.4
    result true
}
reload-result {
    package rfs-vlan-nc-5.4
    result true
}

> configure
Entering configuration mode private

Now when all packages are in place a cfs-vlan service can be configured. The cfs-vlan service will dispatch service data to the right lower RFS node depending on the device names used in the service.

In the CLI terminal window verify the service: 

% set cfs-vlan v1 a-router ex0 z-router ex5 iface eth3 unit 3 vid 77

% commit dry-run
.....
    local-node {
        data  devices {
                  device lower-nso-1 {
                      config {
                          services {
             +                vlan v1 {
             +                    router ex0;
             +                    iface eth3;
             +                    unit 3;
             +                    vid 77;
             +                    description "Interface owned by CFS: v1";
             +                }
                          }
                      }
                  }
                  device lower-nso-2 {
                      config {
                          services {
             +                vlan v1 {
             +                    router ex5;
             +                    iface eth3;
             +                    unit 3;
             +                    vid 77;
             +                    description "Interface owned by CFS: v1";
             +                }
                          }
                      }
                  }
              }
.....

As ex0 resides on lower-nso-1 that part of the configuration goes there and the ex5 part goes to lower-nso-2.

Migration and Upgrades

Since an LSA deployment consists of multiple NSO nodes (or HA pairs of nodes), each can be upgraded to a newer NSO version separately. While that offers a lot of flexibility, it also makes upgrades more complex in many cases. For example, performing a major version upgrade on the upper CFS node only, will make the deployment Multi Version even if it was Single Version before the upgrade, requiring additional action on your part.

In general, staying with the Single Version Deployment is the simplest option and does not require any further LSA-specific upgrade action (except perhaps recompiling the packages). However, the main downside is that, at least for a major upgrade, you must upgrade all the nodes at the same time (otherwise, you no longer have a Single Version Deployment).

If that is not feasible, the solution is to run a Multi Version Deployment. Along with all of the requirements, the section called “Multi Version Deployment” describes a major difference from the Single Version variant: the upper CFS node uses a version-specific cisco-nso-nc-X.Y ned-id to refer to lower RFS nodes. That means, if you switch to a Multi Version Deployment, or perform a major upgrade of the lower-layer RFS node, the ned-id should change accordingly. However, do not change it directly but follow the correct NED upgrade procedure described in the section called “NED Migration” in NSO 5.7 Administration Guide . Briefly, the procedure consists of these steps:

  1. Keep the currently configured ned-id for an RFS device and the corresponding packages. If upgrading the CFS node, you will need to recompile the packages for the new NSO version.

  2. Compile and load the packages that are device compiled with the new ned-id, alongside the old packages.

  3. Use the migrate action on a device to switch over to the new ned-id.

The procedure requires you to have two versions of the device compiled RFS service packages loaded in the upper CFS node when calling the migrate action: one version compiled by referencing the old (current) ned-id and the other one by referencing the new (target) ned-id.

To illustrate, suppose you currently have an upper-layer and a lower-layer nodes both running NSO 5.4. The nodes were set up as described in the Single Version Deployment option, with the upper CFS node using the tailf-ncs-ned:lsa-netconf ned-id for the lower-layer RFS node. The CFS node also uses the rfs-vlan-ned NED package for the rfs-vlan service.

Now you wish to upgrade the CFS node to NSO 5.7 but keep the RFS node on the existing version 5.4. Before upgrading the CFS node, you create a backup and recompile the rfs-vlan-ned package for NSO 5.7. Note that the package references the lsa-netconf ned-id, which is the ned-id configured for the RFS device in the CFS node's CDB. Then, you perform the CFS node upgrade as usual.

At this point the CFS node is running the new, 5.7 version and the RFS node is running 5.4. Since you now have a Multi Version Deployment, you should migrate to the correct ned-id as well. Therefore, you prepare the rfs-vlan-nc-5.4 package, as described in the Multi Version Deployment option, compile the package and load it into the CFS node. Thanks to the NSO CDM feature, both packages, rfs-vlan-nc-5.4 and rfs-vlan-ned, can be used at the same time.

With the packages ready, you execute the devices device lower-nso-1 migrate new-ned-id cisco-nso-nc-5.4 command on the CFS node. The command configures the RFS device entry on CFS to use the “new” cisco-nso-nc-5.4 ned-id, as well as migrate the device configuration and service meta-data to the new model. Having completed the upgrade, you can now remove the rfs-vlan-ned if you wish.

Later on you may decide to upgrade the RFS node to NSO 5.6. Again, you prepare the new rfs-vlan-nc-5.6 package for the CFS node in a similar way as before, now using the cisco-nso-nc-5.6 ned-id instead of cisco-nso-nc-5.4. Next, you perform the RFS node upgrade to 5.6 and finally migrate the RFS device on the CFS node to the cisco-nso-nc-5.6 ned-id, with the migrate action.

Likewise, you can return to the Single Version Deployment, by upgrading the RFS node to the NSO 5.7, reusing the old, or preparing anew, the rfs-vlan-ned package and migrating to the lsa-netconf ned-id.

All these ned-id changes stem from the fact that the upper-layer CFS node treats the lower-layer RFS node as a managed device, requiring the correct model, just like it does for any other device type. For the same reason, maintenance (bug fix or patch) NSO upgrades do not result in a changed ned-id, so for those no migration is necessary.

Next