| Internet-Draft | IS-IS OGID TLV | November 2026 |
| Hegde, et al. | Expires 6 May 2027 | [Page] |
This document introduces a new top-level TLV in IS-IS, the Originating Generation Identifier (OGID) TLV, which is carried in every Link State PDU (LSP) fragment originated by a node. The OGID identifies the logical transaction to which a set of LSP fragment updates belongs. When accompanied by a Fragment Count greater than one, it additionally allows a receiving node to determine when all fragments participating in that transaction have been received. This enables receivers to process multi-fragment updates atomically, avoiding the transient Link State Database (LSDB) inconsistencies that can otherwise occur when logically related LSP fragment updates are flooded and processed independently.¶
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 6 May 2027.¶
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.¶
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.¶
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.¶
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.¶
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 |S| Flags | OGID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OGID (contd) | LRGID |Fragment Count |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBD
Length: 6
Flags: 1 octet of flags. The most significant bit is the Soft
Overload (S) flag, described in Section 4.2.1. The
remaining bits are reserved, MUST be set to zero on
transmission, and MUST be ignored on receipt.
OGID: 16-bit Originating Generation Identifier.
LRGID: 16-bit Latest Resolvable Generation Identifier.
Fragment Count: Number of unique fragments participating in the
transaction. A value of one indicates no coordinated
processing is required.
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.¶
There are situations where an originating node may regenerate and repack a significant portion of its LSP fragment set. Examples include:¶
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.¶
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:¶
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.¶
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:¶
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:¶
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.¶
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:¶
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.¶
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 Section 4.2.1) so that receivers defer processing of the affected updates until the originator's LSP database has stabilised.¶
The following examples illustrate LRGID behaviour.¶
Transaction 100: Fragment Count = 2, involving fragments F1 and
F2. The receiver has received F1 (OGID = 100,
LRGID = 100) and is holding it, waiting for F2.
Before F2 of transaction 100 is processed, the originator makes an
independent single-fragment update to F2:
F2: OGID = 101
Fragment Count = 1
LRGID = 100
=> 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.
Transaction 100: OGID = 100, Fragment Count = 2,
involving fragments F1 and F2 (multi-fragment).
Transaction 101: OGID = 101, Fragment Count = 1,
involving fragment F2 only (single-fragment).
Transaction 102: OGID = 102, Fragment Count = 2,
involving fragments F2 and F3 (multi-fragment).
A single-fragment transaction does not advance the LRGID
back-reference, so F2 carries the following values in each of its
updates:
F2 (transaction 100): OGID = 100, FC = 2, LRGID = 100
F2 (transaction 101): OGID = 101, FC = 1, LRGID = 100
F2 (transaction 102): OGID = 102, FC = 2, LRGID = 100
The receiver has received F1 of transaction 100 and is holding it,
waiting for F2 to resolve transaction 100. It did not receive the
F2 updates of transactions 100 and 101.
=> 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.
Transaction 100: Fragment Count > 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 Section 6), and the held LSP fragments are processed normally, as they would be in the absence of the OGID mechanism.¶
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:¶
The originating node determines whether a transaction requires coordinated processing and advertises a Fragment Count greater than one accordingly.¶
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:¶
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 Section 6), 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.¶
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 Section 5, 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.¶
IS-IS permits both self-originated and non-self-originated LSP purges. The handling of the OGID TLV for purge LSPs is defined below.¶
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.¶
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.¶
[RFC8918] 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.¶
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.¶
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:¶
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.¶
IS-IS nodes that do not support the OGID TLV can safely ignore it upon reception, as required by [RFC8918]. Such nodes can continue to behave as before, albeit with the possibility of hitting the issues mentioned in the problem statement in Section 1.¶
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 [RFC5304] and [RFC5310]. 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 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.¶
| 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 [RFC6233] 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 Section 7. 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.¶
The following person contributed to this document:¶
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.¶