Mark FRR-dependent invariants as unenforced until peering lands #21

New Issue

2026-07-26T17:11:55+10:00

benvin commented

2026-07-26 17:11:55 +10:00

Problem. DESIGN.md invariants 3–5 (zone resolvable on every enforcing
device, zone anchored at ≥1 firewall, firewall binds every connected zone) are
specified as validated against FRR routing state — but internal/ has no
BGP-LS/BMP/route-monitoring package yet. The compiler currently accepts
topologies it cannot check, and it would be easy to forget which guarantees
are real when debugging a reachability hole later.

Proposal. Until FRR peering exists: log a startup warning enumerating
unenforced invariants, note them in the README, and (where possible) enforce
weaker static versions now — e.g. invariant 4's "every zone has ≥1 binding on
some firewall" needs no routing data and can be checked today.

**Problem.** DESIGN.md invariants 3–5 (zone resolvable on every enforcing device, zone anchored at ≥1 firewall, firewall binds every connected zone) are specified as validated against FRR routing state — but `internal/` has no BGP-LS/BMP/route-monitoring package yet. The compiler currently accepts topologies it cannot check, and it would be easy to forget which guarantees are real when debugging a reachability hole later. **Proposal.** Until FRR peering exists: log a startup warning enumerating unenforced invariants, note them in the README, and (where possible) enforce weaker static versions now — e.g. invariant 4's "every zone has ≥1 binding on some firewall" needs no routing data and can be checked today.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unkin/tomswallapi#21