-
Notifications
You must be signed in to change notification settings - Fork 0
FAQ related to NMDA implementations
This page provides answers for common questions related to implementing NMDA.
- What does it mean for a server to be NMDA compliant?
- In which situations can <intended> differ from <running>?
- Does an NMDA compliant implementation have to expose the <operational> datastore?
- Can I find out whether a device has <intended> that can differ from <running>?
- Does a server have to expose <operational> to be NMDA compliant?
- Can an NMDA compliant device only support configuration and no operational state?
- Can an NMDA compliant device only support operational state and not be configurable?
- What if the device cannot provided an applied configuration value?
- Are devices allowed to modify the contents of <running>?
A server is NMDA-compliant if it meets these three requirements:
- It implements the new YANG libary (7895 bis).
- It uses the new YANG library to indicate that it supports .
- The list of modules, with deviations, listed in the new YANG library as being available in , accurately reflect the actual data nodes that the device can report operational state for.
Note, if a server cannot support the "applied configuration" or "operational value" for some module nodes then operational datastore specific deviations can be reported in YANG library to remove those nodes from the YANG schema associated with the operational state datastore.
For many simple systems, <intended> will be identical to <running>. However, if a system support inactive configuration (configuration that is marked as not to use) or it supports some form of template expansion of the configuration in <running>, then <intended> can be different from <running>.
No, it is not necessary.
Exposing <intended> is useful if a system supports mechanisms that allow <intended> to differ from <running>.
If <intended> always matches <running> then an implementation may choose to expose <intended> by trivially returning the same data as in <running>. This may be helpful to clients that wish to generically compare <intended> to the "config true" schema part of <operational> to determine whether all of the intended configuration has been successfully applied.
If <intended> can differ from <running> then implementations are still not required to expose <intended>, but it may be a good idea to do so to allow clients to access the intended configuration used by a device.
There is currently no easy and general mechanism to obtain the information whether a device conceptually has <intended> that may differ from <running>. Support for retrieving such datastore properties was left for future work on NETCONF/RESTCONF 2.0.
Yes, for a server to be regarded as NMDA compliant it must expose <operational>. Also see Q 1. What does it mean for a server to be NMDA compliant?.
However, an NMDA compliant server could expose <operational>, but indicate via the new YANG library that no YANG modules (and hence no data nodes) are supported in <operational>. Also see Q 6. Can an NMDA compliant device only support configuration and no operational state? for when this may be useful.
Yes. An NMDA compliant server could support <operational> but via YANG library indicate that YANG modules are only supported in <running> and are not supported in <operational>.
However, this also means that the client has no way of seeing what configuration is actually applied to the device. It can only see what the device has been asked to do by reading from <running> or <intended>.
Yes. An NMDA compliant server could support <operational> but via YANG library indicate that YANG modules are only supported in \operational> and are not supported in <running>.
The new YANG library allows for per-datastore deviations to be specified, and hence if the applied configuration value or operational state for a given data node cannot be accurately reported then this can be handled via an appropriate deviation listed in YANG library.
This allows devices to make a phased migration towards supporting accurate applied configuration and operational state. The goal is that accurate applied configuration values are reported for all configuration.
Both the existing NETCONF and YANG RFCs, and the NMDA architecture are silent on this, and do not prohibit a device from directly modifying <running> not by a client.
There are reasons why allowing the device to modify <running> is undesirable:
- It means that there is no 'single source of truth' for the contents of the <running> datastore. Rather than the client being entirely in control of its contents, it is partially manipulated by the device.
- It requires additional work on clients to track indirect changes made to <running>, and to learn of any modifications produced by the system.
- The <intended> and <operational> datastores may provide an better long term solution to modifying <running>. E.g. a device could potentially learn of system assigned identifiers from either of these datastores, which a client would be likely to be monitoring anyway to ensure that the configuration has been correctly applied.
However, it is equally acknowledged that some existing devices do modify the contents of the <running> datastore (e.g. to assign a UUID to a user, that needs to be persisted), and nothing in the NETCONF YANG architecture disallows this.