I asked WAE team (copied) on this and Derek T wrote:
WAE 7.0 uses NSO 22.214.171.124 runtime under the hood. To interface to NSO for the service orchestration stuff, we are using NSO clustering, with WAE setting up a remote-node cluster to NSO. It uses this for retrieving and pushing device configurations to NSO.
There is no requirement for the different parts of an NSO cluster to be on the same version, that is the nature of clustering you need to upgrade members individually, even though you recommend to use the same version. Of course I am sure eventually there may come a version of NSO that will not work with WAE 7.0.
More important is the NED, WAE 7.0 is interacting with the devices directly via the device models, so if these change things may break. A question is then in a cluster must the NEDs be identical or is it enough that the remote (I,e, NSO) has a newer NED that introduces no incompatible changes. Another question is will WAE software support make it possible to alter the NEDS on the WAE side like we can do on the NSO side (always assuming they don’t introduce incompatibilities) decoupled from the main software release cycle.
We’ve not completely answered your question yet – I’ve not looked at the cluster features that deeply, but at least we reformulated it and added some info.
My understanding is that WAE 7.0 will not be doing direct “writes” to the network (at least initially) and will go via NSO for all writes. The only exception is when doing PCEP or BGP-LS, there WAE will be using XTC.
The way WAE would write to the network is by treating NSO as a device-node (DN). WAE itself will be designed with its own YANG run-time (i.e. use NSO internally as a platform to host the NIMOs).
So there will be some dependency between service-models/creation-mappings in WAE and the NEDs in the corresponding NSO being used as the DN.
Don’t think this has been fully finalised yet. I’ve copied Martin to keep me honest here.