NSO service without real device configuration

[Oleksii Maksymov]

Hello!

Our customer uses NSO only for part of his devices. But there are certain parameters, which should be unique/negotiated on all the devices. One simple example - EVPN EVI. Also, it may be the VLAN number for hierarchical services, where the access level is not configured using NSO.

One solution would be to reserve a certain range for NSO usage, but there are also other parameters for which it is hardly achievable. So my question is - can I create a "service", which will not use any "device" and real configuration but will be just a CDB element. That way the customer can later use that parameter in other services using leafref, or check for taken values/current states using northbound API from other systems.

Designwise is this ok or is it better just to maintain a separate DB, and use python in NSO services to query those parameters?

[snovello]

Hello,

yes absolutely this is a very normal pattern in almost all service modelling. Its just some yang model where you store data. You can look at the examples in NSO, there is a l3vpn example where for example topology information and qos policies are modelled outside of a service and queried there. Also there is the resource allocation package for allocating numerical or ip address type resources.

The other pattern where agreed values or resources are stored outside is also used. This is typically where there are existing DBs or values that are important to make widely available outside of NSO. If the data is stored in NSO you probably need to a user group with only permissions to query the relevant data. In that case those values tend to be passed into NSO via the NBI, but you can also have logic in NSO to query oiutside DBs, there is one good example in the NSO github of that querying pattern.

[Oleksii Maksymov]

Do you mean this example?

As I can see, all qos parameters are modeled and used in there. If you mean some other example - can you please share a link? At the moment I feel like using external DB will be easier, but I still want to investigate cases of using CDB just as a data storage, without some actual configuration.

Thanks in advance!

[snovello · Accepted solution]

Yes that is the example, that yang model is either a copy or based on the examples within the NSO installation under $NCS_DIR/examples.ncs/service-provider/ which show different ways of implementing a similar yang model. THose are the ones I was referring to. You can see there that you have a layer 3 VPN service, which has some simple qos parameters such as a QoS policy, and a bandwidth, but that other data is defined outside of the service in the qos policy definition. Similarly there is a topology model there which provides the service logic the data to pick which PE to configure when you select a CPE, and also what interfaces to configure on the two devices.

Both are just examples of storing data outside of the service. You also mention that your specific goal is to store values which need to be uniquely allocated, which is a also requires storing data that may or may not be configured outside of a service but is a different use case.

NSO comes with a resource manager package that is doing the use case you mention. It is not included in the installation (it has a separate release cycle from the rest of NSO). If you are iinterested you could look at its yang model to see how it represents the storing of unique values. The yang model is of course  simple. Within a resource pool there are requests for resources (configurable) and allocations (read only and contains the allocated value). It provides numeric (your case) and IP address pools - download is here https://software.cisco.com/download/home/286323467/type/286283941/release/5.8.2.1

On the question of which is better whether to store this data in NSO or in your other DB, I would guess you are not going to create a new DB just for storing these common values. Since your use case is spanning devices in and out of NSO, there is very probably an external DB already that stores data covering the complete use case. In that situation any common values such as those you mention that are use in and out of NSO should probably be there as well. Then you either query them in the service logic, or simply pass them to NSO via the NBI at the point of creating a service. Passing in the values is usually the simplest approach if the values are outside NSO and there is an application above NSO that is automating the end to end use case. Querying would be done if  you want to keep the NBI as simple as possible, maybe because you are manually creating services via the NSO cli or web interface. There is an example package to do that here https://github.com/NSO-developer/external-id-allocation.