How does a YANG leafref such as the interface-ref typedef keep a reference to an existing interface valid, and what does require-instance false change?
answer
- a foreign key in the schema
- path names one leaf
- the default is to insist
- checked on the whole tree
- configuration may not point at state
basics
~20 sA leafref takes the value space of the leaf its path names; with require-instance true, the default, a matching instance must also exist, so removing a referenced interface fails. False keeps the type but drops the existence check.
solid answer
~50 sRFC 8343 defines `interface-ref` as `type leafref { path "/if:interfaces/if:interface/if:name"; }`, so a leaf of that type takes its values from the interface list's `name` key. Two things follow. Its value space is the referred leaf's, so the name's own type rules apply. And with `require-instance` true, which is the default, RFC 7950 §9.9 requires an instance with the same value (or a default in use) to exist in a valid data tree; a configuration leafref with require-instance true must also refer to configuration, not state. That referential integrity is a whole-tree check: on running it is enforced at the end of the edit, on the candidate at `<commit>` or `<validate>`, so deleting an interface that something still names is rejected, never cascaded. `require-instance false`, allowed on leafref since YANG 1.1, keeps the value space but lets the target be absent.
go deeper
Recall that a leafref points at another leaf, usually a list key such as an interface name, and that by default the target must exist.
Explain value space versus existence, the require-instance default, the configuration-to-state rule, and when the integrity check runs on running versus candidate.
Show how leafrefs shape operations: decommissioning order, batched candidate commits, and when an explicit require-instance false is the honest model for a target that may be absent.
Weigh tight referential integrity against cross-system references whose targets live in other models or controllers, and decide where existence should be enforced.
## What a leafref is `leafref` is a YANG built-in type (RFC 7950 §9.9) that ties a leaf to another **leaf or leaf-list** in the schema tree. Its mandatory `path` substatement names the target with a restricted form of XPath. Two properties follow from that one line: - **Value space.** The referring leaf's value space is the referred leaf's. If interface names are strings of up to some length, so are references to them. - **Existence.** Unless told otherwise, a value is valid only when an instance of the target with the same value exists. RFC 8343, the interfaces module, packages the most common reference as a typedef, so other modules write `type if:interface-ref;` instead of repeating the path: `typedef interface-ref { type leafref { path "/if:interfaces/if:interface/if:name"; } }` RFC 7950 itself compares a leafref used as a list key to a foreign key in a relational database. ## require-instance: true versus false | | `require-instance true` (default) | `require-instance false` | |---|---|---| | Value must be of the target's type | yes | yes | | A target instance with that value must exist | yes, in a valid data tree; a default in use counts | no; it MAY exist | | A configuration leaf may refer to state data | no: the target MUST also be configuration | the rule does not apply | | Deleting a referenced target | leaves the tree invalid, so the operation fails | allowed; the reference simply dangles | | Relative cost (RFC 9907 §4.24) | generally more expensive | cheaper | `require-instance` on a leafref is new in YANG 1.1; in YANG 1.0 (RFC 6020) it existed only for `instance-identifier`, so every 1.0 leafref insisted on its target. ## When the check runs RFC 7950 §8 separates checks that need only the value from checks that need the whole tree: 1. **Payload parsing.** The value must match its type; one that breaks the referred leaf's type is an `invalid-value` error at once. 2. **The edit itself.** A NETCONF server applies the change to the datastore. 3. **Validation.** "All referential integrity constraints defined via the path statement MUST be satisfied" in a valid data tree. For running and startup this is enforced at the end of `<edit-config>` or `<copy-config>`; for the candidate it waits for `<commit>` or `<validate>`, so a batch may delete an interface and its references together and still commit. The running datastore MUST always be valid. That is why a request that removes interface `eth0` while a management leaf still names it fails as a whole: YANG has no cascading delete for leafrefs. ## Paths with predicates A path may carry predicates, but only equality tests on list keys. To reference an address of a chosen interface, RFC 7950 pairs two leafrefs: - `ifname` with path `../../interface/name` - `address` with path `../../interface[name = current()/../ifname]/address/ip` The second path narrows the target to the addresses of the interface the first leaf names. Inside a typedef, the context node for the path is the leaf that uses the typedef. ## leafref, instance-identifier and identityref | Type | Points at | Value looks like | |---|---|---| | `leafref` | instances of one schema leaf or leaf-list | the target's value, such as `eth0` | | `instance-identifier` | any single data node | a full path with prefixes and key predicates, evaluated from the root | | `identityref` | an identity, not data | a qualified identity name | ## Rules that trip authors - There MUST NOT be circular chains of leafrefs. - If the target is conditional on features, the referring leaf MUST be conditional on at least the same features. - A `must` expression can follow a leafref to its target with `deref()`; writing such a rule belongs to the constraint statements, but it only works because the leafref defines the link. - A leafref inside a `union` behaves differently when its target disappears: the value is revalidated against the remaining member types. ## The operator's view A leafref turns "which interface did you mean?" into a schema fact. Tools can offer only existing names, the server refuses a dangling reference, and a decommissioning change has to remove the references before, or together with, the interface. When a reference must survive its target's absence, for example while the target is provisioned elsewhere later, `require-instance false` is the explicit, documented choice.
- When would you choose instance-identifier over leafref in a YANG model?When the target can be any node in the data tree rather than instances of one schema leaf. An `instance-identifier` value is a full path with namespace prefixes and key predicates, evaluated from the root, so it can point at a container, a list entry or a leaf anywhere. It accepts `require-instance` too, but tools cannot offer a fixed list of candidates or reuse the target leaf's type.
- Can a YANG configuration leafref refer to a node that exists only as state data?Not with `require-instance true`: RFC 7950 §9.9 says the referred node MUST then also represent configuration. The rule is tied to require-instance, so a configuration leafref with `require-instance false` may point at state, accepting that the target's presence is not checked.
A leafref is a foreign key: the referring row must name a row that exists, and you cannot drop the referenced row while something still points at it. YANG simply refuses the edit; it never cascades the delete.
saying these in an interview costs you the question
- A leafref only borrows the target's type and never checks existence.
- require-instance defaults to false, so integrity is opt-in.
- Deleting an interface also deletes the leaves that reference it.
- A leafref path can point at a whole container or list.
- Referential integrity is checked as each candidate edit is parsed.