| Internet-Draft | draft-hu-rtgwg-isis-process-verification | June 2026 |
| Hu & Hu | Expires 27 December 2026 | [Page] |
In IS-IS deployments, the process identifier (process ID) is used on a local router to distinguish and manage different IS-IS protocol instances. Process ID is local to the router and is not transmitted to neighbors, providing operational flexibility. However, because the process ID is also used to implement route redistribution and specify administrative tags for fine-grained control, its misconfiguration can lead to severe impacts (e.g., routing loops or black holes) with difficult troubleshooting.¶
To address this problem, network operators typically deploy a consistent process ID on both ends of a link within the same domain, to reduce configuration complexity. In this context, to avoid the misconfiguration of the IS-IS process ID, this document introduces two optional approaches for process ID verification. When process ID verification is enabled, an IS-IS adjacency can be established only when the process identifiers at both ends of the link match.¶
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 27 December 2026.¶
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.¶
In IS-IS deployments, the concept of a local process identifier (process ID) is introduced at the implementation level to distinguish and manage multiple IS-IS protocol instances running on a single router. According to [RFC1195], which specifies the use of OSI IS-IS for routing in TCP/IP and dual environments, a router may run one or more IS-IS processes, each associated with a separate set of routing databases and protocol operations. The process ID is a locally significant administrative identifier; it is not transmitted to neighboring routers and does not appear in any IS-IS Protocol Data Unit (PDU) defined by [RFC1195] or its subsequent extensions.¶
The IS-IS process ID serves several operational purposes beyond merely identifying a protocol instance. It is employed to implement route redistribution policies, where routes learned from one routing protocol instance are imported into the IS-IS process identified by a given process ID. The IS-IS process ID is also used in conjunction with administrative tags, as defined in [RFC5130], to specify fine-grained control over route selection and policy enforcement. Because the process ID is a local configuration artifact that influences multiple operational aspects, its misconfiguration can have severe consequences.¶
To address this problem, network operators commonly deploy a consistent process ID on both ends of a link within the same domain. Additionally, operators typically configure separate IS-IS processes for different network layers (e.g., access vs. aggregation), preventing route changes in one layer from propagating across the entire network and thus reducing the overall flooding volume. This operational practice is recommended in network design guidelines and deployment examples, where routers in the same IS-IS routing domain are configured with identical process identifiers to ensure consistent routing behavior and simplify troubleshooting.¶
In this context, this document introduces two optional, backward-compatible mechanisms for IS-IS process ID verification:¶
1. Mechanism 1 (Section 3): A new optional TLV in the IS-IS Hello PDU, called the Process-ID TLV, which carries a configurable process identifier value.¶
2. Mechanism 2 (Section 4): An extension of the existing IID-TLV [RFC8202], reusing the IID=0 value (currently reserved for legacy/non-multi-instance operation) to carry the process identifier information.¶
When process ID verification is enabled via either mechanism, an IS-IS adjacency can be established only when the process identifiers at both ends of the link match. This enables early detection of configuration mismatches, prevents unintended adjacencies, and reduces the operational risk of routing loops and forwarding black holes.¶
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.¶
The Process-ID TLV is carried in the IS-IS Hello (IIH) PDU (both Level 1 and Level 2). It is an optional TLV, meaning that a router not supporting this extension will silently ignore it in accordance with [RFC1195].¶
The TLV is formatted as follows:¶
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 | Process-ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type: TBD by IANA (suggested value: TLV 245, subject to IANA assignment)¶
Length: 2 octets¶
Process-ID: 16-bit unsigned integer. A value of 0 is reserved and MUST NOT be used for process identification.¶
This mechanism applies when two routers that each have an IS-IS Process ID configured are connected over a link.¶
when the router enables process ID verification, it MUST include the Process-ID TLV in IIH PDU.¶
Upon receiving an IIH PDU that contains a Process-ID TLV:¶
1. If the receiving router enables this mechanism:¶
* (1)If received_Process-ID == local_Process-ID, adjacency establishment MAY proceed normally.¶
* (2)If received_Process-ID != local_Process-ID, the router MUST suppress adjacency formation. The event SHOULD be logged.¶
1. If the receiving router does not enable this extension, it MUST silently ignore the TLV.¶
The Process-ID TLV is an optional TLV. Routers that do not recognize it will ignore it without any impact on adjacency formation.¶
[RFC8202] defines the IID-TLV for multi-instance IS-IS. The IID-TLV is a TLV (Type 7, Length 2) carried in all IS-IS PDUs. Its Value field is a 2-octet Instance Identifier (IID) that uniquely identifies the IS-IS instance to which the PDU belongs [RFC8202].When the IID-TLV is absent or the IID value is 0, it indicates that the PDU belongs to the traditional (non-multi-instance) IS-IS process [RFC8202].¶
In multi-instance deployments (IID > 0), the IID itself provides inherent adjacency verification: routers only form instance-specific adjacencies with neighbors sharing the same IID [RFC8202]. When a router's interfaces belonging to different layers (e.g., access vs. aggregation) are configured with different IS-IS process IDs and different Instance IDs. This dual-level mismatch provides built-in protection:¶
Case 1: Process ID misconfigured but Instance ID mismatched: if a operator accidentally configures the same process ID on two interfaces that should belong to different layers, different Instance IDs will still prevent the two routing domains from merging. The LSPs from one instance will be ignored by the other because their Instance IDs do not match.¶
Case 2: Both Process ID and Instance ID are misconfigured as the same values on interfaces belonging to two different layers: In this situation, the router's Instance ID will not match the Instance ID of the neighboring router on the other end of the link. As a result, the IS-IS adjacency cannot be established at all. No routes are exchanged, and the intended layer-isolation is still preserved.¶
Based on the analysis in the previous section, the scope of process ID verification should be limited to non-multi-instance deployments. Therefore, the IID-TLV defined in [RFC8202] is reused as follows in this document:¶
1. If the Process ID verification function is enabled on a router, and the deployment is in non-multi-instance mode, the router MUST include the IID-TLV in its IIH PDUs, and set the IID field to the configured Process ID value for adjacency verification purposes.¶
2. If the deployment is in multi-instance mode, the IID field MUST carry the Instance ID as specified in [RFC8202]; the Process ID verification function does not apply in this mode.¶
This mechanism applies when two routers that each have an IS-IS Process ID configured are connected over a link.¶
The sending router enables the process ID verification function:¶
1. If the router operates in non-multi-instance mode: MUST set the IID field in its IIH PDUs to the configured Process ID value.¶
2. If the router operates in multi-instance mode (IID > 0): MUST set the IID field in all its IIH PDUs to its configured Instance ID value (1-65535), as defined in [RFC8202].¶
Upon receiving an IIH PDU that contains a IID-TLV:¶
1. If the receiving router enables this mechanism and is in non-multi-instance mode:¶
* (1)If received_IID == local_Process_ID, adjacency establishment MAY proceed normally.¶
* (2)If received_IID != local_Process_ID, the router MUST suppress adjacency formation. The event SHOULD be logged.¶
2. If the receiving router enables this mechanism but is in multi-instance mode (IID > 0), the IID field is interpreted as per [RFC8202].¶
3. If the receiving router does not enable this mechanism, it MUST silently ignore the IID-TLV.¶
Routers that do not support the multi-instance extension as per [RFC8202] will not process IID-TLV. Therefore, this mechanism is only effective on routers that support [RFC8202]. However, since the IID-TLV is already present in all PDU headers in multi-instance-capable deployments, no additional TLV space is consumed.¶
IANA is requested to assign a new TLV type code from the IS-IS Top-Level TLV Codepoints registry:¶
Value Description Reference -------------- ------------------- --------------------------- TBD Process-ID TLV Section 3 of this document
No new IANA assignments are required for Solution 2, as it reuses the existing IID-TLV code point.¶
Thanks to all the contributors.¶