diff --git a/docs/CURRENT-STATE.md b/docs/CURRENT-STATE.md index 9b39d28..4999b45 100644 --- a/docs/CURRENT-STATE.md +++ b/docs/CURRENT-STATE.md @@ -2456,6 +2456,31 @@ That needs its own GA-R5 exchange before Step 4. Step 7 (v4 removal) is unchanged, still `storage`+`replication` together, still gated on the unmeasured `network-get` question -- which now arrives LATER, since the deploy that produces it is sequenced after the carve. + **>>> D-139 GAINS AN OOB PLANE, DUAL-STACK, RULED 2026-08-01 (GA-R5) -- AND IT WAS CAUGHT + BEFORE THE STEP-1 WRITE, NOT AFTER. <<<** Operator direction, exact utterances: **"make sure + to include oob in the dual stack recordings"**, then **"Dual-stack; rule 10.12.60.0/22 back + into force for OOB"**. Full text: `### AMENDMENT 2026-08-01 -- D-139 ruling A gains an OOB + plane` in `docs/design-decisions.md`. **MEASURED GAP: D-139's `CARVE` table carried hextets + `10,11,20,21,30,40,50,80` and NO `0xf0` (OOB), NO `0xe0` (VPN)** -- `design-decisions.md:3066` + is the origin (all three were declared out of scope of the six-plane tool; D-139 brought `:80` + back and left the other two). **So the step-1 push as it stood would have written a carve + INCOMPLETE against the org standard ruling B cites as its own reason.** The push was held and + is NOT stale-run. **THE RULING KNOWINGLY DIVERGES FROM BOTH PRECEDENTS, and that is measured, + not assumed: VR0 DC0 and Willamette carry OOB IPv6-ONLY, and a sweep of EVERY apex prefix + returns ZERO v4 rows with role `oob` at ANY site.** Dual-stack OOB is a deliberate correction + on a Roosevelt reason -- BMC/IPMI is overwhelmingly IPv4, so a v6-only OOB plane is unusable on + real hardware. **This SUPERSEDES the standing `| OOB | n/a | n/a | n/a | Bare-metal-only + concern |` row at `design-decisions.md:93`.** **ON THE v4 VALUE: `10.12.60.0/22` comes from + D-058, which is SUPERSEDED by D-060 and REMAINS SO IN FULL** -- this ruling reinstates that one + ROW'S VALUE under D-139's authority and revives nothing else. Verified FREE first: the apex + holds `10.12.64.0/22` + `10.12.68.0/22` (vr1-dc1) and nothing in `10.12.60.0`-`10.12.63.255`; + dc0's MAAS holds none of it. **OPEN AND DELIBERATELY NOT INFERRED -- the per-DC v4 split.** + `10.12.60.0/22` is ONE block and v4 is carved PER DC, with a mapping that is NOT a uniform + offset (4->64/8->68/12->72/16->76 are +60; 32->80/36->84 are +48), so no rule can be derived. + Whether the DCs split it into two `/23`s or dc1 takes a separate block is UNRULED. **The v6 + half is complete and unaffected** (each DC's OOB `/64` comes from its own `/48`), **and the + step-1 push is v6-only, so it is NOT blocked by this.** **VPN (`:e0`) is the SAME omission, + surfaced alongside OOB, named in neither utterance, and left OPEN rather than folded in.** **STILL OWED BEFORE THE DEPLOY, in ruled order:** D-139 step 1 (apex CREATE-only push, `netbox/d139-gua-carve.py --dc vr1-dc0 --commit`; tool built, independently reviewed, dry-run byte-identical, `--commit` never yet passed), step 2 (MAAS GUA `/64`s alongside the diff --git a/docs/design-decisions.md b/docs/design-decisions.md index 0db42d8..bbe5ab0 100644 --- a/docs/design-decisions.md +++ b/docs/design-decisions.md @@ -7150,3 +7150,50 @@ `replication` together per the "B plus C" ruling, and still gated on the unmeasured `network-get` question -- which now arrives later, since the deploy that produces it is sequenced after the carve. + +### AMENDMENT 2026-08-01 -- D-139 ruling A gains an OOB plane, DUAL-STACK, and D-058's `10.12.60.0/22` is ruled back into force for it + +**Operator direction, exact utterance: "make sure to include oob in the dual stack recordings"**, +then on the family/value question: **"Dual-stack; rule 10.12.60.0/22 back into force for OOB"**. + +**WHY IT WAS MISSING, measured rather than assumed.** D-139's carve table (`netbox/d139-gua-carve.py` +`CARVE`) carried hextets `10,11,20,21,30,40,50,80` and **no `0xf0` (OOB) and no `0xe0` (VPN)**. +`docs/design-decisions.md:3066` is the origin: `lbaas-mgmt (:80)`, `vpn (:e0)` and `oob (:f0)` were all +declared OUT OF SCOPE of the six-plane mirroring tool. D-139 brought `:80` back as a first-class plane +and left `:e0`/`:f0` behind. The apex already carries `oob` and `vpn` IPAM roles, so nothing blocked +them. **Had this not been caught, the step-1 push would have written a carve that is incomplete against +the very org standard ruling B cites as its reason.** + +**WHAT THE PRECEDENTS ACTUALLY HOLD, and the ruling KNOWINGLY DIVERGES FROM THEM.** VR0 DC0 +(`2602:f3e2:e02:f0::/60` + `:f0::/64`) and Willamette (`2602:f3e2:102:f0::/60` + `:f0::/64`) both carry +OOB **IPv6-ONLY**; a query across every apex prefix returns **ZERO** v4 rows with role `oob`, at any +site. So dual-stack OOB is NOT conformance -- it is a deliberate correction, and the Roosevelt reason +is sound: BMC/IPMI is overwhelmingly IPv4 in practice, so a v6-only OOB plane would be unusable on real +hardware. VR1 proves it and Roosevelt inherits it. This also SUPERSEDES the standing +`| OOB | n/a | n/a | n/a | Bare-metal-only concern |` row at `docs/design-decisions.md:93`: OOB is no +longer n/a for the virtual rehearsals. + +**ON THE v4 VALUE, stated precisely so no one reads this as reviving a dead decision.** `10.12.60.0/22` +appears at `docs/design-decisions.md:924` inside **D-058, which is SUPERSEDED by D-060** and whose plane +renumber is abandoned. **D-058 remains superseded in full.** This ruling reinstates that one ROW'S VALUE +under D-139's own authority; it does not revive D-058 or any other row of it. MEASURED FREE before the +ruling was applied: the apex holds `10.12.64.0/22` and `10.12.68.0/22` (both `vr1-dc1`) and nothing in +`10.12.60.0`-`10.12.63.255`; dc0's MAAS region holds six v4 subnets, none of them in that range. + +**RULED, amending ruling A's family matrix:** + +| Plane | `/60` parent | dc0 `/64` | dc1 `/64` | IPv4 | Family | +|---|---|---|---|---|---| +| `oob` | `f0X:f0::/60` | `2602:f3e2:f02:f0::/64` | `2602:f3e2:f03:f0::/64` | `10.12.60.0/22` | **dual-stack** | + +**OPEN, NOT INFERRED -- the per-DC v4 split.** `10.12.60.0/22` is ONE block and this deployment carves +v4 PER DC (dc0 `10.12.{4,8,12,16,32,36}.0/22`; dc1 `10.12.{64,68,72,76,80,84}.0/22`, a mapping that is +NOT a uniform offset -- 4->64/8->68/12->72/16->76 are +60 but 32->80/36->84 are +48, so no rule can be +derived from it). Whether dc0 and dc1 split `10.12.60.0/22` into two `/23`s, or dc1 takes a separate +block, is NOT settled by this ruling and must not be guessed. **The v6 half is unaffected and complete** +-- each DC's OOB `/64` comes from its own `/48` by construction. **The apex push (step 1) is v6-only, so +it is NOT blocked by this open item.** + +**VPN (`:e0`) IS THE SAME OMISSION AND IS NOT RULED HERE.** VR0 and Willamette both carry +`:e0::/60` with role `vpn`; VR1 has none. It was surfaced alongside OOB and the operator's direction +named OOB only, so it stays OPEN rather than being folded in silently.