openconfig/ietf models in services

[rhinst001]

Is anyone out there using any of the standards-body models in their service models (not just NEDs)? I've been curious about the idea of trying out openconfig models as the bottom level of my stacked services architecture for some time and would like to know what others' experiences with it might be. Or if anyone hasn't tried it but can think of pros/cons, I'm eager to listen.  Thanks!

[snovello · Accepted solution]

Ietf network models are actively used in cisco crossworks network controller (CNC). The l3nm rfc9182 and l2nm rfc9291 have been there a while and are used in production, the new networking slicing model draft-ietf-teas-ietf-network-slice-nbi-yang-04 is also being worked on. CNC embeds an NSO instance, so there are function packs that implement these models. The included templates create L3VPNs and EVPN on IOS-XR and IOS devices based on segment routing and supporting traffic engineering. The models have been built as examples and have been extended in the field for other device types. CNC not only includes NSO, it also includes service health monitoring following the architecture described in draft-ietf-opsawg-service-assurance-architecture-13, which enables flexible user defined service health monitoring which enables exactly those KPIs that the implemented services require you to monitor.

On whether to use openconfig (OC) models as your lowest layer RFS. I advise against. Say you do this, you will have to write a mapping fhom the OC model to each of the different device models. The mapping may be hard or impossible to write because the source and destination models are both predefined. Neither the device model writer nor the OC model writer is working to requirements that you need to map between their models.

I will give a simple example, we identify leafs in the model that correspond to the same function. OC model has enum enable/disable but in the device we have added some intelligence and have disable/enable-if-a/enable-if-b. Now there is no possible mapping for this leaf. In practice there will be many similar cases.

Also the OC is not designed to be the lowest level RFS for your use-case, it is designed as a model that a device can implement. It has all sorts of dependencies on other OC models and implements many features you are not interested in and likely misses feature you need.

On the otherh and writing a low level RFS that is specifically built for your use case - typically a template only service - is a pretty simple exercise with NSO

[u.avsec]

We (have to) use MEF models for some services. Also been involved with projects based on ietf models in my previous life.

In both cases the models were used on the top level actually. That is because of their biggest pro. It is a standard so whoever wants to integrate with you knows how to do it without the need for much coordination.

Con was always the fact that the use cases don't use everything in the actual standard model. So there is bunch of additional knobs and buttons which, if not hidden somehow, confuse people, even if those buttons aren't actually mapped to something.
So that is another con; standard models might not be the most user friendly if used directly via NSO GUI.

So there is always this question "should we go full on standard or should we make something that makes sense for us as our base and put the standard model on top for 'easy' integration".

[snovello]

Yang allows you to define deviations. It’s a formal way of specifying all the parts of a model that have not implemented, or implemented differently. That is exactly to deal with partially implementing a model that you do not want to implement completely.