Under the NMDA of RFC 8342, how do the intended and operational datastores differ from running, and why can committed configuration be missing from operational?

seniornice to knowfreq 6%

answer

configuration versus what is in use
transformations before applying
hardware that is not there
origin annotations, get-data

basics

~20 s

Running is what clients configured; intended is running after transformations such as template expansion, read-only and validated; operational is what the device actually uses. Configuration for a missing resource stays in running and intended but is absent from operational.

solid answer

~40 s

RFC 8342's Network Management Datastore Architecture keeps <running>, <candidate> and <startup> and adds two read-only datastores. <intended> is running after any configuration transformations, such as removing inactive nodes or expanding templates; the server must update and validate it whenever running is written, and in simple implementations it equals running. <operational> holds the configuration actually in use plus state: applied intended configuration, learned, system-provided and default values. Configuration can be valid and committed yet absent from operational when it refers to a resource that is not present, such as an interface card that is not installed, or while it is still being applied. RFC 8526 adds <get-data> and <edit-data>, which name any datastore by identity, so a client can read operational directly.

RFC 8342's Network Management Datastore Architecture keeps `<running>`, `<candidate>` and `<startup>` and adds two read-only datastores. `<intended>` is running after any configuration transformations, such as removing inactive nodes or expanding templates; the server must update and validate it whenever running is written, and in simple implementations it equals running. `<operational>` holds the configuration actually in use plus state: applied intended configuration, learned, system-provided and default values. Configuration can be valid and committed yet absent from operational when it refers to a resource that is not present, such as an interface card that is not installed, or while it is still being applied. RFC 8526 adds `<get-data>` and `<edit-data>`, which name any datastore by identity, so a client can read operational directly.

code

xml · 11 lines

xml

<rpc message-id="501" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <get-data xmlns="urn:ietf:params:xml:ns:yang:ietf-netconf-nmda"
            xmlns:ds="urn:ietf:params:xml:ns:yang:ietf-datastores">
    <datastore>ds:operational</datastore>
    <subtree-filter>
      <interfaces xmlns="http://example.com/ns/interfaces"/>
    </subtree-filter>
    <config-filter>true</config-filter>
    <with-origin/>
  </get-data>
</rpc>

go deeper

for a junior

Recall that NMDA adds intended and operational, both read-only, next to running, candidate and startup.

for a middle

Explain what intended and operational each contain, which of the five datastores are writable, and how <get-data> names a datastore by identity.

for a senior

Demonstrate verifying a change by comparing intended with operational, reading origin annotations, and recognising missing resources and remnant configuration.

for a principal

Discuss how intent-versus-applied comparison should drive a fleet's change verification and drift alarms, and what that needs from device support.

The problem NMDA solves

The original NETCONF model (RFC 6241) had three configuration datastores and no datastore for what the device is actually doing. The <get> operation returns running together with state data, so a client could not tell "what I configured" from "what is applied". RFC 8342 records that operators said it was essential to retrieve the configuration that had actually been applied, which may be a subset or a superset of running. The Network Management Datastore Architecture (NMDA), RFC 8342 (Standards Track, updates RFC 7950), extends the model rather than replacing it.

The datastores of NMDA

Datastore	Writable	Holds	Persists across reboot
`<startup>`	yes, by copy	configuration loaded at boot	typically yes
`<candidate>`	yes	a working copy to commit to running	typically no
`<running>`	yes	the current configuration; must always be a valid data tree	typically yes, if no distinct startup
`<intended>`	no	running after configuration transformations; what the system attempts to apply	no
`<operational>`	no	configuration actually in use, plus system state	no

The first four are the conventional configuration datastores: they share one schema, so data can be copied between them. Dynamic configuration datastores, sometimes called ephemeral, also feed operational and are lost on reboot.

Running versus intended

<intended> is the configuration after all transformations to running are performed and is the configuration the system attempts to apply. RFC 8342 gives two example transformations, both implementation mechanisms rather than standard ones: nodes marked inactive are not copied to intended, and templates are expanded. Two rules tie it to running:

Whenever data is written to running, the server must immediately update and validate intended.
For simple implementations, running and intended are identical.

RFC 8342 also notes that there are currently no standard mechanisms that make intended differ from running; the architecture only leaves room for them.

Intended versus operational

<operational> contains all config-true and config-false nodes in use: applied configuration from intended, learned configuration (from link negotiation, routing protocols, DHCP), system configuration such as an always-present loopback, default values from the data models, and applied configuration from dynamic datastores. A node with no value in operational is not being used by the device.

That is why committed configuration can be missing from operational, or differ there:

Missing resources. Configuration in intended can refer to something not physically present. RFC 8342's example is interface configuration for an interface that is not currently there: it stays in running and intended but does not appear in operational. The configuration is not made invalid by the missing hardware, because otherwise removing a card, or rebooting without it, would leave the device with an invalid configuration.
Changes still being applied. Configuration takes time to percolate into operational. During that window operational may hold remnant configuration from the previous version alongside the new one, until resources such as connections or memory are released.
Values overridden at runtime. When a YANG description says a negotiated value overrides the configured one, operational reports the learned value and its origin.

Seeing it on the wire

RFC 8526 (Standards Track, updates RFC 6241 and RFC 7950) adds two NETCONF operations that take a datastore identity instead of the fixed choices of <get-config> and <edit-config>:

<get-data> reads any datastore, for example ds:operational, with a subtree or XPath filter, a config-filter, a max-depth, and origin filters. Its with-origin parameter, valid only for operational, asks the server to annotate each node with its origin: intended, dynamic, system, learned, default or unknown.
<edit-data> writes a writable datastore and returns an error for a read-only one such as intended. It has no test-option or error-option; its error behaviour corresponds to rollback-on-error.

<lock>, <unlock> and <validate> gain a datastore leaf as well. An NMDA server must implement the ietf-netconf-nmda module, support operational, and publish its datastores and modules through the YANG library, which clients read from operational.

What it changes for an operator

Check a change by comparing intended with operational, not by reading back running: running only proves the server accepted the configuration.
Read origin before treating a mismatch as a bug; a learned value can override a configured one by design.
Expect a short window of remnant configuration right after a commit.

## The problem NMDA solves The original NETCONF model (RFC 6241) had three configuration datastores and no datastore for what the device is actually doing. The `<get>` operation returns running together with state data, so a client could not tell "what I configured" from "what is applied". RFC 8342 records that operators said it was essential to retrieve the configuration that had actually been applied, which may be a subset or a superset of running. The **Network Management Datastore Architecture (NMDA)**, RFC 8342 (Standards Track, updates RFC 7950), extends the model rather than replacing it. ## The datastores of NMDA | Datastore | Writable | Holds | Persists across reboot | |---|---|---|---| | `<startup>` | yes, by copy | configuration loaded at boot | typically yes | | `<candidate>` | yes | a working copy to commit to running | typically no | | `<running>` | yes | the current configuration; must always be a valid data tree | typically yes, if no distinct startup | | `<intended>` | no | running after configuration transformations; what the system attempts to apply | no | | `<operational>` | no | configuration actually in use, plus system state | no | The first four are the **conventional configuration datastores**: they share one schema, so data can be copied between them. Dynamic configuration datastores, sometimes called ephemeral, also feed operational and are lost on reboot. ## Running versus intended `<intended>` is the configuration after all transformations to running are performed and is **the configuration the system attempts to apply**. RFC 8342 gives two example transformations, both implementation mechanisms rather than standard ones: nodes marked inactive are not copied to intended, and templates are expanded. Two rules tie it to running: - Whenever data is written to running, the server must immediately update and **validate** intended. - For simple implementations, running and intended are identical. RFC 8342 also notes that there are currently no standard mechanisms that make intended differ from running; the architecture only leaves room for them. ## Intended versus operational `<operational>` contains all config-true and config-false nodes in use: applied configuration from intended, **learned** configuration (from link negotiation, routing protocols, DHCP), **system** configuration such as an always-present loopback, **default** values from the data models, and applied configuration from dynamic datastores. A node with no value in operational is not being used by the device. That is why committed configuration can be missing from operational, or differ there: 1. **Missing resources.** Configuration in intended can refer to something not physically present. RFC 8342's example is interface configuration for an interface that is not currently there: it stays in running and intended but does not appear in operational. The configuration is not made invalid by the missing hardware, because otherwise removing a card, or rebooting without it, would leave the device with an invalid configuration. 2. **Changes still being applied.** Configuration takes time to percolate into operational. During that window operational may hold **remnant configuration** from the previous version alongside the new one, until resources such as connections or memory are released. 3. **Values overridden at runtime.** When a YANG description says a negotiated value overrides the configured one, operational reports the learned value and its origin. ## Seeing it on the wire RFC 8526 (Standards Track, updates RFC 6241 and RFC 7950) adds two NETCONF operations that take a `datastore` identity instead of the fixed choices of `<get-config>` and `<edit-config>`: - `<get-data>` reads any datastore, for example `ds:operational`, with a subtree or XPath filter, a `config-filter`, a `max-depth`, and origin filters. Its `with-origin` parameter, valid only for operational, asks the server to annotate each node with its **origin**: `intended`, `dynamic`, `system`, `learned`, `default` or `unknown`. - `<edit-data>` writes a writable datastore and returns an error for a read-only one such as intended. It has no `test-option` or `error-option`; its error behaviour corresponds to `rollback-on-error`. `<lock>`, `<unlock>` and `<validate>` gain a `datastore` leaf as well. An NMDA server must implement the `ietf-netconf-nmda` module, support operational, and publish its datastores and modules through the YANG library, which clients read from operational. ## What it changes for an operator - Check a change by comparing **intended with operational**, not by reading back running: running only proves the server accepted the configuration. - Read `origin` before treating a mismatch as a bug; a `learned` value can override a configured one by design. - Expect a short window of remnant configuration right after a commit.

Why does RFC 8342 allow configuration for absent hardware to stay in running?
Because validity must not depend on the current state of resources. If removing a card made the configuration invalid, a device rebooted without the card would start with an invalid configuration. So configuration for a missing resource remains in running and intended and simply does not appear in operational until the resource is present.
Does intended ever differ from running on an NMDA server today?
Only through implementation mechanisms. RFC 8342 says there are currently no standard mechanisms that make intended differ from running; inactive nodes and templates are its examples of what could. For simple implementations the two are identical, so on many servers a read of intended returns exactly what running holds.

saying these in an interview costs you the question

Intended is a writable datastore you edit in place of running.
Operational holds only config-false state, never configuration.
Anything committed to running always appears in operational.
NMDA replaces running and candidate with new datastores.
Configuration for a missing interface makes running invalid.

Under the NMDA of RFC 8342, how do the intended and operational datastores differ from running, and why can committed configuration be missing from operational?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The problem NMDA solves

The datastores of NMDA

Running versus intended

Intended versus operational

Seeing it on the wire

What it changes for an operator

▾common follow-ups2 questions

▾red flags5 flags

The problem NMDA solves

The datastores of NMDA

Running versus intended

Intended versus operational

Seeing it on the wire

What it changes for an operator

answer

go deeper