LSR Working Group C. Lin Internet Draft New H3C Technologies Intended status: Standards Track L. Gong Expires: 07 January 2027 China Mobile 06 July 2026 Detection of Router-ID Conflicts in IGPs draft-lg-lsr-router-id-conflict-detect-00 Abstract In link-state Interior Gateway Protocols (IGPs) such as OSPF and IS- IS, the router ID (or system ID) serves as a unique identifier for routers within a routing domain. Duplicate router IDs can lead to severe network instability, including persistent Link State Advertisement (LSA/LSP) flooding, inconsistent Link State Databases (LSDBs), and permanent forwarding loops. This document defines mechanisms for detecting such conflicts between non-adjacent routers and proposes procedures to alert network operators, along with defining the corresponding YANG interface and event YANG notifications for OAM operations. 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 06 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Lin. 07 January 2027 [Page 1] Internet-Draft Router ID conflict detect July 2026 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...................................................2 2. Terminology....................................................3 3. Router ID Conflict Detect......................................3 Router-ID Conflict Detection Location.....................3 Router-ID Collision Detection Packet ............................3 Router-ID Conflict Detection Process ............................4 3.3.1. Router-ID Conflict Detection Process for IS-IS.......4 3.3.2. Router-ID Conflict Detection Process for OSPF........5 4. Operational Considerations.....................................6 Configuration Parameters..................................6 YANG Data Model...........................................6 4.2.1. Tree for IS-IS systemid collision....................6 4.2.2. YANG Module for IS-IS systemid collision.............6 4.2.3. Tree for OSPF rid collision.........................12 4.2.4. YANG Module for OSPF rid collision..................12 5. IANA Considerations...........................................17 6. Security Considerations.......................................17 7. Normative References..........................................18 8. Informative References........................................18 Authors' Addresses...............................................18 1. Introduction The stable operation of link-state Interior Gateway Protocols (IGPs) relies on the unambiguous identification of each participating router. A conflict arises when two distinct routers within the same flooding domain advertise the same router ID (OSPF) or system ID (IS-IS). While adjacency establishment between directly connected routers with identical IDs will fail, preventing direct peering, the protocol itself cannot prevent conflicts between non-adjacent routers, which can lead to widespread disruption. This document specifies a method enabling routers to detect non- adjacent router ID conflicts by analyzing the content and frequency of received Link State Protocol Data Units (PDUs). This document further defines the OAM interface, configures router- id collision detection parameters via the YANG interface, and Lin, et al. Expires 07 January 2027 [Page 2] Internet-Draft Router ID conflict detect July 2026 notifies operators through event YANG notifications to alert them to investigate the network and execute corrective actions. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Router ID Conflict Detect Router-ID Conflict Detection Location (RA)---(RB)---(RC) Figure 1 As shown in Figure 1, for adjacent devices, such as RA and RB or RB and RC in the figure, when establishing neighbors, they exchange their Router IDs through neighbor messages. If there is a conflict in Router IDs, the neighbor establishment will fail. Therefore, it can be directly checked through neighbor establishment without additional Router ID collision detection. This document mainly describes the Router ID collision detection between non-adjacent devices, such as the Router ID collision detection between RA and RC in Figure 1. Detection can involve checking for Router ID conflicts between a remote device and the local device, such as detecting Router ID conflicts between RA and RC on RA. Alternatively, it can involve an intermediate device detecting Router ID conflicts between two remote devices, such as detecting Router ID conflicts between RA and RC on RB. The detection methods are the same for checking Router ID conflicts between the local device and a remote device, as well as for checking Router ID conflicts between two remote devices. Router-ID Collision Detection Packet First, for OSPF/OSPFv3, LSA packets are distinguished by area; for IS-IS, LSPs are distinguished by level. Here, there are two options: one is to perform Router ID conflict detection for all areas/levels, and the other is to perform Router ID conflict detection only within the same area/level. The latter reduces the workload of detection, so this document recommends performing Router ID conflict detection only within the same area/level. Lin, et al. Expires 07 January 2027 [Page 3] Internet-Draft Router ID conflict detect July 2026 Second, when performing area detection, after detecting the same Router ID/System ID, it is necessary to compare other fields to determine whether the packets are sent by the same device. Therefore, to reduce the workload of conflict detection, we choose to perform conflict detection only on certain packets. Specifically, the IS-IS protocol only performs conflict detection on LSP packets of fragment 0 and does not detect LSP packets from pseudonodes; the OSPF/OSPFv3 protocol only detects Router LSAs. In the IS-IS protocol, LSP packets are organized by TLV. The content carried in fragment 0 is not fixed, but typically includes the Interface Address TLV and Neighbor TLV. In the OSPF protocol, Router LSAs carry link data of various link types. The data types carried by the two protocols differ, so the inspection process for each protocol varies. However, the general principle remains the same: for two LSPs/LSAs with the same Router ID but different Sequence Numbers, compare whether their contents differ. To reduce false positives, a conflict is only identified as a Router ID conflict when the inconsistency in packet content exceeds a certain threshold, such as 60%. For example, in the IS-IS protocol, if two fragment 0 packets carry 10 interface addresses and 2 neighbors, the total information amount is 12. If 8 interface addresses and 2 neighbors are found to be inconsistent, the inconsistency ratio is 8/12 = 66%, which exceeds 60%. In this case, it is considered a Router ID conflict. Router-ID Conflict Detection Process 3.3.1. Router-ID Conflict Detection Process for IS-IS The core logic of router ID conflict detection is: When a new LSP is received, the locally recorded previously received LSP is the Old LSP: If the LSP is a zero-fragment LSP, the sequence number of the New LSP is one greater than that of the Old LSP, and the Age times of both the New LSP and the Old LSP are not 0, then a system ID conflict detection is required. Compare the content of the old and new LSPs. If the inconsistency ratio exceeds 60%, it is determined that a system ID conflict has been detected, and the conflict count for this system ID is incremented. If the number of conflicts detected within the detection cycle exceeds the threshold, it is considered that this Router ID has a conflict. Lin, et al. Expires 07 January 2027 [Page 4] Internet-Draft Router ID conflict detect July 2026 For the detection cycle and threshold, the default detection cycle is 1 minute, and the default threshold is 10 times. The detection cycle and threshold can be modified and adjusted through configuration. When a router ID conflict is detected, the system will notify through the event YANG, enabling the administrator to quickly locate the conflicting device and resolve the issue based on the notification content. The notification includes the time the conflict was discovered, the conflicting system ID, LSP-ID, the Mini interface address of both ends of the conflict LSP. The specific content of the event YANG notification will be detailed in the following sections. 3.3.2. Router-ID Conflict Detection Process for OSPF The core logic of router ID conflict detection is as follows: When a new Router LSA is received, the locally recorded previously received LSA is referred to as the Old LSA: If the sequence number of the New LSA is greater than that of the Old LSA by 1, and the Age timers of both the New LSA and the Old LSA are not 3600, router ID conflict detection must be performed. Compare the content of the old and new LSAs. If the inconsistency ratio exceeds 60%, it is determined that a Router ID conflict has been detected, and the conflict count for this Router ID is incremented. If the count of detected conflicts exceeds the threshold within the detection cycle, the router ID is considered to have a conflict. For the detection cycle and threshold, the default detection cycle is 1 minute, and the default threshold is 10 times. The detection cycle and threshold can be modified and adjusted through configuration. When a router ID conflict is detected, the system will issue a notification via the event YANG, enabling the administrator to quickly locate the conflicting device and resolve the issue based on the notification content. The notification includes the time of conflict detection, the conflicting Router ID, and the Mini interface address of both ends of the conflict LSA. The specific content of the event YANG notification will be detailed in the following sections. Lin, et al. Expires 07 January 2027 [Page 5] Internet-Draft Router ID conflict detect July 2026 4. Operational Considerations Configuration Parameters The enablement of the router ID collision detection function must support configurability. When configuration changes, neighbor flapping, or other situations occur, false positive collisions may be triggered. To reduce collisions, parameters such as the inconsistency ratio for collision detection, the collision detection cycle, and the collision threshold can be configured via the YANG interface. When a collision is detected, it will be notified through the event YANG. YANG Data Model 4.2.1. Tree for IS-IS systemid collision module: ietf-isis-systemid-collision augment "/isis:isis/isis:instances/isis:instance +-- system-id-collision-detection notification isis-system-id-collision-detected +-- instance-id? leafref -> /isis:isis/instances/instance/name 4.2.2. YANG Module for IS-IS systemid collision [RFC 9130] defines the YANG interface for ietf-isis. This document adds configuration interfaces related to router-id conflicts and event notification interfaces. module ietf-isis-systemid-collision { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-isis-systemid- collision"; prefix isis-sc; import ietf-isis { Lin, et al. Expires 07 January 2027 [Page 6] Internet-Draft Router ID conflict detect July 2026 prefix isis; reference "RFC 9130: YANG Data Model for IS-IS Protocol"; } import ietf-yang-types { prefix yang; reference "RFC 6991: Common YANG Data Types"; } import ietf-inet-types { prefix inet; reference "RFC 6991: Common YANG Data Types"; } organization "IETF LSR Working Group"; contact "WG Web: WG List: "; Author: CW.Lin"; description "This YANG module defines IS-IS System ID collision detection and notification extensions. Copyright (c) 2023 IETF Trust and the persons identified as authors of the code. All rights reserved."; Lin, et al. Expires 07 January 2027 [Page 7] Internet-Draft Router ID conflict detect July 2026 revision 2023-10-01 { description "Initial revision."; reference "RFC XXXX: IS-IS System ID Collision Detection"; } container ISIS { description "ISIS information table"; augment "/isis:isis/isis:instances/isis:instance { description "ISIS instance information table"; container system-id-collision-detection { presence "Enables system ID collision detection"; description "Configuration parameters for IS-IS system ID collision detection."; leaf enable { type boolean; default "true"; description "Enable/disable Router ID collision detection."; } leaf inconsistency-ratio { type uint8 { range "1..100" } Lin, et al. Expires 07 January 2027 [Page 8] Internet-Draft Router ID conflict detect July 2026 default 60 units "percent" description "Inconsistency ratio threshold for determining if packets are from different routers. When the ratio of inconsitent pacaets this threshold, it indicates a Router ID conflict. Default is 60 percent." } leaf detection-window { type uint32 { range "60..3600"; } units "seconds"; default "60"; description "Time window for counting collision events."; } leaf collision-threshold { type uint32 { range "1..100"; } default "10"; description "Number of collisions within detection-window that triggers a notification."; } } Lin, et al. Expires 07 January 2027 [Page 9] Internet-Draft Router ID conflict detect July 2026 } /* Notifications */ notification isis-system-id-collision-detected { description "Notification triggered when an ISIS System ID collision is detected. This notification is associated with an ISIS instance. The 'instance-id' in the notification indicates which ISIS instance detected the collision."; leaf instance-id { type leafref { path "/isis:isis/isis:instances/isis:instance/isis:name"; } mandatory true; description "ISIS instance identifier of the instance that detected the collision. References the ISIS instance in ietf-isis."; } leaf level { type uint8 { range "1..3"; } description "ISIS level (1=Level-1, 2=Level-2, 3=Level-1-2)."; } leaf detection-time { type yang:date-and-time; Lin, et al. Expires 07 January 2027 [Page 10] Internet-Draft Router ID conflict detect July 2026 description "Detection time of the collision event."; } leaf system-id { type rt-types:isis-system-id; description "The System ID involved in the collision."; } leaf one-ip-address { type inet:ip-address; description "One IP address involved in the collision."; } leaf other-ip-address { type inet:ip-address; description "Other IP address involved in the collision."; } leaf neighbor-system-id { type rt-types:isis-system-id; description "Neighbor System ID detected in the collision."; } leaf lsp-id { type rt-types:isis-lsp-id; description Lin, et al. Expires 07 January 2027 [Page 11] Internet-Draft Router ID conflict detect July 2026 "LSP ID associated with the collision event."; } } } } 4.2.3. Tree for OSPF rid collision module: ietf-ospf-rid-collision augment "/ospf:ospf/ospf:instances/ospf:instance" +-- ietf-ospf-rid-collision notification ospf-rid-collision-detected +-- instance-id? leafref -> /ospf:ospf/instances/instance/name 4.2.4. YANG Module for OSPF rid collision [RFC 9129] defines the YANG files for OSPFv2 and OSPFv3. This document adds configuration and event interfaces related to router ID conflicts. module ietf-ospf-rid-collision { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-ospf-rid-conflict- notification"; prefix ospf-rid-ntf; import ietf-ospf { prefix ospf; } import ietf-yang-types { Lin, et al. Expires 07 January 2027 [Page 12] Internet-Draft Router ID conflict detect July 2026 prefix yang; } import ietf-inet-types { prefix inet; } import ietf-ospf-notification { prefix ospf-ntf; } organization "IETF OSPF Working Group"; contact "WG Web: WG List: mailto:ospf@ietf.org"; Editor: CW. link; description "This YANG module defines OSPF Router ID collision notification. Copyright (c) 2023 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). Lin, et al. Expires 07 January 2027 [Page 13] Internet-Draft Router ID conflict detect July 2026 This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2023-10-01 { description "Initial revision."; reference "RFC XXXX: OSPF Router ID Collision Detection Notification"; } container OSPF { description "OSPF information table"; augment "/ospf:ospf/ospf:instances/ospf:instance" { description "OSPF instance information table"; container RID-Collision-Detection { description "Router ID collision detection configuration."; leaf enable { type base:Basetype_Boolean; description "Enable flag for router ID collision detection."; } leaf inconsistency-ratio { type uint8 { range "1..100" } default 60 Lin, et al. Expires 07 January 2027 [Page 14] Internet-Draft Router ID conflict detect July 2026 units "percent" description "Inconsistency ratio threshold for determining if packets are from different routers. When the ratio of inconsitent pacaets this threshold, it indicates a Router ID conflict. Default is 60 percent." } leaf DetectionWindow { type base:Basetype_UnsignedInteger32 { range "1..3600"; } default "60"; units "seconds"; description "Detection window in seconds. Default is 60."; } leaf CollisionThreshold { type base:Basetype_UnsignedInteger32 { range "1..100"; } default "10"; description "Collision threshold count. Default is 10."; } } } /* Notifications */ notification ospf-rid-collision-detected { Lin, et al. Expires 07 January 2027 [Page 15] Internet-Draft Router ID conflict detect July 2026 description "Notification triggered when an OSPF Router ID collision is detected. This notification is associated with an OSPF instance. The 'instance-id' in the notification indicates which OSPF instance detected the collision."; leaf instance-id { type leafref { path "/ospf:ospf/ospf:instances/ospf:instance/ospf:name"; } mandatory true; description "OSPF instance identifier of the instance that detected the collision. References the OSPF instance in ietf-ospf."; } leaf area { type rt-types:ospf-area-id; description "OSPF Area ID where the collision was detected."; } leaf detection-time { type yang:date-and-time; description "Detection time of the collision event."; } leaf router-id { type inet:ipv4-address; description "The Router ID involved in the collision."; Lin, et al. Expires 07 January 2027 [Page 16] Internet-Draft Router ID conflict detect July 2026 } leaf one-ip-address { type inet:ip-address; description "One IP address involved in the collision."; } leaf other-ip-address { type inet:ip-address; description "Other IP address involved in the collision."; } leaf neighbor-rid { type inet:ipv4-address; description "Neighbor Router ID detected in the collision."; } } } } 5. IANA Considerations This document has no IANA actions. 6. Security Considerations TBD Lin, et al. Expires 07 January 2027 [Page 17] Internet-Draft Router ID conflict detect July 2026 7. Normative References [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, . [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, . [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, . [RFC9129] Yeung, D., Qu, Y., Zhang, Z., Chen, I., and A. Lindem, "YANG Data Model for the OSPF Protocol", RFC 9129, DOI 10.17487/RFC9129, October 2022, . [RFC9130] Litkowski, S., Ed., Yeung, D., Lindem, A., Zhang, J., and L. Lhotka, "YANG Data Model for the IS-IS Protocol", RFC 9130, DOI 10.17487/RFC9130, October 2022, . 8. Informative References TBD Authors' Addresses Changwang Lin New H3C Technologies China Email: linchangwang.04414@h3c.com Liyan Gong China Mobile China Email: gongliyan@chinamobile.com Lin, et al. Expires 07 January 2027 [Page 18]