Skip to content

Traveling Maintenance Window

Operational protocol — instantiates Mobile-Defect Reconfiguration

A bounded safe-to-disrupt zone that moves along with the front, taking one segment out of service to work on it while the rest of the system keeps running around it.

You cannot take the whole system down to reconfigure it — but you can take a small piece down at a time. The Traveling Maintenance Window is a bounded zone, cordoned off and served by a parallel path, that moves along the substrate with the front. Inside the window a segment is safely out of service and being worked; outside it, everything keeps running. Its defining idea is to make local disruption safe and legal by isolating it and standing up a parallel service for whatever the window displaces, then advancing that protected envelope forward. It is the moving safety-and-continuity wrapper around the change — not the change itself. The anchor is in-service maintenance of live infrastructure, governed by make-before-break and an N-1 continuity rule.

Example

A telecom operator must replace line cards across a live regional network without dropping customer traffic. Blacking out the region is unthinkable, so it opens a Traveling Maintenance Window. For one node at a time: traffic is rerouted onto a redundant link stood up before the work begins (make-before-break); the node is cordoned out of service — quarantined — and its card swapped; service is verified restored; and only then does the window advance to the next node. A standing invariant gates every step: no customer loses connectivity, and the network never drops below N-1 redundancy. If that condition cannot be held, the window does not move. The entire network is upgraded with no service outage, one protected segment at a time.

How it works

  • Bound the window. Define exactly which segment is in-scope for disruption right now — small enough to be safe.
  • Stand up the parallel scaffold. Reroute or duplicate the service the window displaces, before cutting the old path, so users never feel the outage.
  • Quarantine. Cordon the in-window segment so its disruption cannot leak into the running remainder.
  • Gate on invariants. The window advances only while the continuity-and-safety conditions hold; the invariant is the permission to move, not an afterthought.

The protected envelope travels; the actual reconfiguration inside it is carried out by other mechanisms.

Tuning parameters

  • Window width — how much is out of service at once. Wider finishes faster but risks more per step and strains the parallel capacity.
  • Parallel-capacity headroom — how much spare service you provision to cover the window. More is safer but costs standby resources.
  • Dwell time — how long the window sits on each segment. Longer allows careful work but slows the sweep and prolongs reduced redundancy.
  • Advance-gate strictness — how firmly the continuity invariant must be proven before moving. Strict is safe but slow.
  • Make-before-break vs. break-before-make — prove the parallel path up before cutting the old (safer), or not (cheaper, riskier).

When it helps, and when it misleads

Its strength is letting a live, continuity-critical system be reconfigured with no global outage: disruption is real but bounded, isolated, and covered by a parallel path. It misleads when the window is taken too wide, or advanced before the parallel path is proven — break-before-make turns "bounded disruption" into an outage. And a window that dwells too long leaves the system running degraded below full redundancy for extended stretches, so a second, independent failure during the window becomes catastrophic.[1] The discipline is to keep the window narrow, make-before-break every time, and treat reduced-redundancy time as a cost to minimise rather than a free state to linger in.

How it implements the components

  • parallel_service_scaffold — the stood-up parallel path that carries the service the window displaces, so users do not feel the outage.
  • quarantine_zone — the cordon isolating the in-window segment so its disruption cannot leak into the running remainder.
  • continuity_and_safety_invariants — the conditions (no outage; stay at or above N-1) that must hold for the window to advance.

It provides the safe envelope but does not perform the change inside it (Localized Defect Glide Method, Rolling State-Migration Workflow), verify the finished segment behind it (behind_front_state_verification — Residual-Defect Scan), or cap how many windows may run at once (defect_population_control — Defect-Population Limit Protocol).

References

[1] Make-before-break is the discipline of establishing the new connection or path before severing the old, so continuity is never interrupted during a changeover. Its converse, break-before-make, is cheaper but momentarily drops service — acceptable only where a brief outage is tolerable. ↩