Summary

  • draft-ietf-ivy-network-inventory-topology-11 can map a logical node or termination point to a physical element or port, while its read-only port-breakout data describes channels the hardware is capable of exposing. Neither record proves that the port is currently split, that a lane is operational, or that capacity can carry a service.
  • Mapping fields can be discovered, manually declared or used for planned resources. A defensible topology-to-service chain therefore preserves provenance, configuration, device readback, operational state, capacity, orchestration and delivery as separate receipts.

Four lines on a screen

An operator opens a controller view of a 400G interface. Under port-breakout, four channels are listed. The arithmetic is irresistible: four times 100G. A pending service needs one of them. The dashboard has a termination point, a physical-port reference and a neat list of possible children. Why should the order not proceed?

Because the screen has joined three sentences that the model keeps apart.

The first sentence says that a topology object maps to a physical inventory object. The second says that the port's hardware can expose independent channels. The third—never supplied by those two records—would say that a named channel is configured, present, up, uncommitted and able to carry the requested service.

The draft is not being evasive. Its port-breakout container is config false, and the text says the channel list expresses intrinsic hardware capability regardless of whether the port is currently configured as a trunk or as a breakout port. It is answering a useful inventory question: what could this component do? An orchestration dashboard asks a later operating question: what can I safely allocate now?

The error is not false data. It is a false promotion between reality layers.

A reference is a model assertion

Revision 11 defines an inventory topology type on the RFC 8345 network model. It augments nodes, links and termination points with information that connects a logical topology to physical inventory. A node can carry ne-ref; a termination point can carry port-ref. The draft describes one-to-one mappings to a network element and a physical port component.

That standardised shape matters. A controller no longer has to guess whether router-17, chassis/0 and xe-0/0/0 refer to the same kind of thing in three private APIs. Referential integrity can be tested. Consumers can follow a known path from topology to inventory.

But a well-formed reference does not touch a cable. It records what an authorised system asserts the correspondence to be. The presence of inventory-mapping-attributes distinguishes physical nodes and termination points from abstract or logical ones inside this model; it does not perform an independent physical inspection.

The distinction becomes unavoidable because ne-ref, port-ref, link-type and the topology presence container are writable. The draft expects discovery to populate mappings in ordinary deployments, yet deliberately permits manual configuration when discovery is unavailable. Customer-premises equipment may sit outside the management domain. A leased circuit may expose only its endpoints. A planner may model a future resource that does not exist yet. An operator may override a discovered value.

All of those records can be legitimate. They do not carry the same epistemic weight.

A mapping receipt therefore needs more than the value. It needs the source controller or person, the collection or declaration method, the observation time, the resource scope, the authority permitted to override it and whether the target is observed, imported, third-party or hypothetical. Without that provenance, an apparently precise port-ref can silently outlive a line-card replacement or describe tomorrow's design as today's plant.

The stronger field is still bounded

port-breakout differs from the writable mappings. It is read-only operational data, determined by the hardware rather than manually configured through this model. That gives it a stronger claim: the component reports a capability and enumerates available independent channels.

Stronger does not mean universal.

The record can support procurement checks, compatibility analysis and change planning. It can show that a particular hardware and firmware combination has the structural ability to expose four channels. It still does not say that the parent port has been switched from a 400G trunk into four 100G children. It does not show that channel interfaces were created after commit, that the optics and cabling support the chosen mode, that each lane is up, or that another service has not already claimed the capacity.

The correct inference is narrow: this hardware reports that the breakout form is possible. The incorrect inference is operational: these child interfaces exist and are available.

That boundary is why a capability observation should carry device identity, component identity, firmware or software version, collection time and method. A line-card swap or software upgrade can change the reported capability without changing the logical topology name. A cached controller response can remain syntactically valid after its physical referent has changed.

A media label is not the hidden plant

The link-type leaf is intentionally lightweight. Its identities include media such as fiber, copper, coaxial cable, microwave, WLAN and leased fiber. The value helps a consumer decide which specialised inventory model to consult; it is not a full record of strands, wavelengths, radios, connectors, ownership, route or usable capacity.

Leased fiber is the clearest case. A lessee may know, truthfully, that a topology edge relies on third-party fiber while lacking visibility into the provider's physical path and components. A standardised discriminator improves coordination precisely because it can admit that boundary. It does not dissolve it.

An automation system that treats leased-fiber as if it had received a native fiber inventory has erased the third party's opacity. Conversely, refusing to model the link until every physical detail is visible would erase a real service dependency. The sound position is to preserve both facts: the link type is known; important physical attributes remain outside the observing authority.

Schema health belongs to the document

At the research freeze, the Datatracker showed revision 11 as an active Standards Track Internet-Draft submitted to the IESG and waiting for AD go-ahead. The record showed YANG validation with zero errors and zero warnings. It also showed that IANA review was not yet OK. Those facts locate the document in its standards process.

Zero validation errors are valuable evidence about the module's structure. They are not evidence that a vendor implemented it, a controller collected it, a device returned current values or a service succeeded. A schema can validate perfectly while a mapping is stale. Secure transport can protect a stale answer. NACM can restrict access to an authorised user who makes a wrong decision.

Document state, implementation support, deployed configuration and observed operation need their own receipts. Combining them under a single green “validated” badge converts tooling quality into network testimony.

From capability to an actual channel

Suppose an approved change does intend to split the 400G port. The chain now moves beyond inventory.

First comes intended configuration: the exact device, parent port, breakout mode, lane identifiers, optics assumptions, maintenance window and approval record. Then comes a configuration transaction and device readback. Did the target accept the command? Did the parent interface change mode? Did the expected child interfaces appear with the intended identifiers?

Operational evidence comes later. Are the lanes administratively enabled and operationally up? Do alarms, error counters and transceiver readings support the expected physical state? Does capacity telemetry show unallocated headroom on the exact channel? If a topology or TE model supplies capacity, what was its observation time and does it address the same component referenced by port-ref?

Only after those questions can the orchestrator's own decision be audited: which policy version selected the SAP, which candidates were rejected, which topology snapshots it read, and whether manual intervention changed the choice. The draft's provisioning example reflects this ordering. Mapping a SAP to a physical port is followed by consulting other topology models to verify capacity. Insufficient resources can lead to another SAP or a human decision. The mapping is an input, not the verdict.

Activation then creates another boundary. A configuration commit can succeed while the service path fails. The final record needs an activation result, path observation, traffic counters or probe evidence, and a customer-visible outcome. “Port supported breakout” belongs near the start of that chain, not at its end.

The failure modes are governance evidence

The draft's security discussion warns that stale or misconfigured mappings can cause mis-provisioning, unexpected traffic paths, failed activation and inaccurate capacity planning. These are not four names for one problem.

Mis-provisioning indicates that the decision selected the wrong resource or applied the wrong operation. An unexpected path indicates that logical intent and forwarding observation diverged. Failed activation says the configuration or service transition did not complete. Inaccurate capacity planning says the evidence used before the decision was incomplete or stale. Each failure points to a different missing receipt.

Sensitive inventory also exposes element sets, internal component names, media types, third-party ownership and hardware capabilities. Confidentiality, mutual authentication and RFC 8341 NACM controls are necessary. They constrain who may see or alter the model. They do not certify the truth of a manually entered mapping or prove that an authorised controller used it correctly.

The practical control is not to weaken the model. It is to keep the authority and provenance of each statement attached when records are joined.

A topology-to-service receipt

A reviewable service order should preserve at least ten separable records:

  1. the exact draft or RFC revision, module revision and registry state understood by the tooling;
  2. the controller, device and collection time for the topology and inventory snapshot;
  3. each ne-ref, port-ref and link-type, together with discovered, manual, imported or hypothetical provenance;
  4. referential-integrity checks and the authority allowed to create or override the mapping;
  5. the port-breakout capability response tied to the exact component and software or firmware build;
  6. the approved intended configuration and change record;
  7. post-commit device readback showing the parent mode and actual child interfaces;
  8. operational state, optics, counters and capacity for the selected lane;
  9. the orchestrator policy, candidate set, selected SAP or path and any manual intervention; and
  10. service activation, observed traffic path and customer-visible outcome.

This chain is deliberately redundant. Redundancy lets an auditor see where a claim changed category. It prevents a truthful capability record from being asked to certify a later event it never observed.

Sources