IS-IS Process ID Verification

IS-IS Process ID Verification China Telecom

109, West Zhongshan Road, Tianhe District Guangzhou Guangzhou 510000 CN huzh2@chinatelecom.cn

China Telecom

109, West Zhongshan Road, Tianhe District Guangzhou Guangzhou 510000 CN hujy5@chinatelecom.cn

Routing Routing Area Working Group RFC 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.

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 , 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 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 , 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 , 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.

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.

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 . The TLV is formatted as follows:

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.

Procedure This mechanism applies when two routers that each have an IS-IS Process ID configured are connected over a link.

Sending when the router enables process ID verification, it MUST include the Process-ID TLV in IIH PDU.

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.

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.

Solution 2: Extended IID-TLV Utilization

Background 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 .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 .

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 . 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.

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 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 ; the Process ID verification function does not apply in this mode.

Procedure This mechanism applies when two routers that each have an IS-IS Process ID configured are connected over a link.

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 .

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 . 3. If the receiving router does not enable this mechanism, it MUST silently ignore the IID-TLV.

Backward Compatibility Routers that do not support the multi-instance extension as per will not process IID-TLV. Therefore, this mechanism is only effective on routers that support . However, since the IID-TLV is already present in all PDU headers in multi-instance-capable deployments, no additional TLV space is consumed.

IANA Considerations

Solution 1 IANA is requested to assign a new TLV type code from the IS-IS Top-Level TLV Codepoints registry:

Solution 2 No new IANA assignments are required for Solution 2, as it reuses the existing IID-TLV code point.

Security Considerations TBD

References Normative References

Contributors Thanks to all the contributors.