Summary

  • A 1 October Routing Area Directorate review of revision 20 of the IVY base network-inventory draft asks for a clarification: when an upper controller combines inventories from lower controllers, the upper controller acting as server should ensure that the ne-id keys it exposes are unique.
  • Key uniqueness is only the first control. The aggregator must also decide whether two records describe different devices with the same local ID or the same device under different IDs, and preserve a reversible record of that decision.

Imagine two controller domains that have never met. Each maintains a valid inventory. Each assigns ne-id: 17 to one network element. In the first domain, 17 means a border router. In the second, it means an optical shelf. Nothing is wrong until a higher-level controller attempts to turn both lists into one.

It cannot simply append the rows. The proposed YANG list is keyed by ne-id, so one key cannot safely denote two entries in the combined datastore. It also cannot silently keep one and discard the other. Renaming the second record to 18 would remove the immediate collision, but unless the mapping survives, an alarm, work order or topology reference that began in the second domain may no longer find its way home.

That is the practical question raised by Linda Dunbar’s Routing Area Directorate telechat review of revision 20 of draft-ietf-ivy-network-inventory-yang, completed on 1 October. The result is recorded as Has nits. The review calls the document generally clear and raises one minor issue: a higher-level controller may combine inventories learned from multiple lower-level controllers; because ne-id is server-assigned and is the list key, the higher controller acting as server for the combined inventory should be responsible for uniqueness in the view it exposes. A short clarification, the review says, would help.

The status matters. Revision 20 is an active IVY working-group Internet-Draft intended for the Standards Track and under IESG evaluation and Area Director follow-up. It is not an RFC. The review is not a report of a deployed collision, a vendor defect or a security vulnerability. It identifies an architectural responsibility that the draft’s operational model makes visible.

The draft defines a generic, read-only inventory of network elements and their components. It is a controller’s account of what it knows to be installed, not a warehouse ledger, procurement system or direct testimony from every physical object. Within the model’s scope, the controller providing the data is described as the source of truth. That phrase gives the controller responsibility for the view; it does not turn the view into physical reality.

Revision 20 already explains why ne-id is assigned by the server. A device’s local identifier cannot be assumed unique across the network. It also says the same network element should retain the same ID even if it becomes disconnected. How a server recognises sameness—perhaps by manufacturer and product names, management address, physical location or another signal—is deliberately implementation-specific and outside standardisation.

Those two requirements pull in different directions at an aggregation boundary. The upper server must avoid duplicate keys, but it must also avoid inventing a new identity every time a lower controller disconnects, is replaced or changes its local naming scheme. A fresh unique string solves syntax for today. It can still break continuity tomorrow.

The inverse problem is harder. Two lower controllers may observe the same chassis through overlapping management domains and assign different local IDs. If the upper controller treats them as separate assets, capacity can be counted twice, maintenance can be scheduled twice and an alarm can appear to affect two devices. If it merges them because the manufacturer, product and management address happen to match, it may collapse two genuinely different devices whose evidence is incomplete or stale.

The draft’s common uuid field is useful but does not abolish this judgement. Revision 20 describes the server-assigned UUID as globally unique, and the UUID specification defines interoperable formats and generation properties. Yet uniqueness and sameness are different propositions. Two servers can create two valid UUIDs for one physical object. A copied or incorrectly retained UUID can make two observations look like one. A globally unique label is a strong handle after identity has been established; it is not, by itself, the evidence that establishes identity.

The resulting control surface has at least five layers. First is the physical asset. Second is each lower controller’s observation and local ne-id. Third is the upper controller’s reconciliation decision. Fourth is the identifier exposed in the combined list. Fifth is the downstream action—an alarm correlation, change plan, topology link or asset report—that relies on that combined identity. A successful YANG validation at layer four cannot prove the other four.

BTW’s proposed operational control is a reversible identity-translation receipt. For every imported record, the upper controller would retain the source-controller identity and source ne-id, the combined ne-id, the UUID and whatever hardware anchors were available. It would record the matching rule, confidence, conflicts, first and last observations, and any superseded mapping. It would also identify consequential downstream decisions that consumed the mapping.

That receipt is an editorial proposal, not a requirement in revision 20 or in the review. Its purpose is modest: make renaming and merging inspectable. If domain B’s local 17 becomes combined ID 18, an operator should be able to reverse the path. If later evidence shows that A-17 and B-42 are the same chassis, the merge should leave history rather than erasing two earlier claims. If confidence is low, the system should expose a conflict instead of converting uncertainty into a clean-looking asset.

The approach follows a narrow reading of Heng Lu’s doctrine. Note 20 separates executable reality from symbolic representation: a record can govern workflow without becoming the object it describes. Note 64 argues that the common layer should contain only deterministic invariants needed for uniqueness and interoperability, while future choices remain local and verifiable. Note 19 distinguishes useful coordination from sovereign authority. Applied here, the common model needs a valid unique key; the local aggregator owns its reconciliation method and evidence; neither identifier grants authority over the physical device.

These are editorial lenses, not positions attributed to the IETF or the reviewer.

This boundary also keeps adjacent questions in their proper place. The IVY topology augmentation raises provenance questions when ne-ref and port-ref mappings are manually overridden. The entitlement model separates a licence catalogue from device activation and service outcome. Passive inventory needs custody evidence because a cable cannot speak for itself. The present issue is different: before any of those references can be trusted in a combined hierarchy, the aggregator must know which identity its key denotes and how that identity maps back to the source.

The draft’s reference to hierarchical controllers is not speculative. It says an upper controller may collect inventories from lower controllers and report a combined view to a still higher controller, an Inventory OSS or another application. It also points to the ACTN architecture as one possible context. The more layers a record crosses, the easier it is for a local convenience to acquire the appearance of a global fact.

The useful outcome of the review would therefore be more than the statement that keys must be unique. That clarification should identify the server boundary at which uniqueness is evaluated. Implementers should then make their local translation behaviour explicit: whether identifiers are prefixed, remapped, derived or reconciled against stable anchors; how conflicts are represented; and what survives controller replacement. The standard need not dictate one algorithm to make the responsibility visible.

Sources