]> Huawei

hyu2010b@gmail.com

Huawei

lixiao33@huawei.com

China Unicom

tanyx11@chinaunicom.cn

CAICT

zhaoxing@caict.ac.cn

Old Dog Consulting

daniel@olddog.co.uk

Routing Common Control and Measurement Plane This document defines a YANG module for SLA assurance management in optical transport networks. The module provides a standard way to represent and report issues that may impact service and network availability. It enables consistent reporting of impairments and risks across optical transport domains. The YANG model is designed to support closed-loop operations, allowing automated monitoring, analysis, and remediation workflows to maintain high service reliability and SLA compliance. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Common Control and Measurement Plane Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Service Level Agreement (SLA) assurance management in optical transport networks concerns the continuous monitoring, analysis, and management of network conditions that may impact the performance, availability, and reliability of services. Its objective is to detect potential issues proactively, diagnose their root causes, and initiate corrective actions to prevent SLA violations. Several standards already exist in this area. Service Assurance for Intent-Based Networking (SAIN) defines an architecture, and defines a YANG data model, for network service assurance. defines a YANG model for the network incident lifecycle management. It aims to provide a standard way to report, diagnose, and help resolve network incidents which may cause SLA violations. However, several gaps remain in the existing standards and their associated YANG models with respect to supporting SLA assurance management in optical transport networks. First, the SAIN framework focuses on the detection and resolution of symptoms, that is, conditions indicating that a service instance or subservice is not operating in a fully healthy state. In optical transport networks, however, undesirable network conditions may exist that increase the risk of SLA violations while remaining asymptomatic. For example, multiple service paths may traverse fiber links deployed within the same trench, thereby introducing a common point of failure. Such conditions do not necessarily result in observable service degradation and, therefore, may not be identified through symptom-based monitoring alone; detecting them may require information about shared physical infrastructure that is not part of the service health model. In addition, SLA assurance monitoring, in some cases, needs to detect and report events defined by SLA policies, such as bandwidth utilization exceeding a specified threshold. The threshold values are defined by the user, reflecting user's perception of desired network conditions. The occurrence of such events does not necessarily indicate the presence of an incident affecting service health. Instead, event reporting may serve as a precautionary mechanism requested by the user. A mechanism and a YANG model are therefore needed to support the detection and reporting of such events. Thirdly, some optical network conditions, such as fiber attenuation, may degrade silently and gradually before resulting in observable incidents. These conditions may persist for an extended period of time. For SLA assurance management in optical networks, it is preferable to define, detect, and resolve such issues proactively rather than waiting for them to escalate into incidents. To address these optical network specific challenges, an issue-centric SLA assurance solution is specified. An issue is an optical network condition that, if unaddressed, may lead to SLA violations and incidents. This document defines a YANG data model for SLA assurance management in optical networks. The model defines optical network SLA assurance issues and their corresponding resolutions.

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:

• Event
• Incident
• Anomaly
• Cause
• Characteristic
• SLA (Service Level Agreement)
• SLO (Service Level Objective)

The following terms are defined in this document:

SLA assurance issue:

A detected network condition relevant to the assessment or fulfillment of an SLA objective, which, if not addressed in time, may lead to SLA violations of services and incidents. An issue may exist without customer-visible service impact and without an associated incident. An issue may either be symptomatic or asymptomatic. Symptomatic issues cause visible impacts to the health of services. Asymptomatic issues, in contrast, do not impact services alone. They lead to SLA violations in conjunction with other conditions or events, such as a service reroute.

SLA assurance issue type:

A class used for the classification of SLA assurance issues. Every issue belongs to a certain type. There is a limited number of the types of assurance issues in optical networks.

SLA assurance capability:

The ability to detect SLA assurance issues and initiate preemptive actions to prevent SLA violations. This ability is measured against how many different types of issues the SLA assurance system can handle.

SLA assurance issue classification:

The process to identify the type of an issue when it is raised. It is an SLA assurance capability.

Issue Server:

An entity that is responsible for detecting, classifying, and reporting SLA assurance issues, and performing issue solutions to prevent SLA violations.

Fiber same cable:

A pair of optical fibers traverse the same physical cable sheath (i.e., both fibers are contained within the same fiber cable).

Fiber same trench:

A pair of optical fibers are deployed within the same trench/duct route (i.e., both fibers share the same underground pipeline or trench corridor).

Sample Use Cases

Proactive resilience assurance for high-availability business services Modern optical transport networks underpin mission-critical enterprise and carrier-grade services that require continuous availability and strict SLA compliance. This use case focuses on proactively assuring network resilience to prevent service degradation and minimize the impact of potential failures. In this scenario, the optical transport network continuously monitors key performance indicators such as signal quality, optical power levels, latency, and error rates across wavelengths and optical links, as well as ODUk connections. Advanced analytics and telemetry are used to detect early signs of degradation, including fiber attenuation, amplifier drift, or emerging congestion patterns. When potential risk conditions are identified, the system proactively evaluates network topology and service dependencies to assess impact on high-availability business services. If a risk of SLA violation is detected, automated or semi-automated remediation actions are triggered. These may include traffic rerouting via pre-provisioned protection paths, wavelength re-optimization, or activation of restoration mechanisms in the optical layer. The objective is to ensure near-zero interrupted service delivery (surpassing the five-nines availability) for critical applications, such as financial trading, cloud connectivity, and real-time enterprise communications. By shifting from reactive fault management to proactive resilience assurance, operators can significantly reduce downtime, improve SLA adherence, and enhance overall customer experience in optical transport networks.

Deterministic Latency Assurance for Latency-Sensitive Services Deterministic SLA assurance in optical transport networks is a use case that aims to ensure stable and predictable service performance for latency-sensitive applications, such as AI distributed training, telemedicine, industrial automation, and immersive XR services. These applications require stringent guarantees on end-to-end latency, jitter, packet loss, bandwidth availability, and service continuity. In this use case, an optical transport service is provisioned with explicit SLA objectives that define the required deterministic performance characteristics. During service operation, the network continuously monitors both the service state and the underlying optical transport infrastructure through real-time telemetry collection. The monitored information may include end-to-end path latency, optical link quality, bandwidth utilization, wavelength continuity, congestion conditions, and other transport performance indicators relevant to SLA fulfillment. As network conditions dynamically evolve, the system identifies conditions that may threaten the SLA commitments of active services before visible service degradation occurs. Such conditions may include increasing congestion, abnormal latency variation, optical signal degradation, or predicted failures affecting the active transport path. The network then evaluates alternative optical transport paths and service optimization options capable of preserving the required SLA characteristics. The objective of this use case is to maintain continuous SLA compliance throughout the service lifecycle by enabling adaptive transport behavior in response to changing network conditions. This improves service reliability, minimizes performance instability and disruption, and enhances the capability of optical transport networks to support mission-critical and performance-sensitive applications.

Dynamic Bandwidth Allocation for Cloud-Network Synergy Cloud-Network Synergy-Based Dynamic Bandwidth Allocation is a use case in optical transport networks that enables adaptive allocation of transport resources based on coordinated demands from cloud applications and network conditions. It targets service scenarios such as AI training workloads, distributed computing, cloud bursting, and large-scale data synchronization, where bandwidth demand is highly dynamic and time-varying. In this use case, cloud applications continuously generate workload signals that reflect their resource requirements, including bandwidth demand, traffic intensity, latency sensitivity, and service priority. These requirements are communicated to the optical transport network through a cloud-network interface. At the same time, the optical transport network maintains real-time visibility of available capacity, including wavelength availability, link utilization, path constraints, and operational state across the optical infrastructure. Based on the correlation between cloud-side demand signals and network-side resource state, the system determines when and where bandwidth adjustments are required. When increased demand is detected, the network evaluates feasible optical path and wavelength allocation options that satisfy service constraints. Conversely, when demand decreases, allocated resources may be released or re-optimized to improve overall network efficiency. The objective of this use case is to achieve efficient and elastic utilization of optical transport resources while ensuring that cloud application performance requirements are consistently met. By enabling coordinated decision-making between cloud workloads and optical network control, the system improves resource utilization, reduces congestion by dynamic bandwidth control of hard-pipes, and enhances the responsiveness of the transport network to dynamic application demands.

SLA assurance issues As shown in , SLA assurance issues in optical networks can be classified, based on their impact, into three categories: (1) those affecting service bandwidth, (2) those affecting network and service availability, and (3) those introducing traffic delay. SLA Assurance Issues

Issue category	SLA assurance issues
Bandwidth	Traffic spike (sudden increase in traffic)
	Utilization exceeds threshold defined in the SLA
	Network bit error rate / packet loss rate higher than allowed threshold
Network and service availability	Service outage
	Transient service interruption
	Failover protection failure
	Protection on the same route
	Risk of traffic rerouting (during failover/reconvergence)
	Service performance degradation
	customer premises equipment (CPE) access vulnerability/hazard
Delay	Operating latency exceeds allowed limit
	Protection-path latency exceeds allowed limit

Most SLA assurance issues, if left unaddressed, are expected to eventually result in SLA violations and incidents. However, exceptions exist. For example, an issue indicating that bandwidth utilization has exceeded an SLA-defined threshold does not necessarily imply the presence of a service health problem or any network equipment failures, particularly when the configured threshold provides a substantial operational margin. In such cases, the impact analysis included in the issue report SHOULD indicate that no immediate service impact is expected. The report MAY also recommend that the user review and adjust the threshold value to better align with the intended monitoring objectives. Issues that could eventually lead to SLA violations may be either symptomatic or asymptomatic. For symptomatic issues, the associated symptoms are observable at the service layer and indicate degradation in the health of one or more services. In contrast, asymptomatic issues may not manifest as observable symptoms in any affected service. Despite this distinction, the underlying causes of both types of issues may originate from abnormal conditions in the underlay optical transport network that provides connectivity for the services. More specifically, there are three major sources of possible root causes spanning three layers of transport networks: (1) abnormal conditions in optical fibers, (2) error conditions in optical WDM services, and (3) bit errors in Optical Transport Network (OTN) payloads. SLA assurance analysis must provide accurate diagnosis of these issues and identify their underlying causes. It should also be noted that certain SLA terms permit temporary service outages or transient service interruptions. This is common, for example, for best-effort services or services without protection mechanisms. In such cases, the distinction between issues and incidents may become less clear, and the two concepts may overlap. Accordingly, issue management MAY defer the handling of such cases to incident management processes. Each issue is described in more detail in the following subsections.

Bandwidth Issues Bandwidth issues are service assurance conditions that impact the capacity, throughput, or traffic-carrying efficiency of optical transport networks.

Traffic spike (sudden increase in traffic) This issue refers to the network condition that the customer-side interface receives a large volume of burst traffic within an extremely short period of time (on the order of milliseconds). When the instantaneous rate of microburst traffic exceeds the device's forwarding capacity, the device buffers the burst traffic for later transmission. If the device does not have sufficient buffer space, the excess traffic is dropped, resulting in congestion and packet loss.

Bandwidth utilization exceeds threshold defined in the SLA This issue refers to the network condition that the customer-side service traffic exceeds the user-defined threshold, posing a risk of bandwidth overutilization. This issue can be quantified as the percentage of cumulative time during a specified period in which the service bandwidth utilization exceeds the SLA-defined threshold.

Network bit error rate (or packet loss rate) higher than allowed threshold This issue refers to the problem that the packet loss on the customer side causes the available bandwidth to fall short of the user's requirements. Possible cause at the OTN layer: Bit errors are being generated at the electrical-layer service level, specifically within digital layer channels (such as ODUk and OTUk), indicating that the transmission at the digital wrapper/virtual container layer is experiencing signal corruption. This may result from impairments in the physical transmission path or intermediate equipment, and can lead to degraded service quality or potential data integrity issues at the service layer. Possible cause at the DWDM layer: Corrected bit errors are occurring at the optical-layer (OCh) service level, indicating that the optical channel is experiencing transmission impairments that require error correction mechanisms to recover affected data. While forward error correction (FEC) is able to detect and correct these errors, their presence suggests degradation in optical signal quality, which may be caused by factors such as optical attenuation, noise, dispersion, or aging/impairment of the transmission path, and could eventually lead to uncorrectable errors if conditions worsen. Possible cause at the fiber layer: The logical fiber path traversed by the service is experiencing degradation in terms of attenuation, indicating increased optical loss along the transmission route. This deterioration in signal strength may be caused by fiber aging, connector or splice losses, bending losses, or other impairments in the optical path, and can negatively impact signal quality and overall service performance.

Network and service availability issues Network and service availability issues are service assurance conditions that impact the ability of optical transport networks to maintain continuous and reliable service delivery.

Service outage The service experiences either a network-side interruption or a customer-side interruption, resulting in a loss of connectivity or service availability. Possible cause at the OTN layer: The service experiences an interruption at the electrical-layer service level (ODUk/OTUk/VC), indicating a loss of continuity in the digital wrapper/virtual container transport layer. This type of failure typically results in a complete break in the ODUk/OTUk signal path, causing service disruption and potential traffic loss across the affected connection, and may be triggered by transport defects, equipment failures, or upstream/downstream signal degradation. Possible cause at the DWDM layer: The service experiences an interruption at the optical (OCh/OMS/OTS) service level, indicating a loss of continuity in the optical channel transport path. This results in a complete failure of the optical (OCh/OMS/OTS) signal transmission, leading to service outage and traffic disruption. Such an interruption may be caused by severe optical impairments, fiber cuts, transmitter/receiver failures, or failures in optical switching elements along the transmission path. Possible cause at the fiber medium layer: The logical fiber path traversed by the service experiences an interruption, indicating a complete loss of continuity along the virtualized or logical optical transport route. This results in a service outage due to the inability of the end-to-end path to maintain signal transmission. Such an interruption may be caused by failures in underlying physical fiber links, intermediate network elements, or logical path provisioning issues within the optical transport network.

Transient service interruption Service experiences momentary interruptions. For instance, optical power fluctuations in the fiber may cause short bursts of bit errors or packet loss at higher layers, also leading to transient service interruptions. Possible cause at the OTN layer: The service's electrical-layer (ODU/OSU) working path has switched to a protection path, resulting in a brief service interruption (service hit or transient outage). This switchover indicates that a fault or degradation was detected on the original working route, triggering protection mechanisms to reroute traffic; however, the switching process introduces a short-lived traffic disruption during path convergence. Possible cause at the DWDM layer: The OCh service's optical-layer working path has switched to a protection path, resulting in a brief service interruption (transient outage or service hit). This indicates that degradation or a failure was detected on the original optical channel working route, triggering protection mechanisms to reroute traffic. During the switching and path convergence process, a short-lived disruption may occur, leading to a momentary service blip before normal transmission resumes on the protection path. Possible cause at the fiber layer: Abnormal optical power fluctuations occur on the fiber path traversed by the service, causing transient instability in the received signal level. These rapid variations in optical power can lead to momentary loss of signal integrity, triggering a brief service interruption (service hit or flash outage). Such behavior is typically associated with physical-layer impairments such as connector issues, micro-bending, fiber movement, or unstable optical components along the transmission path.

Failover protection failure This issue may arise when the protection route of the service experiences an interruption, resulting in protection failure. This indicates that the backup (protection) path is unavailable or has lost continuity, preventing the protection mechanism from successfully taking over in the event of a working path fault. As a result, the service is left without effective redundancy, increasing the risk of service disruption or prolonged outage if a failure occurs on the active path. Possible cause at the OTN layer: The protection route at the electrical-layer (ODU/OTU/VC) level experiences an interruption, indicating a loss of continuity in the backup ODU/OTU/VC path. As a result, the protection path becomes unavailable, preventing it from serving as a valid failover for the working route in the event of a failure. This condition reduces service resilience and increases the risk of service disruption if the primary electrical-layer path degrades or fails. Possible cause at the DWDM layer: The protection route at the optical-layer (OCh) experiences an interruption, meaning the backup OCh (or OCh protection path) has lost continuity or become unavailable. As a result, the optical protection mechanism cannot successfully take over traffic in the event of a failure on the working channel, thereby reducing service resilience and increasing the risk of service outage under fault conditions. Possible cause at the fiber layer: The protection fiber traversed by the service - referring to the logical fiber path not currently used by the working route - experiences an interruption, indicating a loss of continuity on the backup transport path. Since this logical fiber represents the protection route, its failure renders the protection mechanism unavailable for failover, thereby reducing overall service resilience and increasing the risk of service disruption if the working path subsequently fails.

Protection on the same route The working and protection paths of the service partially overlap, such as sharing common nodes or fiber links within the same Shared Risk Link Group (SRLG), which may compromise the effectiveness of the protection mechanism in case of a failure. Possible cause at the OTN layer: The service's electrical-layer (ODU/VC) working and protection paths share a common SRLG (Shared Risk Link Group), as identified through protection segment analysis. This indicates that the supposedly redundant primary and backup routes are not fully disjoint and may be simultaneously affected by a single underlying failure domain (e.g., shared fiber segment, duct, node, or equipment). As a result, the effectiveness of protection is compromised, increasing the risk of concurrent working and protection path failure and potential service outage under fault conditions. Similarly, the issue may also arise when the service's electrical-layer working and protection paths traverse the same network element, indicating that both primary and backup routes are not node-disjoint. This introduces a shared risk at the equipment level, meaning that a single failure or maintenance event on that network element could simultaneously impact both working and protection paths. Possible cause at the DWDM layer: The service's optical-layer (OCh) working and protection paths share a common SRLG, indicating that the primary and backup routes are not fully physically diverse. This means both paths may traverse a shared risk element - such as a fiber segment, conduit, node, or optical equipment - creating a single point of correlated failure. As a result, the protection scheme's effectiveness is reduced, increasing the risk that a single failure could simultaneously impact both working and protection OCh paths, potentially leading to service outage. The issue may also arise if the OCh working and protection paths pass through the same network element (NE). This creates a shared risk at the equipment level, where a single device failure, software fault, or maintenance activity on that network element could simultaneously impact both working and protection optical channels. Possible cause at the fiber layer: Fiber same cable and fiber same trench scenarios may also lead to a "protection on the same route" issue, where the working and protection paths are no longer truly physically diverse. In such cases, although logical routing appears to provide redundancy, both fiber paths share the same underlying physical infrastructure - either within the same cable or the same trench/duct corridor. This creates a shared risk domain, meaning that a single physical failure event (such as cable cut, trench excavation damage, or environmental impact) can simultaneously affect both the working and protection fibers. As a result, the protection mechanism may fail to provide effective redundancy, significantly increasing the risk of concurrent path failure and resulting service interruption.

Risk of traffic rerouting (during failover/reconvergence) A service may be exposed to an increased risk of SLA violations during network failover or routing reconvergence events. Although protection switching and restoration mechanisms are designed to maintain service continuity, the newly selected path may exhibit different characteristics from the original path, such as increased latency, reduced available bandwidth, additional optical impairments, or a higher detour factor. These changes may cause one or more SLA performance objectives to be approached or exceeded, even if the service remains operational. Accordingly, the Issue Server SHOULD identify services that are susceptible to such rerouting events, assess the potential impact on SLA compliance, and report the associated risk before or immediately after the rerouting occurs, thereby enabling proactive operational actions to mitigate potential SLA violations. Possible cause at the OTN layer: TBD Possible cause at the DWDM layer: TBD Possible cause at the fiber layer: TBD

Service performance degradation The service experiences performance degradation, indicating a decline in end-to-end service quality compared to normal operating conditions. One example could be the degradation in Optical Channel (OCH) performance - performance degradation at the optical layer, such as post-FEC errors, may cause impairments at the service level (e.g., bit errors and packet loss). Possible cause at the OTN layer: The service experiences performance degradation at the electrical-layer (ODU/VC) service level, typically manifested as error-related performance counters or alarms. This indicates that the ODU/VC transport layer is suffering from signal quality deterioration, leading to increased bit errors, errored seconds, or other degradation indicators. Such conditions are often associated with impairments in the underlying transmission path, equipment issues, or signal interference, and may degrade service quality even if the connection remains up. Possible cause at the DWDM layer: Performance degradation occurs at the optical-layer (OCh) service level, typically manifested as pre-FEC bit error rate (BER) threshold violations or related performance degradations. This indicates that the optical channel is experiencing signal quality deterioration before forward error correction is applied, suggesting impairments such as optical noise, attenuation, dispersion, or aging of optical components. Although FEC may still be able to recover the transmitted data, persistent or worsening pre-FEC error conditions can reduce transmission margins and may eventually lead to uncorrectable errors or service interruption. Possible cause at the fiber layer: The logical fiber path experiences performance degradation, typically indicated by fiber attenuation exceeding the defined threshold (for example, surpassing the designed End-of-Life (EOL) attenuation limit). This suggests that the optical transmission path is suffering from excessive signal loss, which may be caused by fiber aging, connector or splice degradation, bending losses, contamination, or other physical impairments. Excessive attenuation reduces optical power margins and can negatively impact signal quality, increasing the risk of transmission errors, instability, or eventual service interruption.

CPE access vulnerability/hazard This issue refers to the problem that the protection configuration of the service access segment does not match the required availability grade, or the working and protection paths within the access segment share the same SRLG. This indicates that the access-side protection design does not provide the level of resilience required by the service SLA, either because the configured protection mechanism is insufficient or because the primary and backup access paths are not fully risk-disjoint. As a result, a single physical or logical failure event may simultaneously affect both working and protection paths, reducing service availability and increasing the risk of service interruption. Possible cause at the OTN layer: The protection configuration of the access segment does not match the configured service availability grade. For example, the access segment is deployed with a single uplink architecture, while the service availability requirement is configured for dual-uplink protection. This mismatch indicates that the actual redundancy capability of the access network is insufficient to meet the intended SLA or resilience target. As a result, the service may not achieve the expected availability level, and a single uplink failure could directly lead to service interruption. Possible cause at the DWDM layer: TBD Possible cause at the fiber layer: There is a shared SRLG (Shared Risk Link Group) risk between the working and protection paths of the access segment, indicating that the primary and backup access routes are not fully physically or logically diverse. Both paths may rely on the same underlying risk domain - such as shared fiber infrastructure, conduit, node, or access equipment - meaning that a single failure event could simultaneously impact both working and protection connections. As a result, the effectiveness of the access protection mechanism is reduced, increasing the risk of service interruption and lowering overall service resilience.

Latency issues Latency issues are service assurance conditions that affect the delay experienced by traffic traversing optical transport networks. These issues may be introduced by suboptimal routing, increased path length due to protection switching, congestion in optical or OTN layers, or processing delays within network elements.

Operating latency exceeds allowed limit The service's current working latency exceeds the defined threshold, indicating that the end-to-end transmission delay is out of the acceptable range. This may be due to latency threshold violations or an excessive detour factor (route inefficiency), where traffic is forced onto a longer-than-optimal path. Possible causes at the OTN layer: The service may experience a latency-related SLA issue due to changes in the routing characteristics of the working electrical-layer (ODU) service path. For example, an electrical-layer path switch may result in the newly selected working path exhibiting a higher end-to-end latency than the original route, causing the measured latency to exceed the configured threshold. In addition, the new routing may introduce a detour factor violation. The detour factor is defined as the ratio of the measured or estimated latency to the ideal latency, where the ideal latency is calculated as the shortest-path distance in the network topology multiplied by the fiber latency coefficient. If the actual routing deviates significantly from the optimal shortest path, the resulting increase in path length and transmission delay may cause the detour factor to exceed the acceptable limit. Both conditions indicate that the working ODU service path no longer satisfies the latency-related constraints specified by the SLA. Possible causes at the DWDM layer: The service may experience a latency-related SLA issue due to changes in the routing characteristics of the working optical path. For example, an optical-layer path switch may result in the newly selected working path exhibiting a higher end-to-end latency than the original route, causing the measured latency to exceed the configured threshold. In addition, the newly established route may lead to a detour factor violation on the working logical fiber. The detour factor is defined as the ratio of the measured or estimated latency to the ideal latency, where the ideal latency is calculated as the shortest-path distance between the two endpoints in the network topology multiplied by the fiber latency coefficient. If the routing of the working logical fiber deviates significantly from the optimal shortest path, the resulting increase in transmission distance and delay may cause the detour factor to exceed the acceptable limit. Both conditions indicate that the current optical-layer routing no longer satisfies the latency-related constraints specified by the SLA. Possible causes at the fiber layer: The service may experience a latency-related SLA issue following a fiber cut along the optical path that triggers a routing switch. As part of the failure recovery process, the rerouted working path may exhibit higher end-to-end latency than the original route, causing the measured latency to exceed the configured threshold. In addition, the rerouted working logical fiber may exhibit a detour factor violation. The detour factor is defined as the ratio of the measured or estimated latency to the ideal latency, where the ideal latency is calculated as the shortest-path distance in the network topology multiplied by the fiber latency coefficient. If the rerouted logical fiber deviates significantly from the optimal shortest path, the resulting increase in transmission distance and delay may cause the detour factor to exceed the acceptable limit. Both conditions indicate that the post-recovery routing no longer satisfies the latency-related constraints specified by the SLA.

Protection-path latency exceeds allowed limit The service's current protection latency exceeds the defined threshold, indicating that the end-to-end delay on the protection path is out of the acceptable range. This refers to the delay along the protection path, not the time taken to switch to it. Possible cause at the OTN layer: The service experiences a detour factor violation on the protection electrical-layer (ODU) path. The detour factor is defined as the ratio of measured or estimated latency to ideal latency, where ideal latency is calculated as the shortest network path distance between two points multiplied by the fiber latency coefficient. In this case, the protection ODU routing deviates significantly from the optimal shortest path, resulting in excessive transmission delay and causing the detour ratio to exceed the acceptable threshold. Possible cause at the DWDM layer: The service experiences a detour factor violation on the protection optical-layer (OCh) path. The detour factor is defined as the ratio of measured or estimated latency to ideal latency, where the ideal latency is calculated as the shortest network path distance between two points multiplied by the fiber latency coefficient. In this case, the protection OCh routing significantly deviates from the optimal shortest path, resulting in increased transmission delay and causing the detour ratio to exceed the acceptable threshold. Possible cause at the fiber layer: The service experiences a detour factor violation on the protection logical fiber path. The detour factor is defined as the ratio of measured or estimated latency to ideal latency, where the ideal latency is calculated as the shortest path distance between two points in the network topology multiplied by the fiber latency coefficient. In this case, the protection logical fiber route significantly deviates from the optimal shortest path, resulting in increased transmission delay and causing the detour ratio to exceed the acceptable threshold. A detour-factor violation does not by itself establish that the absolute latency objective has been exceeded; the two conditions are reported separately.

SLA Assurance Issue Management Architecture and SLA Assurance Capability

SLA Assurance Issue Management Architecture

illustrates the SLA assurance issue management architecture. The main component for issue management is the Issue Server, which provides capabilities for issue identification and classification, issue reporting, and issue querying. The Issue Server can be deployed on controllers as defined in within each network domain and interfaces with the OSS. A typical workflow is as follows:

• The Issue Server derives monitoring policies from the SLA, including the events, performance metrics, and alarms that need to be monitored, and initiates the corresponding monitoring activities.
• Upon detecting an issue, the Issue Server performs issue classification, impact analysis, and resolution generation, and reports the issue to the Operations Support System (OSS).
• The OSS can query the Issue Server to retrieve information about identified issues, including their status, impact assessment, and recommended resolutions.
• The OSS can invoke RPC operations exposed by the Issue Server to initiate issue resolution.

It should be noted that the SLA assurance capabilities supported by Issue Servers may vary across implementations and products. Therefore, an Issue Server SHOULD provide interfaces that expose its supported capabilities and enable external systems to query such capability information. To support SLA assurance management in optical networks, a unified data model is required for standardized representation. The model should support classification (issue-sla-type) and hierarchical layering (layer), where the layering follows the network architecture defined in . Specifically, the optical layer includes OTS, OMS, and OCh, while the electrical layer includes OTUk and ODUk (including both higher-order and lower-order ODUk). The model should also incorporate severity labeling (severity), explicit identification of affected objects (source-objects), impacted services or objects (impacted-objects), and temporal tracking attributes such as occurrence time (occur-time) and clearance time (clear-time). In addition, each impairment instance should include a detailed description (description) and corresponding remediation or handling recommendations (suggestion), enabling consistent lifecycle tracking, analysis, and operational decision-making.

Interworking with SAIN

Interworking with SAIN

SAIN defines an architecture for network service assurance and specifies mechanisms for detecting symptoms associated with service degradation. For symptomatic issues, issue lifecycle management can leverage the capabilities provided by SAIN to support issue detection, analysis, and handling. SAIN can also represent dependencies that do not affect the reported service health. Asymptomatic issues, however, may require additional information from the underlying physical network resources and associated monitoring mechanisms, such as shared routes or infrastructure, that is not part of the service health model. The division shown in is illustrative rather than a restriction on SAIN capabilities.

Relationship with Incident The objective of SLA assurance issue management is to prevent incidents, or reduce their occurrence, by identifying and resolving issues before they escalate into incidents. However, incidents cannot be fully prevented by issue management for several reasons. First, certain SLA terms permit temporary service outages or transient service interruptions, in which case issue handling is typically delegated to incident management. Second, an Issue Server may have limited SLA assurance capabilities, which may prevent it from detecting certain classes of issues. Therefore, issue management and incident management are complementary functions. The terminology of applies to this document. Mplify and distinguish an Issue experienced by a Buyer from an Incident record created by a Seller. An SLA assurance issue, as used in this document, is an optical-domain assurance construct: a detected condition relevant to the assessment or fulfillment of an SLA objective. It may exist without customer-visible impact and without a Seller-created Incident. The same underlying condition may subsequently be associated with an Incident when handled through incident-management processes, or with a Buyer-experienced Issue if it results in customer-visible service impact. For example, a protection-diversity risk detected in a shared trench while the service is operating normally is an SLA assurance issue; it does not imply a Buyer-experienced Issue, and whether it results in an Incident record depends on the Seller's operational process. This document does not redefine the Mplify terms.

Interworking with ACTN framework The issue lifecycle management framework can interwork with the Abstraction and Control of Traffic Engineered Networks (ACTN) framework to support end-to-end service assurance across multi-domain transport networks. In particular, ACTN provides a hierarchical control architecture that enables coordination between customer-facing service requests and underlying network resources, while issue lifecycle management provides mechanisms for detecting, classifying, and handling SLA assurance issues. In an integrated deployment, the Issue Server may be instantiated within or alongside ACTN controllers in each domain, enabling correlation of service-level issues with underlying network conditions across multiple technology layers and administrative domains. ACTN's provision of abstracted network views can be leveraged by issue management functions to localize the impact of detected issues and to facilitate cross-domain impact analysis. Furthermore, issue-related information, including detected issues, their classifications, and resolution recommendations, may be exposed through ACTN interfaces to support coordinated remediation actions. Conversely, ACTN control and orchestration functions may provide topology, connectivity, and service intent information that enhances issue detection accuracy and improves root cause localization. In ACTN , a Provisioning Network Controller (PNC) can report domain-level observations to a Multi-Domain Service Coordinator (MDSC). This model can supply the issue information for that exchange; it does not define the corrective actions or the interfaces used to invoke them.

SLA Assurance Data Model Design

Overview The YANG module "ietf-optical-sla-assurance" defines a data model for SLA assurance management in optical transport networks. The module provides a standard way to represent and report issues that may impact service and network availability. It enables consistent reporting of impairments and risks across optical transport domains. The information reported in the SLA assurance issue includes issue identification, classification, severity, impacted objects, and remediation suggestions. At the top of the "ietf-optical-sla-assurance" module is the read-only SLA assurance container ("sla"); its contents are operational state reported by the server. The SLA assurance issues are represented as a list and indexed by "csn" (Customer Serial Number). Each SLA assurance issue is associated with issue metadata such as issue name, type, category, layer, severity, and timing information. In addition, the module supports relationships between issues through related-issues list and identifies source objects where the issue occurs. The module also defines impacted objects (services and tunnels) that are affected by each issue. The issue-sla-type enumeration classifies issues into three categories based on their impact: bandwidth, availability, and delay. The layer enumeration identifies the transport layer where the issue originates, including service-layer, electrical-layer (OTN/ODU), optical-layer (DWDM/OCh), and fiber-layer. The issue-category distinguishes between fault conditions (actual failures) and risk conditions (potential failures that may lead to SLA violations). The severity enumeration provides four levels: critical, major, minor, and info, allowing operators to prioritize issue resolution. The related-issues list establishes relationships between issues, enabling correlation analysis and root cause identification. The source-objects list identifies the specific network resources where the issue manifests, with each object identified by UUID and described by name and type. The module also defines an RPC operation "query-history-issue-statistics-by-service" that allows retrieval of historical SLA issue statistics for specific services or tunnels within a specified time range. The RPC accepts service identifiers (UUIDs), time range parameters, and an optional SFTP URL for exporting results. The output provides comprehensive statistics including interruption count, total interruption duration, availability percentage, and a detailed interrupt history with begin/end times and durations. Durations are expressed in milliseconds, and availability is a percentage with six decimal places so that objectives such as 99.999% can be represented. The model is designed to support closed-loop operations for SLA assurance in optical transport networks. It enables automated monitoring systems to detect issues, classify them according to SLA impact, and initiate appropriate remediation actions. The separation between symptomatic issues (actual service degradation) and asymptomatic issues (risk conditions that may lead to future SLA violations) allows for proactive assurance management, helping to prevent incidents before they occur. The module follows YANG 1.1 and imports common types from ietf-yang-types . It defines custom groupings for reusable issue attributes (issue-base) and complete issue definitions (issue), promoting modularity and consistency across different implementations. The use of UUID for service and tunnel identifiers ensures global uniqueness and facilitates integration with other management systems. This data model is intended to be used by network management systems, orchestration platforms, and assurance analytics engines in optical transport network environments. It provides a standardized representation of SLA assurance issues that can be exchanged between different vendor equipment and management systems, enabling multi-vendor interoperability and consistent SLA management across heterogeneous optical transport networks.

SLA assurance issue identification and observability SLA assurance issue identification is the process of detecting and categorizing network conditions that may impact service performance, availability, or reliability. The YANG model provides a structured framework for representing identified issues with comprehensive observability attributes that enable effective monitoring, analysis, and remediation. Each SLA assurance issue is uniquely identified by a Customer Serial Number (CSN), which serves as the primary key in the issues list. The CSN is a 64-bit unsigned integer that is unique within the reporting server. In addition to the CSN, issues may optionally include an issue-id (64-bit signed integer) for legacy compatibility or cross-system referencing, and a human-readable issue-name (string up to 1000 characters) for operator identification and documentation. Observability of issues is enhanced through temporal and descriptive attributes. The occur-time attribute records when the issue was first detected or identified, using the yang:date-and-time type for precise timestamping. The clear-time attribute records when the issue was resolved or cleared, enabling calculation of issue duration and trend analysis. The clear-time is unset while an issue is current.

SLA assurance issue resolution and capability list SLA assurance issue resolution encompasses the processes and capabilities for addressing identified issues, ranging from immediate remediation actions to long-term capacity planning and network optimization. The YANG model provides the data foundation for representing issues throughout their lifecycle and enables the definition of standardized resolution capabilities and procedures. Issue resolution typically follows a structured workflow: detection, classification, prioritization, diagnosis, remediation, and verification. The YANG model supports this workflow through comprehensive issue representation and temporal tracking. The occur-time and clear-time attributes enable measurement of issue duration and resolution time, while the severity attribute drives prioritization. The description and suggestion attributes provide contextual information and remediation guidance for both human operators and automated systems. The SLA assurance capability list represents the set of issue types that a management system can detect, analyze, and resolve. This capability is measured by the comprehensiveness of the issue catalog and the effectiveness of the resolution mechanisms. The YANG model's issue-sla-type and issue-category enumerations provide the framework for organizing this capability list, which can be extended with specific issue instances through the issue-name and description attributes.

Items for Further Discussion Editor's note: the following points are under discussion and are expected to be resolved, with corresponding changes to the YANG module, in a future revision. This section will be removed before publication.

• Service and tunnel identification: the impacted-objects and statistics lists are keyed by both service-name and tunnel-name, so an issue affecting only a service, or only a tunnel, cannot currently be represented.
• Issue types: the issue catalogue in is more specific than the issue-sla-type and issue-category enumerations. A machine-readable, extensible issue-type definition is being considered so that clients need not interpret the issue-name.
• Statistics semantics: the rules for counting overlapping interruptions, handling interruptions that span the observation window, excluding planned maintenance, and reporting incomplete measurement coverage need to be specified.
• SFTP export: the file format, completion and error reporting for the sftp-url parameter need to be specified, or the parameter removed.
• Capability discovery and issue resolution: the architecture in describes capability exposure and resolution operations that the module does not yet define.

SLA Assurance YANG module WG List: Author: Henry Yu Author: Xiao Li "; description "This module defines a data model for reporting Service Level Agreement (SLA) assurance issues and service interruption statistics in optical transport networks. 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). This version of this YANG module is part of RFC XXXX; see the RFC itself for full legal notices."; revision 2026-10-13 { description "Issue inventory made operational state; availability precision, duration units and timestamp types corrected; module metadata completed."; reference "RFC XXXX: A YANG Data Model for Service Level Agreement (SLA) Assurance Management in Optical Transport Networks"; } revision 2026-07-02 { description "Initial revision."; reference "draft-yu-ccamp-sla-assurance-optical-yang-01"; } grouping issue-base { description "Attributes common to all SLA assurance issues."; leaf issue-id { type int64 { range "0..1000000000"; } description "Optional issue identifier for legacy compatibility or cross-system referencing."; } leaf issue-name { type string { length "0..1000"; } description "Human-readable issue name."; } leaf issue-sla-type { type enumeration { enum bandwidth { value 1; description "The issue affects service bandwidth."; } enum availability { value 2; description "The issue affects network or service availability."; } enum delay { value 3; description "The issue affects traffic delay."; } } description "SLA dimension affected by the issue."; } leaf layer { type enumeration { enum service-layer { value 1; description "Service layer."; } enum electrical-layer { value 2; description "Electrical layer (OTUk/ODUk)."; } enum optical-layer { value 3; description "Optical layer (OTS/OMS/OCh)."; } enum fiber-layer { value 4; description "Fiber layer."; } } description "Transport layer at which the issue originates."; } } grouping issue { description "An SLA assurance issue record."; leaf csn { type uint64 { range "0..9223372036854775807"; } mandatory true; description "Serial number of the issue, unique within the reporting server."; } uses issue-base; leaf issue-category { type enumeration { enum fault { value 1; description "An existing failure or impairment."; } enum risk { value 2; description "A condition that may lead to an SLA violation."; } } description "Whether the issue is an observed fault or a risk."; } leaf occur-time { type yang:date-and-time; description "Time at which the issue was first detected."; } leaf clear-time { type yang:date-and-time; description "Time at which the issue was cleared. Absent while the issue is current."; } leaf description { type string { length "0..1000"; } description "Description of the issue."; } leaf suggestion { type string { length "0..1000"; } description "Recommended handling of the issue."; } leaf severity { type enumeration { enum critical { value 1; description "Critical."; } enum major { value 2; description "Major."; } enum minor { value 3; description "Minor."; } enum info { value 4; description "Informational."; } } description "Severity of the issue."; } list related-issues { key "csn"; description "Issues related to this issue."; leaf csn { type uint64 { range "0..9223372036854775807"; } description "Serial number of the related issue."; } } list source-objects { key "object-id"; description "Resources on which the issue was detected."; leaf object-name { type string { length "0..255"; } description "Name of the resource."; } leaf object-id { type yang:uuid; description "UUID of the resource."; } leaf object-type { type string { length "0..64"; } description "Type of the resource."; } } } grouping service-info { description "Identifiers of a service and the tunnel carrying it."; leaf service-name { type yang:uuid; description "UUID of the service."; } leaf tunnel-name { type yang:uuid; description "UUID of the tunnel."; } } container sla { config false; description "SLA assurance issues reported by the server."; list issues { key "csn"; description "List of SLA assurance issues."; uses issue; leaf issue-type { type enumeration { enum current { value 1; description "The issue is current."; } enum history { value 2; description "The issue has been cleared."; } } description "Whether the issue is current or historical."; } list impacted-objects { key "service-name tunnel-name"; description "Services and tunnels impacted by the issue."; uses service-info; } } } rpc query-history-issue-statistics-by-service { description "Retrieve historical SLA issue statistics for a service or tunnel over a time range."; input { uses service-info; leaf begin-time { type yang:date-and-time; description "Start of the observation window."; } leaf end-time { type yang:date-and-time; description "End of the observation window."; } leaf sftp-url { type string { length "0..255"; } description "Optional SFTP destination to which the results are exported."; } } output { list sla-issue-statistic { key "service-name tunnel-name"; description "Statistics for one service and tunnel."; uses service-info; container service-pm { description "Service performance statistics for the observation window."; leaf interruptions { type uint64 { range "0..9223372036854775807"; } description "Number of service interruptions."; } leaf interrupt-duration { type uint64 { range "0..9223372036854775807"; } units "seconds"; description "Total duration of service interruptions."; } leaf availability { type decimal64 { fraction-digits 6; range "0..100"; } units "percent"; description "Service availability over the observation window, as a percentage."; } list interrupt-history { key "interrupt-begin-time interrupt-end-time"; description "Individual service interruptions."; leaf interrupt-begin-time { type yang:date-and-time; description "Start of the interruption."; } leaf interrupt-end-time { type yang:date-and-time; description "End of the interruption."; } leaf interrupt-duration { type uint64 { range "0..9223372036854775807"; } units "seconds"; description "Duration of the interruption."; } } } } } } } ]]>

Security Considerations The YANG module specified in this document defines a data model for SLA assurance management in optical transport networks. The module 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 issue inventory defined by this module is operational state and contains no configuration nodes. Access control is nevertheless needed for read operations and for the statistics RPC. 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 or another state-data retrieval mechanism) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability: '/sla/issues': This list specifies the SLA assurance issue entries for optical transport networks. Unauthorized read access of this list can allow intruders to access SLA assurance information and potentially get a picture of the health and resilience status of the optical transport network. Intruders may exploit the vulnerabilities revealed in the issue data, including source-objects and impacted-objects, 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: "query-history-issue-statistics-by-service": This RPC operation retrieves historical SLA issue statistics and service performance metrics. 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 appropriate RPC error responses. Additionally, the sftp-url parameter provided in this operation MUST be validated against authorized destinations to prevent unauthorized data exfiltration.

IANA Considerations

The "IETF XML" Registry IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group : URI: urn:ietf:params:xml:ns:yang:ietf-optical-sla-assurance Registrant Contact: The IESG. XML: N/A, the requested URIs are XML namespaces.

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. Name: ietf-optical-sla-assurance Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-optical-sla-assurance Prefix: ietf-optical-sla-assurance Reference: RFC XXXX // RFC Ed.: replace XXXX and remove this comment

References Normative References International Telecommunication Union 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. CMCC Telefonica Huawei Ciena 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. 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 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. 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). 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 obsoletes RFC 8446, which specified TLS 1.3. This document obsoletes RFC 5246 (specifying TLS 1.2) and RFCs 5077, 6961, 7627, and 8422, all of which pertain to TLS 1.2 or earlier, and updates RFCs 5705 and 6066. 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 Mplify Alliance Mplify Alliance 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. 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 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. 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. Traffic Engineered (TE) networks have a variety of mechanisms to facilitate the separation of the data plane and control plane. They also have a range of management and provisioning protocols to configure and activate network resources. These mechanisms represent key technologies for enabling flexible and dynamic networking. The term "Traffic Engineered network" refers to a network that uses any connection-oriented technology under the control of a distributed or centralized control plane to support dynamic provisioning of end-to- end connectivity. Abstraction of network resources is a technique that can be applied to a single network domain or across multiple domains to create a single virtualized network that is under the control of a network operator or the customer of the operator that actually owns the network resources. This document provides a framework for Abstraction and Control of TE Networks (ACTN) to support virtual network services and connectivity services.

Acknowledgments The authors would like to thank Yanlei Zheng, Italo Busi, and Christian Dieckhoff for their valuable comments and input to this work.