d139-conformance-dc0-20260801.txt
==================================
Conformance of the vr1-dc0 DEPLOY INPUTS and LIVE SUBSTRATE against the specs
solidified 2026-07-31/08-01: D-139 ruling A (family matrix), ruling B (GUA
addressing), the 2026-08-01 "B plus C" narrowing, and the 2026-08-01 OOB
amendment. Read-only. Host: vcloud + voffice1. No deploy has occurred.
METHOD: each ruled row was compared to the ARTIFACT (live MAAS subnets, apex
prefixes/ip-addresses, the deploy overlays), never to another document. This is
the "RULED IS NOT BUILT -- check the artifact" test.
--------------------------------------------------------------------------------
A. RULING A -- family matrix vs live MAAS (dc0 region, profile vr1-dc0-region)
--------------------------------------------------------------------------------
plane ruled family v4 in MAAS v6 in MAAS verdict
provider-public dual-stack 10.12.4.0/22 Y 2602:f3e2:f02:10::/64 CONFORMS (v6 already GUA)
metal-admin dual-stack 10.12.8.0/22 Y fd50:840e:74e2:220::/64 v4 ok; v6 is ULA -> step 2
metal-internal IPv6-only 10.12.12.0/22 Y fd50:...:221::/64 v4 PRESENT (see note B)
data-tenant IPv6-only 10.12.16.0/22 Y fd50:...:230::/64 v4 PRESENT (see note B)
storage IPv6-only 10.12.32.0/22 Y fd50:...:240::/64 v4 PRESENT (see note B)
replication IPv6-only 10.12.36.0/22 Y fd50:...:250::/64 v4 PRESENT (see note B)
lb-mgmt IPv6-only NEW - - - NOT BUILT, either family (step 5)
oob dual-stack NEW - - - NOT BUILT, either family
NOTE B -- the four v4 prefixes are NOT a defect: the 2026-08-01 "B plus C" ruling
narrowed ruling A's v6-only EXECUTION to a storage+replication experiment, and step 7
(v4 removal) is out of the execution list and gated on the unmeasured `network-get`
question. They are RULED-REMOVED and DELIBERATELY still present. What IS worth
recording: all four sit in the apex as status=active with descriptions citing only
D-101 -- the decision D-139 amended -- and carry NO D-139 annotation anywhere.
--------------------------------------------------------------------------------
B. RULING B -- GUA carve vs apex and MAAS
--------------------------------------------------------------------------------
apex prefixes scoped vr1-dc0: 13 v6 (4 GUA + 9 ULA), 8 v4.
GUA present: 2602:f3e2:f02::/48, :10::/60, :10::/64, :11::/64 (provider-public only,
and it PRE-DATES D-139 -- carved under D-101/D-111)
GUA absent: :20::/60 :20::/64 :21::/64 :30::/60 :30::/64 :40::/60 :40::/64
:50::/60 :50::/64 :80::/60 :80::/64 :f0::/60 :f0::/64 = the 13 CREATE rows
ULA /48 retired for VR1: NOT retired. 9 prefixes live, holding 26 dependent ip-addresses.
VERDICT: ruling B is RULED-BUT-NOT-BUILT except for provider-public. Steps 1-2 close it.
--------------------------------------------------------------------------------
C. >>> THE DEPLOY INPUT DOES NOT CONFORM, AND THIS IS THE BLOCKER <<<
--------------------------------------------------------------------------------
overlays/vr1-dc0-vips.yaml carries an R2 dual-family SEXTET for each of 13 services:
vip: "10.12.4.50 10.12.8.50 10.12.12.50 2602:f3e2:f02:11::50 \
fd50:840e:74e2:220::50 fd50:840e:74e2:221::50"
Counted across the file: 13x 2602:f3e2:f02:11:: (GUA, provider-public VIP)
13x fd50:840e:74e2:220:: (ULA, metal-admin)
13x fd50:840e:74e2:221:: (ULA, metal-internal)
So 26 of the 39 v6 VIP legs are ULA -- and they are EXACTLY the 26 dependent
ip-addresses the step-1 dry run reports inside the retiring ULA /64s. The two sets
are the same objects, confirmed by description ("VIP keystone metal-admin v6 (vr1-dc0)").
CONSEQUENCE: deploying after steps 1-3 alone would configure 26 VIP legs on prefixes
that ruling B RETIRES, while their GUA replacements (:20::/64, :21::/64) exist in the
apex and MAAS but appear NOWHERE in the deploy input. The overlay must be re-rendered
onto GUA before Step 4, or the cloud is deployed onto retired addressing.
This is the measured form of the step 4-6 coupling flagged at the ordering ruling. It
is NOT settled by that ruling, which named steps 1-3 only.
--------------------------------------------------------------------------------
D. OTHER MEASURED GAPS
--------------------------------------------------------------------------------
1. scripts/lib-net.sh contains ZERO IPv6 (0 v6-shaped lines). D-139 step 4 says
"update lib-net.sh's v6 arm" -- there is no v6 arm to update; one must be AUTHORED.
2. No gate compares D-139's family matrix or GUA table to any artifact. Only three
files mention D-139, and dc-node-v6-verify.sh's own header states it asserts
NIC-against-MAAS and explicitly NOT against D-139's ruled table.
3. OOB's v4 half (10.12.60.0/22) has no per-DC split -- UNRULED, deliberately not
inferred. The v6 half is complete and in the tool.
4. VPN (:e0) remains omitted from the carve; VR0 and Willamette both hold it.
--------------------------------------------------------------------------------
E. WHAT IS CONFORMANT TODAY
--------------------------------------------------------------------------------
- provider-public, both families, apex + MAAS + node br-ex (2602:f3e2:f02:10::150).
- All 9 role nodes hold 6 v6 statics each, matching MAAS exactly (gate G19, live).
- The carve TOOL now matches the ruled table incl. OOB: dry run CREATE 13 | EXISTS 3
| RETIRE-REPORT 9, both oob rows present, nothing written.
- Apex prefix count 139, unchanged; --commit has never been passed.
