]> CMCC

Building A01, 1600 Yuhangtang Road, Wuchang Street, Yuhang District Hangzhou 311121 China hutong@cmhi.chinamobile.com

Telefonica

Madrid Spain luismiguel.contrerasmurillo@telefonica.com

Huawei

101 Software Avenue, Yuhua District Nanjing 210012 China bill.wu@huawei.com

Ciena

ndavis@ciena.com

fengchongllly@gmail.com

Operations and Management NMOP Working Group Network Incident Management yang data model This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help reduce troubleshooting tickets and resolve network incidents for the sake of network service health and probable cause analysis.

Introduction defines a framework for Automating Service and Network Management with YANG to 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 defines a standard interface for alarm management. A data model for Network and VPN Service Performance Monitoring defines a standard interface for network performance management. In addition, distributed tracing mechanism defined in 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 ; 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 ) into fewer network incidents and there are many solutions in the market today 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, a network-wide incident-centric solution is specified 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 , 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 , 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 ). For example, Neural Network Algorithm or Hierarchy Aggregation Algorithm 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 with rpc operations in this YANG module.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are defined in , , and are not redefined here:

• Alarm
• Resource
• Event
• Problem
• Incident
• Anomaly
• Cause
• Symptom
• Characteristic
• SLA (Service Level Agreement)
• SLO (Service Level Objective)

The following terms are defined in this document:

Service Impact Assessment:

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 service, which can reduce the volume of fault/alarms reporting, facilitate troubleshooting, and assure network service performance and availability.

Incident Management:

Lifecycle management of network incidents, including network incident identification, reporting, acknowledgement, diagnosis, and resolution. Different from the traditional 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 when service SLA associated with one specific network service and network incident has been affected. How customer incident is translated from the network incident is beyond the scope of this document.

Incident Management System:

An entity that implements network incident management. It includes (but not limited to) Incident Server and Incident Client.

Incident Server:

An entity that is responsible for detecting and reporting one network incident, performing network incident diagnosis, resolution and prediction in specific domain, etc.

Incident Client:

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.

Incident Handler:

An entity that can receive network incident notification, 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.

Probable Root Cause:

If removing a fault condition completely resolves 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 Cause.

Sample Use Cases

Incident-Based Trouble Tickets Dispatching Usually, the dispatching of trouble tickets in a network is mostly based on alarms data analysis and often requires operators' maintenance engineers. These operators' maintenance engineers are responsible for monitoring and 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 to 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 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 point of traditional trouble ticket dispatching.

Incident Derivation from L3VPN Service Unavailability The Service Attachment Points (SAPs) defined in represent the network reference points where network services can be delivered or are being delivered to customers. SLOs can be used to characterize the ability of a particular set of nodes to communicate according to certain measurable expectations . For example, an SLA might state that any given SLO applies to at least a certain percentage of packets, allowing for a certain level of packet loss and exceeding packet delay threshold to take place. For example, an SLA might establish a multi-tiered SLO of end-to-end latency as follows:

• Not to exceed 30 ms for any packet.
• Not to exceed 25 ms for 99.999% of packets.
• Not to exceed 20 ms for 99% of packets.

This SLA information can be bound with two SAPs or multiple SAPs defined in , so that the service orchestration layer can use these interfaces to commit the delivery of a service on specific point-to-point service topology or point to multi-point topology. When a given SLO threshold is violated, a network incident (or customer incident associated with an L3VPN service may be derived.

Multi-layer Fault Demarcation 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 (e.g., Wavelength Division Multiplexing (WDM) client fault) at an optical-layer device. Second, faults occurring at an optical-layer device might further cause faults (e.g., Layer 3 link down) at a packet- layer device. 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 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 analyzing result and dispatch site engineers to perform relevant maintenance actions (e.g., splice fiber) based on the Probable Root Cause.

Network Incident Management Architecture

Network Incident Management Architecture

illustrates the Network Incident Management architecture. Two key components for the Incident Management are the Incident Client and the Incident Server. The Incident Server can be deployed in network operation platforms, network analytic platforms, controllers 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 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 report" 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 report" notification reported by Incident Server, and acknowledges it with the subsequent "incident ack" 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.

Functional Interface Requirements between the Client and the Server

Incident Identification As depicted in , multiple alarms, metrics, or hybrid can be aggregated into a network incident after analysis.

Incident Identification

The Network Incident Management server MUST be capable of identifying network incidents. Multiple alarms, metrics and other information are reported to Incident Server, and the server must analyze it and find out the correlations of them, if the correlation match the network incident rules, network incident will be identified, and reported to the client. If the network incident is repeated many times, the problem needs to be raised. 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 will think these alarms have some correlations. These new correlations will be put into the knowledge base, and the network incident will be identified faster according to knowledge base next time.

Example 1 of Network Incident Identification

As described in , vpn a is deployed from PE1 to PE2, if a 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, e.g., igp down, has impact on the service.

Example 2 of Network Incident Identification

As described in , 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.

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

Incident Resolution After the Probable Root Cause is diagnosed, the Incident Client MAY resolve the network incident. The Incident Client MAY choose 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 Cause. If the Probable Root Cause cannot be resolved, an alternative solution SHOULD be required. For example, if a network incident caused by a physical component failure, it cannot be automatically resolved, the standby link can be used to bypass the faulty component. Incident Server will monitor 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. Network incident resolution may affect the running network services. The client can choose not to perform those operations after determining the impact is not trivial.

Incident Data Model Concepts

Identifying the Incident Instance An incident id is used as an identifier of an incident instance, if an incident instance is identified, a new incident ID is created. The incident id MUST be unique in the whole system.

The Incident Lifecycle The network incident model clearly separates network incident instance lifecycle from operator incident lifecycle. o Network incident instance lifecycle: The network incident instrumentation that controls whether a network incident is raised, updated, or cleared. o Operator incident lifecycle: Operators acting upon the network incident with rpcs like acknowledged, diagnosed and resolved.

Network Incident Instance Lifecycle 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'.

Operator Incident Lifecycle 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' rpc (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.

Incident Data Model Design

Overview 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 "incident-id". 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 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.

Incident YANG Tree Diagram /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? identityref | | +--ro detail? string | +--ro cause-name? identityref | +--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 +--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-id? 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? identityref | | +--ro detail? string | +--ro cause-name? identityref | +--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 ]]>

Incident Notifications A general notification, incident-notification, is provided here. When a network incident instance is identified, the notification will be sent. 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'.

Incident Acknowledge /inc:incidents/inc:incident/inc:incident-no ]]> After an incident is generated, updated, or cleared, the operator needs to confirm 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.

Incident Diagnose /inc:incidents/inc:incident/inc:incident-no ]]> After a network incident is generated, network 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.

Incident Resolution /inc:incidents/inc:incident/inc:incident-no ]]> 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. Network 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 will be 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.

RPC Failure 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 for structures is defined as follows: Valid errors that can occur for each structure defined in this document are described as follows:

Network Incident Management YANG Module This module imports types defined in , , ,. ; WG List: Author: Chong Feng Author: Tong Hu Author: Luis Miguel Contreras Murillo Author : Qin Wu Author: Nigel Davis "; 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) 2024 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). This version of this YANG module is part of RFC xxxx (https://www.rfc-editor.org/info/rfc9940); ; 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 "Merge incident yang with incident type yang and fix broken ref."; reference "RFCxxxx: YANG module for network incident management."; } // Identities identity incident-domain { description "The abstract identity to indicate the domain of an incident."; } identity single-domain { base incident-domain; description "Single domain."; } identity access { base single-domain; description "access domain."; } identity ran { base access; description "Radio access network domain."; } identity transport { base single-domain; description "Transport domain."; } identity otn { base transport; description "Optical transport network domain."; reference "RFC9376: Applicability of GMPLS for beyond 100 Gbit/s Optical Transport Network"; } identity ip { base single-domain; description "Ip domain."; reference "RFC1136: Administrative Domains and Routing Domains A Model for Routing in the Internet"; } identity ptn { base ip; description "Packet transport network domain."; reference "RFC6373: MPLS Transport Profile (MPLS-TP) Control Plane Framework"; } identity cross-domain { base incident-domain; description "Cross domain."; } identity incident-category { description "The abstract identity for incident category."; } identity device { base incident-category; description "Device category."; reference "RFC8348: A YANG Data Model for Hardware Management"; } identity power-environment { base device; description "Power environment category."; reference "RFC8348: A YANG Data Model for Hardware Management"; } identity device-hardware { base device; description "Device hardware category."; reference "RFC8348: A YANG Data Model for Hardware Management"; } identity device-software { base device; description "Device software category"; reference "RFC8348: A YANG Data Model for Hardware Management"; } identity line-card { base device-hardware; description "Line card category."; reference "RFC8348: 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 "VM category."; } identity event-type { description "The abstract identity for Event type"; reference "RFC9940: Some Key Terms for Network Fault and Problem Management"; } identity alarm { base event-type; description "Alarm event type."; reference "RFC8632: A YANG Data Model for Alarm Management"; } identity notif { base event-type; description "Notification event type."; reference "RFC5277:NETCONF Event Notifications"; } identity metric { base event-type; description "Metric event type."; reference "RFC9375: YANG Data Model for Network Incident Management"; } identity unknown { base event-type; description "Unknown event type."; } identity incident-type { description "The abstract identity for Incident category."; } 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 "RFC9940: Some Key Terms for Network Fault and Problem Management"; } identity sla-violation { base incident-type; description "It indicates the class of the incident is a 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 probable-cause-unlocated { base diagnose-error; description "Fail to locate the probable 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 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."; } identity cause-name { description "Base identity for the cause name."; } // Typedefs typedef incident-priority { type enumeration { enum critical { description "The incident MUST be handled immediately."; } enum high { description "The incident should be handled as soon as possible."; } enum medium { description "Network services are not affected, or the services are slightly affected,but corrective measures need to be taken."; } enum low { description "Potential or imminent service-affecting incidents are detected,but services are not affected currently."; } } description "Define the priority of incident."; } typedef incident-ref { type leafref { path "/inc:incidents/inc:incident/inc:incident-no"; } description "Reference a network incident."; } // Groupings grouping probable-cause-info { description "The information of probable cause."; leaf cause-name { type identityref { base cause-name; } description "The name of cause."; } 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; 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-id { 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."; } } default "raised"; 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."; } } default "unacknowledged"; 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"; 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 cause objects."; list probable-cause { key "node-ref"; description "The probable causes of incident."; uses resources-info { augment "resource" { description "Augment probable cause information."; //if probable cause object is a resource of a node uses probable-cause-info; } } //if probable cause object is a node uses probable-cause-info; } } container probable-events { description "The probable cause related events of the incident."; list probable-event { key "type event-id"; description "The probable 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"; } description "Network 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"; } 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"; } 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 leafref { path "/al:alarms/al:alarm-list/al:alarm" + "/al:resource"; } description "Network resource."; reference "RFC 8632: A YANG Data Model for Alarm Management"; } leaf metric-name { type string; description "Metric Name."; } leaf threshold-value { type string; description "Threshold value for the specific metric."; } leaf observed-value { type string; 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."; } 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."; } 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."; } } } } } } } // RPCs rpc incident-acknowledge { description "This rpc can be used to acknowledge the specified incidents."; input { leaf-list incident-no { type incident-ref; description "The unique sequence number of an incident instance based on 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; description "The unique sequence number of an incident instance based on 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; description "The unique sequence number of an incident instance based on the name type incident-id keys."; } } } sx:structure incident-acknowledge-error-info { container incident-acknowledge-error-info { description "This structure data MAY be inserted in the RPC error response to indicate the reason for the incident acknowledge failure."; leaf incident-no { type uint64; description "Indicates the incident 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 MAY be inserted in the RPC error response to indicate the reason for the incident diagnose failure."; leaf incident-no { type uint64; description "Indicates the incident 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 MAY be inserted in the RPC error response to indicate the reason for the incident resolution failure."; leaf incident-no { type uint64; description "Indicates the incident 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."; } uses incident-info; leaf time { type yang:date-and-time; description "Occuring time of an incident instance."; } } // Data definitions container incidents { config false; description "The information of incidents."; list incident { key "name type incident-id"; description "The information of incident."; leaf incident-no { type uint64; mandatory true; description "The unique sequence number of the incident instance based on the name type incident-id keys."; } uses incident-info; uses incident-time-info; } } } ]]>

Operational Consideration The "ietf-incident" YANG module introduces an incident-centric architecture designed to overcome the structural silo of traditional management systems that handle alarms and performance metrics separately at different network layers. Operators must 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-id) corresponds to a single incident instance. This means that incident notifications for the same name and same type and incident-id are matched to update the same incident instance. These three leafs are therefore used as the key in the incident list: 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.

Interworking with Alarm Management

Interworking with Alarm Management | Process | | || |alarm | | | |+-------+ +-----------+ | | ^ ^ | +---|--------------|----------+ |alarm | metrics/trace/etc. | | +-------+--------------+---------------+ | | | Network in the Autonomous Domain | | | +--------------------------------------+ ]]>

A YANG model for the alarm management defines a standard interface to manage the lifecycle of alarms. Alarms represent the undesirable state of network resources , 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 , 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 . In some cases, e.g., cutover scenario, the Incident Server may use alarm management interface 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. Incident Management is not a substitute for alarm management. Instead, they can work together to implement fault management.

Interworking with SAIN SAIN defines an architecture of network service assurance.

Interworking with SAIN

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 and the network incident will be reported if symptoms match certain condition or characteristic considered as an indication of a problem or potential problem.

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

Relationship with Trace Context W3C defines a common trace context for distributed system tracing, defines a netconf extension for and 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.

Relationship with Network Anomaly Detection 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 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 defines an "id" which should be mapped to "event-id" in the 'ietf-incident' YANG module described in this document on the "Incident Server". 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.

Security Considerations 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 and RESTCONF . These YANG-based management protocols (1) have to use a secure transport layer (e.g., SSH , TLS , and QUIC ) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) 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. 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 on the server side as well as network resources. Servers MUST ensure they have sufficient resources to fulfill this request; otherwise, they MUST 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 MUST reject the request without compromise on security of data-at-rest in the server.

IANA Considerations

The "IETF XML" Registry IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group :

The "YANG Module Names" Registry IANA is requested to register the following YANG module in the "YANG Module Names" registry within the "YANG Parameters" registry group. // RFC Ed.: Replace RFC xxxx with this RFC id, when published and remove this comment

Acknowledgements The authors would like to thank Mohamed Boucadair, Robert Wilton, Benoit Claise, Oscar Gonzalez de Dios, Adrian Farrel, Mahesh Jethanandani, 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.

References Normative References YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document defines a YANG module for alarm management. It includes functions for alarm-list management, alarm shelving, and notifications to inform management systems. There are also operations to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards. This document sets out some terms that are fundamental to a common understanding of network fault and problem management within the IETF. The purpose of this document is to bring clarity to discussions and other work related to network fault and problem management -- in particular, to YANG data models and management protocols that report, make visible, or manage network faults and problems. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document captures the current syntax used in YANG module tree diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. This document introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. This document describes YANG mechanisms for defining abstract data structures with YANG. The Network Configuration Protocol (NETCONF) defined in this document provides mechanisms to install, manipulate, and delete the configuration of network devices. It uses an Extensible Markup Language (XML)-based data encoding for the configuration data as well as the protocol messages. The NETCONF protocol operations are realized as remote procedure calls (RPCs). This document obsoletes RFC 4741. [STANDARDS-TRACK] This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol. [STANDARDS-TRACK] This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery. This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. This document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas. YANG is a data modeling language used to model configuration and state data manipulated by the Network Configuration Protocol (NETCONF), NETCONF remote procedure calls, and NETCONF notifications. [STANDARDS-TRACK] Informative References n.d. Data models provide a programmatic approach to represent services and networks. Concretely, they can be used to derive configuration information for network and service components, and state information that will be monitored and tracked. Data models can be used during the service and network management life cycle (e.g., service instantiation, service provisioning, service optimization, service monitoring, service diagnosing, and service assurance). Data models are also instrumental in the automation of network management, and they can provide closed-loop control for adaptive and deterministic service creation, delivery, and maintenance. This document describes a framework for service and network management automation that takes advantage of YANG modeling technologies. This framework is drawn from a network operator perspective irrespective of the origin of a data model; thus, it can accommodate YANG modules that are developed outside the IETF. The data model for network topologies defined in RFC 8345 introduces vertical layering relationships between networks that can be augmented to cover network and service topologies. This document defines a YANG module for performance monitoring (PM) of both underlay networks and overlay VPN services that can be used to monitor and manage network performance on the topology of both layers. This document describes an architecture that provides some assurance that service instances are running as expected. As services rely upon multiple subservices provided by a variety of elements, including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with symptoms of a specific network component but, it also lists the services impacted by the failure or degradation of a specific network component. University of Luxembourg and Inria Independent 3NLab Belgium Research Center Canada Post Digital Railway (DSD) at Deutsche Bahn This document is intended to introduce the challenges to overcome when Network Management (NM) problems may require coupling with Artificial Intelligence (AI) solutions. On the one hand, many difficult NM problems still lack good solutions, or existing approaches come with significant limitations. Artificial Intelligence may help produce novel solutions to those problems. On the other hand, due to the high computational costs of AI solutions and stringent data privacy constraints, the distributed execution of AI workloads has become paramount. Consequently, networks must be operated efficiently to sustain these distributed processing requirements. To identify the right set of challenges, the document defines a method based on the evolution and nature of NM problems. This will be done in parallel with advances and the nature of existing solutions in AI in order to highlight where AI and NM have already been coupled together or could benefit from a closer integration. So, the method aims at evaluating the gap between NM problems and AI solutions. Challenges are derived accordingly, assuming that solving these challenges will help to reduce the gap between NM and AI. This document is a product of the Network Management Research Group (NMRG) of the Internet Research Task Force (IRTF). This document reflects the consensus of the research group. It is not a candidate for any level of Internet Standard and is published for informational purposes. This document describes network slicing in the context of networks built from IETF technologies. It defines the term "IETF Network Slice" to describe this type of network slice and establishes the general principles of network slicing in the IETF context. The document discusses the general framework for requesting and operating IETF Network Slices, the characteristics of an IETF Network Slice, the necessary system components and interfaces, and the mapping of abstract requests to more specific technologies. The document also discusses related considerations with monitoring and security. This document also provides definitions of related terms to enable consistent usage in other IETF documents that describe or use aspects of IETF Network Slices. This document defines a YANG data model for representing an abstract view of the provider network topology that contains the points from which its services can be attached (e.g., basic connectivity, VPN, network slices). Also, the model can be used to retrieve the points where the services are actually being delivered to customers (including peer networks). This document augments the 'ietf-network' data model defined in RFC 8345 by adding the concept of Service Attachment Points (SAPs). The SAPs are the network reference points to which network services, such as Layer 3 Virtual Private Network (L3VPN) or Layer 2 Virtual Private Network (L2VPN), can be attached. One or multiple services can be bound to the same SAP. Both User-to-Network Interface (UNI) and Network-to-Network Interface (NNI) are supported in the SAP data model. Ericsson Ericsson ZTE Corp. Futurewei Futurewei Inria and University of Luxembourg This document defines a set of metrics for networking services with performance requirements expressed as Service Level Objectives (SLO). These metrics, referred to as Precision Availability Metrics (PAM), are useful for defining and monitoring SLOs. For example, PAM can be used by providers and/or customers of an RFC XXXX Network Slice Service to assess whether the service is provided in compliance with its defined SLOs. Note to the RFC Editor: Please update "RFC XXXX Network Slice" with the RFC number assigned to draft-ietf-teas-ietf-network-slices. Telefonica Nokia Huawei This document defines two YANG data models to support on-demand network diagnosis using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam- test-sequence' YANG modules to manage the lifecycle of network diagnosis procedures, intended for use by external management and orchestration systems (including SDN controllers and network orchestrators), rather than by individual network nodes. This document specifies YANG modules for representing assurance graphs. These graphs represent the assurance of a given service by decomposing it into atomic assurance elements called subservices. The companion document, "Service Assurance for Intent-Based Networking Architecture" (RFC 9417), presents an architecture for implementing the assurance of such services. The YANG data models in this document conform to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. Cisco Systems Deutsche Telekom AG All For Eco This document defines how to propagate trace context information across the Network Configuration Protocol (NETCONF), that enables distributed tracing scenarios. It is an adaption of the HTTP-based W3C specification. Huawei Everything OPS Swisscom Telefonica I+D China Telecom Network equipment are often configured by a variety of network management systems (NMS), protocols, and teams. If a network issue arises (e.g., because of a wrong configuration change), it is important to quickly identify the root cause and obtain the reason for pushing that modification. Another potential network issue can stem from concurrent NMSes with overlapping intents, each having their own tasks to perform. In such a case, it is important to map the respective modifications to its originating NMS. This document specifies a NETCONF mechanism to automatically map the configuration modifications to their source, up to a specific NMS change request. Such a mechanism is required, in particular, for autonomous networks to trace the source of a particular configuration change that led to an anomaly detection. This mechanism facilitates the troubleshooting, the post-mortem analysis, and in the end the closed loop automation required for self-healing networks. The specification also includes a YANG module that is meant to map a local configuration change to the corresponding trace id, up to the controller or even the orchestrator. Swisscom Swisscom INSA-Lyon Deutsche Telekom This document describes the motivation and architecture of a Network Anomaly Detection Framework and the relationship to other documents describing network Symptom semantics and network incident lifecycle. The described architecture for detecting IP network service interruption is designed to be generic applicable and extensible. Different applications are described and examples are referenced with open-source running code. Huawei Swisscom Swisscom Deutsche Telekom This document defines a structured, iterative lifecycle for network anomaly detection systems to enable "human-in-the-loop" refinements. Key contributions include defining three lifecycle stages, a state machine for anomaly annotations, and YANG data models for standardized labeling and exchange. Swisscom Swisscom Deutsche Telekom Huawei The document proposes a unified symptoms vocabulary for network anomaly metadata to improve data sharing and analysis among human network operators, network analytics implementers, and AI systems to improve accuracy of Service Disruption Detection.

Examples of Network Incident Format Representation

Network Incident Correlated with Specific Network Topology and the Network Service In this example, we show a network incident that are associated with the service-instance "optical-svc-A", the node 'D1', the network topology 'L2-Topo' and the domain 'FAN'. The Probable Root Cause is also analysed.

Network Incident Correlated with Trouble Tickets In this document, the objective of the Incident Management is to identify Probable Causes and reduce duplicated tickets. Traditionally, troubleshooting ticket is created upon critical alert is received, e.g., due to excessive BGP flaps on a particular device by the OSS system. Such troubleshooting ticket will trigger Network Incident Management in the network controller. Therefore normally troubleshooting tickets and network incident are managed by the OSS and the network controller respectively. However Network troubleshooting is sometimes complicated and requires data gathering and analysis from many different tools from the controllers, therefore correlation between troubleshooting ticket and network incident becomes necessary.

Correlation with troubleshooting tickets

In order to manage the correlation between network incidents and trouble tickets in the YANG data model, three rpcs to manage the network incidents and one notification to report on network incident state changes defined in "ietf-incident" module can be further extended to include "ticket-no" attribute so that such correlation can be carried in the incident update notification and report the upper-layer OSS system. Such correlation can be used by the incident handler in the upper-layer OSS system for further fault demarcation, e.g., identify whether the fault is on the user side or on the network side.

Intent Based Networking with Incident Diagnosis Task List 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. |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. "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. ... | +--ro probable-events leafref //List ... | +-- 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. So that the controller can send diagnosis task notification to the OSS system upon diagnosis task completes and outputs repair suggestion.

Multi-Domain Fault Demarcation with Network Incident Management 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.

Multi-Domain Fault Demarcation related-objects? leafref //List .... } ]]>

Service Complaint triggered Network Diagnosis

Service Complaint triggered Network Diagnosis

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.

Changes between Revisions 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)

• Change draft name from draft-feng-opsawg-incident-management into draft-feng-nmop-netwrok-incident-yang
• Change title into A YANG Data Model for Network Incident Management
• open issues is tracked in https://github.com/billwuqin/network-incident/issues

Contributors Orange

lionel.tailhardat@orange.com

Swisscom

Switzerland thomas.graf@swisscom.com

CMCC

li_zhenqiang@hotmail.com

China Unicom

zhengyanlei@chinaunicom.cn

CAICT

xuyunbin@caict.ac.cn

CAICT

zhaoxing@caict.ac.cn

Huawei

yuchaode@huawei.com