Summary

  • RFC 9717 lets a management plane distribute anticipated topology changes, but it says a predicted link addition must not be used until ordinary IS-IS liveness proves the relevant adjacencies operational.
  • A scheduled disconnection is materially different: orbital physics makes the loss highly predictable, so metrics and traffic-engineered paths should change early enough for convergence before the link disappears.
  • Leadership needs separate receipts for schedule authority, dissemination, observed adjacency, topology convergence, path computation, forwarding installation and customer traffic; none of the earlier layers proves the later one.

The green line on the orbital map

At 14:00:00, a constellation controller paints a green line between two satellites. The orbital schedule says their geometry has entered a potential optical-connectivity window. A path computation element has already produced a segment-routing path that crosses the line. The ingress device has a label stack ready.

What, exactly, is true?

The schedule may be authentic and accurately derived. The route may be mathematically valid against the forecast graph. The label stack may be syntactically correct. None of those facts says that two optical terminals have acquired one another, that the link layer is usable, that IS-IS has formed an adjacency, or that a packet has crossed the link. The map is useful because it arrives before reality. It becomes dangerous when that timing advantage is mistaken for authority over reality.

RFC 9717, published in January 2025, is unusually candid about this boundary. Satellite links can fail without warning, just like terrestrial links. Orbital dynamics also make some potential connection and disconnection times predictable. But the two predictions are asymmetric: a forecast that a link can connect is not a guarantee that it will connect, while a forecast that geometry will force it to disconnect is effectively guaranteed. Physics can close a window; it cannot promise that every terminal, pointing system and control process successfully opened it.

That distinction is the operating centre of the document. It is also a limit on the document's authority. RFC 9717 is an Independent Stream, Informational RFC. It explicitly presents the author's view, not an IETF product or community consensus, and proposes no protocol changes. It offers one architecture based on existing mechanisms. Publication is evidence that the proposal entered the RFC Series, not that the architecture has been validated, deployed or adopted.

One schedule, several authorities

RFC 9717 assigns scheduled topology information to the management plane. That plane must make the information available to every node that will make a routing decision from it: the affected IS-IS Level 1 or Level 2 population, plus gateways and PCEs carrying the related topology. The exact dissemination mechanism is outside scope; a YANG model is one possibility.

This leaves an operational question that a diagram cannot answer: which copy of the schedule is authoritative at a particular instant? A defensible record needs an issuer, schedule version, generation time, validity interval, intended recipients, delivery acknowledgements and supersession history. Without those fields, two controllers can each be “using the schedule” while acting on different futures.

Schedule receipt still proves only receipt. A satellite may have the right version but an unhealthy terminal. A gateway may have missed a revision. A PCE may have refreshed its traffic-engineering database before the update arrived. Evidence must preserve both the forecast and the moment each decision-maker incorporated it.

Additions wait for the network

The RFC's rule for a topological addition is conservative. A link coming up or a node joining should cause no functional change until normal IS-IS liveness has proven all relevant adjacencies fully operational. Routers may pre-compute their new tables, and gateways or PCEs may pre-compute candidate paths, but they should not install routes that use the new topology before confirmation.

This makes pre-computation a hypothesis. Its evidence object is an input graph, constraints, algorithm version, candidate path and calculation time. It does not own the claim “this path exists.” Once liveness confirms the adjacency, a fresh or reconciled topology view must still show that the candidate remains valid. Capacity, competing changes or a different failure may have altered the best path while the forecast waited to become real.

The RFC acknowledges that some operators may pre-install. If they do, they must be ready for the topology to fail to become operational and must revert related paths or take another action. A pre-install receipt therefore requires a paired abort path: trigger, owner, deadline, affected labels and confirmation that stale forwarding state was removed. “Installed successfully” is incomplete when installation was conditional on a future physical event.

Deletions require action before observation

A scheduled deletion reverses the evidence order. Waiting for liveness to declare the link dead would surrender the benefit of prediction. RFC 9717 recommends raising the affected link's metric early enough to move traffic, propagate the change and converge before the anticipated loss. Gateways and PCEs should likewise update and install paths in advance.

The exact lead time is not standardized. It depends on network scale, configuration, dissemination delay, IGP convergence, PCE computation and device programming. This turns “before” into a measured operating parameter, not a calendar constant. An operator should retain the scheduled loss time, metric-change time, LSDB propagation spread, path-update time, hardware acknowledgement and last packet observed on the retiring link.

Changing each router's local computation to exclude the link might be possible. The RFC prefers the high-metric method because familiar IGP signalling is safer when schedule distribution or synchronization could be incomplete. That is a governance choice as much as a routing choice: it keeps the decision visible in the control plane that already owns convergence, instead of creating a hidden parallel truth in every node.

A path is a series of claims

The architecture proposes IS-IS, Area Proxy, orbital “stripes,” Segment Routing over MPLS and traffic engineering by gateways or PCEs. Area Proxy can hide the internal detail of a Level 1 stripe from Level 2, limiting global churn. Area and node SIDs can then express an off-stripe path compactly. A gateway or PCE can obtain topology through the IGP, a tunnel or BGP-LS and convert a SID list into a label stack.

Each transformation narrows one question and opens another:

  1. Schedule authorised: the management plane issued a particular future graph.
  2. Schedule received: every relevant node acknowledged the same version in time.
  3. Adjacency observed: terminal and IS-IS liveness showed a current working link.
  4. Topology converged: LSDB, BGP-LS and the PCE's database reflected the same usable graph.
  5. Path computed: a named algorithm produced a SID list from named inputs and constraints.
  6. Path installed: ingress and relevant forwarding hardware confirmed the intended state.
  7. Traffic observed: packets followed the expected path without a hidden fallback or loop.
  8. Service delivered: defined users, regions and traffic classes met stated loss, latency and continuity bounds.

No receipt disappears merely because a later one exists. A customer success probe cannot identify a stale PCE input on its own. A hardware acknowledgement cannot prove a remote optical adjacency. An IS-IS adjacency cannot prove available capacity. A clean LSDB cannot prove the intended label stack was selected. The audit value comes from joining the layers with one change identifier and a synchronized timeline.

The architecture is still a proposition

RFC 9717 assumes the network is almost always connected, enough working links and aggregate bandwidth exist for demand, and scheduled availability is usually accurate. If the graph has no path, it accepts dropping payload packets rather than requiring buffering. These are design premises, not measured properties of any named constellation.

The future-work section makes the uncertainty explicit. Satellite operators still need to validate the architecture through simulation and operational deployment. Meaningful simulation depends on exact ISL connectivity statistics that are not publicly available. Supported pointing angles, distances and rates of change are also unknown. Stripe sizing may range from a few orbits and hundreds of satellites to dozens of orbits and thousands—potentially beyond an implementation's IGP scaling bounds.

The most honest reading is therefore neither dismissal nor endorsement. Scheduled information can reduce avoidable disruption, especially for predictable loss. Existing protocols can supply useful building blocks. But the proposal does not make a forecast self-authenticating, a route self-installing or a service result self-evident.

Sources

Primary records: RFC 9717, the RFC Editor record, the draft history and IETF conflict review. Mechanism context: RFC 9666 on IS-IS Area Proxy, RFC 8402 on Segment Routing, RFC 8660 on SR-MPLS, RFC 4655 on the PCE architecture and RFC 9552 on BGP-LS.