| Internet-Draft | Network Incident Management | September 2026 |
| Hu, et al. | Expires 20 March 2027 | [Page] |
This document defines a YANG data model for the network incident lifecycle management. This YANG module provides a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable root cause analysis.¶
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 20 March 2027.¶
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.¶
[RFC8969] defines a framework for Automating Service and Network Management with YANG [RFC7950] for full life cycle network management. A set of YANG data models have already been developed in IETF for network performance monitoring and fault monitoring, e.g., a YANG data model for alarm management [RFC8632] defines a standard interface for alarm management. A data model for Network and VPN Service Performance Monitoring [RFC9375] defines a standard interface for network performance management. In addition, distributed tracing mechanism defined in [W3C-Trace-Context] can be used to analyze and debug operations, such as configuration transactions, across multiple distributed systems.¶
However, these YANG data models for network maintenance are based on specific data source information and manage alarms and performance metrics data separately at different layers in various separate management systems. In addition, the frequency and quantity of alarms and performance metrics data reported to Operating Support System (OSS) have increased dramatically (in many cases multiple orders of magnitude) with the growth of service types and complexity and greatly overwhelm OSS platforms [TMF724A]; with existing known dependency relationships between metric, alarm, and events at each layer (e.g., packet layer or optical layer), it is possible to compress series of alarms (see Section 3.5.3 of [RFC8632]) into fewer network incidents and there are many solutions in the market when this document was written that essentially do this to some degree. However, conventional solutions such as data compression are time-consuming and labor-intensive, usually rely on maintenance engineers' experience for data analysis, which, in many cases, result in low processing efficiency, inaccurate Probable Root Cause identification and duplicated tickets. It is also difficult to assess the impact of alarms, performance metrics and other anomaly data on network services without known relation across layers of the entire network topology data or the relation with other network topology data.¶
To address these challenges, this document specifies a network-wide, incident-centric solution to establish the global view on dependency relationships with both network service and network topology at various different layers, which not only can be used at a specific layer in one domain but also can be used to span across layers for multi-layer network troubleshooting.¶
As described in [RFC9940], a network incident refers to an undesired Occurrence such as an unexpected interruption of a network service, degradation of the quality of a network service, or the below-target performance of a network service. Different data sources, including alarms, metrics, and other anomaly information, can be correlated and combined into one or a few network incidents, regardless of layer, informed by correlation analysis and service impact assessment. For example, if the protocol-related interface fails to work properly, a large amount of alarms may be reported to the upper-layer management system. Although a lot of network services may be affected by the interface, only one aggregated network incident pertaining to the abnormal interface will be reported. A network incident may also be raised through the analysis of some network performance metrics, for example, as described in SAIN [RFC9417], network services can be decomposed to several sub-services, specific metrics can be monitored for each sub-service. Therefore symptoms will occur if services/sub-services are unhealthy (after analyzing metrics), in addition, these symptoms may give rise to a network incident when it causes degradation of the network services.¶
In addition, Artificial Intelligence (AI) and Machine Learning (ML) are key technologies in the processing of large amounts of data with complex data correlations (see Section 6.1 of [I-D.irtf-nmrg-ai-challenges]). For example, Neural Network Algorithm or Hierarchy Aggregation Algorithm [BERT] can be used to replace manual alarm data correlation. Through online and offline self-learning, these algorithms can be continuously optimized to improve the efficiency of fault diagnosis.¶
This document defines a YANG data model for network incident lifecycle management, which improves troubleshooting efficiency, and improves network automation [RFC8969] with remote process call (RPC) operations in this YANG module.¶
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 following terms are defined in [RFC9543],[RFC9940] and are not redefined here:¶
Alarm¶
Resource¶
Fault¶
Event¶
Problem¶
Incident¶
Anomaly¶
Cause¶
Symptom¶
Characteristic¶
Occurrence¶
SLA (Service Level Agreement)¶
SLO (Service Level Objective)¶
The following terms are defined in this document:¶
A process that uses algorithmic techniques (e.g., machine learning, automated reasoning, conformance checking, graph traversal, among others) to evaluate whether the network service has been impacted by the network incident and map the network incident to one or a set of network services. This process can reduce the volume of fault/alarms reporting, facilitate troubleshooting, and assure network service performance and availability.¶
Lifecycle management of network incidents, including network incident identification, reporting, acknowledgement, diagnosis, and resolution. Unlike previous fault management, it takes various different data sources including alarms, metrics, and other anomaly information and aggregates them into one or a few network incidents irrespective of layer through data correlation analysis and the Service Impact Assessment. A network incident might impact one or a set of network services. The network incident can also been seen as customer incident [TMF724A] when the service SLA [RFC9543] associated with one specific network service and network incident has been affected. How a customer incident is translated from the network incident is beyond the scope of this document. Note that a customer incident specifically arises when an issue or problem identified by a customer (or derived from a service-level threshold/SLO violation) impacts their service experience.¶
An entity that implements network Incident Management. It includes (but not limited to) Incident Server and Incident Client.¶
An entity that is responsible for detecting and reporting one network incident, performing network incident diagnosis, resolution and prediction in specific domain, etc.¶
An entity that can manage network incidents based on global view on network topology data correlation. For example, it can receive network incident notifications, query the information of network incidents, instruct an Incident Server to diagnose, help resolve, etc. In addition, it can trigger issue tickets and involve repair crew to fix the problem.¶
An entity that can receive network incident notifications, store and query the information of network incidents for data analysis. Unlike the Incident Client, it does not control the incident server and cannot instruct it to perform network incident diagnosis or resolution.¶
A multi-step workflow used by network operation teams to identify, analyze, and unexpected service disruptions or quality reductions, with the primary goal of restoring normal operations as quickly as possible while minimizing service impact.¶
If removing a fault condition completely s the ongoing incident (specifically, regarding network outage or service impairments and their associated subsequent failures and symptoms) and prevents the problem from recurring, then such fault condition is considered as a Probable Root Cause of a problem.¶
Since one fault may give rise to another fault or problem, a Probable Root Cause is commonly meant to describe the original event or combination of circumstances that is the foundation of all related faults.¶
Conversely, a causal fault condition is a contributing action that influences the outcome of the incident or event, but is not the Probable Root Cause.¶
Usually, the dispatching of trouble tickets in a network is mostly based on alarm data analysis and often requires operators' maintenance engineers. These operators' maintenance engineers are responsible for monitoring, detecting and correlating alarms, e.g., that alarms at both endpoints of a specific tunnel or at both optical and IP layers which are associated with the same network fault. Therefore, they can correlate these alarms to the same trouble ticket, which offers a low level of automation. If there are more alarms, then the human costs for network maintenance are increased accordingly.¶
Some operators preconfigure accept-lists and adopt some coarse granularity data correlation rules for the alarm management. This approach seems to improve fault management automation. However, some trouble tickets might be missed if the filtering conditions are too restrictive. If the filtering conditions are not restrictive, it might end up with multiple trouble tickets being dispatched for the same network fault. It is hard to achieve a perfect balance between the network management automation and duplicated trouble tickets under the conventional working situations.¶
With the help of the Network Incident Management, massive sets of alarms can be aggregated into a few network incidents based on Service Impact Assessment, so the number of trouble tickets will be reduced. At the same time, the efficiency of network troubleshooting can be largely improved, which addresses the pain points of trouble ticket dispatching.¶
When a fault occurs in a network that contains both packet layer devices and optical-layer devices, it may cause correlative faults in both layers, i.e., packet layer and optical layer. Specifically, fault propagation could be classified into three typical types. First, faults occurring at a packet layer device might further cause fault at an optical-layer device (e.g., Wavelength Division Multiplexing (WDM) client fault). Second, faults occurring at an optical-layer device might further cause faults at a packet layer device (e.g., Layer 3 link down). Third, faults occurring at the inter-layer link between a packet layer device and an optical-layer device might further cause faults at both devices. Multiple operation teams are usually needed to first analyse a large amount of alarms (triggered by the above-mentioned faults) from single network layer (either packet layer or optical layer) independently, then cooperate to locate the Probable Root Cause through manually analyzing multi-layer topology data and service data, thus fault demarcation becomes more complex and time-consuming in multi-layer scenario than in single-layer scenario.¶
With the help of Network Incident Management, the management systems first automatically analyze Probable Root Cause of the alarms at each layer and report corresponding network incidents to the multi-layer, multi-domain management system, then such management system comprehensively analyzes the topology relationship and service relationship between the Probable Root Causes of both layers. The inner relationship among the alarms will be identified and finally the Probable Root Cause will be located among multiple layers. By cooperating with a test tool that checks fiber optic cables (e.g.,the integrated Optical time-domain reflectometer (OTDR)) embedded within the network device, we can determine the target optical exchange station before site visits. Therefore, the overall fault demarcation process is simplified and automated, the analysis result could be reported and visualized in time. In this case, operation teams only have to confirm the analyzed result and dispatch site engineers to perform relevant maintenance actions (e.g., splice fiber) based on the Probable Root Cause.¶
+-------------------------------------------------+
| |
| |
| Incident Client |
| |
| |
+----^------------+------------+------------+-----+
| | | |
|Incident |Incident |Incident |Incident
|Notification| Ack |Diagnose |Resolve
| | | |
| | | |
| | | |
+----+------------V------------V------------V-----+
| |
| |
| |
| |
| |
| |
| Incident Server |
| |
| |
| |
| |
| |
| |
+----^-----------^-------------^------------^-----+
| | | |
| | | |
|Alarm |Abnormal |Network |Network
|Report |Operation |Performance |Diagnosis
| | Report |Metrics/ |using
| | |Telemetry |OAM Test
| | | |
| | | |
+--------+-----------+-------------|------------V-------+
| |
| |
| Network in the Autonomous Domain |
| |
+-------------------------------------------------------+
Figure 1 illustrates the Network Incident Management architecture. Two key components for the Network Incident Management are the Incident Client and the Incident Server.¶
The Incident Server can be deployed in network operation platforms, network analytic platforms, controllers [RFC8969] in each domain and provides functionality such as network incident identification, report, diagnosis, resolution, or querying for the network incident lifecycle management.¶
The Incident Client can be deployed within a single domain as the Incident Server or across domains with the global view of network data. It can be deployed either in the same network operation platforms, network analytic platforms, controllers as the Incident Server within a single domain, or at the upper-layer network operation platforms, network analytic platforms or controllers (i.e., multi-domain controllers), to invoke the functionalities provided by the Incident Server in each domain to meet business requirements of the fault management.¶
A typical workflow of network incident lifecycle management is as follows:¶
Some alarm or abnormal operations, network performance metrics, network diagnosis information [I-D.ietf-opsawg-scheduling-oam-tests] are reported from the network to the Incident Server. The Incident Server receives these alarms/abnormal operations/metrics and try to analyze the correlation of them, e.g., generate a symptom if some metrics are evaluated as unhealthy, the Probable Root Cause can be detected based on the data correlation analysis. If a network incident is identified, the "incident-notification" notification will be reported to the Incident Client. The impact of network services will be further analyzed and will update the network incident if the network service is impacted.¶
Incident Client receives the network incident from the "incident-notification" notification reported by Incident Server, and acknowledges it with the subsequent 'incident-acknowledge' RPC operation. The Incident Client may further invoke the 'incident-diagnose' RPC to diagnose this network incident to find the Probable Root Causes.¶
If the Probable Root Causes have been found, the Incident Client can resolve this network incident by invoking the 'incident-resolve' RPC operation to ask the Incident Server to resolve it, or dispatching a troubleshooting ticket or using other network functions (routing calculation, configuration, etc.) without being known by the Incident Server.¶
In case of the 'incident-resolve' RPC operation invoked by the Incident Client, the Incident Server will monitor the status of the network incident and update the status of network incident to 'cleared' if the incident can be fixed. For more detailed workflow, please refer to section 5.3.¶
As depicted in Figure 2, multiple alarms, metrics, or hybrid can be aggregated into a network incident after analysis.¶
+--------------+ +--| Incident1 | | +--+-----------+ | | +-----------+ | +--+ alarm1 | | | +-----------+ | | | | +-----------+ | +--+ alarm2 | | | +-----------+ | | | | +-----------+ | +--+ alarm3 | | +-----------+ | +--------------+ +--| Incident2 | | +--+-----------+ | | +-----------+ | +--+ metric1 | | | +-----------+ | | +-----------+ | +--+ metric2 | | +-----------+ | | +--------------+ +--| Incident3 | | +--+-----------+ | | +-----------+ | +--+ alarm1 | | | +-----------+ | | +-----------+ | +--| metric1 | | +-----------+
The Incident Server is capable of identifying network incidents. Multiple alarms, metrics and other information are reported to the Incident Server, and the server needs to analyze it and find out the correlations of them, if the correlation match the network incident rules, network incident is identified, and reported to the client. If the network incident is repeated many times, the problem needs to be raised based on the incident and the operator's policy. Service Impact Assessment SHOULD be performed if a network incident is identified, and the content of network incident SHOULD be updated if impacted network services are detected.¶
AI/ML may be used to identify the network incident. Expert system and online learning can help AI to identify the correlation of alarms, metrics and other information by time-base correlation algorithm, topology-based correlation algorithm, etc. For example, if the interface is down, then many protocol alarms will be reported, AI may find some correlations within the raised alarms. These new correlations will be put into the knowledge base [I-D.mackey-nmop-kg-for-netops], and the network incident will be identified faster according to knowledge base next time.¶
+----------------------+
| |
| Orchestrator |
| |
+--------^-------------+
|VPN A Unavailable
|
+-------+------------+
| |
| Controller |
| |
| |
+-^-^------------^---+
| | |
IGP | |Interface |IGP Peer
Down | |Down | Abnormal
| | |
VPN A | | |
+----------+-+------------+-------------------------+
| \ +---+ ++-++ +-+-+ +---+ /|
| \ | | | | | | | | / |
| \|PE1+-------| P1+X--------|P2 +--------|PE2|/ |
| +---+ +---+ +---+ +---+ |
+---------------------------------------------------+
As described in Figure 3, VPN A a is deployed from PE1 to PE2, if an interface of P1 is going down, many alarms are triggered, such as interface down, IGP down, and IGP peer abnormal from P2.¶
These alarms are aggregated and analyzed by the controller/Incident Server, and then the network incident 'VPN unavailable' is triggered by the controller/Incident Server. If the network incident 'VPN unavailable' is repeated, the problem can be raised.¶
Note that Incident Server within the controller can rely on data correlation technology such as Service Impact Assessment and data analytic component to evaluate the real effect on the relevant service and understand whether lower level or device level network anomaly has impact on the service (e.g., IGP down).¶
+----------------------+
| |
| Orchestrator |
| |
+----------+-----------+
|VPN A Degradation
|
+---------+----------+
| |
| controller |
| |
| |
+--^------------^----+
| |
|Packet |Path Delay
|Loss |
| |
VPN A | |
+-----------+------------+---------------------------+
| \ +---+ ++-++ +-+-+ +---+ / |
| \ | | | | | | | | / |
| \|PE1+-------|P1 +---------|P2 +--------|PE2|/ |
| +---+ +---+ +---+ +---+ |
+----------------------------------------------------+
As described in Figure 4, controller collect the network metrics from network elements, it finds the packet loss of P1 and the path delay of P2 exceed the thresholds, a network incident 'VPN A degradation' may be triggered after the Service Impact Assessment.¶
After a network incident is reported to the network Incident Client, the Incident Client may diagnose the incident to determine the Probable Root Cause. Some diagnosis operations may affect the running network services. The Incident Client can choose not to perform that diagnosis operation after determining the impact is not trivial. The Incident Server can also perform self-diagnosis. However, the self-diagnosis MUST NOT affect the running network services. Possible diagnosis methods include link reachability detection, link quality detection, alarm/log analysis, and short-term fine-grained monitoring of network quality metrics, etc.¶
After the Probable Root Cause is diagnosed, the Incident Client may resolve the network incident. The Incident Client may choose to resolve the network incident by invoking other functions, such as routing calculation function, configuration function, dispatching a ticket or asking the server to resolve it. Generally, the Incident Client would attempt to directly resolve the Probable Root Cause. If the Probable Root Cause cannot be resolved, an alternative solution SHOULD be sought. For example, if a network incident caused by a physical component failure and cannot be automatically resolved, the standby link can be used to bypass the faulty component.¶
Incident Server monitors the status of the network incident, if the faults are fixed, the Incident Server will update the status of network incident to 'cleared', and report the updated network incident to the client. Please refer to Section 6.2 for the Incident Lifecycle and its status.¶
Network incident resolution may affect the running network services. The client can choose not to perform those operations based on operator's policy after determining the impact is not trivial.¶
An 'incident-no' is used as an identifier of an incident instance, if an incident instance is identified, a new 'incident-no' is created. The 'incident-no' MUST be unique in the whole system.¶
The network incident model clearly separates network incident instance lifecycle from operator incident lifecycle:¶
Network incident instance lifecycle: The network incident instrumentation that controls whether a network incident is 'raised', 'updated', or 'cleared'.¶
Operator incident lifecycle: Operators acting upon the network incident with RPCs like 'incident-acknowledge', 'incident-diagnose' and 'incident-resolve'.¶
From a network incident instance perspective, a network incident can have the following lifecycle: 'raised', 'updated', 'cleared'. When a network incident instance is first generated, the status is 'raised'. If the status changes after the network incident instance is generated, (for example, self-diagnosis, diagnosis command issued by the client, or any other condition causes the status to change but does not reach the 'cleared' level) , the status changes to 'updated'. When a network incident is successfully resolved, the status changes to 'cleared'.¶
Operators can act upon network incident with network incident RPCs. From an operator perspective, the lifecycle of a network incident instance includes 'acknowledged', 'diagnosed', and 'resolved'.¶
When a network incident instance is generated, the operator SHOULD acknowledge the network incident with 'incident-acknowledge' RPC. And then the operator attempts to diagnose the network incident with 'incident-diagnose' PRC (for example, find out the Probable Root Cause and affected components). Diagnosis is not mandatory. If the Probable Root Cause and affected components are known when the network incident is generated, diagnosis is not required. After locating the Probable Root Cause and affected components, operator can try to resolve the network incident by invoking 'incident-resolve' RPC.¶
There is one YANG module in the "ietf-incident" model, which defines technology independent abstraction of network incident construct for alarm, log, performance metrics, etc. The information reported in the network incident include Probable Root Cause, priority, impact, suggestion, etc.¶
At the top of "ietf-incident" module is the Network Incident. Network incident is represented as a list and indexed by "name type incident-qualifier". Each Network Incident is associated with a network service instance, domain and sources. Under sources, there is one or more sources. Each source corresponds to a node defined in the network topology model and network resource in the network device, e.g., interface. In addition, "ietf-incident" supports one general notification to report network incident state changes and three RPCs to manage the network incidents.¶
=============== NOTE: '\' line wrapping per RFC 8792 ================
module: ietf-incident
+--ro incidents
+--ro incident* [name type incident-qualifier]
+--ro incident-no uint64
+--ro name string
+--ro type identityref
+--ro incident-qualifier string
+--ro service-instance* string
+--ro domain identityref
+--ro priority incident-priority
+--ro status? enumeration
+--ro ack-status? enumeration
+--ro category identityref
+--ro detail? string
+--ro resolve-advice? string
+--ro sources
| +--ro source* [node-ref]
| +--ro node-ref -> /nw:networks/network[nw:\
network-id=current()/../network-ref]/node/node-id
| +--ro network-ref? -> /nw:networks/network/network-id
| +--ro resource* [name]
| +--ro name al:resource
+--ro probable-causes
| +--ro probable-cause* [node-ref]
| +--ro node-ref -> /nw:networks/network[nw:\
network-id=current()/../network-ref]/node/node-id
| +--ro network-ref? -> /nw:networks/network/network-id
| +--ro resource* [name]
| | +--ro name al:resource
| | +--ro cause-name? string
| | +--ro detail? string
| +--ro cause-name? string
| +--ro detail? string
+--ro probable-events
| +--ro probable-event* [type event-id]
| +--ro type -> ../../../events/event/type
| +--ro event-id -> ../../../events/event[type = \
current()/../type]/event-id
+--ro events
| +--ro event* [type event-id]
| +--ro type identityref
| +--ro event-id string
| +--ro (event-type-info)?
| +--:(alarm)
| | +--ro alarm
| | +--ro resource? -> /al:alarms/\
alarm-list/alarm/resource
| | +--ro alarm-type-id? -> /al:alarms/\
alarm-list/alarm[al:resource = current()/../resource]/alarm-type-id
| | +--ro alarm-type-qualifier? -> /al:alarms/\
alarm-list/alarm[al:resource = current()/../resource][al:alarm-type-\
id = current()/../alarm-type-id]/al:alarm-type-qualifier
| +--:(metric)
| | +--ro metric
| | +--ro resource? al:resource
| | +--ro metric-name? string
| | +--ro threshold-value? decimal64
| | +--ro observed-value? decimal64
| +--:(notification)
| +--ro notification
| +--ro event-time? yang:date-and-time
| +--ro hostname? inet:host
| +--ro sequence-number? yang:counter32
+--ro raise-time? yang:date-and-time
+--ro occur-time? yang:date-and-time
+--ro clear-time? yang:date-and-time
+--ro ack-time? yang:date-and-time
+--ro last-updated? yang:date-and-time
rpcs:
+---x incident-acknowledge
| +---w input
| +---w incident-no* incident-ref
+---x incident-diagnose
| +---w input
| +---w incident-no* incident-ref
+---x incident-resolve
+---w input
+---w incident-no* incident-ref
notifications:
+---n incident-notification
+--ro incident-no incident-ref
+--ro name? string
+--ro type? identityref
+--ro incident-qualifier? string
+--ro service-instance* string
+--ro domain identityref
+--ro priority incident-priority
+--ro status? enumeration
+--ro ack-status? enumeration
+--ro category identityref
+--ro detail? string
+--ro resolve-advice? string
+--ro sources
| +--ro source* [node-ref]
| +--ro node-ref -> /nw:networks/network[nw:network\
-id=current()/../network-ref]/node/node-id
| +--ro network-ref? -> /nw:networks/network/network-id
| +--ro resource* [name]
| +--ro name al:resource
+--ro probable-causes
| +--ro probable-cause* [node-ref]
| +--ro node-ref -> /nw:networks/network[nw:network\
-id=current()/../network-ref]/node/node-id
| +--ro network-ref? -> /nw:networks/network/network-id
| +--ro resource* [name]
| | +--ro name al:resource
| | +--ro cause-name? string
| | +--ro detail? string
| +--ro cause-name? string
| +--ro detail? string
+--ro probable-events
| +--ro probable-event* [type event-id]
| +--ro type -> ../../../events/event/type
| +--ro event-id -> ../../../events/event[type = \
current()/../type]/event-id
+--ro events
| +--ro event* [type event-id]
| +--ro type identityref
| +--ro event-id string
| +--ro (event-type-info)?
| +--:(alarm)
| | +--ro alarm
| | +--ro resource? -> /al:alarms/\
alarm-list/alarm/resource
| | +--ro alarm-type-id? -> /al:alarms/\
alarm-list/alarm[al:resource = current()/../resource]/alarm-type-id
| | +--ro alarm-type-qualifier? -> /al:alarms/\
alarm-list/alarm[al:resource = current()/../resource][al:alarm-type-\
id = current()/../alarm-type-id]/al:alarm-type-qualifier
| +--:(metric)
| | +--ro metric
| | +--ro resource? al:resource
| | +--ro metric-name? string
| | +--ro threshold-value? decimal64
| | +--ro observed-value? decimal64
| +--:(notification)
| +--ro notification
| +--ro event-time? yang:date-and-time
| +--ro hostname? inet:host
| +--ro sequence-number? yang:counter32
+--ro time? yang:date-and-time
notifications:
+---n incident-notification
+--ro incident-no incident-ref
+--ro name? string
+--ro type? identityref
+--ro incident-qualifier? string
+--ro service-instance* string
+--ro domain identityref
+--ro priority incident-priority
+--ro status? enumeration
+--ro ack-status? enumeration
+--ro category identityref
+--ro detail? string
+--ro resolve-advice? string
+--ro sources
| +--ro source* [node-ref]
| +--ro node-ref leafref
| +--ro network-ref? leafref
| +--ro resource* [name]
| +--ro name al:resource
+--ro probable-causes
| +--ro probable-cause* [node-ref]
| +--ro node-ref leafref
| +--ro network-ref? leafref
| +--ro resource* [name]
| | +--ro name al:resource
| | +--ro cause-name? string
| | +--ro detail? string
| +--ro cause-name? string
| +--ro detail? string
+--ro probable-events
| +--ro probable-event* [type event-id]
| +--ro type leafref
| +--ro event-id leafref
+--ro events
| +--ro event* [type event-id]
| +--ro type identityref
| +--ro event-id string
| +--ro (event-type-info)?
| +--:(alarm)
| | +--ro alarm
| | +--ro resource? leafref
| | +--ro alarm-type-id? leafref
| | +--ro alarm-type-qualifier? leafref
| +--:(metric)
| | +--ro metric
| | +--ro resource? al:resource
| | +--ro metric-name? string
| | +--ro threshold-value? decimal64
| | +--ro observed-value? decimal64
| +--:(notification)
| +--ro notification
| +--ro event-time? yang:date-and-time
| +--ro hostname? inet:host
| +--ro sequence-number? yang:counter32
+--ro time? yang:date-and-time
¶
A general notification, "incident-notification", is provided here. When a network incident instance is identified, the notification is sent from the incident server to the incident client . After a notification is generated, if the incident server performs self diagnosis or the Incident Client uses the interfaces provided by the Incident Server to deliver diagnosis and resolution actions, the notification update behavior is triggered, for example, the Probable Root Cause objects and affected objects are updated. When a network incident is successfully resolved, the status of the network incident would be set to 'cleared'.¶
rpcs: +---x incident-acknowledge | +---w input | | +---w incident-no* incident-ref¶
After an incident is generated, updated, or cleared, the operator confirms the incident to ensure that the client knows the incident.¶
In some scenarios where automatic diagnosis and resolution are supported, the status of an incident may be updated multiple times or even automatically resolved. Therefore the 'incident-acknowledge' RPC can confirm multiple incidents at a time.¶
rpcs: +---x incident-diagnose | +---w input | | +---w incident-no* incident-ref¶
After a network incident is generated, 'incident-diagnose' RPC can be used to diagnose the network incident and locate the Probable Root Causes. On-demand Diagnosis can be performed on some detection tasks, such as bfd detection, flow detection, telemetry collection, short-term threshold alarm, configuration error check, or test packet injection.¶
After the on-demand diagnosis is performed successfully, a separate network incident update notification will be triggered to report the latest status of the network incident asynchronously.¶
rpcs: +---x incident-resolve +---w input | +---w incident-no* incident-ref¶
After the Probable Root Causes and impacts are determined, incident-resolve RPC can be used to resolve the incident (if the server can resolve it). How to resolve an incident instance is out of the scope of this document.¶
'incident-resolve' RPC allows multiple network incident instances to be resolved at a time. If a network incident instance is successfully resolved, a separate notification is triggered to update the network incident status to 'cleared'. If the network incident content is changed during this process, a notification update will be triggered.¶
If the RPC fails, the RPC error response MUST indicate the reason for the failure. The structures defined in this document MUST encode specific errors and be inserted in the error response to indicate the reason for the failure.¶
The tree diagram [RFC8340] for structures is defined as follows:¶
structure incident-acknowledge-error-info:
+-- incident-acknowledge-error-info
+-- incident-no? uint64
+-- reason? identityref
+-- description? string
structure incident-diagnose-error-info:
+-- incident-diagnose-error-info
+-- incident-no? uint64
+-- reason? identityref
+-- description? string
structure incident-resolve-error-info:
+-- incident-resolve-error-info
+-- incident-no? uint64
+-- reason? identityref
+-- description? string
¶
Valid errors that can occur for each structure defined in this document are described as follows:¶
incident-acknowledge-error-info ----------------------------------- repeated-acknowledge incident-not-found incident-diagnose-error-info ----------------------------------- probable-cause-unlocated permission-denied operation-timeout resource-unavailable incident-not-found incident-resolve-error-info ----------------------------------- probable-cause-unresolved permission-denied operation-timeout resource-unavailable incident-not-found¶
This module imports types from [RFC9911], [RFC8632], [RFC8345], [RFC8791] and uses types defined in [RFC9376], [RFC1136], [RFC6373], [RFC8348], [RFC8632], [RFC5277], [RFC9940], [RFC9375], [RFC5277], [RFC8639], [RFC8641], [I-D.ietf-netconf-notif-envelope].¶
<CODE BEGINS> file "ietf-incident@2026-07-30.yang"
module ietf-incident {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-incident";
prefix inc;
import ietf-yang-types {
prefix yang;
reference
"RFC 9911: Common YANG Data Types, Section 3";
}
import ietf-inet-types {
prefix inet;
reference
"RFC 9911: Common YANG Data Types, Section 4";
}
import ietf-alarms {
prefix al;
reference
"RFC 8632: A YANG Data Model for Alarm Management";
}
import ietf-network {
prefix nw;
reference
"RFC 8345: A YANG Data Model for Network Topologies";
}
import ietf-yang-structure-ext {
prefix sx;
reference
"RFC 8791: YANG Data Structure Extensions";
}
organization
"IETF NMOP Working Group";
contact
"WG Web: https://datatracker.ietf.org/wg/nmop/;
WG List: NMOP <mailto:nmop@ietf.org>
Author: Chong Feng
<mailto:fengchongllly@gmail.com>
Author: Tong Hu
<mailto:hutong@cmhi.chinamobile.com>
Author: Luis Miguel Contreras Murillo
<mailto:luismiguel.contrerasmurillo@telefonica.com>
Author: Qin Wu
<mailto:bill.wu@huawei.com>
Author: Nigel Davis
<mailto:ndavis@ciena.com>";
description
"This module defines the interfaces for incident management
lifecycle.
This module is intended for the following use cases:
* incident lifecycle management:
- incident report: report incident instance to client
when an incident instance is detected.
- incident acknowledge: acknowledge an incident instance.
- incident diagnose: diagnose an incident instance.
- incident resolve: resolve an incident instance.
Copyright (c) 2026 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).
All revisions of IETF and IANA published modules can be found
at the YANG Parameters registry group
(https://www.iana.org/assignments/yang-parameters).
This version of this YANG module is part of RFC XXXX; see
the RFC itself for full legal notices.
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 (RFC 2119) (RFC 8174) when, and only when,
they appear in all capitals, as shown here.";
revision 2026-07-30 {
description
"Initial version.";
reference
"RFC XXXX: A YANG Data Model for Network Incident Management.";
}
// Identities
identity incident-domain {
description
"The base identity to indicate the domain of
an incident.";
}
identity single-domain {
base incident-domain;
description
"Indicates single domain.";
}
identity access {
base single-domain;
description
"Indicates access domain.";
}
identity ran {
base access;
description
"Indicates a radio access network domain.";
}
identity transport {
base single-domain;
description
"Indicates a transport domain.";
}
identity otn {
base transport;
description
"Indicates an optical transport network domain.";
reference
"RFC 9376: Applicability of GMPLS for beyond 100 Gbit/s Optical
Transport Network";
}
identity ip {
base single-domain;
description
"Indicates an IP domain.";
reference
"RFC 1136: Administrative Domains and Routing Domains A Model
for Routing in the Internet";
}
identity ptn {
base ip;
description
"Indicates a packet transport network domain.";
reference
"RFC 6373: MPLS Transport Profile (MPLS-TP) Control Plane
Framework";
}
identity cross-domain {
base incident-domain;
description
"Indicates a cross domain.";
}
identity incident-category {
description
"The abstract identity for incident category.";
}
identity device {
base incident-category;
description
"Device category.";
reference
"RFC 8348: A YANG Data Model for Hardware Management";
}
identity power-environment {
base device;
description
"Power environment category.";
reference
"RFC 8348: A YANG Data Model for Hardware Management";
}
identity device-hardware {
base device;
description
"Device hardware category.";
reference
"RFC 8348: A YANG Data Model for Hardware Management";
}
identity device-software {
base device;
description
"Device software category.";
reference
"RFC 8348: A YANG Data Model for Hardware Management";
}
identity line-card {
base device-hardware;
description
"Line card category.";
reference
"RFC 8348: A YANG Data Model for Hardware Management";
}
identity maintenance {
base incident-category;
description
"Maintenance category.";
}
identity network {
base incident-category;
description
"Network category.";
}
identity protocol {
base incident-category;
description
"Protocol category.";
}
identity overlay {
base incident-category;
description
"Overlay category.";
}
identity vm {
base incident-category;
description
"Virtual Machine category.";
}
identity event-type {
description
"The abstract identity for Event type.";
reference
"RFC 9940: Some Key Terms for Network Fault and Problem
Management";
}
identity alarm {
base event-type;
description
"Alarm event type.";
reference
"RFC 8632: A YANG Data Model for Alarm Management";
}
identity notif {
base event-type;
description
"Notification event type.";
reference
"RFC 5277: NETCONF Event Notifications and
RFC 8639: Subscription to YANG Notifications and
RFC 8641: Subscription to YANG Notifications for
Datastore Updates and
I-D.ietf-netconf-notif-envelope: Extensible YANG
Model for YANG-Push Notifications";
}
identity metric {
base event-type;
description
"Metric event type.";
reference
"RFC 9375: A YANG Data Model for Network and VPN
Service Performance Monitoring";
}
identity unknown {
base event-type;
description
"Unknown event type.";
}
identity incident-type {
description
"The abstract identity for Incident type.";
}
identity problem {
base incident-type;
description
"It indicates the class of the incident is a problem
(i.e., cause of the incident) for example an interface
fails to work.";
reference
"RFC 9940: Some Key Terms for Network Fault and Problem
Management";
}
identity sla-violation {
base incident-type;
description
"It indicates the class of the incident is an SLA
violation, for example high CPU rate may cause
a fault in the future.";
}
identity acknowledge-error {
description
"Base identity for the problem found while attempting
to fulfill an 'incident-acknowledge' RPC request.";
}
identity diagnose-error {
description
"Base identity for the problem found while attempting
to fulfill an 'incident-diagnose' RPC request.";
}
identity resolve-error {
description
"Base identity for the problem found while attempting
to fulfill an 'incident-resolve' RPC request.";
}
identity repeated-acknowledge {
base acknowledge-error;
description
"The incident referred to has already been acknowledged.";
}
identity incident-not-found {
base acknowledge-error;
base diagnose-error;
base resolve-error;
description
"The incident is triggered when the incident does not
exist in the datastore and a Client performs the RPCs.";
}
identity probable-cause-unlocated {
base diagnose-error;
description
"Fail to locate the Probable Root Causes when performing the
diagnosis operation. The detailed reason MUST be included
in the 'description'.";
}
identity probable-cause-unresolved {
base resolve-error;
description
"Fail to resolve the Probable Root Causes when performing the
resolution operation. The detailed reason MUST be included
in the 'description'.";
}
identity permission-denied {
base diagnose-error;
base resolve-error;
description
"The permission required for performing specific
detection/resolution task is not granted.";
}
identity operation-timeout {
base diagnose-error;
base resolve-error;
description
"The diagnosis/resolution time exceeds the preset time.";
}
identity resource-unavailable {
base diagnose-error;
base resolve-error;
description
"The resource is unavailable to perform
the diagnosis/resolution operation.";
}
// Typedefs
typedef incident-priority {
type enumeration {
enum critical {
description
"The 'critical' priority level indicates that a service-
affecting condition has occurred and an immediate
corrective action is required. Such a priority can be
reported, for example, when a resource becomes totally out
of service and its capability must be restored.";
}
enum high {
description
"The 'high' priority level indicates that a service-
affecting condition has developed and an urgent corrective
action is required. Such a priority can be reported, for
example, when there is a severe degradation in the
capability of the resource and its full capability must be
restored.";
}
enum medium {
description
"The 'medium' severity level indicates the existence of a
non-service-affecting fault condition and that corrective
action should be taken in order to prevent a more serious
(for example, service-affecting) fault. Such a priority
can be reported, for example, when the detected alarm
condition is not currently degrading the capacity of the
resource.";
}
enum low {
description
"The 'low' priority level indicates the detection of a
potential or impending service-affecting fault, before any
significant effects have been felt. Action should be
taken to further diagnose (if necessary) and correct the
problem in order to prevent it from becoming a more
serious service-affecting fault.";
}
}
description
"Defines the priority of incident.";
}
typedef incident-ref {
type leafref {
path "/inc:incidents/inc:incident/inc:incident-no";
require-instance false;
}
description
"Provides a reference to a network incident using incident-no
note that incident no is unique but not incident list key.
The incident-ref is used for correlation between incident no
and incident list key in the RPCs and Notification.";
}
// Groupings
grouping probable-cause-info {
description
"The information of Probable Root Cause.";
leaf cause-name {
type string;
description
"Specifies the cause name.";
}
leaf detail {
type string;
description
"The detail information of the cause.";
}
}
grouping resources-info {
description
"The grouping which defines the network
resources of a node.";
uses nw:node-ref;
list resource {
key "name";
description
"The resources of a network node.";
leaf name {
type al:resource;
description
"Network resource name.";
}
}
}
grouping incident-time-info {
description
"The grouping defines incident time information.";
leaf raise-time {
type yang:date-and-time;
description
"The time when an incident instance is raised.";
}
leaf occur-time {
type yang:date-and-time;
mandatory true;
description
"The time when an incident instance occurs.
It's the occur time of the first event during
incident detection.";
}
leaf clear-time {
type yang:date-and-time;
description
"The time when an incident instance is
resolved.";
}
leaf ack-time {
type yang:date-and-time;
description
"The time when an incident instance is
acknowledged.";
}
leaf last-updated {
type yang:date-and-time;
description
"The latest time when an incident instance is
updated.";
}
}
grouping incident-info {
description
"The grouping defines the information of an
incident.";
leaf name {
type string;
description
"The name of an incident.";
}
leaf type {
type identityref {
base incident-type;
}
description
"The type of an incident.";
}
leaf incident-qualifier {
type string;
description
"The unique qualifier of an incident instance type.
This leaf is used when the 'type' leaf cannot
uniquely identify the incident instance type. Normally,
this is not the case, and this leaf is the empty
string.";
}
leaf-list service-instance {
type string;
description
"The related network service instances of
the incident instance.";
}
leaf domain {
type identityref {
base incident-domain;
}
mandatory true;
description
"The domain of an incident.";
}
leaf priority {
type incident-priority;
mandatory true;
description
"The priority of an incident instance.";
}
leaf status {
type enumeration {
enum raised {
description
"An incident instance is raised.";
}
enum updated {
description
"The information of an incident instance
is updated.";
}
enum cleared {
description
"An incident is cleared.";
}
}
description
"The status of an incident instance.";
}
leaf ack-status {
type enumeration {
enum acknowledged {
description
"The incident has been acknowledged by user.";
}
enum unacknowledged {
description
"The incident hasn't been acknowledged.";
}
}
description
"The acknowledge status of an incident.";
}
leaf category {
type identityref {
base incident-category;
}
mandatory true;
description
"The category of an incident.";
}
leaf detail {
type string;
description
"Detailed information of this incident.";
}
leaf resolve-advice {
type string;
description
"The advice to resolve this incident.";
}
container sources {
description
"The source components.";
list source {
key "node-ref";
min-elements 0;
description
"The source components of incident. An Incident might
be created even if we don't know yet the sources
(hence we can not populate source list in the sources
container). Therefore the min-elements for the source
list is set to 0. Once the Incident is diagnosed, the
source(s) will be populated.";
uses resources-info;
}
}
container probable-causes {
description
"The Probable Root Cause objects.";
list probable-cause {
key "node-ref";
description
"The Probable Root Causes of incident.";
uses resources-info {
augment "resource" {
description
"Augment Probable Root Cause information.";
//if Probable Root Cause object is a resource of a node
uses probable-cause-info;
}
}
//if Probable Root Cause object is a node
uses probable-cause-info;
}
}
container probable-events {
description
"The Probable Root Cause related events of the incident.";
list probable-event {
key "type event-id";
description
"The Probable Root Cause related event of the incident.";
leaf type {
type leafref {
path "../../../events/event/type";
}
description
"The event type.";
}
leaf event-id {
type leafref {
path "../../../events/event[type = current()/../type]"
+ "/event-id";
}
description
"The event identifier, such as uuid,
sequence number, etc.";
}
}
}
container events {
description
"Related events.";
list event {
key "type event-id";
description
"Related events.";
leaf type {
type identityref {
base event-type;
}
description
"Event type.";
}
leaf event-id {
type string;
description
"The event identifier, such as uuid,
sequence number, etc.";
}
choice event-type-info {
description
"Various different event type information.";
case alarm {
when "derived-from-or-self(type, 'alarm')" {
description
"Only applies when type is alarm.";
}
container alarm {
description
"Alarm type event.";
leaf resource {
type leafref {
path "/al:alarms/al:alarm-list/al:alarm"
+ "/al:resource";
require-instance false;
}
description
"This is an identification of the alarming
resource.";
reference
"RFC 8632: A YANG Data Model for Alarm
Management";
}
leaf alarm-type-id {
type leafref {
path "/al:alarms/al:alarm-list/al:alarm"
+ "[al:resource = current()/../resource]"
+ "/al:alarm-type-id";
require-instance false;
}
description
"Alarm type id.";
reference
"RFC 8632: A YANG Data Model for Alarm
Management";
}
leaf alarm-type-qualifier {
type leafref {
path "/al:alarms/al:alarm-list/al:alarm"
+ "[al:resource = current()/../resource]"
+ "[al:alarm-type-id = current()/.."
+ "/alarm-type-id]/al:alarm-type-qualifier";
require-instance false;
}
description
"Alarm type qualifier.";
reference
"RFC 8632: A YANG Data Model for Alarm
Management";
}
}
}
case metric {
when "derived-from-or-self(type, 'metric')" {
description
"Only applies when type is metric.";
}
container metric {
description
"Metric type event. Performance metrics
exceeding SLO thresholds.";
leaf resource {
type al:resource;
description
"This is an identification of the network
resource such as interface, where the metric
can be collected or measured.";
reference
"RFC 8632: A YANG Data Model for Alarm
Management";
}
leaf metric-name {
type string;
description
"Metric Name.";
}
leaf threshold-value {
type decimal64 {
fraction-digits 2;
}
description
"Threshold value for the specific metric.";
}
leaf observed-value {
type decimal64 {
fraction-digits 2;
}
description
"Observed value for the specific metric.";
}
}
}
case notification {
when "derived-from-or-self(type, 'notif')" {
description
"Only applies when type is notification.";
}
container notification {
description
"Notification type event.";
leaf event-time {
type yang:date-and-time;
description
"The date and time the event was generated by
the network node.";
reference
"I-D.ietf-netconf-notif-envelope: Extensible YANG
Model for YANG-Push Notifications";
}
leaf hostname {
type inet:host;
description
"The hostname of the network node. This value
is usually configured on the node by the
administrator to identify the node in the
network uniquely.";
reference
"I-D.ietf-netconf-notif-envelope: Extensible YANG
Model for YANG-Push Notifications";
}
leaf sequence-number {
type yang:counter32;
description
"Unique sequence number for each published
message by the publisher process. The initial
number is 1 and counts up by 1 at every
published notification message until it reaches
4294967295. Then, it wraps around and restarts
at 0. The value 0 is used to detect wrap
arounds.";
reference
"I-D.ietf-netconf-notif-envelope: Extensible YANG
Model for YANG-Push Notifications";
}
anydata contents {
description
"This contains the values defined by the
'notification' statement unchanged.";
}
}
}
}
}
}
}
// RPCs
rpc incident-acknowledge {
description
"This rpc can be used to acknowledge the specified
incidents.";
input {
leaf-list incident-no {
type incident-ref;
min-elements 1;
description
"The unique number of an incident instance
based on the incident-no which is corresponding
to the name type incident-id keys.";
}
}
}
rpc incident-diagnose {
description
"This rpc can be used to diagnose the specified
incidents. The result of diagnosis will be reported
by incident notification.";
input {
leaf-list incident-no {
type incident-ref;
min-elements 1;
description
"The unique number of an incident instance
based on the incident-no which is corresponding
to the name type incident-id keys.";
}
}
}
rpc incident-resolve {
description
"This rpc can be used to resolve the specified
incidents. The result of resolution will be reported
by incident notification.";
input {
leaf-list incident-no {
type incident-ref;
min-elements 1;
description
"The unique number of an incident instance
based on the incident-no which is corresponding
to the name type incident-id keys.";
}
}
}
sx:structure incident-acknowledge-error-info {
container incident-acknowledge-error-info {
description
"This structure data must be inserted in the RPC error
response to indicate the reason for the
incident acknowledge failure.";
leaf incident-no {
type uint64;
description
"Indicate the incident instance identifier that
fails the operation.";
}
leaf reason {
type identityref {
base acknowledge-error;
}
description
"Indicates the reason why the operation
is failed.";
}
leaf description {
type string;
description
"Indicates the detailed description about
the failure.";
}
}
}
sx:structure incident-diagnose-error-info {
container incident-diagnose-error-info {
description
"This structure data must be inserted in
the RPC error response to indicate the
reason for the incident diagnose failure.";
leaf incident-no {
type uint64;
description
"Indicate the incident instance identifier that
fails the operation.";
}
leaf reason {
type identityref {
base diagnose-error;
}
description
"Indicates the reason why the operation
is failed.";
}
leaf description {
type string;
description
"Indicates the detailed description about
the failure.";
}
}
}
sx:structure incident-resolve-error-info {
container incident-resolve-error-info {
description
"This structure data must be inserted in
the RPC error response to indicate the
reason for the incident resolution failure.";
leaf incident-no {
type uint64;
description
"Indicate the incident instance identifier that
fails the operation.";
}
leaf reason {
type identityref {
base resolve-error;
}
description
"Indicates the reason why the operation is failed.";
}
leaf description {
type string;
description
"Indicates the detailed description about the failure.";
}
}
}
// Notifications
notification incident-notification {
description
"Incident notification. It will be triggered when
the incident is raised, updated or cleared.";
leaf incident-no {
type incident-ref;
mandatory true;
description
"The identifier of an incident instance. With incident-no
used in both incident-notification and RPCs, an Incident
Client know which notification is the result of a given
RPC.";
}
uses incident-info;
leaf time {
type yang:date-and-time;
description
" The time when an incident instance occurs.
It is the occur time of the first event during
incident detection.";
}
}
// Data definitions
container incidents {
config false;
description
"The information of incidents.";
list incident {
key "name type incident-qualifier";
unique "incident-no";
description
"The information of incident.";
leaf incident-no {
type uint64;
mandatory true;
description
"The unique identifier of the incident
instance based on the name type incident-qualifier keys.";
}
uses incident-info;
uses incident-time-info;
}
}
}
<CODE ENDS>¶
The "ietf-incident" YANG module introduces an incident-centric architecture designed to overcome the structural silo of management systems that handle alarms and performance metrics separately at different network layers. Operators need to ensure that the underlying management system feeding this model maintains continuous, real-time read access to diverse end to end network topology data spanning multiple layers.¶
Because accurate multi-layer troubleshooting depends on establishing a global view of cross-layer dependency relationships, any disruption or stale state in the underlying network topology discovery mechanisms will directly degrade the accuracy of the Incident Process's probable root cause identification and service impact analysis.¶
In addition, the YANG module defined in this document is intended to automate and streamline incident dispatching at the network layer so that integration with trouble-ticketing management system at the OSS layer is required. Operators should implement a deterministic translation layer between the "ietf-incident" model states (e.g., raised, cleared, acknowledged) and external ticket states (e.g., Open, Assigned, In-Progress, Resolved) to prevent split-brain visibility scenarios where an incident is closed in the network layer but remains active in the ticketing system, or vice versa.¶
This incident data model states that the tuple (name, type and incident-qualifier) corresponds to a single incident instance. This means that incident notifications for the same name and same type and incident-qualifier are matched to update the same incident instance. These three leafs are therefore used as the key in the incident list:¶
list incident {
key "name type incident-qualifier";
...
}
¶
In the meanwhile, in order to improve processing efficiency, this incident data model also allows using the unique sequence number 'incident-no' to identify each incident instance, this means that incident RPCs or notifications for the same incident-no are matched to update the same incident instance.¶
+-----------------------------+
| OSS |
| +--------+ +-----------+ |
| |Alarm | | Incident | |
| |handler | | handler | |
| +--------+ +-----------+ |
+---^---------------^---------+
| |
|alarm |incident
+---|---------------|---------+
| | controller | |
| | | |
|+--+----+ +-----------+ |
||Alarm | | Incident | |
||process+----->| Process | |
|| |alarm | | |
|+-------+ +-----------+ |
| ^ ^ |
+---|--------------|----------+
|alarm | metrics/trace/etc.
| |
+-------+--------------+---------------+
| |
| Network in the Autonomous Domain |
| |
+--------------------------------------+
A YANG model for the alarm management [RFC8632] defines a standard interface to manage the lifecycle of alarms. Alarms represent the undesirable state of network resources [RFC9940], The alarm data model also defines the Probable Root Causes and impacted services fields, but there may be insufficient information to determine them at lower layer system (mainly in devices level), so alarms do not always tell the status of network services or necessarily point to the Probable Root Causes of problems. As described in [RFC8632], the alarm management acts as a starting point for high-level fault management. While Network Incident Management often works at the network level, so it is possible to have enough information to perform data correlation and Service Impact Assessment. Alarms can work as one of data sources of Network Incident Management and may be aggregated into a few network incidents by the correlation analysis, network service impact and Probable Root Causes may be determined during the Incident Process.¶
Network Incident also contains some related alarms, if needed users can query the information of alarms by alarm management interface [RFC8632]. In some cases, e.g., cutover scenario, the Incident Server may use alarm management interface [RFC8632] to shelve some alarms.¶
Alarm management may keep the original process, alarms are reported from network to network controller or network analytic platform and then reported to upper-layer system (e.g., the alarm handler within the OSS).¶
Similarly, the network incident is reported from the network to the network controller or network analytic platform and then reported to the upper-layer system (e.g., Incident Handler within the OSS). Upper-layer system may store these network incidents and provide the information for fault analysis (e.g., deeper customer incident analysis based on network incident).¶
Different from alarm management, Incident Process within the controller comprising both Incident Client and Incident Server functionalities provides not only network incident reporting but also diagnosis and resolution functions, it's possible to support self-healing and may be helpful for single-domain closed-loop control.¶
Network Incident Management is not a substitute for alarm management. Instead, they can work together to implement fault management.¶
SAIN [RFC9417] defines an architecture of network service assurance.¶
+----------------+
|Incident Handler|
+----------------+
^
|incident
+-------+--------+
|Incident Process|
+----------------+
^
|symptoms
+-------+--------+
| SAIN |
| |
+----------------+
^
|metrics
+---------------+-----------------+
| |
|Network in the Autonomous Domain |
| |
+---------------------------------+
A network service can be decomposed into some sub-services, and specific metrics can be monitored for sub-services. For example, a tunnel service can be decomposed into some peer tunnel interface sub- services and IP connectivity sub-service. If some metrics are evaluated to indicate unhealthy for specific sub-service, some symptoms will be present. Incident Process comprising both Incident Client and Incident Server functionalities may identify the network incident based on symptoms, and then report it to Incident Handler within the Operation Support System (OSS). So, SAIN can be one way to identify network incident, services, sub-services and metrics can be preconfigured via APIs defined by service assurance YANG model [RFC9418] and the network incident will be reported if symptoms match certain condition or characteristic considered as an indication of a problem or potential problem.¶
[RFC8969] defines a framework for network automation using YANG, this framework breaks down YANG modules into three layers, service layer, network layer and device layer, and contains service deployment, service optimization/assurance, and service diagnosis. Network incident works at the network layer and aggregates alarms, metrics and other information from device layer, it's helpful to provide service assurance. And the network incident diagnosis may be one way of service diagnosis.¶
W3C defines a common trace context [W3C-Trace-Context] for distributed system tracing, [I-D.ietf-netconf-trace-ctx-extension] defines a netconf extension for [W3C-Trace-Context] and [I-D.ietf-netconf-configuration-tracing] defines a mechanism for configuration tracing. If some errors occur when services are deploying, it's very easy to identify these errors by distributed system tracing, and a network incident SHOULD be reported.¶
[I-D.ietf-nmop-network-anomaly-architecture] and related network anomaly detection documents describe how anomaly detection is applied to detect service interruption in IP networks by performing outlier detection on all 3 network planes, preserve relationships among them and score the result with a concern and with a confidence score. Section 3 of [I-D.ietf-nmop-network-anomaly-architecture] describes the elements of the system architecture where the "Alarm Management System" maps to the "Incident Server" in Section 4 of this document. The "relevant-state" YANG notification defined in Section 8.2 of [I-D.ietf-nmop-network-anomaly-lifecycle] defines an "id" which SHOULD be mapped to "event-id" in the 'ietf-incident' YANG module described in this document on the "Incident Server". [I-D.ietf-nmop-network-anomaly-semantics] augments relevant-state YANG notification with 'ietf-network-anomaly-symptom' YANG module symptom semantics described in Section 4.2 and service and network relationships with 'ietf-network-anomaly-service-topology' YANG module in Section 4.3. "hostname" in "vpn-node-termination" grouping of 'ietf-network-anomaly-service-topology' YANG module maps to "node-ref" in "node-ref" grouping respectively the "vpn-id" in the "vpn-service" list of the "vpn-service" grouping maps to the "service-instance" leaf-list of the "incident-info" grouping in 'ietf-incident' YANG module. Thus, preserving the mapping between relevant-state notification id, service id and hostname in the network where the outlier was detected.¶
This section records the status of known implementations of the YANG module defined by this specification at the time of posting of this document and is based on a proposal described in [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and MUST NOT be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶
According to [RFC7942], "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶
Note to the RFC Editor: As per [RFC7942] guidelines, please remove this Implementation Status Section prior to publication.¶
Huawei iMaster NCE has implemented incident model with the intent management framework and AI tools to support intelligent Network Incident Management.¶
The Huawei Implementation of Incident model covers the following a) RESTCONF support b) Incident Lifecycle management including incident instance lifecycle and operator incident lifecycle. c) Incident Notification¶
Contact information: Qin Wu (bill.wu@huawei.com)¶
The YANG module specified in this document defines a data model that is designed to be accessed via YANG-based management protocols, such as NETCONF [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) MUST use a secure transport layer (e.g., SSH Transport Layer [RFC4253]) and (2) MUST use mutual authentication (e.g., SSH [RFC4252], TLS [RFC8446], and QUIC [RFC9000]).¶
The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.¶
Some of the readable data nodes in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:¶
'/incidents/incident': This list specifies the network incident entries, such as the service-instance leaf-list and the sources/probable-causes containers may reveal customer-identifiable information (e.g., which VPN services are affected, which customer endpoints are involved). Unauthorized read access of this list can allow intruders to access network incident information and potentially get a picture of the broken state of the network. Intruders may exploit the vulnerabilities of the network to lead to further negative impact on the network. Care must be taken to ensure that this list is accessed only by authorized users.¶
Some of the RPC operations in this YANG module may be considered sensitive or vulnerable in some network environments. It is thus important to control access to these operations. These are the operations and their sensitivity/vulnerability:¶
"incident-diagnose": This RPC operation performs network incident diagnosis and Probable Root Cause locating. If a malicious or buggy client performs an unexpectedly large number of this operation, the result might be an excessive use of system resources [RFC9940] on the server side as well as network resources. Servers MUST ensure they have sufficient resources to fulfill this request; otherwise, they can choose to block the connection (e.g., block abusive IP address) to this client and/or reject the request using rpc errors defined in section 7.6.¶
"incident-resolve": This RPC operation is used to resolve the network incident. If a malicious or buggy client performs an unexpectedly large number of this operation, the result might be an excessive use of system resources on the server side as well as network resources. Servers MUST ensure they have sufficient resources to fulfill this request; otherwise, they can choose to reject the request without compromise on security of data-at-rest in the server.¶
"incident-acknowledge": This RPC operation is used to confirm the incident to ensure that the client knows the incident. If a malicious or buggy client repeatedly confirms multiple incidents at a time, the result might be an excessive use of system resources on the server side as well as network resources. Servers MUST ensure they have sufficient resources to fulfill this request; otherwise, they can choose to block connection (e.g., block abusive IP address) to this client and/or reject the request using rpc errors defined in section 7.6.¶
IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group [RFC3688]:¶
URI: urn:ietf:params:xml:ns:yang:ietf-incident Registrant Contact: The IESG. XML: N/A, the requested URIs are XML namespaces.¶
IANA is requested to register the following YANG module in the "YANG Module Names" registry [RFC6020] within the "YANG Parameters" registry group.¶
Name: ietf-incident Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-incident Prefix: inc Reference: RFC XXXX¶
// RFC Ed.: Replace RFC xxxx with this RFC id, when published and remove this comment¶
The authors would like to thank Mohamed Boucadair, Robert Wilton, Benoit Claise, Oscar Gonzalez de Dios, Adrian Farrel, Mahesh Jethanandani, Paul Aitken, Balazs Lengyel, Dhruv Dhody,Bo Wu, Qiufang Ma, Haomian Zheng, YuanYao, Wei Wang, Peng Liu, Zongpeng Du, Zhengqiang Li, Andrew Liu, Joe Clark, Roland Scott, Alex Huang Feng, Kai Gao, Jensen Zhang, Ziyang Xing, Mingshuang Jin, Aihua Guo, Zhidong Yin, Guoxiang Liu, Kaichun Wu for their valuable comments and great input to this work.¶
In this example, we show an example of the Incident notification in JSON encoding for the incident base model.¶
{
"example-incident-module:incident-notification": {
"incident-no": "INC-2026-98765",
"name": "Link Failure Core Router",
"type": "example-types:hardware-fault",
"incident-qualifier": "interface-down",
"service-instance": [
"srv-mpls-vpn-01",
"srv-voip-05"
],
"domain": "example-types:transport-network",
"priority": "critical",
"status": "active",
"ack-status": "unacknowledged",
"category": "example-types:network-infrastructure",
"detail": "Interface GigabitEthernet0/0/1 reports a Link Down state due\
to loss of signal.",
"resolve-advice": "Check physical fiber connections and optics transceiver\
at local node.",
"sources": {
"source": [
{
"node-ref": "router-core-01",
"network-ref": "backbone-east",
"resource": [
{
"name": "GigabitEthernet0/0/1"
}
]
}
]
},
"probable-causes": {
"probable-cause": [
{
"node-ref": "router-core-01",
"network-ref": "backbone-east",
"resource": [
{
"name": "GigabitEthernet0/0/1",
"cause-name": "example-types:los-of-signal",
"detail": "Laser rx power below operational threshold."
}
],
"cause-name": "example-types:interface-hardware-failure",
"detail": "SFP module may need replacement."
}
]
},
"probable-events": {
"probable-event": [
{
"type": "example-types:link-down-event",
"event-id": "EV-10293"
}
]
},
"events": {
"event": [
{
"type": "example-types:alarm-event",
"event-id": "AL-55443",
"alarm": {
"resource": "GigabitEthernet0/0/1",
"alarm-type-id": "link-down",
"alarm-type-qualifier": "port-failure"
}
}
]
},
"time": "2026-09-12T08:47:00Z"
}
}
¶
In this document, the incident-diagnosis RPC defined in "ietf- incident" module can be used to identify Probable Root Causes; and an incident update notification can be triggered to report the diagnosis status if successful.¶
In some cases, workflows may span a long duration or involve multiple steps task. In such case, intent based networking concept can be used to support such multiple step task and provide more detailed network diagnosis information.¶
+------------------------------------------------+
| OSS |
| +---------------------------------------+ |
| | Incident Handler | |
| +------+-----------^-----------+--------+ |
+-----------+-----------+-------------+----------+
|Diagnosis |Diagnosis |NETCONF
|Task |Task |<get-config>
|Creation |Notification |
+-----------+-----------+-------------+----------+
|Controller | | | |
| +-------V-----------------------V--------+ |
| | Incident Process | |
| +----------------------------------------+ |
+------------------------------------------------+
To do so, the new "diagnosis task creation" RPC can be further defined to support "task-id" attribute in the output parameters and other auxiliary attributes in the input parameters. such RPC can be used to return task-id from the controller. The controller is responsible for task-id allocation and maintaining task-id list.¶
+---x diagnose-task-creation
| +---w input
| | +---w incident-no? string
| | +---w ticket-no? string
| | +---w occur-time? yang:date-and-time
| | +---w context? string
| | +---w related-events
| | | +---w probable-event* []
| | | +---w type? leafref
| | | +---w event-id? leafref
| | +---w related-objects
| | +---w source* [node-ref]
| | +---w node-ref leafref
| | +---w network-ref? leafref
| | +---w resource* [name]
| | +---w name al:resource
| +--ro output
| +--ro task-id? string
¶
"ietf-incident" module can be further extended to include "incident-diagnosis-task" list with the following diagnosis information:¶
The current status (e.g., created, diagnosing, diagnosed, finished) of each diagnosis task.¶
Task start time, end time, diagnosis result (succeeded, failed), failure description, etc.¶
Probable Root Causes, probable events, repair recommendations, etc.¶
so that OSS system can use NETCONF <get-config> operation to look up the diagnosis task detailed information based on such module extension.¶
augment /inc:incidents/inc:incident:
+--ro incident-diagnosis-tasks
| +--ro incident-diagnosis-task* [task-id]
| +--ro task-id? string
| +--ro incident-no* incident-ref
| +--ro ticket-no? string
| +--ro start-time? yang:date-and-time
| +--ro end-time? yang:date-and-time
| +--ro task-state? enumeration
| +--ro diagnosis-result? enumeration
| +--ro diagnosis-result-description? string
| +--ro probable-causes leafref //List <RootCause>
...
| +--ro probable-events leafref //List <Event>
...
| +-- ro repair-advices
| +-- ro state enumeration // Incident states such as
// Creation, Update, Clear
...
¶
In addition, the new Diagnosis Task Notification can be defined to support Diagnosis Task related attributes reporting.¶
+---n task-notification
| +--ro task-id? string
| +--ro incident-no? string
| +--ro ticket-no? string
| +--ro start-time? yang:date-and-time
| +--ro end-time? yang:date-and-time
| +--ro task-state? task-state
| +--ro diagnosis-result? diagnosis-result
| +--ro diagnosis-result-description? string
| +--ro probable-causes
| | +--ro probable-cause* []
| | +--ro node-ref? leafref
| | +--ro network-ref? leafref
| | +--ro resource* [name]
| | | +--ro name al:resource
| | | +--ro cause-name? identityref
| | | +--ro detail? string
| | +--ro cause-name? identityref
| | +--ro detail? string
| +--ro probable-events
| | +--ro probable-event* []
| | +--ro type? leafref
| | +--ro event-id? leafref
| +--ro repair-advices? string
| +--ro incident-status? incident-status-value
¶
So that the controller can send diagnosis task notification to the OSS system upon diagnosis task completes and outputs repair suggestion.¶
Take multi-domain fault demarcation as an example, when both base station incident in the RAN network and Network Link incident in the IP network are received and base station incident from user side results from network incident in other domains, the OSS system is unable to find network side problem simply based on base station incident. Therefore incident diagnosis RPC will be invoked with IP address of Base station and incident start time as input and sent to the network controller. The network controller can use network diagnosis related intent based interface to find the corresponding network side port according to the base station IP address, and then further associated with transmission path (current path, historical path) to the base station and current and historical network performance, network resources, and incident status data, to diagnose the Probable Root Cause of the network incident and provide repair suggestions.¶
+------------------------------------------------+
|OSS +------------------------------------------+|
| | Incident Handler ||
| +----^------------------------^------+-----+|
+---------+------------------------|------|------+
Incident | |
| | |
Update | Incident Incident
Notification | Update Diagnosis
| | Notification |
| | |
+---------------+ | | |
| +-----------+ | | +-----|------+--+
| | Incident | | | | +---+------V+ |
| | Process | | | | | Incident | |
| +-----------+ | | | Process | |
| RAN Controller| | | +-----------+ |
+---------------+ | | IP Controller |
| +---------------+
|
RAN Autonomous Domain | IP Autonomous Domain
|
Diagnosis Key Parameters:
{
ticket-no, string
incident-no, string
occur-time, yang:date-and-time
context? string
related-events? leafref //List <Event>
related-objects? leafref //List <ResourceObject>
....
}
Customer
Complaint
| on Service
| Degradation
+-----------------V-----------------------+
|OSS +-----------------------------------+|
| | Incident Handler ||
| +------------^------^---------------+|
+-----------------+------+----------------+
Diagnosis Incident | |Incident Update
Key Parameters: Diagnosis| | Notification
{ +-----|------+--+
incident-no, | +---V------|+ |
ticket-no, | | Incident | |
occur-time, | | Process | |
context?, | | | |
related-events?, | | | |
related-objects?, | | | |
... | +-----------+ |
| IP Controller |
} +---------------+
IP Autonomous Domain
Similarly, in case of service degradation for a lease line service receiving from the customer, the OSS system can request network diagnosis at the network side conducted by the network controller. The network controller can use network diagnosis related intent based interface to find the corresponding network side port based on the dedicated line service, and then further associate the transmission path (current path, historical path) and current and historical network performance, network resources, and incident status data to diagnose the Probable Root Cause of the fault and provide repair suggestions.¶
NOTE TO THE RFC-EDITOR: Please remove this appendix before publication¶
v14 - v15¶
Replace incident-id with incident-qualifier¶
Add a new definition for the incident process¶
replace probable cause with probable root cause in the YANG model¶
Clean up probable cause in the normative text¶
Remove cause-name identity to align with example in A.1¶
Change the type of root cause into string¶
Fix invalid yang instance in the appendix A.1¶
Clean up unused references¶
Fix Incident priority issue raised by Adrian¶
Add JSON example on YANG notification for Base Model¶
Add Security Consideration for incident-acknowledgement¶
Add implementation status section¶
Add incident-not-found support¶
Other Editorial changes¶
v10 - v11¶
Remove log identity¶
Add other cases such metric, notification¶
Replace incident-class with incident-type¶
Replace factor with fault condition¶
Reference RFC9375 for metric event type¶
Replace probable cause with probable root cause¶
v08 - v09¶
Second alignment with RFC9940¶
Fix document references to match Model references¶
Allow create incident without knowing the source¶
Make incident-no mandatory¶
Add clarification text for min-element set to unknown¶
Update YANG model tree diagram to align with update of YANG data model¶
Create ietf-incident-tree diagram¶
v07 - v08¶
Add a new section to clarify Relationship with network anomaly architecture;¶
Clarify the relation with OAM Schdule YANG in section 4;¶
Abstract update;¶
Terminology alignment with RFC9940;¶
Other Editorial changes;¶
v06 - v07¶
Fix Yanglint issue in the YANG data model.¶
Align with RFC8407bis section 3.8.3.1 IANA template.¶
Align with YANG Module Security Considerations template.¶
Probable Root Cause Definition Polishing.¶
Tree diagram update for RPC error construct¶
v05 - v06¶
Break down A.3 into 3 sections covering 3 examples.¶
v04 - v05¶
Replace probable cause with probable root cause based on Adrian and Benoit's suggestion.¶
Address editorial comments raised by Aitken Paul.¶
YANG Model editorial changes based on Aitken Paul's comments.¶
v03 - v04¶
Remove constraint of using machine learning for service impact assessment and replace machine learning with algorithmic techniques.¶
Replace root cause with probable cause based on IETF 122 NMOP Session Discussion.¶
Add two ITU-T references for probable cause definition in the terminologies section.¶
Add Lionel Tailhardat from Orange as new contributors based on his input.¶
Add two new examples in the Appendix to explore correlation between troubleshooting ticket and incident management and intent based network diagnoisis interaction.¶
v02 - v03¶
Cross-checking terminology across NMOP drafts based on Adrian's comments.¶
Align with the Terminology draft based on Thomas's comments.¶
Clarify the relation between the Network Incident, and Customer Incident.¶
Add service impact assessment term and its definition.¶
Clarify the relation between fault, problem, incident, service.¶
Other Editorial changes.¶
v01 - v02¶
Clarify the relation between fault, incident and problem.¶
Clarify the relation between fault management and incident management.¶
Add clarification text to make draft focus on network level incident management, not be tied with OSS or under the control of OSS.¶
Other Editorial changes.¶
v00 - v01¶
Clarify the relationship between incident-no and incident-id.¶
Fix Tree Diagram to align with YANG module code change.¶
Add json example in the appendix.¶
Add failure handling process for RPC error.¶
Clarify the relationship between events and cause.¶
Clarify synchronous nature of these RPCs.¶
Clarify the relationship between inter-layer and inter-domain.¶
Refer to terminology draft for terminology alignment.¶
Fix pyang compilation issue and yang lint issue.¶
Fix Broken ref by using node-ref defined in RFC8345.¶
Update YANG data model based on issues raised in issue tracker of the github.¶
Shorten the list of authors to 5 based on chairs' comment and move additional authors to top 3 contributors.¶
Merge ietf-incident-type.yang into ietf-incident.yang¶
Fix enumeration on leaf type¶
Clarify the scope in the abstract and introduction and make the scope focus on YANG data model¶
Provide text around figure 5 to clarify how the incident server know the real effect on the relevant services.¶
Other editorial changes.¶
v00 (draft-ietf-nmop-network-incident-yang)¶