Skip to content

docs: propose IPClass, a policy layer for claiming IP space - #70

Draft
scotwells wants to merge 1 commit into
mainfrom
feat/ip-class-enhancement
Draft

scotwells wants to merge 1 commit into
mainfrom
feat/ip-class-enhancement

Conversation

@scotwells

@scotwells scotwells commented Jul 2, 2026

Copy link
Copy Markdown
Contributor

What this proposes

Today a consumer who wants IP space has to know how the platform carved it — an IPClaim either names a specific IPPool or matches pools by label. That forces the person asking for an address to understand pool names, label conventions, and which project owns which range, and it bakes environment-specific topology into every claim, so a claim that works in staging fails in production.

IPClass adds the missing layer of indirection: a platform-owned policy object, the direct analog of a Kubernetes StorageClass. It names a kind of address space and the rules for handing it out — which pools back it, how blocks are placed, allowed prefix sizes, what happens on release. Consumers stop saying "give me a /24 from prod-backbone-us-east" and say "give me a /24 of class public-egress."

Why it's a better shape

  • Separation of concerns — the claim carries intent, the class carries policy, the pool carries topology.
  • Portable manifests — the same claim works in dev, staging, and production.
  • Transparent cross-project sharing — consumers claim from another project's shared space just by naming the class, never learning its identity or pool names.
  • A real ownership boundary — consumers see only classes; pools stop leaking through permissions.
  • A natural unit for governance — quota and utilization read in terms people actually use.
  • Room to grow — a provisioner field reserves a seam for future BYOIP, cloud, and external address sources without changing the claim experience.

Scope

Fully backward compatible and additive. Claiming by class name becomes the standard path; label selection on the claim is deprecated in favor of the class; naming a pool directly remains as an advanced escape hatch.

Contents

This PR is the proposal onlydocs/enhancements/ip-class.md (summary, motivation, the CLI experience, design details, migration, drawbacks, alternatives). The implementation lands separately in #72. A follow-up for catalog-driven per-project class distribution is drafted separately.

Status

Draft for review.

Consumers currently claim IP space by naming a pool or matching pools by
label, which forces them to understand the platform's pool topology and
makes claim manifests non-portable across environments. This enhancement
proposes IPClass: a platform-owned policy object (analogous to a Kubernetes
StorageClass) that names a kind of address space and the rules for handing
it out. Consumers claim by class name; the platform decides which pools
back a class and how blocks are placed.

The proposal separates intent (the claim), policy (the class), and topology
(the pool); makes cross-project sharing transparent; establishes a clean
platform/consumer ownership boundary; gives quota and utilization a natural
unit; and reserves a provisioner seam for future external and cloud address
sources. It is fully backward compatible.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant