Routing Area Working Group Zehua. Hu, Ed. Internet-Draft Jiayuan. Hu, Ed. Intended status: Informational China Telecom Expires: 27 December 2026 25 June 2026 IS-IS Process ID Verification draft-hu-rtgwg-isis-process-verification-00 Abstract 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. 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 27 December 2026. Hu & Hu Expires 27 December 2026 [Page 1] Internet-Draft draft-hu-rtgwg-isis-process-verification June 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 3. Solution 1: Process-ID TLV . . . . . . . . . . . . . . . . . 4 3.1. TLV Format . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Sending . . . . . . . . . . . . . . . . . . . . . . . 5 3.2.2. Receiving . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Backward Compatibility . . . . . . . . . . . . . . . . . 5 4. Solution 2: Extended IID-TLV Utilization . . . . . . . . . . 5 4.1. Background . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Rationale: Multi-Instance Scenarios Are Already Protected . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3. Extended Semantics for IID=0 . . . . . . . . . . . . . . 6 4.4. Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4.1. Sending . . . . . . . . . . . . . . . . . . . . . . . 7 4.4.2. Receiving . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Backward Compatibility . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. Solution 1 . . . . . . . . . . . . . . . . . . . . . . . 7 5.2. Solution 2 . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 7.1. Normative References . . . . . . . . . . . . . . . . . . 8 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 Hu & Hu Expires 27 December 2026 [Page 2] Internet-Draft draft-hu-rtgwg-isis-process-verification June 2026 1. Introduction 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. Hu & Hu Expires 27 December 2026 [Page 3] Internet-Draft draft-hu-rtgwg-isis-process-verification June 2026 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. 2. Conventions Used in This Document 2.1. 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. Solution 1: Process-ID TLV 3.1. TLV Format 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: TLV Format 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. Hu & Hu Expires 27 December 2026 [Page 4] Internet-Draft draft-hu-rtgwg-isis-process-verification June 2026 3.2. Procedure This mechanism applies when two routers that each have an IS-IS Process ID configured are connected over a link. 3.2.1. Sending when the router enables process ID verification, it MUST include the Process-ID TLV in IIH PDU. 3.2.2. Receiving 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. 3.3. Backward Compatibility The Process-ID TLV is an optional TLV. Routers that do not recognize it will ignore it without any impact on adjacency formation. 4. Solution 2: Extended IID-TLV Utilization 4.1. Background [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]. Hu & Hu Expires 27 December 2026 [Page 5] Internet-Draft draft-hu-rtgwg-isis-process-verification June 2026 4.2. Rationale: Multi-Instance Scenarios Are Already Protected 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. 4.3. Extended Semantics for IID=0 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. 4.4. Procedure This mechanism applies when two routers that each have an IS-IS Process ID configured are connected over a link. Hu & Hu Expires 27 December 2026 [Page 6] Internet-Draft draft-hu-rtgwg-isis-process-verification June 2026 4.4.1. Sending 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]. 4.4.2. Receiving 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. 4.5. Backward Compatibility 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. 5. IANA Considerations 5.1. Solution 1 IANA is requested to assign a new TLV type code from the IS-IS Top- Level TLV Codepoints registry: Hu & Hu Expires 27 December 2026 [Page 7] Internet-Draft draft-hu-rtgwg-isis-process-verification June 2026 Value Description Reference -------------- ------------------- --------------------------- TBD Process-ID TLV Section 3 of this document Figure 2 5.2. Solution 2 No new IANA assignments are required for Solution 2, as it reuses the existing IID-TLV code point. 6. Security Considerations TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC1195] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, DOI 10.17487/RFC1195, December 1990, . [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, . [RFC8202] Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June 2017, . Contributors Thanks to all the contributors. Authors' Addresses Hu & Hu Expires 27 December 2026 [Page 8] Internet-Draft draft-hu-rtgwg-isis-process-verification June 2026 Zehua Hu (editor) China Telecom 109, West Zhongshan Road, Tianhe District Guangzhou Guangzhou, 510000 China Email: huzh2@chinatelecom.cn Jiayuan Hu (editor) China Telecom 109, West Zhongshan Road, Tianhe District Guangzhou Guangzhou, 510000 China Email: hujy5@chinatelecom.cn Hu & Hu Expires 27 December 2026 [Page 9]