cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
55
Views
2
Helpful
16
Replies
Highlighted
Cisco Employee

stacked service models?

We are building a NSO demo for an ALU insertion use case. 

This UC requires both flow-through integration (OSS to NSO via an API), and manual integration (swivel-chair from the OSS to an NSO GUI).

For flow-through integration with a NB OSS, we want to offer an API that’s vendor-agnostic. 

This is so that the NB OSS doesn’t have to add conditional logic (if IOS do this, if ALU do this, etc.).

We need to pass in device name, port name, and a few other parameters that are common across all vendors’ implementations of the service, so in theory the NB OSS doesn’t need to know anything about the vendors’ implementations. 

For GUI & CLI use we’d like to make use of tab completion, auto-filled drop-down lists, etc.

In order to do this we need to have leafrefs etc. i.e., We need a service model that propagates some vendor-specific details out of the respective NEDs.

These 2 goals would seem to conflict with each other.

One solution would be to use stacked service models, with the vendor-agnostic model on top.

Is this the best approach?  Any alternatives that we should consider?

thanks

--Ian

1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Ian,

We are building a NSO demo for an ALU insertion use case. 

   

This UC requires both flow-through integration (OSS to NSO via an API), and manual integration (swivel-chair from the OSS to an NSO GUI).

   

For flow-through integration with a NB OSS, we want to offer an API that’s vendor-agnostic.

   

This is so that the NB OSS doesn’t have to add conditional logic (if IOS do this, if ALU do this, etc.).

   

We need to pass in device name, port name, and a few other parameters that are common across all vendors’ implementations of the service, so in theory the NB OSS doesn’t need to know anything about the vendors’ implementations.

   

For GUI & CLI use we’d like to make use of tab completion, auto-filled drop-down lists, etc.

   

In order to do this we need to have leafrefs etc.  i.e., We need a service model that propagates some vendor-specific details out of the respective NEDs.

   

These 2 goals would seem to conflict with each other.

   

One solution would be to use stacked service models, with the vendor-agnostic model on top.

   

Is this the best approach?  Any alternatives that we should consider?

You can certainly abstract away the devices using NSO. You would start by abstracting the common features into a kind of abstract device model, in YANG. Then you have three options:

a) Back the abstract device model by a traditional NSO service. You'd implement it as template (simple cases) or a combination of template and code (more complex cases). The drawback with this approach is that it would not tolerate any local changes on the device(s). All device level changes would have to flow through NSO. The good thing is that this is pretty simple and straight forward to implement.

b) Back the abstract device model by an NSO transform. I won't explain here how to implement it, suffice it to say that things typically (but not always) get a lot more complex and expensive to develop. This is the approach taken to implement support for IETF standard models on top of existing native models in devices, for example.

c) Back the abstract device model by a very smart NED. Basically ship the complexity of this mapping into a lower layer. This is the brute force approach of the wild west.

Best Regards,

/jan

View solution in original post

16 REPLIES 16
Highlighted
Cisco Employee

Ian,

You can use stacked services but there will be different services. Depends what kind of lifecycle these services will have in the future.

Now, I do believe you could construct what you want using YANG. Have you tried to use the “case” logic to map the different device types to the respective interface name schema? There are a number of examples that comes with NSO.

Regards,

Roque

Highlighted
Cisco Employee

I guess that a service created via the “lower” model won’t exist in the “upper” model, and so can’t be subsequently modified/deleted by the OSS?

Highlighted
Cisco Employee

That is what I meant by “what kind of lifecycle” you are planning in the future.

You can also have a leaf called “API” and then a “case” based on that leaf. So, if api=OSS you have certain inputs and by default api=non-OSS.

Roque

Highlighted
Cisco Employee

Ian,

We are building a NSO demo for an ALU insertion use case. 

   

This UC requires both flow-through integration (OSS to NSO via an API), and manual integration (swivel-chair from the OSS to an NSO GUI).

   

For flow-through integration with a NB OSS, we want to offer an API that’s vendor-agnostic.

   

This is so that the NB OSS doesn’t have to add conditional logic (if IOS do this, if ALU do this, etc.).

   

We need to pass in device name, port name, and a few other parameters that are common across all vendors’ implementations of the service, so in theory the NB OSS doesn’t need to know anything about the vendors’ implementations.

   

For GUI & CLI use we’d like to make use of tab completion, auto-filled drop-down lists, etc.

   

In order to do this we need to have leafrefs etc.  i.e., We need a service model that propagates some vendor-specific details out of the respective NEDs.

   

These 2 goals would seem to conflict with each other.

   

One solution would be to use stacked service models, with the vendor-agnostic model on top.

   

Is this the best approach?  Any alternatives that we should consider?

You can certainly abstract away the devices using NSO. You would start by abstracting the common features into a kind of abstract device model, in YANG. Then you have three options:

a) Back the abstract device model by a traditional NSO service. You'd implement it as template (simple cases) or a combination of template and code (more complex cases). The drawback with this approach is that it would not tolerate any local changes on the device(s). All device level changes would have to flow through NSO. The good thing is that this is pretty simple and straight forward to implement.

b) Back the abstract device model by an NSO transform. I won't explain here how to implement it, suffice it to say that things typically (but not always) get a lot more complex and expensive to develop. This is the approach taken to implement support for IETF standard models on top of existing native models in devices, for example.

c) Back the abstract device model by a very smart NED. Basically ship the complexity of this mapping into a lower layer. This is the brute force approach of the wild west.

Best Regards,

/jan

View solution in original post

Highlighted
Cisco Employee

and another thing

it is common in service-models to refer to interfaces and as you say you would like drop-downs and CLI tab completion a leafref means referencing down into the device-tree.

So the good thing is automatic tab completion and drop-downs The draw-back is that the actual NED (device-type) ripples up into the service model.

In many cases we do the service models agnostic and the interface is just a string And the mapping code does the mapping to the concrete device model

Then you have to programmatically add

CLI completion

Validation

Web UI drop-down

/stefan v

Highlighted
Cisco Employee

 

Stefan - do you have any information about how to programmatically add CLI completion? This is the scenario we are trying to address. We want the tab completion and UI dropdown for when we demo using NSO directly, but we want the model to stay agnostic for the NBI.

 

 

So for example, where we are adding IOS and IOSXR routers to a list of devices, ideally we¹d like to use a single list of devices, but that means we can¹t have different leafrefs for the interfaces. We have to have two separate lists - IOS devices and IOSXR devices.

 

 

Roque - we¹ve tried the different conditional logic supported by YANG, but I don¹t think it¹s possible to do what we want. For the scenario I¹ve mentioned above we¹d need to either union the leafrefs or use the same node name but with different ³when² clauses. Neither of these are supported.

 

 

Jan - I think we can rule out building a new NED. It seems the first option is similar to the stacked service idea, but we upload all of the device information into our abstract model, and the service model on top references that? Is it possible to get more information on NSO transformations? I¹ve not seen this in any of the documentation.

 

 

Thanks,

 

Michael

 

Highlighted
Cisco Employee

 

Thanks all for the advice.

 

 

Stacked service models don't seem to be a good idea, for the reasons Roque has pointed out.

 

We definitely want to use existing NEDs and not write new ones.

 

 

The remaining option is Stefan's "programmatically add: CLI completion, Validation, Web UI drop-down" -- either that or lose those features.

 

Can somebody point us to any documentation on how that is done?

 

 

thanks

 

--Ian

 

Highlighted
Cisco Employee

 

a) is my favourite.

 

/klacke

Highlighted
Cisco Employee

Ian,

Thanks all for the advice.

Stacked service models don't seem to be a good idea, for the reasons Roque has pointed out.

Which reasons? I tried to look in the thread, but didn't quite get what you refer to. This is by far the easiest approach, so let's not dismiss it until we have fully understood that it's not applicable. We definitely want to use existing NEDs and not write new ones.

Sure, I agree with that.


The remaining option is Stefan's "programmatically add: CLI completion, Validation, Web UI drop-down" -- either that or lose those features.


Can somebody point us to any documentation on how that is done?

What Stefan is talking about is add-on component(s) for making the stacked services option nicer, so that hitting <tab> will complete the names of interfaces etc based on the concrete device type, or similarly in the webui. This can be done in other ways as well. The NSO man page "clispec" mentions completionpoint, have a look there. For the webui, you have to do web programming.

We also have the transform option. If the mapping from the abstract model to the concrete device models is simple, this will not take very long to implement. It requires use of software components that have been developed by other projects, however, that are not part of the NSO package. I can explain further in unicast.

Best Regards,
/jan

Highlighted
Cisco Employee

 

The problem that Roque brought up with the stacked models is that anything done to the service via the lower model isn’t visible in the upper model.

 

For example, I create a service via the NBI (upper model), then I modify that service via the GUI or CLI (lower model). 

 

Those changes are not reflected in the upper model.

 

…is that correct?

 

--Ian

 

Highlighted
Cisco Employee

 

Ian,

 

 

The problem that Roque brought up with the stacked models is that anything done to the service via the lower model isn’t visible in the upper model.

 

 

For example, I create a service via the NBI (upper model), then I modify that service via the GUI or CLI (lower model).

 

Those changes are not reflected in the upper model.

 

 

…is that correct?

 

--Ian

 

 

Yes, with a service the information always flows from the service model downwards. That's why it's so much easier to work with than other alternatives. This is primarily a concern if you need to 'sync-from' the device in the network, e.g. if somebody is making local changes on the devices that you want to keep.

 

 

If that is the case, and it's an important enough use case to warrant the extra cost, you'd have to either develop a service-reconciliation application, or develop a transform. From a high-level, logical perspective these alternatives are pretty similar. A transform is something that always acts automatically behind the scenes. Just sync-from, and the next time an operator shows the abstract data it is what you'd expect. A service-reconciliation app on the other hand is something the operator would explicitly run after the sync-from.

 

 

Technically speaking we also have the alternative with a special multi-device NEDs, but I agree with you this does not look tempting.

 

 

Best Regards,

 

/jan

 

Highlighted
Cisco Employee

 

Ian, do not read you on this.

 

There is no association between interfaces and models

 

/Stefan

Highlighted
Cisco Employee

 

Thanks Jan,

 

 

Here’s my understanding of where we are:

 

 

What we need is 2 interfaces onto the same service, one flow-through and one CLI.

 

The differences between the various NEDs encourages a hardened service model, so that we have tab completion etc.

 

The flow-through interface requires a vendor-agnostic service model, so that the OSS doesn’t have to know about those same differences.  i.e., a softer model.

 

Using stacked models (one hard, one soft) introduces issues that require some non-trivial development to overcome, as you describe below. 

 

What we really want is 2 facades onto the same model (not 2 models), but I understand why this is not easily done.

 

 

So my conclusion is that a soft model is better in this case.  The need for a vendor-agnostic model overrides the desire for tab completion etc.

 

That way we get most of what we want, without a large development effort.

 

 

We wanted to make sure that we’ve explored all the avenues and not missed something (we’re newbies).

 

--Ian

 

Highlighted
Cisco Employee

 

  1. Hmm.  Just when I thought we'd reached a conclusion :-)

 

 

Putting aside stacked models, because maybe we've gone down a rathole: 

 

Do you understand what we're trying to accomplish?

 

Do you have a proposed solution?

 

 

Thanks

 

--Ian

 

Content for Community-Ad
Cisco Community August2020 Spotlight Award Winners
This widget could not be displayed.