Status
Proposed on 2026-03-14 by Lars Solem.
Context
Dataverket has decided that both switch and router platform choices remain open for v1.
That is the correct state for now, but it creates a new risk: the eventual hardware and NOS selection could be driven by availability, price, or familiarity alone, without being tested against the actual needs of Nett, inter-datacenter failover, and multi-tenant platform automation.
The platform therefore needs explicit criteria for selecting the first supported switch and router platforms.
Decision
Dataverket will not select its first switch or router platforms until candidate platforms are evaluated against a shared capability checklist.
The first supported switch and router platforms must satisfy the requirements in this document.
Mandatory switch requirements
The first supported switch platform must support:
- VLANs and trunk/access configuration
- LACP or equivalent link aggregation support
- MLAG or an acceptable equivalent, if the fabric design requires it
- BGP support if the switch role includes routed underlay or edge behavior
- VRF support where separated routing domains are needed
- stable remote configuration workflows
- safe rollback or clearly auditable staged rollout behavior
- machine-readable or at least scriptable configuration/state retrieval
Mandatory router requirements
The first supported router platform must support:
- BGP for north-south and inter-datacenter routing
- route filtering and policy control
- support for private and public address advertisement
- support for failover-triggered routing changes
- stable remote configuration workflows
- observable routing state for automation and health checks
- machine-readable or scriptable state retrieval
Mandatory automation requirements
Both the first switch and router platforms must support:
- non-interactive automation
- configuration export and drift inspection
- reliable identity in inventory, such as serial number, hostname, or management IP
- management over dedicated out-of-band or controlled management paths
- operational workflows that can be driven by Nett without manual CLI editing as the primary model
If a platform only supports brittle screen-scraping or highly stateful interactive CLI behavior, it should not be the first supported platform.
Multi-datacenter requirements
Because Dataverket is explicitly multi-datacenter, candidate platforms must be able to support:
- inter-datacenter routed links
- site-aware routing policy
- deterministic failover behavior
- controlled convergence during link loss or site failover
Platforms that technically support routing but make cross-site failover opaque or hard to automate should be rejected for v1.
Operational requirements
The first platforms should be operable by a small team.
That means preference should be given to platforms with:
- understandable failure modes
- clear configuration model
- testability in lab environments
- reproducible software lifecycle and upgrades
- accessible telemetry for troubleshooting
Procurement requirements
The first supported platforms should also be evaluated on:
- realistic availability in the target market
- hardware replacement and support expectations
- power, port density, and rack footprint fit
- ability to build at least two datacenters with the same operational model
Procurement convenience alone must not override the automation and failover requirements above.
Evaluation model
Candidate platforms should be scored in four dimensions:
Network capability fit VLAN, VRF, BGP, policy, and topology fit.
Automation fit How practical it is to automate safely through Nett.
Operational fit Day-2 operations, observability, upgrades, and failure handling.
Commercial fit Cost, availability, support, and procurement realism.
No platform should be selected unless it is acceptable in all four dimensions.
Consequences
- Dataverket now has a disciplined basis for choosing its first switch and router platforms
- later vendor selection can be justified against platform needs instead of intuition
- Nett can continue designing a vendor-neutral intent model while procurement and evaluation proceed
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- This ADR supports 010-supported-network-vendors.md.
- The selected platforms must also satisfy the topology and failover needs in 005-network-service-and-topology.md and 012-inter-datacenter-topology-and-failover.md.
Audit
- 2026-03-14: ADR proposed.