Parent folderOpen Confluence

RWS Architecture article

Datacenter 3.0

DC 3.0 is the network operating model for deterministic delivery: intent data is rendered, approved in Git, deployed through AAP, and accepted only with evidence.

  1. Typetopic
  2. Statusactive
  3. Domainnetwork
On this page
  1. Topic – DC 3.0
  2. Overview
  3. Context
  4. Applicable Principles
  5. Decisions
  6. Current State
  7. Rollout lanes by location
  8. Operating contract (NetBox -> Git -> AAP -> Evidence)
  9. Network boundaries
  10. Policy governance and identity boundary
  11. Future Work
  12. Related

Topic – DC 3.0

Overview

DC 3.0 is the network operating model for deterministic delivery: intent data is rendered, approved in Git, deployed through AAP, and accepted only with evidence.

This topic describes the cross-lane operating contract. Device-level details live in topic-network-nxos-evpn-implementation.

Context

Location A and Location B run different lanes under one governance model: adr-019-hybrid-network-rollout-aci-a-ai-only-evpn-b-target defines lane boundaries, while adr-018-network-validation-ansible-vendor-cli and adr-002-nxos-config-replace define delivery controls.

This note is intentionally narrow: it owns the operating model and references implementation and policy authority.

Applicable Principles

Decisions

Current State

Rollout lanes by location

  • Location A: single ACI pod used strictly for AI-cluster-only scope.
  • Location B: EVPN/VXLAN target-state lane for multi-tenant and multi-cluster platform capabilities.
  • Expansion of Location A ACI scope beyond AI requires a new ADR.

Operating contract (NetBox -> Git -> AAP -> Evidence)

  1. Source-of-truth data in netbox defines devices, links, addresses, and policy objects.
  2. Generator produces deterministic artifacts and stores them in Git.
  3. Human approval on Git merge is the production change boundary.
  4. AAP executes precheck -> approval -> deploy -> postcheck -> evidence using approved artifacts.
  5. Change closure requires raw output, parsed output, parser version, and workflow metadata.

Network boundaries

Policy governance and identity boundary

  • Network intent, platform policy, and identity assertions share one Git approval path.
  • Platform admission controls remain managed via policy-as-code admission control.
  • Identity assertions remain managed via keycloak and midpoint with auditable approvals.

Future Work

  • Define policy lifecycle KPIs and evidence retention targets.
  • Publish RT governance and MTU budget standards aligned to implementation runbooks.

Related