IS-IS Originating Generation Identifier (OGID) TLV

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.

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 when, and only when, they appear in all capitals, as shown here.

Solution Overview This document introduces an Originating Generation Identifier (OGID) TLV, carried in every LSP fragment of a node. The OGID TLV provides a lightweight mechanism to identify updates belonging to a particular logical transaction. When accompanied by a Fragment Count greater than one, it additionally allows receiving nodes to determine when all fragments participating in that transaction have been received. The proposal separates update identification from transaction synchronization. The OGID allows a receiving node to identify successive logical updates originating from a node, regardless of whether they involve a single fragment or multiple fragments. The Fragment Count is used only when the originating node determines that multiple fragment updates must be observed together to avoid transient inconsistencies. As a result, simple updates continue to be processed immediately, while complex multi-fragment updates can be processed atomically, preserving existing IS-IS flooding behaviour.

Originating Generation Identifier (OGID) TLV

OGID TLV Format

Flags The Flags field is one octet. The most significant bit of the Flags field is defined as the Soft Overload (S) bit. All other bits are reserved; they MUST be set to zero on transmission and MUST be ignored on receipt.

Soft Overload There are situations where an originating node may regenerate and repack a significant portion of its LSP fragment set. Examples include:

Global configuration changes.
Protocol configuration changes affecting many advertisements.
Significant LSP repacking operations.
Other implementation-specific events resulting in widespread LSP regeneration.

In such situations, attempting to track individual transactions using Fragment Count may provide limited benefit because a large number of fragments may be updated over a short period of time. The Soft Overload (S) flag in the OGID TLV allows an originating node to signal such an event. The sending and receiving side procedures for the S bit are described in the following sub-sections.

Sending Side Behaviour The originating node MAY set the Soft Overload (S) flag in the OGID TLV to indicate such an event. When the S bit is set:

Fragment Count MUST be set to one.
The update is treated as a node-wide transient event rather than a coordinated multi-fragment transaction.

During a Soft Overload event, all regenerated fragments SHOULD advertise the same newly allocated OGID value. When the S bit is set, the LRGID field carries no special meaning and MAY be set equal to the advertised OGID. The S bit is intended as a transient hint to receiving nodes and does not represent persistent state. An originating node MUST NOT generate an additional LSP update solely for the purpose of clearing the S bit. Instead, the S bit MAY be cleared as part of the next normal transactional update that affects the corresponding LSP fragment. This avoids unnecessary flooding associated with explicit S-bit removal.

Receiving Side Behaviour The S bit is informational and applies only to updates received through normal flooding procedures. The S bit MAY be ignored when the associated LSP is received as a response to a CSNP or PSNP. This avoids unnecessary holdoff behaviour during database synchronization and recovery operations. Upon receiving the first LSP fragment from an originating node with the Soft Overload (S) bit set, a receiving node MAY start a Soft Overload hold-down timer. During this timer interval:

Newly received LSP fragments from that originating node are placed in a temporary hold list.
The LSP fragments continue to be flooded according to normal IS-IS procedures.
SPF computation and higher-level processing of those updates MAY be deferred.

Once a receiving node has started a Soft Overload hold-down timer for a given originating node, receipt of additional LSP fragments from the same node, whether carrying the same OGID and the S bit or a changed OGID:

MUST NOT start a new hold-down timer.
MUST NOT restart an existing hold-down timer.
MUST NOT extend the duration of an existing hold-down timer.

While the hold-down timer is running, an LSP fragment received from the same originating node with the S bit clear and a higher OGID value MUST also be placed in the temporary hold list and flooded according to normal IS-IS procedures. When the timer expires, the receiver MUST install all held LSP fragments from the temporary hold list into the Link State Database (LSDB), releasing them for normal processing, and trigger the necessary Traffic Engineering Database (TED) update and SPF computation. The duration of the hold-down timer is implementation dependent but is expected to be on the order of a few seconds.

Originating Generation Identifier (OGID) The OGID is a transaction identifier maintained by the originating node. Any modification to the link-state information advertised by a node constitutes a transaction. This includes:

Changes affecting a single fragment.
Changes affecting multiple fragments.
Addition or removal of TLVs.
Movement of TLVs between fragments.
Any other update resulting in a new version of the node's LSP database.

For every new transaction, the originating node increments the OGID and advertises the new value in the OGID TLV carried in all LSP fragments generated or regenerated as part of that transaction. The OGID is a 16-bit unsigned value. When the maximum value (65535) is reached, the next transaction causes the OGID to wrap to 1. A receiving node SHOULD treat OGID values using serial number arithmetic. An OGID value is considered newer if it falls within the forward half of the 16-bit sequence space relative to the currently tracked OGID. This ensures correct ordering across wrap events. The OGID therefore provides an indication that a new logical update has occurred at the originating node, independent of how many fragments were modified.

Latest Resolvable Generation Identifier (LRGID) The LRGID is a per-fragment value carried in the OGID TLV of each fragment. It carries the OGID of the latest previous transaction in which this fragment participated as part of a multi-fragment transaction, that is, a transaction advertised with a Fragment Count greater than one. The LRGID field always carries an OGID corresponding to the multi-fragment transaction. If this transaction is the first multi-fragment transaction the fragment participates in, the LRGID is set to OGID. Irrespective of whether the current transaction is a multi-fragment transaction or a single-fragment transaction, the LRGID field carries the OGID of the latest multi-fragment transaction. When the same fragment is updated multiple times in quick succession, the LRGID informs the receiver of the most recent multi-fragment transaction the fragment was involved in. This allows a receiver that is holding fragments for an unresolved transaction to recognise that the received fragment belongs to that transaction and to resolve it, even when the fragment's current update belongs to an independent transaction. Because only the latest multi-fragment transaction GID is carried, a receiver can resolve at most the transaction identified by the advertised LRGID. If a fragment participates in several multi-fragment transactions within a short interval and a receiver does not receive the fragment's update for each such transaction, the receiver may be unable to resolve the earlier transactions. In such situations, it is RECOMMENDED that the originating node set the Soft Overload (S) bit (see ) so that receivers defer processing of the affected updates until the originator's LSP database has stabilised. The following examples illustrate LRGID behaviour.

Example 1: Resolving a Transaction Using LRGID The LRGID = 100 informs the receiver that F2 was part of the multi-fragment transaction 100. The receiver counts F2 towards transaction 100, resolves it, and releases the held fragments for normal processing. ]]>

Example 2: Repeated Multi-fragment Transactions, Earlier Transaction Resolvable When the receiver receives F2 from transaction 102 (OGID = 102, LRGID = 100), the LRGID = 100 informs it that F2 was part of the multi-fragment transaction 100. The receiver counts F2 towards transaction 100 and resolves it, while also beginning to track transaction 102 (awaiting F3). Transaction 100 remains resolvable because the intervening single-fragment transaction 101 did not advance F2's LRGID back-reference. ]]>

Example 3: Repeated Multi-fragment Transactions, Earlier Transaction Unresolvable 1, involving fragment F2. Transaction 102: Fragment Count > 1, again involving fragment F2. Transaction 104: Fragment Count > 1, again involving fragment F2. F2 participates in three multi-fragment transactions in quick succession. Each update of F2 carries only a single back-reference in its LRGID, pointing to the immediately preceding multi-fragment transaction that F2 participated in: F2 (transaction 100): OGID = 100, LRGID = 100 F2 (transaction 102): OGID = 102, LRGID = 100 F2 (transaction 104): OGID = 104, LRGID = 102 ]]> Suppose a receiver is waiting to resolve transaction 100 but, having missed the F2 updates of transactions 100 and 102, it receives only F2 from transaction 104 (LRGID = 102). This LRGID references transaction 102, not 100, so transaction 100 can no longer be resolved. Because the LRGID carries only the most recent preceding multi-fragment transaction, earlier transactions in such a rapid succession may become unresolvable. In this case the receiver's transaction-resolution timer for transaction 100 eventually expires (see ), and the held LSP fragments are processed normally, as they would be in the absence of the OGID mechanism.

Transaction Coordination (Fragment Count) While every transaction receives a new OGID, not every transaction requires coordinated processing at the receiving node. For transactions where coordinated processing is not required, the originating node advertises a Fragment Count of one. Such transactions may affect a single fragment or multiple fragments. A Fragment Count value of one indicates that the update can be processed immediately upon receipt using normal IS-IS procedures. For transactions that affect multiple fragments and where the originating node wishes receiving nodes to observe the update only after all participating fragments have been received, a Fragment Count greater than one is advertised. Examples include:

TLV movement from one fragment to another.
Addition or removal of information causing fragment redistribution.
Multi-fragment configuration changes.
Any update where processing an incomplete subset of fragments could result in transient inconsistencies.

The originating node determines whether a transaction requires coordinated processing and advertises a Fragment Count greater than one accordingly.

Receiving Node Behaviour Upon receiving an updated LSP fragment, the receiving node examines the advertised OGID, LRGID, Fragment Count, and Flags. If the Fragment Count is one and the Soft Overload bit is unset, the update is processed immediately using normal IS-IS behaviour. If the Fragment Count is greater than one, the receiving node interprets the update as a coordinated multi-fragment transaction and:

Floods the received LSP normally.
Places the updated fragment in a temporary hold list.
Tracks all fragments associated with the advertised OGID.
Maintains the set of unique fragment numbers received for that transaction.
Compares the number of unique fragments received against the advertised Fragment Count.

Once the number of unique fragments received equals the advertised Fragment Count, the transaction is considered resolved and all held fragments are released for normal processing and SPF computation. Holding an LSP fragment for transaction resolution defers only its higher-level processing (such as SPF computation and TED updates); it does not remove the fragment from the Link State Database (LSDB). A fragment that is being held as part of an incomplete transaction is stored in the LSDB and flooded using normal IS-IS procedures. Consequently, such held fragments MUST be included in LSDB checksum computation, reflected in Complete Sequence Number PDUs (CSNPs) and Partial Sequence Number PDUs (PSNPs) used for database synchronization, and shown in database query or diagnostic output, exactly as they would be in the absence of the OGID mechanism. The OGID mechanism therefore affects only when a transaction's effect is applied to route computation, and never the receiver's participation in flooding and database synchronization. A receiving node MAY simultaneously track multiple unresolved transactions. When a fragment is received, the receiver uses the advertised LRGID to determine the latest multi-fragment transaction in which that fragment participated. If the receiver is holding fragments for an unresolved transaction whose OGID equals the advertised LRGID, the received fragment is counted towards that transaction, allowing the transaction to be resolved even when the fragment's current update belongs to an independent transaction. Any earlier unresolved transaction involving the same fragment whose update the receiver did not observe SHALL be considered unresolvable, and any associated tracking state MAY be discarded. As a safety mechanism to avoid accumulating too many unfinished transactions, an implementation MAY impose a limit on the number of unresolved multi-fragment transactions a receiving node simultaneously tracks for a given originating node. If this limit is exceeded, the receiving node MAY release the fragments it is currently holding for one or more incomplete transactions, install them into the Link State Database (LSDB), process them using normal IS-IS procedures, and cease tracking those transactions. As with expiry of the transaction-resolution timer (see ), this bounds the amount of state a receiver maintains and ensures that the OGID mechanism only ever delays, and never prevents, the installation of received LSP fragments.

Transaction Resolution Timer A receiving node MUST NOT wait indefinitely for a multi-fragment transaction to resolve. To bound this wait, the receiver maintains a transaction-resolution timer (also referred to as the wait timer) for each unresolved transaction it is tracking. The transaction-resolution timer for a transaction is started when the receiver begins tracking that transaction, that is, upon receipt of the first LSP fragment it holds for a transaction advertised with a Fragment Count greater than one. Subsequent fragments received for the same transaction do not restart or extend the timer, so that the total time the receiver waits for the transaction to resolve remains bounded. If all fragments participating in the transaction are received before the timer expires, the transaction is resolved as described in , the held fragments are released for normal processing and SPF computation, and the timer is cancelled. If the timer expires before all participating fragments have been received, the receiver MUST immediately release the LSP fragments it is currently holding for that transaction and process them as it would in the absence of the OGID mechanism, including any required TED update and SPF computation. The receiver then stops tracking the transaction. This ensures that the OGID mechanism only ever delays, and never prevents, the installation of received LSP fragments. The duration of the transaction-resolution timer is implementation dependent and SHOULD be configurable.

Interaction with LSP Purges IS-IS permits both self-originated and non-self-originated LSP purges. The handling of the OGID TLV for purge LSPs is defined below.

Purge of Another Node's LSP When a node purges an LSP originated by another node, the purge LSP MUST NOT contain an OGID TLV. The node whose LSP was purged is expected to subsequently regenerate and advertise a replacement LSP, if appropriate. Such regenerated LSPs SHALL be treated as a new transaction and advertised with an updated OGID value. This avoids introducing transactional state on behalf of another originator and ensures that OGID ownership remains solely with the originating node.

Self-Originated LSP Purges When a node purges its own LSP fragment(s), the purge LSP MAY include an OGID TLV. The originating node SHALL allocate a new OGID for the purge transaction. If the purge affects a single fragment and coordinated processing is not required, the node SHOULD advertise a Fragment Count of one. If the purge is part of a coordinated multi-fragment transaction, the node MAY advertise a Fragment Count greater than one using the procedures described in this document. Self-originated purges are therefore treated in the same manner as any other transactional update.

Configuration and RFC 8918 Compliance places restrictions on the addition of new information to self-originated purge LSPs. To maintain compliance and preserve operational flexibility, inclusion of the OGID TLV in self-originated purge LSPs SHOULD be controlled through an implementation-specific configuration option. When this configuration option is disabled, self-originated purge LSPs SHALL be transmitted without an OGID TLV. When enabled, the node MAY include the OGID TLV in self-originated purge LSPs as described above.

Receiving Node Behaviour for Purges Upon receiving a purge LSP, a receiving node SHALL first determine whether an OGID TLV is present. If an OGID TLV is present, the receiving node SHALL process the purge using the normal OGID procedures defined in this document. This includes Soft Overload processing (if applicable), Fragment Count validation (if the Fragment Count is greater than one), and OGID transaction tracking and resolution procedures. If an OGID TLV is not present, the receiving node SHALL process the purge according to the current transactional state associated with the originating node. If no unresolved OGID transaction exists for that node, the purge SHALL be processed immediately using normal IS-IS procedures. If an OGID transaction is currently pending resolution, the purge SHALL follow the existing state associated with that transaction. Any active transaction-resolution timer, hold list, or Soft Overload hold-down already in effect SHALL continue unchanged. Receipt of the purge SHALL NOT terminate, restart, or otherwise modify the existing transaction-resolution procedures. This behaviour prevents a purge arriving midway through a transactional update from causing premature processing of an unresolved database state.

OGID Behaviour During Restart A restarting node may not immediately have a stable view of its complete LSP fragment set. During restart procedures, individual fragments may be regenerated over time and the final fragment packing may not yet be determined. To avoid unnecessary transaction tracking during this period, a restarting node MAY advertise an OGID TLV with a Fragment Count of one until the restart or Graceful Restart (GR) procedure has completed. A restarting node MAY additionally set the Soft Overload (S) bit in the OGID TLV while rebuilding or regenerating its LSP database. This allows receiving nodes to temporarily defer processing of updates from the restarting node using the Soft Overload procedures defined in this document. During the restart period:

The node MAY continue to increment the OGID for subsequent transactions.
The Fragment Count SHOULD remain one while the node is rebuilding its LSP fragment set.
The S bit MAY be advertised in one or more regenerated LSP fragments.

Once restart processing has completed and the node has reached a stable LSP state, subsequent updates SHALL follow the normal OGID and Fragment Count procedures defined in this document.

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

Security Considerations The OGID TLV does not introduce any new security vulnerabilities beyond those already applicable to IS-IS. The OGID is a database consistency and transaction-identification mechanism and is not, in itself, a security mechanism. An on-path attacker that can inject or modify IS-IS PDUs could forge or alter the OGID, LRGID, Fragment Count, or Flags fields, for example to make a receiver defer processing of legitimate LSP fragments, to prematurely release held fragments, or to trigger unnecessary Soft Overload hold-down behaviour. To protect against man-in-the-middle and replay attacks, it is RECOMMENDED to enable IS-IS authentication as described in and . When IS-IS authentication is enabled, the OGID TLV is covered by the authentication of the LSP that carries it, which prevents an attacker from forging or tampering with its value.

IANA Considerations IANA is requested to assign a new top-level TLV type for the Originating Generation Identifier (OGID) TLV defined in this document from the "IS-IS TLV Codepoints" registry. OGID TLV Codepoint

Value	Name	IIH	LSP	SNP	Purge	Reference
TBD	Originating Generation Identifier (OGID)	n	y	n	y	[This document]

The IIH, LSP, SNP, and Purge columns of the registry are defined in and are populated as follows. The "Purge" column is set to "y" (yes) to indicate that the OGID TLV is permitted in self-originated purged LSPs, as described in . The "LSP" column is set to "y", and the "IIH" and "SNP" columns are set to "n" (no), as the OGID TLV is carried only in Link State PDUs.

Contributors The following person contributed to this document: HPE

zhaohui.zhang@hpe.com

Acknowledgements Claude Opus 4.8 was used to assist in the preparation and editing of this document. Thanks to Les Ginsberg for careful review and comments on the initial version of the draft.