IS-IS Minimum Remaining Lifetime
Extracted elements (15)
Purging of LSPs by non-originators is provided as an optimization to remove stale entries from the LSPDB, not as a correctness requirement. ISO10589 specifies two legitimate non-originator purge cases: LSP aging out (implying originator unreachable), and DIS change on a LAN (stale pseudonode LSPs). Neither is required for protocol correctness.
The MaxAge floor mechanism may result in retaining an LSP longer than its original lifetime, but this has no negative side effects beyond additional LSPDB memory usage. When the originator becomes unreachable (the condition under which delayed purging occurs), ISO10589 already specifies that unreachable-node LSPs are not used for routing, so stale LSP retention does not impact forwarding correctness.
The Remaining Lifetime field is deliberately excluded from the LSP checksum calculation (ISO10589) and from cryptographic authentication hashes (RFC 5304, RFC 5310), because it must be decremented by all intermediate systems. This exclusion makes corruption of the Remaining Lifetime field undetectable.
When the Remaining Lifetime is corrupted to a value smaller than the originator intended, the LSP may age out prematurely, causing two harms: temporary loss of reachability for destinations in that LSP, and unnecessary flooding from the premature purge followed by the originator regenerating and reflooding a new version.
The MaxAge floor mechanism does not change handling of received purged LSPs (zero Remaining Lifetime). A purged LSP is still considered newer than a matching LSP with non-zero Remaining Lifetime per ISO10589 Section 7.3.15.1.b, ensuring LSPDB consistency across routers in the network is preserved.
When the originating IS has a smaller MaxAge than the receiving IS, setting the received Remaining Lifetime to the local MaxAge prevents premature purge. When the receiver's MaxAge is smaller than the originator's, premature purging may still occur; implementors may make the floor value configurable to address this.
An additional action vi is added to ISO10589 Section 7.3.15.1.e(1): when a received LSP is newer than the local LSPDB copy and has a non-zero Remaining Lifetime, if the Remaining Lifetime of the new LSP is less than MaxAge, it MUST be set to MaxAge before storage. This ensures no non-originator IS will purge an LSP until it has existed in the database for at least MaxAge.
As a diagnostic aid, an implementation MAY retain the value of the Remaining Lifetime received when the LSP was added to the LSPDB, to assist in identifying corruption events after the fact.
If the Remaining Lifetime floor value used under the conditions in Section 2 is made configurable, the configured value MUST be greater than or equal to the locally configured value of MaxAge.
To minimize false positives when detecting corrupt Remaining Lifetime fields, the following algorithm SHOULD be used: the LSP passed all Section 7.3.15.1 acceptance tests; the LSP is newer than the local LSPDB copy; the received Remaining Lifetime is less than ZeroAgeLifetime; and the adjacency to the neighbor has been up for at least ZeroAgeLifetime.
When the conditions of the corruption detection algorithm (Section 3.2) are met, an IS SHOULD generate a CorruptRemainingLifetime event to aid in identifying network problems. The algorithm cannot guarantee detection of all corrupt cases nor that all reported events are valid.
ISO10589 Section 7.3.16 defines LSP comparison rules: higher sequence numbers are newer; a zero Remaining Lifetime (purged LSP) is newer than the same LSP with non-zero Remaining Lifetime at equal sequence numbers; two LSPs with non-zero Remaining Lifetimes and equal sequence numbers are considered the same regardless of differing Remaining Lifetime values.
MaxAge is the architectural constant defining the maximum value for the Remaining Lifetime in an LSP, defined by ISO10589 as 20 minutes (1200 seconds). Implementations may support configurable MaxAge values to allow longer lifetimes, reducing periodic LSP regeneration in stable topologies.
ZeroAgeLifetime is used in the corruption detection algorithm (Section 3.2) as both the threshold below which a received Remaining Lifetime is considered possibly corrupt and the minimum adjacency uptime required before reporting a CorruptRemainingLifetime event.
A man-in-the-middle attacker can modify an LSP in transit by setting the Remaining Lifetime to a small value, causing premature purges even when cryptographic authentication (RFC 5304 or RFC 5310) is in use, because the Remaining Lifetime is excluded from the authentication hash. The MaxAge floor mechanism defined in this document prevents such an attack from being effective by overriding any small received Remaining Lifetime value.