Summary

  • In RFC 9719, was-the-last-lie-accepted reports whether the most recently received Link Information Element passed acceptance on one interface. It does not certify a ThreeWay adjacency, a correct hierarchy, a converged TIE database, installed forwarding or delivered traffic.
  • A sound operational test follows the protocol’s evidence chain. A clear action begins reconstruction; only subsequent state, database, route, forwarding and delivery observations can demonstrate recovery.

One true statement, six unproven conclusions

A boolean can be perfectly accurate and still be operationally dangerous when its scope is forgotten. RFC 9719 defines was-the-last-lie-accepted as read-only state beneath a RIFT interface. If the last received LIE was accepted, the value is true. If it was rejected, last-lie-reject-reason and the neighbor-error notification provide diagnostic context.

That is valuable evidence. It establishes that one received discovery message crossed the acceptance boundary. It does not say that the remote node has seen this node in the required state, that the adjacency has reached ThreeWay, that Zero Touch Provisioning selected the intended level, that the topology database is complete, that routes reached a forwarding plane, or that an application packet arrived.

The distinction follows directly from RIFT’s architecture. RFC 9692 gives the adjacency finite-state machine separate OneWay, TwoWay and ThreeWay states. TwoWay already means a valid LIE has been received, but it is explicitly not a valid ThreeWay LIE. Only ThreeWay causes the adjacency to be advertised and allows TIE, TIDE and TIRE exchanges to proceed. Acceptance is therefore an input verdict, not an end-to-end verdict.

What the YANG model actually exposes

RFC 9719 is a YANG 1.1 model built for the Network Management Datastore Architecture. It augments the IETF routing model instead of creating a parallel management universe. That matters because intended configuration and operational state are different datastores under RFC 8342: what an operator asked for and what the network is doing must not be collapsed into one reassuring record.

The model supplies the pieces needed to keep those layers apart:

  • interface state, including the last accepted LIE and its reject reason;
  • the adjacency FSM state and neighbor information;
  • sent and received ZTP offers, plus best-offer and removal decisions with reasons;
  • LIE, TIE, TIDE and TIRE counters and queues;
  • the local topology-information database;
  • SPF timing and the TIE that triggered a calculation;
  • neighbor and TIE error notifications;
  • explicit actions for clearing one neighbor or every neighbor on an interface.

These are not redundant views of the same condition. They are checkpoints in a causal sequence.

A disciplined evidence chain

Start at the receiving interface. If the last LIE was rejected, preserve the reject string, the notification and the peer identity before changing anything. The message may expose an invalid system identifier, level conflict, hold-time problem or another protocol-level incompatibility. The exact implementation vocabulary may vary, which is why the standard’s structured state should be retained alongside logs rather than replaced by them.

If the LIE was accepted, move to the FSM. Ask whether the adjacency reached ThreeWay and stayed there. A transition that stops at TwoWay is not a contradiction: it is precisely the case in which a valid discovery message exists without reciprocal proof.

Then inspect offer selection and hierarchy. RIFT’s ZTP behavior can receive several offers and distinguish the best offer from offers marked for removal. An accepted LIE does not prove that the selected level or direction matches the intended fabric design.

Only after that should the operator assess synchronization. Check the TIE database, TIDE and TIRE activity, queue depth, neighbor counts and SPF trigger. A stable adjacency with an incomplete or inconsistent information database still cannot support a conclusion about routing correctness.

Finally, leave the protocol model. RFC 9692 deliberately does not specify how an implementation programs its forwarding plane. RIB and FIB inspection, hardware counters and an actual delivery probe therefore remain separate evidence. The management model can show why RIFT believes something; it cannot by itself prove that a packet crossed the fabric.

Clearing is a command, not a recovery certificate

RFC 9719 defines clear-neighbor and clear-all-neighbors. The latter clears every neighbor connection on the selected interface. Its successful invocation means the action was accepted. The security section warns that unauthorized use can repeatedly rebuild connections and disrupt stability.

The operational implication is plain: do not close an incident because the clear call returned without error. Capture the pre-clear evidence, issue the narrowest justified action, then watch the entire chain re-form—LIE acceptance, ThreeWay, offers, topology information, SPF, route installation, hardware forwarding and delivery. A reset can remove stale state; it can also erase the clues that explained it.

The diagnostic boundary RFC 9719 creates

The standard is most useful when automation treats every leaf according to its real semantic reach. A controller may alert on repeated LIE rejection. It may gate a later check on ThreeWay. It may compare intended configuration with operational offers. It may correlate a triggering TIE with SPF duration. What it must not do is promote one local boolean into a green status for the whole fabric.

RFC 9719 does not make RIFT observable with one answer. It makes the boundaries between answers machine-readable. That is the stronger capability.