📏 Standards on Deevnet Infrastructure Platform

Correctness

Mon, 01 Jan 0001 00:00:00 +0000

Deevnet Infrastructure Correctness #

Purpose #

This document defines what it means for Deevnet infrastructure to be correct.

Correctness is not defined by whether something “works once,” but whether it:

is deterministic,
is reproducible,
respects separation of concerns,
and remains understandable months later.

This document captures the intent, principles, and invariants of Deevnet infrastructure design.

1. Foundational Principles #

1.1 Determinism Over Convenience #

Infrastructure behavior MUST be deterministic.

Naming

Mon, 01 Jan 0001 00:00:00 +0000

Deevnet Naming Standard #

Purpose #

This document defines the canonical naming conventions for the Deevnet ecosystem. The goal is to ensure that names are:

Deterministic (predictable, repeatable)
Scalable (works as the lab grows)
Readable (humans can understand intent quickly)
Environment-safe (dvnt vs dvntm is always explicit)
Service-oriented (service names are stable even if hosts move)

This naming standard applies to:

DNS zones and hostnames
Service endpoints (artifacts, PXE, DNS, etc.)
Tenants (logical workload namespaces)
Inventory naming (host identifiers)

1. Definitions #

Site #

A site is a self-contained infrastructure boundary that hosts systems and workloads.

Secure Identity

Mon, 01 Jan 0001 00:00:00 +0000

Deevnet Secure Identity Standard #

Purpose #

This document defines what it means for Deevnet client access to be secure.

Secure identity is not defined by whether you can “SSH in,” but whether access:

minimizes secret exposure,
is reproducible across devices and OSes,
supports least privilege and revocation,
and avoids habits that don’t scale beyond a lab.

This document captures the intent, principles, and invariants of secure client identity and access in Deevnet.

Identity vs Intent

Mon, 01 Jan 0001 00:00:00 +0000

Identity vs Intent in Deevnet #

Purpose #

This document explains how identity and intent are deliberately separated in the Deevnet infrastructure model.

The goal of this separation is to ensure that:

Hosts can change purpose without renaming
Workloads can move without rewriting inventory
Configuration intent can be preserved, detached, and reused
Infrastructure history is not lost when systems are repurposed
Inventory remains truthful over time

This document complements the Naming Standard and focuses specifically on how inventory and configuration are modeled in Deevnet.

MAC Address Format

Mon, 01 Jan 0001 00:00:00 +0000

MAC Address Format Standard #

Rule #

All MAC addresses in Deevnet inventory and configuration MUST use:

lowercase hex digits (a-f, not A-F)
Colon separators (:, not -)

Examples #

Correct:

mac: "bc:24:11:2e:26:4e"
mac: "dc:a6:32:c3:b4:bc"

Incorrect:

mac: "BC:24:11:2E:26:4E" # uppercase
mac: "bc-24-11-2e-26-4e" # dashes

Rationale #

Deevnet uses lowercase to match Unix tooling conventions:

ifconfig, ip link, and most Linux utilities display MAC addresses in lowercase
Copy-paste from system output works without transformation
Consistent with what operators see when troubleshooting

IEEE 802 and RFC 7042 documentation examples use uppercase, but this is a documentation convention rather than a technical requirement. We prioritize practical alignment with the Unix ecosystem over formal documentation style.

MAC Namespace Specification

Mon, 01 Jan 0001 00:00:00 +0000

MAC Namespace Specification #

Purpose #

This document defines the deterministic MAC address strategy used across the Deevnet platform, with a primary focus on management-plane workloads.

Deterministic MAC addressing enables:

Stable DHCP reservations
Predictable IP assignments
Reproducible VM rebuilds
Clear mapping between identity layers

Formatting: All MAC addresses must follow the formatting rules in the MAC Address Format Standard (lowercase hex, colon separators).

Guiding Principles #

MAC addresses are generated outside the hypervisor
MACs are explicitly defined in inventory/code
Hypervisors must never auto-generate identity
Identity must survive VM destruction and recreation

Scope #

Workload Type	Policy
Management Plane	Mandatory deterministic MACs
Tenant Workloads	Optional, future-controlled
Ephemeral/Test VMs	May use auto-generated MACs

This specification applies primarily to the management plane.

Network Segmentation

Mon, 01 Jan 0001 00:00:00 +0000

Network Segmentation #

Defines mandatory requirements for network segmentation in Deevnet sites.

Purpose #

This standard establishes rules for how sites implement network segmentation. It complements the Substrate Networking architecture document, which describes the segment model and design rationale.

Definitions #

Term	Definition
Segment	An isolated broadcast domain (VLAN) with controlled routing to other segments
Trust boundary	The point where traffic policy changes between segments
Inter-segment traffic	Network communication that crosses segment boundaries
Segment authority	The system responsible for segment routing and policy (core router in production)

Segment Requirements #

1. Management Segment #

The management segment contains infrastructure management plane systems.