Les Ginsberg and the State Discipline Behind IS-IS Restart, Flooding, and Registry Control

Summary

Les Ginsberg's attributed work on RFCs 6823, 7370, 7987, 8706, 8918, and 9681 connects six operational controls: keep restarted adjacencies conditional on current topology, prevent application advertisements from becoming stale, maintain accurate codepoint records, bound damage from corrupted lifetime state, distinguish invalid fields from specially constrained purge content, and accelerate flooding only within the receiver's declared capacity.
These RFCs are collaborative IETF outputs, not evidence that one author controls IS-IS, IETF consensus, implementations, deployments, convergence, or security outcomes. Their practical value lies in making state transitions, registries, failure handling, and sender-receiver responsibilities visible enough for implementations and operators to verify.

A person-attributed technical record with a firm boundary

The IETF Datatracker profile for Les Ginsberg connects the same person record to a substantial body of published routing work. The six RFCs examined here span more than a decade and address different parts of IS-IS operation: how a restarting router communicates with its neighbors, how applications place information into the link-state system, how the protocol's type registries describe valid use, how implementations respond to corrupted lifetime fields, how they handle fields that are invalid in a particular message, and how they can flood link-state information faster without outrunning receivers.

That record supports a focused analysis, but it does not support a conventional biography. The official sources establish authorship and technical participation. They do not establish private motives, personal history, commercial outcomes, or responsibility for incidents. They also do not make Ginsberg the sole author of IS-IS behavior. RFC 7370 lists him as its author, while the other RFCs discussed here have multiple authors. Every document also sits within an IETF process involving working groups, reviewers, implementers, vendors, and operators.

The resulting protocol behavior is produced by running code and current network state, not by a byline.

This distinction is central to the subject. Link-state routing depends on shared records, but a shared record is not sovereign over reality. An LSP can describe reachability, carry application information, or advertise flooding parameters. An IANA registry can document which type values have been assigned and where they may appear. A restart signal can request that an adjacency be preserved. None of those records can make a failed link available, force an implementation to parse malformed input safely, or prove that a receiver has enough capacity for a faster stream.

The RFC sequence instead shows how records become operationally useful when their limits are explicit. Restart signaling has an exit path when topology changes. Generic application information has ownership and withdrawal rules intended to prevent stale copies. Registry entries distinguish the messages in which a type is allowed. A minimum lifetime rule bounds a corruption case that can amplify flooding. Invalid fields are handled differently in ordinary messages and purges because the security consequences differ. Fast flooding is tied to receiver feedback and conservative rate selection rather than to an abstract demand for speed.

This is not a narrative of a single designer steadily improving a protocol. It is a source-dated record of collaborative decisions about state discipline. Ginsberg's attribution provides the person-level connection required to examine that record. The evidence ceiling remains equally important: the RFCs define protocol behavior and design constraints, but they do not prove universal deployment or measured outcomes in any particular network.

RFC 8706: restart continuity without pretending the topology stood still

RFC 8706, published in February 2020, specifies restart signaling for IS-IS and obsoletes RFC 5306. It addresses several related situations. A router may be restarting while retaining forwarding-plane state. A router may be starting without preserved state. Neighbors need to reestablish adjacencies and synchronize their LSP databases. The specification also aims to reduce transient disruption during startup without allowing old adjacency state to survive unrelated topology changes.

The key operational distinction is between continuity and concealment. A restarting router can ask neighbors to maintain an adjacency while its control-plane state is rebuilt, but that request does not turn the previous topology into permanent truth. Neighbors can still bring the adjacency down when other topology evidence requires it. The mechanism therefore preserves a relationship conditionally, while normal database synchronization proceeds.

The Restart Signaling TLV carries flags for the relevant state. A restart request tells a neighbor that the sender is restarting. A restart acknowledgment supplies information the restarting system needs, including the remaining holding time and, where applicable, the neighbor's system identifier. A suppression-advertisement flag supports startup behavior in which a router asks that an adjacency not yet be advertised until the starting router is ready. These are protocol records with distinct meanings, not a single "keep everything up" switch.

The SA bit illustrates why a startup mechanism must be explicit about what is hidden and for how long. A starting router can request that a neighbor suppress advertising their adjacency. Until an IIH arrives with that bit clear, the neighbor does not advertise the adjacency in its LSP. This avoids making a partially synchronized router look fully usable merely because the local hello exchange has begun. Once startup has advanced sufficiently, the request can be cleared and ordinary advertisement can resume.

Database synchronization is the other half of the design. Preserving an adjacency is useful only if the restarting router can determine when its view of the LSP database is current. RFC 8706 defines behavior for synchronization and an optimization based on the information exchanged with neighbors. A router that cannot complete synchronization has to expose that failure rather than silently claim recovery. The protocol uses defined state and timers to decide whether the process has completed.

The design also assigns responsibilities on both sides. A restarting system must signal its state and use the received acknowledgments to rebuild a consistent view. A neighbor must interpret the request in the context of current topology, not in isolation. If a different change makes the preserved adjacency unsafe, the neighbor retains the ability to bring it down. That condition keeps restart continuity subordinate to the wider link-state system.

This matters because link-state protocols derive paths from a distributed database. If one adjacency is retained while the rest of the topology changes, an old forwarding view can become inconsistent with what other routers calculate. A continuity mechanism that ignored those changes could extend a transient control-plane outage into a forwarding anomaly. RFC 8706 instead treats continuity as a bounded exception whose validity depends on surrounding evidence.

The source does not show that every router implements every part of the mechanism, that every restart preserves traffic, or that a given operator enables the relevant behavior. Nor does it quantify convergence or outage reduction. What it establishes is a protocol contract: restart state is signaled, synchronization remains necessary, adjacency preservation is conditional, and unrelated topology changes can override the request.

For operators, the practical question is therefore not only whether restart signaling is supported. They also need to know which flags are being exchanged, whether database synchronization completes, whether timers expire, whether a topology change terminates the preserved state, and whether the implementation exposes enough telemetry to distinguish a successful restart from an adjacency that merely remained visible.

RFC 6823: application information needs ownership, scope, and withdrawal

RFC 6823, published in December 2012, defines a method for advertising generic application information in IS-IS. The attraction is easy to understand. A link-state protocol already distributes information across a routing domain, so applications may want to use that distribution system rather than invent a separate transport. The danger is equally clear: copied application data can become stale, conflicting, or excessively chatty if its ownership and flooding behavior are vague.

The document responds by defining a Generic Information TLV and guidelines for the applications that use it. Application identifiers are assigned through an IANA registry. The encoded information identifies the application and carries application-specific content. Yet the generic container does not give applications unlimited freedom. Each application specification remains responsible for defining how its information is originated, updated, scoped, and interpreted.

Stale-state avoidance is a first-class requirement. The RFC discusses the case in which information associated with one router may be advertised by another system for redundancy. That pattern can improve availability, but it creates a withdrawal problem. If the original source disappears or changes state, replicas must not keep advertising an obsolete value indefinitely. An application needs enough coordination to determine which copy is current and when a stale copy must be removed.

This is a general lesson about distributed records. Replication increases the number of places from which information can be obtained, but it also increases the number of places that must converge when the information changes. A record without a clear origin, version, or withdrawal condition can survive beyond the reality it was meant to describe. In a link-state system, that stale record is then distributed efficiently, turning a local ambiguity into a domain-wide one.

RFC 6823 also warns application designers about update behavior. Frequent changes can cause repeated LSP generation and flooding. If an application treats the routing protocol as an unconstrained message bus, its own update rate can compete with the protocol information needed for path calculation. The document therefore requires application specifications to consider how often information changes and to avoid designs that can create flooding storms.

Scope matters as well. Information may be useful only within a particular area or may need broader distribution. An application has to define that scope instead of assuming that every participant should receive every record. The decision affects both meaning and cost. A value valid inside one administrative or topological context may be misleading outside it, while unnecessarily broad flooding consumes processing and bandwidth throughout the domain.

The new application registry contributes uniqueness and interpretability. A stable identifier allows receivers to know which application owns the bytes that follow and which specification defines their semantics. But the registry does not validate an application's live data, authorize deployment, or guarantee that implementations honor the specification. It records assignments so that independently developed systems do not attach different meanings to the same code.

This division between registry and running state is important. IANA can maintain a unique application identifier. The application specification can define format and behavior. An implementation can originate and parse the information. An operator can choose whether to enable it. Only the running systems can show whether the advertisements are current, correctly scoped, and stable under change.

Ginsberg is one of the RFC's co-authors, alongside Stefano Previdi and Mike Shand. That attribution supports connecting him to the design problem. It does not support crediting him alone for the container, its consensus, or its deployment. The operational result established by the RFC is narrower: generic information can be carried in IS-IS under explicit application ownership and flooding guidelines, and stale-state prevention is part of the contract rather than an optional cleanup.

RFC 7370: a protocol registry should describe the protocol accurately

RFC 7370, published in September 2014, turns from live LSP content to the record that describes IS-IS type assignments. It recommends editorial changes to the IANA IS-IS TLV Codepoints registry and gives guidance to the designated experts who review allocation requests. The stated objective is to document the state of the protocol more accurately.

At first glance, this may look less operational than restart or flooding behavior. In practice, a type registry is part of interoperability. A TLV codepoint identifies a particular structure, and the registry indicates the protocol data units in which that structure is allowed. Implementers, reviewers, and future specifications depend on that information when deciding whether an incoming field is recognized, permitted in context, or reserved for another use.

An inaccurate registry creates two kinds of risk. It can describe a legitimate use as unavailable, encouraging unnecessary reinvention or conflicting allocation. Or it can imply that a field is allowed in a context where the defining specification does not permit it. The latter is especially significant for purges and other messages with constrained semantics. A parser or validator that relies on a misleading table can make a different decision from one that follows the underlying RFC.

RFC 7370 therefore improves both presentation and review procedure. It separates and labels parts of the registry so that the relationship between a type and its valid message contexts is clearer. It also explains how designated experts should assess requests, including early allocations associated with work that has not yet completed the standards process.

Expert review here is not sovereignty over implementation. The reviewer checks whether an allocation is technically justified, sufficiently documented, and compatible with the registry's purpose. IANA records an approved assignment. Neither action proves that the resulting extension is correct in all implementations, safe in every deployment, or useful to every operator. The registry's authority is narrower and more concrete: keep assignments unique, traceable, and accurately described.

The document's handling of early allocation reinforces that boundary. Work may need codepoints before an RFC is published so that implementations and interoperability testing can proceed. A designated expert can approve such an allocation under defined conditions. The registry then records a provisional fact that supports running-code evaluation. If the work changes, expires, or does not progress, the allocation process has rules for correction or release. The record serves experimentation without converting an unfinished proposal into permanent legitimacy.

This is a strong example of a registry as a ledger. It records who has been assigned which scoped value and under what specification. It reduces collision and preserves a history that implementations can consult. It does not command routers to accept the corresponding TLV or authorize arbitrary use of it. The actual parsing and operational effect remain governed by the protocol documents and implemented behavior.

RFC 7370 also connects directly to later invalid-TLV work. If a registry accurately shows where a TLV is allowed, implementations can distinguish an unknown but potentially extensible field from a known field appearing in the wrong kind of message. That distinction affects interoperability and security. The administrative quality of the registry therefore influences the clarity of the runtime boundary.

The evidence supports describing Ginsberg as the author of this registry update and the associated expert guidance. It does not support inferring control over IANA, later expert decisions, or vendor behavior. The enduring operational point is that metadata about a protocol is part of the protocol's reliability when independently built systems use it to attach the same meaning to the same number.

RFC 7987: corrupted lifetime state must not become a flooding amplifier

RFC 7987, published in October 2016, addresses a narrow field with potentially broad consequences: the Remaining Lifetime in an IS-IS Link State PDU. The originator sets that value, and it decreases as the LSP remains in the network. When the value reaches zero, the LSP is purged. This gives link-state information a bounded life and helps remove records that are no longer refreshed.

The difficulty is that the Remaining Lifetime field is changed in transit and is excluded from the checksum calculation. It is also excluded from the cryptographic hash in the authentication mechanisms cited by the RFC. Those exclusions allow ordinary aging, but they also mean corruption of the field can go undetected by the protections that cover the rest of the PDU.

Corruption in one direction can make an LSP appear to live longer than intended. Corruption in the other direction can make it expire too soon. The latter can trigger a damaging cycle: an implementation purges what appears to be an expired LSP, the originator regenerates it, and a corrupted low value causes another purge. Repeated regeneration and flooding can consume resources and disrupt reachability. The document also recognizes this as a possible denial-of-service vector.

RFC 7987 defines a backward-compatible minimum value for normal LSP origination and refresh behavior. The mechanism creates enough remaining lifetime to prevent a small or corrupted value from producing an immediate, repeating purge-and-regenerate loop. It does not eliminate aging or prevent a legitimate purge. It bounds a specific transition so that corruption is less able to amplify itself through the protocol's own recovery behavior.

The document carefully preserves exceptions. Purges legitimately use a zero lifetime. A system taking over designated-router duties may need to purge pseudonode LSPs associated with the former designated system. Other protocol-defined cases still require removal. The minimum is therefore not a blanket rule that every LSP must persist. It applies to ordinary generation and refresh where a nonzero record is intended to remain in the database.

This distinction is operationally important. A simplistic defense could avoid premature removal by refusing to accept a low lifetime, but that might also retain information that genuinely needs to be withdrawn. The RFC instead separates ordinary advertisements from authorized purge behavior and defines the minimum in the context where the corruption loop arises.

The backward-compatible character of the solution also matters. A change intended to reduce flooding storms should not require an instantaneous, domain-wide upgrade before it can help. New implementations can originate or refresh values according to the safer floor while older systems continue to process standard IS-IS lifetime semantics. Compatibility allows the protection to enter mixed environments incrementally.

The document was authored collaboratively by Ginsberg, Paul Wells, Bruno Decraene, Tony Przygienda, and Hannes Gredler. Its analysis establishes a protocol vulnerability and a bounded response. It does not establish that the vector has been exploited in a particular network, that the change eliminates all flooding storms, or that every implementation adopted it. Flooding instability can have many causes, including topology churn, application behavior, queueing, receiver overload, and other malformed state.

For operators and implementers, the broader lesson is to inspect mutable metadata that sits outside ordinary integrity checks. A field may look minor because it does not describe a prefix or adjacency, yet it can control when a distributed record disappears. If corruption of that field activates a regeneration mechanism, the interaction can become an amplifier. The correct response is not to declare all mutable fields untrustworthy, but to define bounds that make their failure behavior observable and recoverable.

RFC 8918: invalid data is contextual, and purges need special care

RFC 8918, published in September 2020, addresses what an IS-IS implementation should do when it receives a TLV that is disallowed in a particular Protocol Data Unit. Extensibility depends on implementations tolerating information they do not yet understand. Interoperability also depends on rejecting or constraining fields that appear where their semantics are not valid. The challenge is to distinguish those cases precisely.

The IANA IS-IS TLV Codepoints Registry records whether a TLV is allowed in particular message types. A receiver can therefore encounter several different situations. A TLV may be recognized and allowed. It may be unrecognized but appear in a context where extension is permitted. Or it may be known or unknown and appear in a PDU where the registry says it is disallowed.

For most received PDUs other than LSP purges, RFC 8918 makes the behavior explicit: disallowed TLVs are ignored and the PDU is otherwise processed normally. This avoids turning one misplaced optional element into loss of the entire routing message. It also prevents implementations from inventing divergent responses to the same malformed input.

Purges require separate acceptance rules because they remove link-state information. ISO 10589 recommends removing the body before generating a purge but allows received purges with TLVs, whose contents are ignored. RFC 5304 tightened that behavior for cryptographic authentication by requiring receivers not to accept purges containing TLVs other than the authentication TLV. RFC 6232 added the Purge Originator Identification TLV, and RFC 6233 added a Purge column to the TLV Codepoints Registry so implementations can identify the TLVs allowed in that context.

RFC 8918 does not collapse those rules into a single normalization procedure. Instead, it documents the compatibility boundary among the base behavior, authenticated-purge rules, originator identification, and the registry. Authentication-only acceptance is not backward compatible with the base behavior, and originator identification changes that accepted set again. The document therefore recommends implementation controls when enabling behavior that all nodes may not support, so operators can introduce it without silently creating inconsistent purge acceptance.

This distinction depends on an accurate registry. The implementation needs to know which TLVs are permitted in purges and which are not. RFC 7370's work on registry clarity and RFC 8918's runtime handling are thus complementary. The registry records the scoped assignment; the implementation applies that record to a live message; the security analysis explains why the purge context cannot be treated like every other PDU.

The document also updates earlier RFCs and reconciles behavior that implementations might otherwise interpret differently. That clarification improves interoperability because independent systems have a common answer for the same invalid input. It does not guarantee that every parser is free from bugs or that authentication is configured correctly. It supplies the expected boundary against which implementation behavior can be tested.

Ginsberg is one of several authors, with Paul Wells, Tony Li, Tony Przygienda, and Shraddha Hegde. The authorship record connects him to the decision problem, but the RFC remains a collaborative standards result. Nothing in it supports claims about particular attacks, affected customers, vendor defects, or deployment outcomes.

For operators, invalid-TLV counters and logs can be valuable evidence. A system that repeatedly receives fields in disallowed contexts may be seeing an implementation defect, stale extension behavior, accidental corruption, or hostile input. The protocol response should keep the domain interoperable, but it should not make the anomaly invisible. Processing and observability serve different purposes: one preserves bounded operation, while the other allows the cause to be investigated.

RFC 9681: faster flooding begins with receiver capacity

RFC 9681, published in November 2024, examines IS-IS fast flooding. Link-state propagation contributes directly to convergence time, and modern networks may be able to support rates far above older defaults. Larger topologies and tighter convergence objectives create pressure to deliver changed LSPs more quickly. Yet increasing a sender's rate without understanding the receiver can replace slow convergence with queue loss, retransmission, control-plane overload, or unstable feedback.

The RFC frames faster flooding as a system problem rather than a timer tweak. It discusses sender pacing, receiver performance, flow or congestion behavior, LAN effects, acknowledgment generation, and protocol extensions that communicate desired parameters. This breadth is important because an LSP crosses several resource boundaries: creation, queueing, transmission, reception, validation, database installation, acknowledgment, and onward flooding.

One protocol extension allows a receiver to advertise flooding parameters. The LSP Transmission Interval expresses a sustainable reception rate that a sender can safely use even when it does not implement a more elaborate flow-control algorithm. Other parameters describe burst behavior and ordered flooding preferences. These values turn receiver capacity into explicit protocol state rather than leaving the sender to assume that every neighbor can accept the same rate.

On a LAN, the problem is more complex because multiple transmitters can send to one receiver. The receiver may advertise more conservative values to account for their combined load. A transmitter that receives different advertisements from different receivers should use the most conservative value on a per-parameter basis. This is a practical allocation of authority: the receiver describes what it can sustain, and the sender must not reinterpret that declaration into a more aggressive rate.

The conservative rule prevents a fast neighbor from setting the pace for a slower one. Flooding is only as safe as the path through the constrained receiver. A sender can still use optimization and feedback, but an advertised interval provides a minimum safe basis when acknowledgments stop or an algorithm enters an unexpected state.

Receiver behavior also affects progress. Partial Sequence Number PDUs acknowledge groups of LSPs. The RFC discusses generating acknowledgments based on both time and the number of received LSPs, allowing feedback to arrive promptly without creating excessive acknowledgment overhead. This matters because a sender needs evidence that the receiver is making progress. A high transmission rate without useful feedback can fill queues faster than the system can detect the problem.

Ordered flooding is another tool rather than a universal requirement. Preserving a useful ordering can improve behavior in some convergence scenarios, but it introduces implementation and queue-management considerations. The specification does not reduce fast flooding to a single mandatory algorithm. It defines information and behavior that implementations can use while preserving the receiver's ability to set bounds.

The document's treatment of scale is therefore conditional. Faster rates can reduce the propagation component of convergence when processing, links, queues, and receivers can sustain them. They do not remove shortest-path calculation time, hardware programming time, topology complexity, or application-specific recovery behavior. Nor do they prove that a particular default rate is appropriate for every platform.

RFC 9681 was authored by Bruno Decraene, Ginsberg, Tony Li, Guillaume Solignac, Marek Karasek, Gunter Van de Velde, and Tony Przygienda. Its recent publication provides a current endpoint for the record, but it remains a standards document rather than a deployment survey. The evidence supports describing protocol extensions and design constraints. It does not support claiming measured subsecond convergence in a named network, universal implementation, or a customer outcome.

The practical operational question is not "How fast can this sender transmit?" It is "What rate can the full path of receivers, queues, processors, and acknowledgment mechanisms sustain while preserving correct state?" That question keeps fast flooding subordinate to observable capacity. Speed becomes a controlled parameter, not a legitimacy claim.

One sequence, six kinds of state discipline

Read together, the six RFCs show that IS-IS continuity depends on several different records that should not be collapsed into one.

RFC 8706 deals with adjacency and synchronization state during restart or startup. The restart signal describes an exceptional condition, while current topology and database synchronization determine whether the exception remains safe. RFC 6823 deals with application-owned information carried by the link-state system. Its identifiers, scope, update rate, and withdrawal rules determine whether replicated content remains current.

RFC 7370 deals with the administrative record of type assignments. Accurate registry metadata helps specifications and implementations agree about where a field may appear. RFC 7987 deals with a mutable lifetime value whose corruption can trigger repeated protocol action. A minimum bounds the amplification without eliminating legitimate expiry and purge behavior.

RFC 8918 deals with contextual validity. An unknown extension and a disallowed field are not the same thing, while a purge cannot be handled exactly like an ordinary message because discarding it may preserve stale state. RFC 9681 deals with capacity state. A receiver's sustainable rate constrains the sender even when faster flooding would otherwise improve convergence.

The records also have different owners. IANA maintains assignments. An RFC defines semantics. An implementation parses, stores, and transmits data. A router originates current LSPs. A receiver advertises capacity. An operator decides policy and observes results. No one record or actor can substitute for all the others.

This division is useful because it creates checkable failure points. A restart can fail synchronization. An application can leave stale information. A registry can misstate a permitted context. A lifetime field can be corrupted. A parser can mishandle a disallowed TLV. A sender can exceed receiver capacity. Each failure has a more precise remedy than a generic demand for resilience.

It also prevents advocacy from replacing evidence. Calling a mechanism graceful does not prove that traffic was preserved. Calling information generic does not mean it is safe to flood without limits. Calling a codepoint assigned does not validate its live use. Calling a change backward compatible does not prove every mixed deployment behaves correctly. Calling flooding fast does not prove convergence improved. The specifications are valuable because they define what can be checked, not because their labels settle the result.

Operator implications: verify the transition, not only the feature

The first operator implication is to monitor transitions. Restart support is less important than the observed sequence from restart request through synchronization, adjacency handling, timer completion, and return to ordinary operation. A dashboard that shows only "restart capable" can miss a failed database sync or a preserved adjacency invalidated by topology change.

The second implication is to treat stale-state controls as part of application design. Any use of generic link-state information should identify the originator, replication behavior, scope, refresh cadence, and withdrawal path. Operators need to know how an advertisement disappears after the producing application or router fails. Without that answer, redundancy can become persistence of a false record.

The third implication is to make registry changes traceable. Implementations and internal tooling should consume current assignments and preserve links to defining specifications. A codepoint copied into a private table without provenance can outlive the context that gave it meaning. When a TLV is accepted or rejected, the decision should be explainable in terms of the current registry and RFC rules.

The fourth implication is to watch fields excluded from ordinary integrity checks. Remaining Lifetime is changed as an LSP traverses the network, so it cannot be protected exactly like immutable content. That does not make its failure harmless. Implementations should expose abnormal purges, regeneration rates, lifetime discontinuities, and related flooding behavior so that a bounded protocol response is matched by operational visibility.

The fifth implication is to distinguish tolerant parsing from silent acceptance. In a non-purge PDU, a disallowed TLV must be ignored and must not cause the PDU itself to be rejected. Purge acceptance follows the enabled authentication and originator rules together with the Purge column in the registry. In both contexts, counters and logs still matter because an interoperable protocol response should not erase evidence that the input violated expectations.

The sixth implication is that convergence tuning starts at the receiver. Faster sender timers should be evaluated against receiver queues, processing, acknowledgment behavior, LAN fan-in, and conservative advertised parameters. Tests should include loss of acknowledgments and mixed receiver capabilities rather than only the best-case path. A high rate is useful only when the distributed system remains observable and stable.

Several questions remain outside the cited RFC record. They do not establish current vendor support, defaults, deployment prevalence, or measured outcomes. They do not show how a particular operator configures restart signaling or fast flooding. They do not quantify how often lifetime corruption or invalid TLVs appear. Those questions require current implementation documentation, lab testing, telemetry, and network-specific evidence.

The source-supported conclusion is narrower and stronger. Ginsberg's attributed IETF work participates in a recurring effort to make IS-IS state explicit, scoped, bounded, and recoverable. The contribution is not a promise that the network will remain available. It is a set of protocol boundaries through which implementations and operators can determine when continuity remains justified and when current evidence requires a different action.