Status
Proposed on 2026-03-14 by Lars Solem.
Context
Dataverket has decided to automate switching, routing, VLANs, and inter-datacenter connectivity through the Nett service.
That requires a concrete v1 vendor strategy. Without one, Nett risks becoming an abstraction project with no deployable target hardware.
The platform still wants a vendor-neutral intent model, but v1 needs a narrow and realistic support matrix.
Decision
Dataverket adopts a narrow v1 network vendor strategy:
- Switching v1 target: unknown for now
- Routing v1 target: unknown for now
- Management protocol preference: SSH plus rendered declarative configuration files
This means Nett will keep both switching and routing vendor-neutral until concrete platforms are selected.
Why this direction
The v1 platform needs:
- predictable automation interfaces
- support for BGP, VLANs, VRFs, and inter-datacenter routing
- a low-friction path for testing in labs and smaller production environments
- room to extend to more vendors later without redesigning Nett
The platform still needs:
- open configuration formats
- standard Linux automation patterns
- support for BGP, VLANs, VRFs, and inter-datacenter routing
- a clear development and CI path without depending on opaque proprietary APIs
Support matrix
The initial support matrix is:
- Leaf / top-of-rack switching: unknown for now
- Spine or routed core where needed: unknown for now
- Edge and inter-datacenter routing: unknown for now
This is a support statement for v1, not a ban on future vendors.
Automation model
Nett should implement drivers in this order:
Vendor-neutral switch intent and abstraction Define the normalized switch model for VLANs, trunks, MLAG or equivalent, and underlay expectations before locking a specific switch driver.
Vendor-neutral router intent and abstraction Define the normalized router model for BGP, routed uplinks, inter-datacenter paths, and edge policy before locking a specific router driver.
First selected switch driver Implement the first concrete switch driver once hardware and NOS are chosen.
First selected router driver Implement the first concrete router driver once hardware and NOS are chosen.
Common Linux network primitives Use Linux-native tooling for interface, VLAN, VRF, and system-level configuration where relevant.
Explicit non-goals for v1
The following are not required for the first version:
- broad multi-vendor switch support
- EVPN/VXLAN automation
- proprietary controller integrations
- deep vendor-specific feature parity across multiple NOS families
These may be added later through new drivers if the vendor-neutral intent model holds up in practice.
Operational implications
This decision allows Dataverket to:
- build Nett against a stable intent model before hardware is finalized
- run labs and production on the same automation approach
- defer irreversible vendor coupling until requirements are better understood
It also means:
- switch and router hardware purchasing cannot be finalized until the first supported platforms are selected
- the intent model must be disciplined enough to survive the later vendor choice
Consequences
- Nett gets a concrete modeling direction, but not a locked vendor target yet
- switch and router automation remain intentionally open until hardware selection is made
- later vendor choice will need a follow-up ADR before deep driver implementation starts
Decision Outcome
Proposed. This ADR records the current preferred direction and still needs acceptance before it becomes binding.
Related Decisions
- This ADR extends 005-network-service-and-topology.md by keeping concrete switch and router platform choices open.
- Candidate platform selection must be justified through 013-network-platform-selection-criteria.md.
- Any eventual platform choice must also satisfy the inter-datacenter requirements in 012-inter-datacenter-topology-and-failover.md.
More Information
- network config rendering and rollout safety model
- IPAM and DNS source of truth
- load balancer implementation
- later vendor expansion criteria
Audit
- 2026-03-14: ADR proposed.