Latest revision as of 16:16, 25 June 2019

VOM as a middleware

These efforts have started with this Proof of Concept. This demonstrates that it is possible to have the unmangled C symbols that sysrepo requires to dynamically load the shared library though developping the library in C++.

Read this passage from RFC 8342. VOM has the same property as the intended datastore but it is not expressed in YANG.

Advantages/Inconvenients

Advantages of using VOM over scvpp:

1. VOM offers a much more backward compatible API than VAPI.
2. VOM is used in other projects like opflex-vpp (less bugs/more contributions)
3. VOM::OM::replay can recommit configurations in case of failure of VPP
4. VOM is part of VPP so changes of definition in "api" files will be updated in VOM too by VPP maintainers.

Inconvenients:

1. VOM is very good to configure VPP but not to fetch information from it as it outputs dumps in a string format which needs to be parsed (problem of types, ...)
2. VOM stores as: (key, list(objects)). The problem is that deleting a key will delete the entire list of objects so keys SHOULD BE uniquely choosen for each object (interface, route, etc...)
3. Most VOM operations are not thread-safe
4. Supporting new features in VOM is less straightforward than in scvpp because of the heavy usage of design patterns and inheritance.

A workflow for interface management for ietf-interfaces non NMDA with VOM

Problem statement: How can an operator configure a physical interface without knowing the names they can have ?

Answer:

• For ietf-interfaces prior to NMDA RFC 7223, if you receive a <get> interfaces on interfaces-state subtree, you should answer with all existing interfaces on the system not just the one which have been created on interfaces subtree through <edit-config>.
• For ietf-interfaces after NMDA RFC 8343 and openconfig-interfaces, as there is no separate subtree for config false and config true <get> interfaces must only answer the previously configured interfaces.

Architecture for VOM

TODO