# G18 -- Octavia lb-mgmt IPAM: GA-R5 ruling PREP package (2026-08-08)

**Status: PREP ONLY. This document does NOT rule and mutates nothing.** It assembles the
quotes, options, and governing-decision reconciliation so the operator can issue a GA-R5
ruling on gate **G18**. No D-number is minted here; no built surface is edited.

Author context: prep for firing octavia `configure-resources` on the **dc0 throwaway
checkpoint**, ruling G18 now so the ruling transfers to the 10.13 rebuild. All facts below
are quoted from repo artifacts (path:line) or explicitly flagged as an OWED live read.

---

## A. What G18 IS (and what it does NOT reopen)

**Verbatim definition** -- `docs/CURRENT-STATE.md:7721` (gate register row):

> | G18 | **IPAM apex completeness for the Octavia lb-mgmt plane** -- does the
> charm-created `lb-mgmt-net` prefix get BACK-FILLED into the NetBox apex, or is that plane
> recorded as deliberately charm-owned and out of apex scope? | [R] ruling-type gate
> (GA-R6 rule 6): closes ONLY on a GA-R5 recorded ruling with the operator's exact
> utterance, dated, committed and pushed. **DEFERRED BY OPERATOR DIRECTION 2026-07-27 until
> the cloud is LIVE and IPv6 behaviour has been observed** -- it is not answerable from
> artifacts alone. **BLOCKING: the deployment may NOT be declared complete while this is
> open.** ANSWERABLE from Stage 5 onward (the prefix exists once Octavia deploys); BLOCKS
> the FINAL stage close / project close. | operator | **OPEN 2026-07-27.** ... |

**Current status: OPEN 2026-07-27** (same row). Ruling-type `[R]` gate; closes only on a
recorded GA-R5 ruling with the operator's exact utterance.

**Operator direction that opened it, verbatim** (`CURRENT-STATE.md:7721`, echoed at
`design-decisions.md:2486-2492`):

> "leave this as an open decision that will need a ruling once we have the cloud live and we
> have a better read on the network and how everything is functioning with the addition of
> the new IPv6 configurations. Make this a gated decision so we cannot close the project (or
> whatever phase you think it best ruled in) without a ruling on this item."

**The pre-stated options recorded on the gate row** (`CURRENT-STATE.md:7721`):
> (a) back-fill the charm-created prefix into NetBox post-deploy as a documented record;
> (b) record the plane as charm-owned and explicitly out of apex scope; (c) fold the
> decision into D-136's render-pipeline ruling if that is taken first.

### What G18 does NOT reopen -- ALREADY RULED by R8 (D-101 ruling note 2026-07-27)

`design-decisions.md:2434-2507` (the **R8** ruling note under D-101). Operator utterance,
verbatim (`:2444-2445`):

> "I want to take a Octavia creates and owns its own IPv6 network."

R8 settled THREE things that G18 must **not** reopen:
1. **Ownership** -- Octavia creates and owns its own lb-mgmt network (`create-mgmt-network`
   left at charm default **True**; set NOWHERE in bundle/overlays -- `:2450-2452`, confirmed
   again below in B).
2. **Address family** -- IPv6 **ULA** (`fc00::/7`); the charm default is a ULA and it agrees
   with D-101's "IPv6-only ULA ... Octavia lb-mgmt ... Internal, no external clients"
   classification (`:2469-2472`).
3. **Prefix source** -- **charm-generated**; the charm exposes NO CIDR / family / router
   config option, so the prefix "cannot come from the apex" (`:2481-2484`).

Therefore G18's live question is **NOT "what CIDR should lb-mgmt use"** -- that is charm-
generated and ruled. G18 is **only the APEX-RECORDING question**: does the charm-generated
prefix get recorded in NetBox (back-fill), or is the plane declared deliberately charm-owned
and out of apex scope. Any option that changes the CIDR, family, or ownership REOPENS R8 and
must be flagged as such (see Section C, Option D).

### The deferral trigger is NOT met -- state this to the operator

G18 was deferred "until the cloud is LIVE and IPv6 behaviour has been observed." **dc0 is a
pre-`configure-resources` throwaway checkpoint** -- the lb-mgmt network does not exist yet
and no IPv6 behaviour has been observed. The operator is choosing to rule **ahead of their
own stated trigger**, on artifacts, so the ruling transfers to the 10.13 rebuild. That is
the operator's prerogative; it is surfaced here so the condition they themselves set is not
hidden. The live observation the deferral wanted remains available later as a review item
(the OWED checks in Section F).

---

## B. What `configure-resources` will CREATE, and the IPAM question precisely stated

**The action** (`runbooks/phase-05-octavia-enablement.md:53-91`): `configure-resources` is
D-021 Phase 1; it **takes NO parameters** (`:63`). With `create-mgmt-network=true` (the
MEASURED charm default) it creates the neutron management resources the charm locates by
resource TAG (`charm-octavia`).

**What it creates** (as-built capture from the prior deploy, `phase-05:89-99`, `:203-208`):
- `lb-mgmt-net` -- a **Neutron** network (found via `openstack network list --tags
  charm-octavia`).
- `lb-mgmt-subnetv6` -- an **IPv6 ULA** subnet, `fc00::/64`, **charm-generated**, and it
  **"regenerates per deploy"** (`:205` -- "a fresh IPv6-ULA on the lb-mgmt prefix
  (fc00::/64; exact addr not captured this run -- the ULA regenerates per deploy)").
- `lb-mgmt-sec-grp` -- security group(s).
- a **Neutron router** ("Router for IPv6 RA or north/south mgmt traffic" -- required for
  Router Advertisement so amphorae get addresses; `octavia-ipv6-research-20260727.md:233-235`).
- `o-hm0` -- the health-manager port, a **br-int** port carrying an `fc00::/64` ULA
  (`phase-05:92-95`).
- a **default amphora flavor** (charm-created alongside the network resources).

**This is a Neutron OVERLAY network, not a MAAS/underlay plane.** It rides the geneve overlay
whose underlay is the `data-tenant` plane: `octavia:ovsdb-cms` and `ovn-chassis-octavia:data`
bind to `data-tenant` (`docs/network-space-binding-reference.md:60`), and the octavia
application itself binds to `metal-admin` (`:113`). **There is NO `octavia` binding to any
`lb-mgmt` space** (bundle.yaml octavia `bindings:` block, lines 749-762: amqp / certificates
/ cluster / ha / identity-service / internal / neutron-api / neutron-openvswitch /
ovsdb-subordinate / shared-db -> metal-internal; ovsdb-cms -> data-tenant; public ->
provider-public). This fact is load-bearing for Section D.

**The charm control surface** (`octavia-ipv6-research-20260727.md:217-230`): "`create-mgmt-
network` (default True) is the ONLY related option ... There is NO configuration option for
CIDR, address family, router creation, or north/south control." Getting a specific prefix
"REQUIRES `create-mgmt-network: false`, and you then own the network AND the security groups
AND the ports AND the router, because resource TAGS are how the charm finds them."

### THE IPAM QUESTION, precisely stated

Given R8 (charm owns it; IPv6-ULA; charm-generated per-deploy prefix), the ONLY open IPAM
question G18 asks is:

> The charm generates its own `lb-mgmt-subnetv6` ULA prefix at `configure-resources` time,
> and that prefix is NOT specified by any artifact and REGENERATES on each (re)deploy. The
> NetBox apex therefore has no allocation the deploy consumes for this plane. **Does the
> apex (a) back-fill the charm-created prefix as a record, or (b) record the plane as
> deliberately charm-owned and out of apex scope?** -- plus the D-139 sub-question in
> Section D (what becomes of the *separate* apex-carved `lb-mgmt` GUA prefix).

---

## C. Options for the lb-mgmt IPAM (with re-IP portability)

Re-IP frame: the charm net is IPv6-ULA `fc00::/64`, Neutron overlay, regenerating per deploy.
The re-IP is **v4** (`10.12.0.0/16` -> `10.13.0.0/16`). **Zero intersection** -- the v4 re-IP
cannot touch the lb-mgmt prefix, and the lb-mgmt prefix cannot constrain the re-IP, in either
direction. Portability differences below are therefore about *record staleness across the
teardown/rebuild*, not about v4 addressing.

### Option B (RECOMMENDED) -- record the plane as deliberately charm-owned / out of apex scope
- Accept `create-mgmt-network=true` (charm default, R8-ruled). The apex carries a NOTE for
  the plane -- "charm-owned; prefix charm-generated ULA, ephemeral per deploy; not an
  apex-driven allocation" -- rather than a concrete prefix row the deploy is expected to
  consume.
- **Re-IP portable: YES, natively.** Nothing to migrate; the note is deploy-agnostic and
  survives the 10.13 rebuild unchanged. The charm regenerates its ULA on the rebuild exactly
  as on dc0.
- Aligns with R8 (no reopen), and is D-141-compliant (see D).

### Option A -- back-fill the charm-created prefix into NetBox post-deploy
- After `configure-resources`, capture the actual generated `fc00::/64` and record it in the
  apex as an `active` (or observed) allocation.
- **Re-IP portable: NO, in the naive form.** Because the ULA **regenerates per deploy**, a
  back-filled concrete prefix is **stale the moment dc0 is torn down** and wrong for the
  10.13 rebuild -- which is precisely the rebuild the operator is ruling for. A concrete
  back-fill would have to be re-captured and re-written on every deploy.
- Survives ONLY as a **structural** back-fill (record "the plane exists, charm-owned, prefix
  ephemeral" without pinning the concrete /64) -- which **converges to Option B**. So A-naive
  is close to disqualified for this project's stated purpose; A-structural == B.

### Option C -- fold into D-136's render-pipeline ruling
- **MOOT / effectively closed.** D-136 is **ADOPTED 2026-07-27, option (D)**
  (`design-decisions.md:6401-6419`). The G18 deferral note's premise -- "ruling it early
  would pre-empt the *unruled* D-136" (`:2491`) -- **no longer holds**; D-136 is ruled. There
  is no open D-136 ruling to fold into. Listed for completeness; not a live path.

### Option D -- carve a dedicated lb-mgmt prefix and hand it to the charm (REOPENS R8)
- Set `create-mgmt-network=false` and point octavia at a pre-created Neutron network on a
  chosen prefix (e.g. the D-139 apex `lb-mgmt` GUA `/64`, or a D-134-style carved band).
- **This REVERSES R8.** Per the research capture (`:228-230`) it drags ownership of the
  network AND security groups AND ports AND router onto the operator, and R8 explicitly chose
  the opposite ("Octavia creates and owns its own IPv6 network"). It also changes the family
  (charm ULA -> whatever is carved).
- **Re-IP portable: only if the carved prefix is v6** (a v4 carve would enter the re-IP blast
  radius). But portability is moot -- this option is listed to be **explicitly rejected as a
  reopen of a GA-R5 ruling**, not recommended. Included so the operator sees the full space.

---

## D. Governing-decision reconciliation (D-021, D-134, D-139, D-141) + the two-objects finding

### D-021 (Octavia amphora image pipeline) -- `design-decisions.md:507-517`
D-021 governs the **amphora IMAGE** (charm-native `octavia-diskimage-retrofit`,
`use-internal-endpoints: true`, `image-format: raw`, tag `octavia-amphora` matching octavia's
`amp-image-tag`). It is the pipeline that `configure-resources` (D-021 Phase 1) precedes. **It
does NOT touch lb-mgmt IPAM** -- it is about the image the amphorae boot, not the management
network they attach to. Reconciliation: **no option in C conflicts with D-021.** All options
leave the amphora image pipeline unchanged. (`amp-image-tag: octavia-amphora` and
`loadbalancer-topology=SINGLE` are the MEASURED octavia config; neither is an IPAM lever.)

### D-134 (per-DC octet bands) -- `design-decisions.md:5858-6200`
D-134 is a **v4** per-role octet-band scheme over the **SIX** MAAS DC planes. **It allocates
NOTHING for an lb-mgmt / amphora-management network.** Confirmed in the as-built model:
`scripts/lib-net.sh:22-31` -- `PLANE_CIDRS` and `PLANE_NAME` list exactly six planes
(provider-public, metal-admin, metal-internal, data-tenant, storage, replication); there is
**no lb-mgmt plane**, and `lbaas` is listed in `STALE_SPACES` (`lib-net.sh:34`). D-134's bands
(`.1-.3` infra / `.4-.49` utility / `.50-.99` VIP / `.100-.200` nodes / `.201-.254` dynamic)
have **no lb-mgmt band**. **lb-mgmt is outside the D-134 carved-plane model entirely.**

### D-139 (full-GUA re-carve) -- `design-decisions.md:7254-7497` -- THE COLLISION FINDING
D-139 ruling A adds `lb-mgmt` as a **"NEW plane"** in its family matrix (`:7282`) and ruling B
carves it an apex **GUA** `/64`: parent `f0X:80::/60`, dc0 `2602:f3e2:f02:80::/64`, dc1
`2602:f3e2:f03:80::/64` (`:7312`). Execution step 5 (`:7489`): "**Carve `lb-mgmt` its
VLAN/space/subnet. It has never had one anywhere, in either family.**"

**This is NOT a contradiction with R8 -- it is TWO OBJECTS SHARING ONE NAME:**
- **D-139's `lb-mgmt`** is a **MAAS underlay plane** (a space / VLAN / subnet -- the vocabulary
  of step 5, sitting in the matrix beside storage/replication/data-tenant, all MAAS spaces).
- **R8's / the charm's `lb-mgmt-net`** is a **Neutron overlay network** the charm creates and
  owns, riding the geneve overlay on the `data-tenant` underlay (Section B).

The discriminating evidence: **octavia binds to NO `lb-mgmt` space** (bundle.yaml:749-762;
binding-reference:60,113). So the D-139 apex GUA `lb-mgmt` `/64` **has no charm consumer**, and
**D-139 step 5 is unexecuted** (the v6 GUA carve is largely unexecuted; `lib-net.sh` still
holds six planes with no lb-mgmt). This yields a **sub-question the operator's ruling should
also settle**: what becomes of the carved-but-unconsumed D-139 apex `lb-mgmt` GUA `/64`?
Candidate dispositions to put alongside the main options: keep it as a **`reserved`**
architectural allocation under D-141 (intent recorded, no live consumer) with a note that it
is NOT the charm's mgmt network; or record that the D-139 "lb-mgmt plane" and the charm's
"lb-mgmt-net" are distinct and the former is an underlay reservation only.

### D-141 (author dual-stack; apex drives the deploy) -- `design-decisions.md:7920-7962`
D-141 requires apex allocations to **drive** the deploy, not be back-filled to match it -- "the
authority direction G18/lens-7 requires" (`:7937-7940`). At first glance Option B (record as
out-of-scope) looks like conceding apex incompleteness. It is not: **D-141 governs allocations
the deploy CONSUMES.** The charm's mgmt prefix is one no artifact can specify and the charm
regenerates per deploy -- it is **not an apex-driven allocation**, so recording it as
deliberately out of scope is **D-141-COMPLIANT, not an exception.** D-141 says so itself
(`:7958-7960`, quote it in the ruling):

> "**Adjacent to gate G18** (IPAM apex completeness, deferred-until-live): D-141 governs the
> STRUCTURE of apex allocations; G18 remains the separate ruling on the charm-created lb-mgmt
> prefix and must not be treated as answered by this."

That line is the license to rule Option B without contradicting D-141. (Note the tension: the
D-139 apex GUA `/64` IS an apex allocation -- so the D-141 "author dual-stack / reserved
until consumable" discipline applies to *that* object, which supports keeping it `reserved`
rather than deleting it. Two objects, two treatments.)

---

## E. The GA-R5 ruling QUESTION drafted for the operator

**Reminder (GA-R5): ONE decision; reconcile the governing decisions; the operator's exact
utterance is recorded verbatim at ruling time.** Do NOT mint a new D-number (Section F).

> **G18 -- Octavia lb-mgmt IPAM apex recording.** R8 (D-101 note, 2026-07-27) already ruled
> that Octavia creates and owns its own IPv6-ULA lb-mgmt network (`create-mgmt-network=true`),
> with a **charm-generated `fc00::/64` prefix that regenerates on every deploy**. This ruling
> does NOT reopen ownership, family, or CIDR. The open question is **how the apex records
> this one plane**:
>
> - **(B) RECORDED OUT OF APEX SCOPE [RECOMMENDED]** -- the charm-created `lb-mgmt-net` is
>   declared deliberately charm-owned; the apex carries a structural note (plane exists,
>   charm-owned, prefix ephemeral ULA), not a concrete prefix row the deploy consumes.
>   D-141-compliant (D-141 governs consumed allocations; this is not one). Re-IP portable to
>   10.13 natively.
> - **(A) BACK-FILL THE CONCRETE PREFIX** -- capture and record the actual `fc00::/64` after
>   `configure-resources`. NOT portable: the ULA regenerates per deploy, so the record is
>   stale on the 10.13 rebuild. (Its portable form -- a structural, non-pinned record --
>   collapses into B.)
> - **(C) FOLD INTO D-136** -- MOOT; D-136 is already ADOPTED (2026-07-27, option D).
> - **(D) REOPEN R8** (create-mgmt-network=false + operator-carved prefix) -- reverses a GA-R5
>   ruling and transfers ownership of the net/secgroups/ports/router to the operator. Listed
>   to be explicitly rejected.
>
> **Sub-question (D-139):** the D-139 apex GUA `lb-mgmt` `/64` (`2602:f3e2:f02:80::/64` dc0)
> is a **MAAS-underlay plane with no charm consumer** -- distinct from the charm's Neutron
> `lb-mgmt-net`. Ruling B should also state its disposition: keep as a **`reserved`**
> architectural allocation per D-141, explicitly noted as NOT the charm's mgmt network.

**RECOMMENDED DEFAULT: Option (B), out of apex scope, + keep the D-139 GUA `/64` as a
`reserved` underlay allocation noted distinct from the charm net.**

**One-line rationale:** the charm-generated ULA regenerates per deploy so it is not an
apex-driven allocation (D-141 governs only consumed allocations, and says G18 is separate);
B is the only option that is both R8-aligned and natively portable to the 10.13 rebuild the
operator is ruling for.

---

## F. OWED read-only checks + D-number status

### No new D-number needed (grep reported)
Highest live decision number is **D-142** (`design-decisions.md`; the apparent "D-202" is a
false-positive substring of the filename fragment `RETIRED-20260806`). **Next-free would be
D-143** IF one were required -- **but it is not.** G18 is a `[R]` ruling-type gate that closes
on a GA-R5 ruling recorded against **existing** decisions: annotate the **D-101 / R8** ruling
note (the decision that owns lb-mgmt ownership/family) and, for the two-objects finding, add a
reconciliation note on **D-139** (the decision that carved the apex GUA `lb-mgmt` plane). This
matches the caught near-miss in auto-memory (#19: do not mint a D-number for what is really an
amendment to a ruled parent). **The operator may overrule and mint D-143 if they judge this a
standalone architectural decision.** GRAND TOTAL: prep proposes NO mint; reports D-143 as
next-free.

### OWED live read-only checks (name them; do NOT run the action; run AFTER `configure-resources`)
1. **Capture the actual generated prefix** (settles what B's note / A's back-fill would
   reference): `openstack subnet list --tags charm-octavia -f value -c Name -c Subnet`
   (expect `lb-mgmt-subnetv6`, an `fc00::/64`). Read-only `list`.
2. **Settle R8's explicitly-unasserted external-gateway / isolation question**
   (`design-decisions.md:2503-2507`, `octavia-ipv6-research-20260727.md:232-242` -- "cannot be
   asserted that the charm never attaches an external gateway"):
   `openstack router list --tags charm-octavia` then inspect the router's
   `external_gateway_info` (read-only `show`). Confirms the mgmt net is isolated.
3. **Standing MTU obligation (adjacent, NOT a G18 input)** -- LP #2018998 recurred on our
   exact pin (`design-decisions.md:2494-2501`): verify `o-hm0`'s MTU MATCHES `lb-mgmt-net`'s,
   measured. This is a Stage-5 Octavia-step obligation independent of the G18 ruling; noted
   here only so it is not lost.

### Items I could NOT verify from artifacts (flagged, not guessed)
- The **concrete** charm-generated `fc00::/64` for the dc0 checkpoint does not exist yet
  (`configure-resources` not fired) -- check #1 above captures it post-action.
- Whether the charm attaches an external gateway on its own -- check #2 (R8 left this
  unasserted by design; it needs the live router or the charm source).

---

*Prep complete. No ruling issued, no D-number minted, no built surface edited, nothing
committed. Operator rules from Section E; record the exact utterance per GA-R5.*