ADR-003 DC 3.0 validation, state capture, and operational tooling

Status: superseded by adr-018-network-validation-ansible-vendor-cli.

Context and Problem Statement

DC 3.0 requires deterministic config delivery and evidence that intent, device state, and operational behavior align. We need tools that provide: (1) pre-change intent validation on the generated config, (2) pre-change device state snapshots scoped to the change set, (3) normalized post-change runtime baselines, and (4) operational observations across the fabric.

Decision Drivers

• Explicit separation of intent validation vs. runtime observation so pre-change and post-change evidence cannot be conflated.
• Device-vendor mix and API variability require normalized outputs across platforms.
• Evidence quality: repeatable, artifact-based outputs that can be stored with each change.
• Change-set scoping to control blast radius and to avoid sweeping checks on unrelated devices.
• Automation-friendly interfaces for CI/CD workflows and scheduled drift checks.

Considered Options

1. Batfish + Nornir + NAPALM + Suzieq (historical chosen option).
2. PyATS/Genie for pre/post checks and diffing.
3. Ansible + vendor CLIs for checks and data capture.
4. Streaming telemetry + vendor NMS for operational truth.

Decision Outcome

Historical chosen option (at the time): Batfish, Nornir, NAPALM, and Suzieq.

This ADR is superseded by adr-018-network-validation-ansible-vendor-cli, which makes Ansible + vendor CLI evidence collection the active baseline.

Positive Consequences

• Intent checks are performed on generated configs before deployment using a model of routing and policy behavior (Batfish).
• Pre-change snapshots are scoped to the change set and captured consistently from the same commands or APIs (Nornir).
• Running state and device facts are normalized and comparable across devices, enabling consistent drift detection (NAPALM).
• Fabric-wide operational state is captured independently of device configs, exposing real-time behavior and anomalies (Suzieq).

Negative Consequences

• Multiple tools require consistent inventory and credential management.
• Operators must maintain artifacts across four pipelines.
• Each tool adds its own dependency chain and maintenance overhead.

Pros and Cons of the Options

Option 1 – Batfish + Nornir + NAPALM + Suzieq (historical)

• Good: Separates intent validation, pre-change evidence, runtime baseline, and operational truth into clear lanes.
• Good: Produces explicit artifacts for audits and rollback decisions.
• Good: Normalizes outputs to stable formats that can be compared over time.
• Bad: Requires integration across multiple tools.

Historical note: this option is no longer the active baseline after adr-018-network-validation-ansible-vendor-cli.

Option 2 – PyATS/Genie

• Good: Strong post-change parsing and diffing for supported platforms.
• Bad: Does not validate intent on the generated configuration before deployment.
• Bad: Less suitable for fabric-wide operational observation.

Option 3 – Ansible + vendor CLIs

• Good: Simple to execute commands at scale.
• Bad: Output normalization and comparison are inconsistent across platforms.
• Bad: Drift detection depends on custom parsing for every device type.

Option 4 – Streaming telemetry + vendor NMS

• Good: Rich operational visibility over time.
• Bad: Does not validate intent on generated configs or provide pre-change evidence.
• Bad: Vendor coupling and data-model differences complicate standardization.

Links and References

• Related Topics: topic-datacenter-3-0