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.