IS-IS Originator Sequence Number Checksum TLV

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 7 January 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

As additional sub-TLVs are introduced, a parent TLV (for example, link information or prefix information) may need to grow to carry the new content. If the current fragment does not have sufficient space, the parent TLV may need to be moved to a different LSP fragment.¶

For example, assume TLV T1 is originally advertised in fragment F1 (having a sequence number f1s1) of the LSP, but after adding a few more pieces of information to the TLV, it now has to be placed in an existing fragment F2 (currently having a sequence number f2s1). The node performs this relocation and updates the sequence numbers of F1 and F2 to f1s2 and f2s2, respectively, before flooding the updated fragments. It is possible that a remote node (whose database currently has F1 (seq. no f1s1) and F2 (f2s1)), receives the new F1 LSP fragment with sequence number f1s2. Although the remote node eventually receives the new F2 fragment, there can be a transient interval during which it has the new F1 fragment and the old F2 fragment. During this interval, the remote node may incorrectly conclude that TLV T1 was removed by the originator. If T1 carries link information, this condition may be misinterpreted as a link failure. Such a situation could potentially cause traffic drops or traffic rerouting unnecessarily. This can also negatively affect a controller or head-end that relies on the IGP database for routing decisions. In such a situation a controller/head-end could end up re-routing a huge number of tunnels even though there was no real network change.¶

2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. Originator Sequence Number Checksum TLV

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Type        |     Length    |  Originator SNC               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Originator SNC (continued)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Originator SNC (continued)   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  where:

  Type:  TBD

  Length:  8

  Originator Sequence Number Checksum:  64-bit SipHash-1-3 digest computed on
  LSP ID, sequence number and size of each LSP fragment of the originator node
  in the increasing order of LSP-ID.

The Originator Sequence Number Checksum (OSNC) is an 8-octet value. This field MUST contain the 64-bit SipHash-1-3 [SIPHASH] digest computed over all LSP IDs originated by the node,their corresponding sequence numbers and the size. The computation MUST be done in increasing order of the LSP-ID. SipHash-1-3 MUST be used with the fixed 128-bit salt (the SipHash key) defined here, so that every node in the domain computes an identical digest over the same set of fragments. The salt is a well-known, non-secret constant derived from the ASCII string "ISIS-OSNC-SIPH13", expressed as the two 64-bit SipHash key words k0 = 0x495349532D4F534E and k1 = 0x432D534950483133. The salt provides no cryptographic protection, as the OSNC is used only for detecting database inconsistency and not for security (see Section 9). When a node sends an updated LSP fragment, it MUST calculate the checksum of LSP ID and sequence numbers of all the self-originated fragments and MUST include this OSNC TLV in the fragment that is getting updated. A node MUST update the SNC TLV and flood the fragment only when information in that fragment (excluding the OSNC TLV) changes, or when the fragment is refreshed.¶

The following example illustrates the OSNC computation for a node that originates both its own LSP fragments and pseudonode LSP fragments. Consider a node with System-ID 1921.6800.1001 that is elected the Designated Intermediate System (DIS) on a LAN and therefore also originates a pseudonode LSP with pseudonode-id 0x02. At a given instant the node has originated the LSP fragments shown below:¶

   LSP-ID                PN-ID  Frag   Seq Number   Size
   --------------------  -----  ----   ----------   ----
   1921.6800.1001.00-00  0x00   0x00   0x00000012    512
   1921.6800.1001.00-01  0x00   0x01   0x00000005    340
   1921.6800.1001.02-00  0x02   0x00   0x00000009    275
   1921.6800.1001.02-01  0x02   0x01   0x00000003     96

The LSP-ID is the 8-octet tuple {System-ID, Pseudonode-ID, LSP-Number}, and the Size column is the LSP PDU length in octets carried in the LSP header. The fragments with pseudonode-id 0x00 are the node's own LSPs, while the fragments with pseudonode-id 0x02 are the pseudonode LSPs the node originates in its role as DIS. The OSNC is computed by running the SipHash-1-3 algorithm over the concatenation of each LSP-ID, its sequence number, and its size, taken in increasing order of the LSP-ID. Because the ordering is on the full LSP-ID, the node's own fragments (pseudonode-id 0x00) are processed before the pseudonode fragments (pseudonode-id 0x02), and within the same pseudonode-id the fragments are processed in increasing LSP-Number order. The resulting order of computation is:¶

   1.  1921.6800.1001.00-00 , 0x00000012 , 512
   2.  1921.6800.1001.00-01 , 0x00000005 , 340
   3.  1921.6800.1001.02-00 , 0x00000009 , 275
   4.  1921.6800.1001.02-01 , 0x00000003 ,  96

The same OSNC value is carried in every self-originated LSP fragment, including the pseudonode fragments. Consider an update in which a TLV that no longer fits in fragment 1921.6800.1001.00-00 is relocated to fragment 1921.6800.1001.00-01. This changes two fragments at once: fragment 1921.6800.1001.00-00 shrinks and its sequence number is incremented, while fragment 1921.6800.1001.00-01 grows and its sequence number is incremented. The updated fragments are shown below:¶

   LSP-ID                PN-ID  Frag   Seq Number   Size
   --------------------  -----  ----   ----------   ----
   1921.6800.1001.00-00  0x00   0x00   0x00000013    448   (changed)
   1921.6800.1001.00-01  0x00   0x01   0x00000006    404   (changed)
   1921.6800.1001.02-00  0x02   0x00   0x00000009    275
   1921.6800.1001.02-01  0x02   0x01   0x00000003     96

The node recomputes the OSNC over all four fragments using the new sequence numbers and sizes of the two changed fragments, and MUST include the updated OSNC TLV in both fragment 1921.6800.1001.00-00 and fragment 1921.6800.1001.00-01 before flooding them. A neighbor that has received only one of the two updated fragments computes a different SNC over its local copy of the originator's fragments, and can therefore infer that the other changed fragment is still to arrive. This avoids the transient misinterpretation described in Section 1, in which the relocated TLV could otherwise appear to have been withdrawn.¶

4. Procedures on Receiving Node

When a receiving node receives an LSP fragment containing the OSNC TLV, it MUST compute the SNC for the originator using its local LSDB by walking all fragments from that originator. If the SNC does not match then there are more fragments to be received from the same originator. The actions a receiver takes for delayed fragments are implementation-dependent. For example, an implementation may delay updating the TE database until all fragments from the node are received. Some implementations may delay triggering SPF calculation.¶

If a receiving node cannot match the SNC in a received LSP fragment with its locally computed SNC, it MAY delay processing that fragment. However, this delay MUST NOT be indefinite. A configurable timer SHOULD be used, and upon timer expiry the receiver MUST process the changed LSP fragment.¶

5. Handling Continuous LSP Churn

The OSNC mechanism relies on a receiver being able to reconstruct, from its local LSDB, the same set of {LSP-ID, sequence number, size} tuples that the originator used to compute the OSNC carried in a received fragment. When the originator's LSP set is stable, the locally computed SNC converges to the received OSNC once all fragments belonging to a given update have been received. However, when an originator undergoes continuous LSP churn -- that is, its self-originated fragments are updated repeatedly and in quick succession, for example due to flapping links, unstable adjacencies, rapidly changing TE attributes, or frequent relocation of TLVs across fragments -- the OSNC becomes a moving target.¶

Under continuous churn, the following issues can arise on a receiver:¶

• The OSNC carried in each newly received fragment reflects a newer snapshot of the originator's LSDB than the one the receiver currently holds. Before the receiver has received and installed all fragments belonging to one snapshot, the originator has already produced another update carrying a different OSNC. As a result, the receiver's locally computed SNC may never match the received OSNC.¶
• If the receiver defers processing while the SNC does not match, it may hold off SPF computation or TE database updates for the affected originator for as long as the churn persists. This leads to stale routing information and delayed convergence -- the opposite of the transient-consistency benefit the mechanism is meant to provide.¶
• Recomputing the SNC over all fragments of an originator on every received update consumes CPU. Sustained churn can therefore impose a non-trivial processing load on every receiver in the area.¶

To bound this impact, a receiver MUST NOT defer processing of a changed LSP fragment indefinitely on the basis of an SNC mismatch. In addition to the configurable deferral timer described in Section 4, an implementation SHOULD apply the following safeguards:¶

• Bounded deferral: the deferral timer described in Section 4, started on the first SNC mismatch for an originator, MUST have a finite, configurable maximum. Upon expiry, the receiver MUST process the most recently received fragments as-is, exactly as it would in the absence of the OSNC mechanism.¶
• Churn detection and fallback: if a receiver observes that the SNC for a given originator repeatedly fails to match, or that the deferral timer for that originator expires more than a configurable number of times within a monitoring interval, it SHOULD temporarily stop deferring processing for that originator and revert to standard IS-IS behaviour, processing each fragment immediately as it is received. OSNC-based deferral can be resumed once the originator's SNC has matched and remained stable for a configurable period.¶

These safeguards ensure that the OSNC mechanism only ever delays the installation of LSP fragments and never prevents it. In the worst case -- an originator in sustained churn -- a receiver falls back to the same behaviour it would have had without this extension, so correctness is preserved while the optimization is temporarily suspended until the originator stabilizes.¶

6. Purged LSPs

Purging an LSP fragment changes the set of LSP fragments that a node originates and therefore changes the value of the OSNC. For this reason, purged LSPs MUST be allowed to carry the OSNC TLV, and the procedures defined in this document MUST be applied to a purge in the same way as to any other LSP update.¶

Historically, an IS-IS purge carries only the LSP header with an empty body, and only a restricted set of TLVs is permitted in a purge [RFC6233]. This document adds the OSNC TLV to the set of TLVs permitted in a purge. When a node purges one of its self-originated fragments, it MUST recompute the OSNC over its remaining self-originated fragments and MUST include the updated OSNC TLV in the purge it floods, as well as in any other self-originated fragment that is updated as a consequence of the purge.¶

A node that receives a purge containing the OSNC TLV MUST apply the procedures described in Section 4: it recomputes the SNC for the originator from its local LSDB and compares it with the OSNC carried in the purge. If the locally computed SNC does not match, the receiver MAY defer processing of the purge, subject to the bounded deferral timer and the continuous-churn safeguards described in Section 4 and Section 5. Applying the same mechanism to purges ensures that removing a fragment does not create a transient inconsistency in which a receiver momentarily misinterprets the purge, for example by concluding that information still present in another fragment has been withdrawn.¶

7. Router Restart

When a router restarts without retaining its Link State Database, its LSP fragments start again from the initial sequence number (effectively zero), while the other nodes in the IS-IS domain still hold the fragments that the router originated before the restart, each with a higher sequence number. Through the normal IS-IS sequence number synchronization procedure, the restarted node learns these higher sequence numbers from its neighbors and eventually re-originates each fragment with a sequence number one greater than the value it had before the restart.¶

This re-origination does not happen atomically across all fragments. Until every fragment has been re-originated with its updated sequence number and synchronized to the databases of all nodes in the IS-IS domain, different nodes may temporarily hold different sequence numbers for the restarting node's fragments. During this interval the OSNC advertised by the restarting node will not match the SNC computed by a receiver over its local copy of the fragments, and receivers will observe an inconsistent database for the restarting originator.¶

A receiver MUST treat this transient condition in the same way as any other OSNC mismatch. It MAY defer processing of the affected fragments, but MUST bound that deferral using the timer described in Section 4 and the continuous-churn safeguards described in Section 5, so that convergence is not delayed indefinitely while the restarting node re-synchronizes its sequence numbers.¶

8. Backward Compatibility

IS-IS nodes that do not support the SNC TLV can safely ignore it upon reception. Such nodes can continue to behave as before, albeit with the possibility of hitting the issues mentioned in the problem statement.¶

9. Security Considerations

The OSNC TLV does not introduce any new security vulnerabilities beyond those already applicable to IS-IS. The OSNC is a database consistency-detection mechanism and is not, in itself, a security mechanism; the fixed, well-known salt used with SipHash-1-3 (see Section 3) is not secret and provides no cryptographic protection. An on-path attacker that can inject or modify IS-IS PDUs could forge or alter the OSNC TLV, for example to make a receiver defer processing of legitimate LSP fragments or to replay stale fragments.¶

To protect against man-in-the-middle and replay attacks, it is RECOMMENDED to enable IS-IS authentication as described in [RFC5304] and [RFC5310]. When IS-IS authentication is enabled, the OSNC TLV is covered by the authentication of the LSP that carries it, which prevents an attacker from forging or tampering with its value.¶

10. IANA Considerations

IANA is requested to assign a new top-level TLV type for the Originator Sequence Number Checksum (OSNC) TLV defined in this document from the "IS-IS TLV Codepoints" registry.¶

The "Purge" column is set to "y" (yes) to indicate that the OSNC TLV is permitted in purged LSPs, as described in Section 6. The "LSP" column is set to "y", and the "IIH" and "SNP" columns are set to "n" (no), as the OSNC TLV is carried only in Link State PDUs.¶

11. Acknowledgements

The authors would like to thank Tony Li for his valuable review and comments on this document.¶

Claude Opus 4.8 was used to assist in the preparation and editing of this document.¶

Authors' Addresses