IS-IS Process ID Verification
draft-hu-lsr-isis-process-verification-00

Link State Routing                                        Zehua. Hu, Ed.
Internet-Draft                                          Jiayuan. Hu, Ed.
Intended status: Standards Track                           China Telecom
Expires: 2 January 2027                                      1 July 2026

                     IS-IS Process ID Verification
               draft-hu-lsr-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 2 January 2027.

Hu & Hu                  Expires 2 January 2027                 [Page 1]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 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.  Typical Network Deployment Scenario and Problem Analysis  . .   4
     3.1.  Scenario Overview . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Problem Analysis  . . . . . . . . . . . . . . . . . . . .   5
   4.  Solution 1: Process-ID TLV  . . . . . . . . . . . . . . . . .   5
     4.1.  TLV Format  . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Procedure . . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  Sending . . . . . . . . . . . . . . . . . . . . . . .   6
       4.2.2.  Receiving . . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Backward Compatibility  . . . . . . . . . . . . . . . . .   6
   5.  Solution 2: Extended IID-TLV Utilization  . . . . . . . . . .   7
     5.1.  Background  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Rationale: Multi-Instance Scenarios Are Already
           Protected . . . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Extended Semantics for IID=0  . . . . . . . . . . . . . .   7
     5.4.  Procedure . . . . . . . . . . . . . . . . . . . . . . . .   8
       5.4.1.  Sending . . . . . . . . . . . . . . . . . . . . . . .   8
       5.4.2.  Receiving . . . . . . . . . . . . . . . . . . . . . .   8
     5.5.  Backward Compatibility  . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     6.1.  Solution 1  . . . . . . . . . . . . . . . . . . . . . . .   9
     6.2.  Solution 2  . . . . . . . . . . . . . . . . . . . . . . .   9
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
   Contributors  . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

Hu & Hu                  Expires 2 January 2027                 [Page 2]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 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.  Solution 1 (Section 4): A new optional TLV in the IS-IS Hello
   PDU, called the Process-ID TLV, which carries a configurable process
   identifier value.

   2.  Solution 2 (Section 5): 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 2 January 2027                 [Page 3]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 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.  Typical Network Deployment Scenario and Problem Analysis

3.1.  Scenario Overview

   In typical metro network deployments, the architecture is
   hierarchical, comprising access, aggregation, and core layers.
   Operators commonly configure separate IS-IS processes for different
   network layers to isolate routing impacts and simplify operations.
   Figure 1 illustrates a typical topology: access layer devices run IS-
   IS process 2, while aggregation layer devices run IS-IS process 1.

   Alternatively, operators typically apply administrative tags or
   whitelist-based policies to mark specific IS-IS processes, thereby
   enabling fine-grained route import control between aggregation and
   access layers.  In Figure 1, the Spine device apply administrative
   tags to specific routes originating from the access layer Process 2,
   and then selectively import these tagged routes into the aggregation
   layer Process 1.

Hu & Hu                  Expires 2 January 2027                 [Page 4]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 2026

                   +--------------+        +--------------+
                   | Super-Spine1 +--------+ Super-Spine2 |
                   +------+-------+        +------+-------+
                 process 1|  \                  / | process 1
                         |   \\\\\\\\    //////  |
                         |         //X///        |
                         |   //////   \\\\\\\\\  |
                 process 1|  /                  \ | process 1
                     +----+-----+             +---+------+
                     |  Spine1  +-------------+  Spine2  |
                     +----+-----+             +----+-----+
                 process 2|  \                  /  |process 2
                         |   \\\\\\\\    //////   |
                         |         //X///         |
                         |   //////   \\\\\\\\\   |
                 process 2|  /                  \  |process 2
                     +----+----+               +---+-----+
                     |  Leaf1  +---------------+  Leaf2  |
                     +---------+               +---------+

    Figure 1: Metro Network Topology with Access and Aggregation Layers

3.2.  Problem Analysis

   Because the process ID is a local configuration artifact and does not
   appear in any IS-IS PDU, misconfiguration of the process ID on both
   ends of a link can result a severe impact on service availability.
   For example, as shown in Figure 1, if the interface on Spine1 that
   connects to Super-Spine1 is misconfigured to belong to Process 2
   (instead of the correct Process 1), the routing separation between
   the access and aggregation layers is effectively broken.
   Consequently, routes imported by Spine2 from Process 2 could be re-
   advertised back to Leaf1 through Spine1, resulting the routing loop.
   Such misconfiguration of the process ID can lead to severe impacts
   including routing loops and black holes, with difficult
   troubleshooting

4.  Solution 1: Process-ID TLV

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

Hu & Hu                  Expires 2 January 2027                 [Page 5]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 2026

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

4.2.  Procedure

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

4.2.1.  Sending

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

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

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

Hu & Hu                  Expires 2 January 2027                 [Page 6]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 2026

5.  Solution 2: Extended IID-TLV Utilization

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

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

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

Hu & Hu                  Expires 2 January 2027                 [Page 7]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 2026

   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.

5.4.  Procedure

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

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

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

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

Hu & Hu                  Expires 2 January 2027                 [Page 8]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 2026

6.  IANA Considerations

6.1.  Solution 1

   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

                                  Figure 3

6.2.  Solution 2

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

7.  Security Considerations

   TBD

8.  References

8.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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC1195]  Callon, R., "Use of OSI IS-IS for routing in TCP/IP and
              dual environments", RFC 1195, DOI 10.17487/RFC1195,
              December 1990, <https://www.rfc-editor.org/info/rfc1195>.

   [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,
              <https://www.rfc-editor.org/info/rfc5130>.

   [RFC8202]  Ginsberg, L., Previdi, S., and W. Henderickx, "IS-IS
              Multi-Instance", RFC 8202, DOI 10.17487/RFC8202, June
              2017, <https://www.rfc-editor.org/info/rfc8202>.

Hu & Hu                  Expires 2 January 2027                 [Page 9]
Internet-Draft  draft-hu-lsr-isis-process-verification-0       July 2026

Contributors

   Thanks to all the contributors.

Authors' Addresses

   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 2 January 2027                [Page 10]