]> Telefonica

luismiguel.contrerasmurillo@telefonica.com

Nokia

victor.lopez@nokia.com

Huawei

bill.wu@huawei.com

Operations and Management Operations and Management Area Working Group OAM Scheduling Unitary Test Sequence Test This document defines two YANG Data Models to support scheduled network diagnosis using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-sequence-test' 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. 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 Operations and Management Area Working Group Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction Operations, Administration, and Maintenance (OAM) tasks are fundamental functions of the network management (see, e.g., ). Given the emergence of data models and their utilization in Service Provider's network management and the need to automate the overall service management lifecycle , managing OAM operations is also essential. Relevant data models are still missing to cover specific needs. The term OAM is used in this document as defined in and further characterized according to the classification guidelines in . The scope of this document applies primarily to active and hybrid OAM mechanisms, as scheduling tests generally implies the generation of additional OAM traffic. Passive OAM mechanisms are not the focus of this work. Specifically, OAM functions provide the means to identify and isolate faults, measure and report the network performance (see section 4.2, ). For example, defines the three main areas involved in OAM:

• Fault management, which allows network operators quickly identify and isolate faults in the network. Examples of these mechanisms for fault detection and isolation are: continuity check, link trace, and loopback.
• Performance management enables monitoring network performance and diagnosing performance issues (i.e., degradation). Some of the measurements such as packet delay measurement, packet delay variation measurement, and packet loss measurement.
• Security management defines mechanisms to protect OAM communications from unauthorized access and tampering.

presents OAM tools for detecting and isolating failures in networks and for performance monitoring, some examples are:

• Continuity Check: This function verifies that a path exists between two points in a network and that the path is operational. Some technologies following this approach are Y.1731 Continuity Check , Ethernet OAM Continuity Check , MPLS-TP BFD CC .
• Loopback: This function allows a device to loop back a received packet back to the sender for diagnostic purposes. There are multiple technologies for this function, like IP Ping , , VCCV Ping , LSP Ping or Ethernet Loopback .
• Link Trace: This function allows a network operator to trace a path through a network from one device to another. Some technologies following this approach are Y.1731 Linktrace or IP traceroute , .
• Performance Monitoring: This function allows a network operator to monitor the performance of a network and to identify and diagnose performance issues. Protocols like TWAMP , STAMP , Alternative Marking , IOAM (In Situ OAM) , or Y.1731 DMM/SLM can obtain performance measurements.

More recently, Incident Management focuses on the network incident diagnosis, which can be favored by dynamic invocation of OAM tests. , , defined YANG models for OAM technologies: o "A YANG Data Model for Connection Oriented OAM": defines a YANG data model for connection-oriented OAM protocols. The main aim of this document is to define a generic YANG data model that can be used to configure, control, and monitor connection-oriented OAM protocols such as MPLS-TP OAM and TRILL OAM . o "A YANG Data Model for Connectionless OAM Protocols": provides a generic YANG data model that can be used to configure, control, and monitor connectionless OAM protocols such as BFD (Bidirectional Forwarding Detection) , ICMP Ping , and LSP Ping . o "A YANG Data Model for Retrieval Methods for the Management of OAM Protocols that Use Connectionless Communications": provides a YANG data model that can be used to retrieve information related to OAM protocols such as BFD (Bidirectional Forwarding Detection) , ICMP Ping , and LSP Ping . These OAM related YANG data models at the device level defined parameters required for each of the different tests that are used in network elements today. This work aims to reuse and build upon existing YANG models for OAM technologies, such as those defined in , , and . By leveraging these foundational models, this document specifies two Network Models for scheduling and coordinating sequences of OAM tests, enabling more advanced and automated network diagnosis procedures. In addition to reusing the device-level OAM YANG models from , , and , this document builds upon the generic scheduling framework defined in . The ietf-schedule module provides reusable groupings and mechanisms for specifying periods of time, recurrence rules, and scheduling status. These constructs are directly imported and used in the OAM unitary test and OAM sequence test models defined in this document, enabling precise scheduling, repetition, and conflict reporting for OAM tasks in a network-wide context.

Terminology and Notations This document assumes that the reader is familiar with the contents of "The YANG 1.1 Data Modeling Language". Following terms are used for the representation of this data model: o OAM Unitary Test: A single scheduled OAM diagnostic procedure. At each scheduled occurrence, every network element listed in the ne-config list is configured and executed as part of that one procedure under one schedule and one unitary-test-status state machine. When the procedure spans multiple network elements, each ne-config entry MUST use the same test-type identity (for example, TWAMP on each node), while the mounted configuration under root MAY differ per node (for example, TWAMP session-sender on one node and session-reflector on another). Multiple measurement sessions on the same node (for example, two entries in a mounted TWAMP test-session list) are device-model configuration for that node, not separate unitary tests. o OAM sequence test: An ordered collection of OAM unitary test steps that share one schedule on the sequence. At each scheduled occurrence, the steps are usually executed in user-specified order (ordered-by user). Each step reuses the unitary-test template (including its own ne-config list) and MAY use a different test-type from other steps, on the same or on different network elements. Use a sequence when diagnosis requires multiple distinct OAM procedures in a defined order (for example, a connectivity check followed by TWAMP, or tests using different OAM technologies). Tree diagrams used in this document follow the notation defined in . This document adopts the OAM characterization defined in : o Active OAM – uses dedicated OAM packets to assess network performance or verify continuity. o Passive OAM – observes existing data traffic without injecting OAM packets. o Hybrid OAM – combines active and passive methods. The use of the terms in-band and out-of-band is avoided in this document, consistent with .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in , when, and only when, they appear in all capitals, as shown here.

Prefix in Data Node Names In this document, names of data nodes and other data model objects will be prefixed using the standard prefix associated with the corresponding YANG imported modules, as shown in the following table. Prefixes and Corresponding YANG Modules

Prefix	Yang Module	Reference
oamut	ietf-oam-unitary-test	RFCXXXX
oamts	ietf-oam-sequence-test	RFCXXXX
yang	ietf-yang-types

• RFC Editor Note: Please replace XXXX with the RFC number assigned to this document if the document becomes a RFC. Please remove this note in that case.

Sample OAM Test Scheduling Network Model Usage A service provider network's management operations can be automated using a variety of means such as interfaces based on YANG modules . From that standpoint, and considering the architecture depicted in , The goal of this document is to provide a mechanism to via a YANG-based northbound interface using ietf-oam-unitary-test and ietf-oam-sequence-test, manage the lifecycle of network diagnosis procedure from the network controller to network elements with a focus on scheduling Network Diagnosis. In addition, both the service orchestrator and the network controller can use schema mount mechanism to retrieve ietf-yang-library data from the underlying network element and instantiate specific device-level OAM modules the network element supports under the designated data node (labeled as a mount-point) through YANG based interface or device CLI, a local script. If multiple identical devices are being managed, the network controller can reference a shared schema entry configured in its own/schema-mounts state data to mount the same model structure across all those network element locations. For more details on how schema mount works please refer to .

OAM Test Scheduling Network Model Usage

Network-wide OAM Use Cases This document covers how to use OAM for network-wide use cases. These use cases rely primarily on active or hybrid OAM methods, depending on whether dedicated test packets or augmented data packets are used, following . The following illustrative examples are provided.

Troubleshooting After the detection of a problem in the network, OAM tests are performed to find the root cause for the detected problem. However, a detected problem can be caused by a variety of factors, such as a misconfiguration, hardware failure, or a software bug. OAM tests can help identify likely root causes by testing specific components of the network and looking for anomalies or issues. Also, the reliability and efficiency of the tests depend on the nature of the test itself. There are a variety of OAM tests that can be executed as a function of the target scenario. For example, if the issue is related to a Layer 2 capability, specific tests can be designed and run to check the status of the path via Ethernet Linktrace and later run an Ethernet Loopback to a concrete network element. These tests can be coupled with others to test if any filtering is in place by varying, e.g., some Layer 2 fields or checking the configuration of relevant nodes. If these tests are correct, the operator may want to check the availability of the service (or its delivered performance). Even though the troubleshooting process may be different depending on the problem detected, there are certain common procedures or logics that can be executed in order to narrow down the cause of the problem and thus help locate candidate root cause.

Birth Certificate The aim of a birth certificate process is to validate that all relevant parameters are set appropriately in accordance with the target network service. The birth certificate process is done once the configuration of the network elements is completed, and they are ready for service. If the birth certificate is successful, it means that the network service is functioning correctly (that is, measured service is matching the expected service) and meets the requirements defined by the operator. The process requires running a set of OAM tasks (e.g., tests) to verify that the service is performing as expected. The set of OAM tests conducted as part of a birth certificate process depends on the network service that is tested. For example, if the service is a Virtual Private Network (VPN), Two-Way Active Measurement Protocol (TWAMP) Light will be used, while if the service is an E-LINE, ITU-T Y.1731 Ethernet PM tests will be executed. Typically, once the birth certificate process has been completed and the OAM tests have been executed, the test results are stored as part of the documentation process performed by the operator. Many of these tasks take place during pre-deployment phases.

Proactive Supervision Some network services require fulfillment of strict Service Level Agreements (SLAs). An SLA defines the performance parameters that the service must fulfill in order to meet the requirements of the customer or end user (e.g., IP Connectivity Provisioning Profile (CPP) and Network Slice Service ). As part of service fulfillment and assurance (e.g., Section 2.3.3 of ), proactive verification is undertaken to assess whether SLAs are met and implement appropriate adjustment measures when service distortion is observed. Proactive supervision requires running tests not only end-to-end, but also on service components to identify early symptoms and resolve issues before they impact the customer or end user. This help prevent or minimize the impact of the end user. Mitigation action may be enforced to alleviate the impact of networks incidents and nullify the impact on services that are delivered via that network. Proactive testing might be done via OAM tests. These tests can be run periodically at regular intervals depending on the specific SLA requirements and the network operator procedures. These procedures may require documenting the test results for future auditing processes with the customers (eventually, negotiated and agreed with a customer as part of service assurance).

Performance-based Traffic Engineering and Routing Path Computation Elements (PCEs) are used to compute end-to-end paths in a network . PCEs are used for Traffic Engineering (TE) purposes (e.g., optimize network performance, reduce congestion, and improve the overall user experience). There are different algorithms to calculate a path in the network for some of them the PCE requires traffic engineering information. TE information includes data such as link metrics, bandwidth availability, and routing constraints. By using this information, the PCE can compute the optimal path for a particular service , taking into account its constraints and requirements. In addition to TE Metric Extensions in OSPF or IS-IS , OAM techniques also allow obtaining link metrics like delay and loss which can be used in the PCE algorithms.

Modelling the Scheduling of OAM Tests This document specifies two models: OAM Unitary Test and OAM sequence test models.

Relationship Between OAM Unitary Test and OAM Sequence Test An OAM unitary test models one logical diagnosis action at one point in time (or on each recurrence of that schedule). All ne-config entries under the same oam-unitary-test list instance cooperate toward that action—for example, configuring the TWAMP sender and reflector for one measurement campaign. The orchestrator still applies one schedule and tracks one unitary-test-status for the whole instance. An OAM sequence test chains several such actions. Each unitary-test list entry under oam-sequence-test is a step with its own ne-config list and MAY select a different test-type than other steps. The sequence shares the schedule on the parent sequence-test and advances through steps in list order; sequence-test-status reflects progress across the chain. If two procedures do not need ordering or the same scheduling, they SHOULD be modeled as separate unitary tests rather than as steps in a sequence.

OAM Unitary Test The OAM unitary test model encompasses parameters that define a specific type of OAM test to be performed. The YANG model includes a container named "oam-unitary-tests" that serves as a container for activating OAM unitary tests for network diagnosis procedures. Within the container, there is a list called "oam-unitary-test" representing a list of specific OAM unitary tests. The list key is defined as "name", which provides a unique name for each test. Each OAM test in the list contains a "ne-config" list with "ne-id" as list key and references a test type with its concrete parameters. The test type indicates which OAM test YANG module is mounted at the "root" mount point for that "ne-config" list entry. All ne-config entries under the same oam-unitary-test MUST share the same test-type; per-node differences are expressed only in the mounted data under root (see ). In addition, each OAM unitary test has two temporal parameters: "period" container and "recurrence" container. Both import groupings from the "ietf-schedule" module from . "period" container identifies the one shot period values that contain a precise period of time and can be used to support on-demand troubleshooting, while "recurrence" container identifies the properties that contain a recurrence rule specification and can be used to periodic troubleshooting. To support on-demand troubleshooting and periodical troubleshooting, this document relies on standard data store configuration writes (like NETCONF edit-config or RESTCONF POST/PUT) rather than creating a custom RPC, while reading state via NETCONF get operations or subscription to YANG notifications to dynamically stream the unitary-test-status , . Moreover, "schedule:schedule-status" grouping has been imported from to describe common properties of scheduling status. Wrap-around of the "counter" and "failure-counter" leaves is as specified in . "unitary-test-status" leaf indicates the state of the OAM unitary test (see the state machine in ). Each oam-unitary-test instance defined by this model is conceptually an instance of an active or hybrid OAM operation, since it triggers the generation or coordination of OAM packets. The YANG model allows such differentiation by referencing the underlying test type identity. shows the structure of OAM Unitary Test module:

Tree Structure of OAM Unitary Test

Unitary Test Status State Machine The 'unitary-test-status' state machine is shown in . The state machine includes the following states:

• "planned": The initial state where the test is planned by the management and hasn't been applied to any network element.
• "configured": The state where the test is being configured. This state is triggered when the planned test configuration is applied to one or more network element(s).
• "ready": The state where the test is ready to be executed. This state is triggered after the planned test configuration is applied and before the test is executed.
• "on-going": The state where the test is currently running. This state is triggered when the test has been executed but the test results haven't been produced.
• "error": The state where an error occurs during the test. This state is triggered when the test has not been conducted successfully. Implementations may report a more specific error cause using child identities such as "resource-contention" or "priority-conflict".
• "stop": The state where the test is manually stopped. This state is triggered when the test is manually interrupted, using mechanisms which are outside the scope of this document. A manual stop is not a successful completion and is not an execution error; the next cycle, if any, starts from "planned".
• "success": The final state where the test is completed. This state is triggered when the test has been conducted successfully.

Note that how state transition triggering generation of YANG notifications and how external management and orchestration systems subscribe to these YANG notifications are not in the scope of this document.

OAM Unitary Test State Machine | planned |----->|configured|----->| ready | | +---------+ +----------+ +---------+ | A A A | | | | | | | V | | | | +-------+ | +----------+ | | | ---| error |<--+----------| on-going | | | | +-------+ +----------+ | | | | | | | +--------+ | | | +----------| stop |<------------+ | | +--------+ | | | | | +---------+ | +-| success |<-----------------------------+ +---------+ ]]>

OAM Sequence Test The OAM sequence test model consists of a collection of OAM unitary test steps that are executed based on specified time constraints, repetitions, ordering, and reporting outputs. These sequences provide a structured approach to running multiple OAM procedures in a coordinated manner, including cases where successive steps use different test-type values or target different network elements. Note that each test sequence is local sequence configuration; any later changes to the configured unitary test template in the ietf-oam-unitary-test should not silently change an already configured sequence. Each OAM unitary test in Each OAM test sequence references an OAM unitary test type with its concrete parameters to indicate which OAM Test YANG module, is mounted at the "root" mount point for that "ne-config" list entry. Each OAM test sequence has two temporal parameters related to time constraints: "period" container and "recurrence" container and one constraint related to ordering: "ordered-by user". Time constraints parameters are imported from the "ietf-schedule" module from . "period" identifies the one shot period values that contain a precise period of time and can be used to support on demand troubleshooting, while "recurrence" identifies the properties that contain a recurrence rule specification and can be used to support periodical troubleshooting. Note that the "recurrence" is only intended to expose current and latest summary state, per occurrence result history is outside the scope of this document. Future extension can choose to define notifications or other result model to report per occurence result history. To support on-demand troubleshooting and periodical troubleshooting, this document relies on standard data store configuration writes (like NETCONF edit-config or RESTCONF POST/PUT) rather than creating a custom RPC, while reading state via NETCONF get operations or subscription to YANG notifications to dynamically stream the sequence-test-status , . Moreover, "ordered-by user" YANG statement indicates that the user is responsible for the ordering on a collection of OAM unitary tests. "sequence-test-status" shows the state of the OAM test sequence. "state" imported from the "ietf-schedule" module indicates the current state of the schedule. Note that repetition is specified by "count" parameter and only applies to the recurrence schedule type. If no count is indicated, the test is considered to run indefinitely. In case of the recurrence schedule type, both frequency and interval should be specified. Each execution runs at the scheduled recurrence interval. Since the OAM sequence test model consists of a collection of OAM unitary tests, one or more tests on one or multiple ne nodes in the sequence might get an error, however error in one or more tests doesn't prevent the subsequent tests or remaining tests on the same ne nodes or on various different ne nodes to execute. In addition, any change to the ordering of the OAM sequence test will lead to different reporting output results therefore the user should have full control on the ordering and "ordered-by user" YANG statement needs to be specified. "ordered-by user" YANG statement indicates that the user is responsible for the ordering on a collection of OAM unitary tests. If two or more tests are to run concurrently, they MUST be run in the order specified by the user. shows the structure of OAM sequence test module:

OAM sequence test

Sequence Test Status State Machine The 'sequence-test-status' state machine is shown in . The state machine includes the following states:

• "planned": The initial state where the sequence test is planned by the management and hasn't been applied to any network element.
• "configured": The state where the sequence test is being configured. This state is triggered when the planned test configuration is applied to one or more network element.
• "ready": The state where the sequence test is ready to be executed. This state is triggered after the planned test configuration is applied and before the test is executed.
• "on-going": The state where the sequence test is currently running. This state is triggered when the test has been executed but the test results haven't been produced.
• "error": The state where an error occurs during the sequence test. This state is triggered when one or more tests haven't been conducted successfully. Implementations may report a more specific error cause using child identities such as "resource-contention" or "priority-conflict".
• "stop": The state where the sequence test is manually stopped. This state is triggered when the test is manually interrupted,, using mechanisms which are outside the scope of this document. A manual stop is not a sequence failure and is not a successful completion; the next cycle, if any, starts from "planned".
• "failure": The state when error occurs for one or more unitary tests in the sequence test while the sequence test continues to execute remaining unitary tests.
• "success": The final state where all Unitary Tests in the sequence test are completed. This state is triggered when all unitary tests in the sequence test have been conducted successfully.

Note that how state transition triggering generation of YANG notifications and how external management and orchestration systems subscribe to these YANG notifications are not in the scope of this document.

OAM sequence test state machine | planned |----->|configured|----->| ready | | +---------+ +----------+ +---------+ | A A A | | | | | | | V | | | | +-------+ | +----------+ | | | +-| error |<--+----------| on-going | | | | +-------+ +----------+ | | | | | | | +--------+ | | | +---------| stop |<------------+ | | +--------+ | | | | | | +---------+ | | +---------| failure |<---------------+ | +---------+ | | | | +---------+ | +-| success |<----------------------------+ +---------+ ]]>

YANG Data Models for Scheduling OAM Tests

YANG Model for Scheduling OAM Unitary Test This module imports typedefs from , and , and it uses references defined in , , , , , . WG List: Author: Luis Miguel Contreras Murillo Author: Victor Lopez Author: Qin Wu "; description "This module defines the 'ietf-oam-unitary-test' YANG model for activation of network diagnosis procedures. 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 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices. "; // RFC Ed.: update the date below with the date of RFC // publication and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove // this note. revision "2026-09-14" { description "Initial version"; reference "RFCXXXX: A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests"; // Update with the correct RFC number when assigned } /* Identities */ identity unitary-test-status { description "Base identity for unitary test status. Note that it only allows extensible error reporting such as resource contention, priority conflict."; } identity planned { base unitary-test-status; description "Identity for planned."; } identity configured { base unitary-test-status; description "Identity for configured."; } identity ready { base unitary-test-status; description "Identity for ready."; } identity on-going { base unitary-test-status; description "Identity for on-going."; } identity stop { base unitary-test-status; description "Identity for stop."; } identity success { base unitary-test-status; description "Identity for success."; } identity error { base unitary-test-status; description "Identity for error."; } identity resource-contention { base error; description "Identity for resource contention conflict. Resource contention conflict is referred to two OAM tests require exclusive access to the same resource at the same time."; } identity priority-conflict { base error; description "Identity for priority based conflict. The prioritization-related conflict occurs when a higher-priority OAM test preempts, defers, or cancels a lower-priority OAM test because they are competing for the exact same network execution resources at the same time."; } identity test-type { description "Base identity of the test type."; } identity connection-oriented-oam { base test-type; description "Base identity of connection oriented oam test type."; reference "RFC 8531: Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols"; } identity connectionless-oam { base test-type; description "Base identity of connectionless oam test type."; reference "RFC 8532: Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications"; } identity in-situ-oam { base test-type; description "Base identity of In Situ OAM test type."; reference "RFC 9617: A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM)"; } identity twamp { base test-type; description "Base identity of TWAMP test type."; reference "RFC 8913: Two-Way Active Measurement Protocol (TWAMP) YANG Data Model"; } identity ip-ping { base connectionless-oam; description "Base identity of IP Ping test type."; reference "RFC 792: nternet Control Message Protocol"; } identity lsp-ping { base connection-oriented-oam; description "Base identity of MPLS LSP Ping test type."; reference "RFC 8029: Detecting Multiprotocol Label Switched (MPLS) Data-Plane Failures"; } identity srmpls-ping { base connection-oriented-oam; description "Base identity of SR MPLS Ping test type."; reference "RFC 9716: Mechanisms for MPLS Ping and Traceroute Procedures in Inter-Domain Segment Routing Networks"; } identity bfd { base test-type; description "Base identity of BFD test type."; reference "RFC 9107: YANG Data Model for Bidirectional Forwarding Detection (BFD)"; } grouping oam-unitary-test { description "Specifies a grouping for OAM unitary test for network diagnosis procedures. This grouping has been defined to allow being imported and reused by other YANG modules."; leaf name { type string; description "Defines the name of the test."; } list ne-config { key ne-id; description "List of node configurations required to enable the unitary tests."; leaf ne-id { type union { type inet:host; type nw:node-id; } description "This is identification of a network node within an autonomous system such as router, switch, firewalls, etc. It should be as fine-grained as possible to both guide the operator and guarantee uniqueness of the network element."; } leaf managed { type boolean; default "true"; description "True if the host can access oam unitary test using the root mount point. This value may not be modifiable in all implementations."; } leaf test-type { type identityref { base test-type; } description "Choose the type of test. Note that for the same unitary test, if the test is conducted on multiple ne node, the test type should be same, but test configuration on each ne node might be different."; } container root { description "Container for mount point."; yangmnt:mount-point "root" { description "Root for models supported per oam unitary test. This mount point may or may not be inline based on the server implementation. When the associated 'managed' leaf is 'false', any operation that attempts to access information below the root should fail with an error-tag of 'access-denied' and an error-app-tag of 'oamut-not-managed'."; } } } } container oam-unitary-tests { description "Container for OAM unitary tests activation for network diagnosis procedures."; list oam-unitary-test { key name; description "List of OAM unitary tests activation for network diagnosis procedures."; uses oam-unitary-test; uses schedule:schedule-status; leaf unitary-test-status { type identityref { base unitary-test-status; } config false; description "Status of the test."; } choice schedule-class { description "Choice based on the type of the time range."; container period { description "The OAM Test takes effect based on a precise period of time."; uses schedule:period-of-time; } container recurrence { description "The OAM test takes effect based on a recurrence rule."; uses schedule:recurrence-utc; } } } } } ]]>

YANG Model for OAM Sequence Test This module imports typedefs from . For the model design overview, please refer to . WG List: Author: Luis Miguel Contreras Murillo Author: Victor Lopez Author: Qin Wu "; description "This module defines the 'ietf-oam-sequence-test' YANG model for management of network diagnosis procedures. 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 (https://www.rfc-editor.org/info/rfcXXXX); see the RFC itself for full legal notices."; // RFC Ed.: update the date below with the date of RFC // publication and remove this note. // RFC Ed.: replace XXXX with actual RFC number and remove // this note. revision "2026-09-14" { description "Initial version"; reference "RFCXXXX"; } /* Identities */ identity sequence-test-status { description "Base identity for sequence-test-status."; } identity planned { base sequence-test-status; description "Identity for planned."; } identity configured { base sequence-test-status; description "Identity for configured."; } identity ready { base sequence-test-status; description "Identity for ready."; } identity on-going { base sequence-test-status; description "Identity for on-going."; } identity stop { base sequence-test-status; description "Identity for stop."; } identity success { base sequence-test-status; description "Identity for success."; } identity failure { base sequence-test-status; description "Identity for failure"; } identity error { base sequence-test-status; description "Identity for error."; } identity resource-contention { base error; description "Identity for resource-contention error cause."; } identity priority { base error; description "Identity for priority error cause."; } /* Data model definition */ container oam-sequence-tests { description "Container for executing a sequence of ietf-oam-unitary-tests N times."; list oam-sequence-test { key "name"; description "List of test sequences. note that each test sequence is local sequence configuration, any later changes to the configured unitary test template in the ietf-oam-unitary-test should not silently change an already configured sequence."; leaf name { type string; description "Unique name for the sequence test."; } list unitary-test { key "name"; description "Reuses the ietf-oam-unitary-tests template for each unitary test in the test seqence. it support both ordered-by user and ordered-by system."; uses "oamut:oam-unitary-test"; } uses schedule:schedule-status; leaf sequence-test-status { type identityref { base sequence-test-status; } config false; description "Status of the sequence test execution."; } choice schedule-class { description "Choice based on the type of the time range."; container period { description "The OAM Test takes effect based on a precise period of time."; uses schedule:period-of-time; } container recurrence { description "The OAM test takes effect based on a recurrence rule."; uses schedule:recurrence-utc; } } } } } ]]>

Using Device Model Within OAM Scheduling Models This section discusses the issues related to reusing device models already defined in IETF within the context of scheduling OAM tests. There are two main approaches to enable OAM scheduling models:

• Importing YANG model into the OAM scheduling models. This approach will copy the device model into the OAM unitary test model to enable the configuration and utilization of the desired OAM test. This approach requires recreating new YANG models for each new test type or variation of the device models.
• Schema-mount allows mounting a data model at a specified location of another (parent) schema. The main difference with importing the YANG modules is that they don't have to be prepared for mounting; any existing modules such as "ietf-twamp" can be mounted without any modifications.

The "test-type" leaf and the schema mount are complementary. The "test-type" leaf (identityref to "test-type") explicitly indicates which OAM test type, and thus which YANG module, is mounted at the "root" mount point for that "ne-config" list entry. Each "ne-config" entry therefore pairs a test-type identity with the corresponding mounted module configuration under "root", so that management systems and implementations know which OAM module applies to that node. This document defines the base identity "test-type" and a set of child identities for OAM test type; YANG modules that augment "ietf-oam-unitary-test" may define additional child identities derived from "test-type" for other OAM test types. As an example, we will use , which defines a YANG data model for TWAMP, to illustrate how device models could be used in .

Operational Considerations

Conflict Resolution and Reporting Among Scheduled OAM Tasks When multiple OAM tasks are scheduled to run concurrently or overlap in time, conflicts may arise due to resource contention or operational constraints. This document leverages the scheduling status groupings defined in the common schedule YANG module (see A Common YANG Data Model for Scheduling]) to detect and report such conflicts. The YANG models defined in this document (both for unitary test and sequence test) use the unitary-test-status and sequence-test-status leaves to indicate the current scheduling state of each OAM task. These leaves are of type identityref, allowing extensible error reporting. If a conflict is detected (e.g., two tests require exclusive access to the same resource at the same time), the server sets the corresponding status to error or to a more specific error-cause identity derived from error: resource-contention for resource conflicts, or priority based conflict for prioritization-related conflicts , . This error-cause indication allows operators and management systems to distinguish the reasons for the failure. Note that it is intention to allow extensibility for the error codes rather than extend states in the state machine. Operators and management systems SHOULD monitor the scheduling status of OAM tasks and take appropriate action if a conflict is reported. To support deterministic operations across heterogeneous multi-vendor environments, implementations SHOULD perform a commit-time validation on multi-node configuration, e.g., if a scheduling conflict (e.g., the number of schedule conflict exceeds the specific threshold) or resource over-allocation is detectable a priori, the configuration commit SHOULD be rejected by the server rather than accepted for delayed resolution. Another example is when manually running OAM test is colliding with previously scheduled OAM tests, we need to make sure to check the existence of schedule tests before running manual OAM testing. In both examples, the conflict MUST be clearly reported via the YANG model status leaves. If a conflict cannot be caught a priori or occurs dynamically during runtime execution, the server resolves the resource friction using a well-defined precedence model. OAM task categories are prioritized according to the following operational hierarchy:

• On-Demand Troubleshooting: Manually triggered diagnostics designed to pinpoint live issues MUST take absolute precedence, overriding and preempting any scheduled or proactive monitoring sequences.
• Birth-Certificate/Verification Tests: Initial service activation verification sequences take secondary precedence, superseding background tasks but yielding to active troubleshooting if system resources are exhausted.
• Proactive SLA Supervision: Routine, recurring performance verification tests operate under lowest relative priority and may be systematically deferred, rescheduled, or canceled when high-priority tasks claim the required execution resources.

When an active test or upcoming schedule is modified or aborted by a higher-priority operation, the server must update the corresponding unitary-test-status or sequence-test-status leaf. It must also log the preempted event alongside an error notification to ensure observability across the network management layer. In addition, the preemption applies only to the OAM sessions being setup using the YANG data models defined in this document, while other OAM sessions being running on the devices through other mechanims should not be preempted (e.g., through CLI or by configuring the device YANG data model directly) to avoid operaetional impact on other OAM sessions.

Coverage of Input Parameters and Output Results The YANG models defined in this document are designed to schedule OAM tests at a network-wide level. The input parameters required to configure and execute specific OAM functions (such as test type, target, and configuration options) are referenced or reused from the existing device-level OAM YANG models (e.g., , , , ). This approach avoids duplication and ensures consistency with established models. Similarly, the output results of OAM tests such as test status, performance metrics, and diagnostic information,are expected to be reported using the mechanisms and data nodes defined in those foundational YANG modules. The scheduling models in this document provide references to these output results and enable their collection and correlation across multiple tests and devices, but do not redefine the detailed input/output parameters of each OAM function. In summary, this document focuses on the scheduling, coordination, and status tracking of OAM tests, while relying on existing YANG models for the detailed specification of test parameters and results.

Use of the Managed Leaf The "managed" leaf in each "ne-config" entry defaults to "true", meaning that the orchestrator or controller hosting this model is expected to configure the device OAM function through the "root" schema-mount point. The orchestrator or controller can rely on the YANG Library (RFC 8525) to discover which structural OAM modules are supported by a network element before scheduling tests. This capability discovery allows the orchestrator or controller to determine supported standard schemas, such as TWAMP or ICMP, and works in conjunction with YANG Schema Mount (RFC 8528) to dynamically mount native OAM modules into the scheduling framework. Operators set "managed" to "false" when the OAM function on that network element is configured outside this model, for example by a device CLI, a local script, or a different controller. In that case, any attempt to access data below "root" fails with error-tag "access-denied" and error-app-tag "oamut-not-managed", as specified in the YANG module. Scheduling of the unitary test or sequence test still applies when "managed" is "false": time constraints and status reporting remain in this model, but the device-level OAM configuration is not pushed through the mount point to support smooth migration. Implementations that cannot disable mount access may keep "managed" as a read-only value of "true".

Performance impact and Operational Guidance for concurrent OAM task scheduling Concurrent OAM task scheduling introduces significant resource strain across managed devices. Management and orchestration systems need to make sure to have sufficient resource before conducting those multiple concurrent OAM tasks. To plan capacity at scale and safeguard network stability, implementations SHOULD adhere to the following operational boundaries:

• Concurrency Limits: Devices SHOULD enforce limits on concurrent active tests to prevent CPU starvation. Active traffic per interface MUST be bounded to a minimal fraction (e.g., <1%) of link capacity. Network-wide tasks MUST be staggered using random jitter to avoid synchronized telemetry and processing spikes.
• Preemptive Control: Implementations SHOULD NOT rely solely on reporting resource-contention errors after a failure. Managed nodes SHOULD apply local rate limiting and preemptive traffic-shaping. If resource thresholds are approached, devices SHOULD automatically defer or back off pending tests, while prioritizing vital keep-alives over ad-hoc diagnostics.
• SLA and Windowing Considerations: High-frequency proactive supervision MUST use various different QoS markings to reflect real line-rate conditions without degrading SLAs. Bulk diagnostics SHOULD run at low priority. Routine supervision is suited for in-service periods, whereas intrusive OAM loopbacks and multi-path tracing SHOULD be restricted to maintenance windows, where false alarms must be suppressed.

Impact on Security Operations Centrally orchestrated and scheduled OAM tests introduce specific traffic patterns—characterized by distinct timing, predictable volumes, and targeted path probing—that differ from normal network traffic. Network operators MUST evaluate the impact of these automated patterns on security operations systems:

• Anomaly Detection & IDS/IPS: Automated OAM traffic may trigger false positives in flow-based Intrusion Detection/Prevention Systems (IDS/IPS) or behavioral anomaly detectors, which might flag rapid, scheduled path probing as network scanning. Operators SHOULD configure security baseline policies to recognize authorized OAM orchestration boundaries or whitelist controlled test sources.
• Packet Capture & Parsing Observability: Centralized scheduling can significantly increase packet volume during test windows. Network monitoring tools, packet capture systems, and protocol parsing MUST be capable of identifying, parsing, and filtering these scheduled OAM packets. This ensures that synthetic test traffic does not overwhelm log storage, degrade packet processing performance, or obscure genuine malicious payloads hidden within traffic flows.

Schedule Health Verification Operators SHOULD follow a post-configuration validation checklist to verify schedule health and configuration deployment. verification focuses on two primary phases:

• Schedule Acceptance Verification: Operators must inspect the root schedule instance to ensure it has been successfully accepted by the controller. This is validated by verifying that the upcoming-occurrence leaf and status counters imported from the ietf-schedule module reflect a valid, upcoming execution timestamp rather than an error or inactive state.
• Mount Application Verification: Operators must verify that the OAM configuration nested under the schema mount root has been successfully propagated to each target network element (ne-id). This is achieved by querying the local state of the mounted OAM unitary test or sequence test modules on individual network elements to confirm that the configuration was applied correctly and the elements are primed for the upcoming schedule trigger.

Operational Considerations for Auditing and Results Tracking To support the accounting and auditing requirements described in Section 2.2 and Section 2.3, the test results of the scheduling model including mounted device-level OAM Test results (e.g., TWAMP Test results in ) or audit nodes (i.e., ne-config list) should be associated with each schedule instance (e.g., 'oam-unitary-test' or 'oam-sequence-test' list instance) to ensure that automated audit tools and operators can seamlessly validate test execution, correlate schedules with actual performance data, and maintain a verifiable audit trail.

Security Considerations This section is modeled after the template described in Section 3.7.1 of . Both "ietf-oam-unitary-test " YANG module and "ietf-oam-sequence-test" YANG module define data models that are designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) and RESTCONF . These YANG-based management protocols (1) MUST use a secure transport layer (e.g., Secure Shell (SSH) , TLS , and QUIC ) and (2) MUST 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. There are a number of data nodes defined in this YANG module that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. The following subtrees and data nodes have particular sensitivities/vulnerabilities:

• /oamut:oam-unitary-tests/oamut:oam-unitary-test: This list specifies all the oam unitary test entries for network diagnosis procedures. Unauthorized write access to this list can allow intruders to modify the entries so as to forge an unitary test name that does not exist or maliciously delete an existing unitary test, which could be used to craft an attack.
• /oamts:oam-sequence-test/oamts:sequence-test: This list specifies all the oam sequence test entries for network diagnosis procedures. Unauthorized write access to this list can allow intruders to modify the entries so as to forge an sequence test name that does not exist or maliciously delete an existing sequence test, which could be used to craft an attack.

This YANG module uses groupings from other YANG modules that define nodes that may be considered sensitive or vulnerable in network environments. Refer to the Security Considerations of for information as to which nodes may be considered sensitive or vulnerable in network environments.

IANA Considerations

Updates to the IETF XML Registry for New YANG Module IANA is requested to register the following URI in the "ns" registry within the "IETF XML Registry" group .

Updates to the YANG Module Names Registry for New YANG Module IANA is requested to register the following YANG module in the "YANG Module Names" registry within the "YANG Parameters" registry group.

Implementation Status There are currently no known implementations of the YANG modules defined in this document. This section is intended to track implementation experience as it becomes available and is expected to be removed if the document is published as an RFC.

Acknowledgments Thanks Joe Clark, Daniel King, Qiufang Ma, Italo Busi, Fung Lim, Xiao Min, Saumya Dikshit for valuable review and comments. The work of Luis M. Contreras has been partially supported by the European Union’s Horizon Program through the 6G DAta and ML operations automation via an end-to-end AI framework (6G-DALI) Project under Grant 101192750.

References Normative References 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. As the IETF continues to produce and standardize different Operations, Administration, and Maintenance (OAM) protocols and technologies, various qualifiers and modifiers are prepended to the OAM abbreviation. While, at first glance, the most used qualifiers appear to be well understood, the same qualifier may be interpreted differently in different contexts. A case in point is the qualifiers "in-band" and "out-of-band", which have their origins in the radio lexicon, and which have been extrapolated into other communication networks. This document recommends not to use these two terms when referring to OAM. This document considers some common qualifiers and modifiers that are prepended, within the context of packet networks, to the OAM abbreviation and lays out guidelines for their use in IETF documents. This document extends RFC 6291 by adding to the guidelines for the use of the term "OAM" with qualifiers. It does not modify any part of RFC 6291. This document lists architectural and functional requirements for the Operations, Administration, and Maintenance of MPLS Transport Profile. These requirements apply to pseudowires, Label Switched Paths, and Sections. [STANDARDS-TRACK] The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices. OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements. However, it does not accommodate round-trip or two-way measurements. This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities. The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances. [STANDARDS-TRACK] This document defines common types and groupings that are meant to be used for scheduling purposes, such as events, policies, services, or resources based on date and time. For the sake of better modularity, the YANG module includes a set of recurrence-related groupings with varying levels of representation (i.e., from basic to advanced) to accommodate a variety of requirements. It also defines groupings for validating requested schedules and reporting scheduling statuses. 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 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. 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 introduces a collection of common data types to be used with the YANG data modeling language. This document obsoletes RFC 6021. 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). This document defines a mechanism that adds the schema trees defined by a set of YANG modules onto a mount point defined in the schema tree in another YANG module. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance criteria (e.g., latency) are becoming as critical to data path selection as other metrics and constraints. These metrics are associated with the Service Level Agreement (SLA) between customers and service providers. The link bandwidth utilization (the total bandwidth of a link in actual use for the forwarding) is another important factor to consider during path computation. IGP Traffic Engineering (TE) Metric Extensions describe mechanisms with which network performance information is distributed via OSPF and IS-IS, respectively. The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Client (PCC) requests. This document describes the extension to PCEP to carry latency, delay variation, packet loss, and link bandwidth utilization as constraints for end-to-end path computation. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network performance information (e.g., link propagation delay) is becoming critical to data path selection. This document describes common extensions to RFC 3630 "Traffic Engineering (TE) Extensions to OSPF Version 2" and RFC 5329 "Traffic Engineering Extensions to OSPF Version 3" to enable network performance information to be distributed in a scalable fashion. The information distributed using OSPF TE Metric Extensions can then be used to make path selection decisions based on network performance. Note that this document only covers the mechanisms by which network performance information is distributed. The mechanisms for measuring network performance information or using that information, once distributed, are outside the scope of this document. In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document defines a YANG data model and associated mechanisms enabling subscriber-specific subscriptions to a publisher's event streams. Applying these elements allows a subscriber to request and receive a continuous, customized feed of publisher-generated information. This document describes a mechanism that allows subscriber applications to request a continuous and customized stream of updates from a YANG datastore. Providing such visibility into updates enables new capabilities based on the remote mirroring and monitoring of configuration and operational state. This document defines a collection of common data types to be used with the YANG data modeling language. It includes several new type definitions and obsoletes RFC 6991. This document provides guidelines for authors and reviewers of specifications containing YANG data models, including IANA-maintained YANG modules. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG modules. This document obsoletes RFC 8407; it also updates RFC 8126 by providing additional guidelines for writing the IANA considerations for RFCs that specify IANA-maintained YANG modules. 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 Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack. This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document. The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary. At first glance, the acronym "OAM" seems to be well-known and well-understood. Looking at the acronym a bit more closely reveals a set of recurring problems that are revisited time and again. This document provides a definition of the acronym "OAM" (Operations, Administration, and Maintenance) for use in all future IETF documents that refer to OAM. There are other definitions and acronyms that will be discussed while exploring the definition of the constituent parts of the "OAM" term. This memo documents an Internet Best Current Practice. This document gives an overview of the IETF network management standards and summarizes existing and ongoing development of IETF Standards Track network management protocols and data models. The document refers to other overview documents, where they exist and classifies the standards for easy orientation. The purpose of this document is, on the one hand, to help system developers and users to select appropriate standard management protocols and data models to address relevant management needs. On the other hand, the document can be used as an overview and guideline by other Standard Development Organizations or bodies planning to use IETF management technologies and data models. This document does not cover Operations, Administration, and Maintenance (OAM) technologies on the data-path, e.g., OAM of tunnels, MPLS Transport Profile (MPLS-TP) OAM, and pseudowire as well as the corresponding management models. This document is not an Internet Standards Track specification; it is published for informational purposes. Continuity Check, Proactive Connectivity Verification, and Remote Defect Indication functionalities are required for MPLS Transport Profile (MPLS-TP) Operations, Administration, and Maintenance (OAM). Continuity Check monitors a Label Switched Path for any loss of continuity defect. Connectivity Verification augments Continuity Check in order to provide confirmation that the desired source is connected to the desired sink. Remote Defect Indication enables an end point to report, to its associated end point, a fault or defect condition that it detects on a pseudowire, Label Switched Path, or Section. This document specifies specific extensions to Bidirectional Forwarding Detection (BFD) and methods for proactive Continuity Check, Continuity Verification, and Remote Defect Indication for MPLS-TP pseudowires, Label Switched Paths, and Sections using BFD as extended by this memo. [STANDARDS-TRACK] This document describes the format of a set of control messages used in ICMPv6 (Internet Control Message Protocol). ICMPv6 is the Internet Control Message Protocol for Internet Protocol version 6 (IPv6). [STANDARDS-TRACK] This document describes Virtual Circuit Connectivity Verification (VCCV), which provides a control channel that is associated with a pseudowire (PW), as well as the corresponding operations and management functions (such as connectivity verification) to be used over that control channel. VCCV applies to all supported access circuit and transport types currently defined for PWs. [STANDARDS-TRACK] This document describes a simple and efficient mechanism that can be used to detect data plane failures in Multi-Protocol Label Switching (MPLS) Label Switched Paths (LSPs). There are two parts to this document: information carried in an MPLS "echo request" and "echo reply" for the purposes of fault detection and isolation, and mechanisms for reliably sending the echo reply. [STANDARDS-TRACK] This document describes the Simple Two-way Active Measurement Protocol (STAMP), which enables the measurement of both one-way and round-trip performance metrics, like delay, delay variation, and packet loss. This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321. In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets. 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. This document presents a base YANG data model for connection-oriented Operations, Administration, and Maintenance (OAM) protocols. It provides a technology-independent abstraction of key OAM constructs for such protocols. The model presented here can be extended to include technology-specific details. This guarantees uniformity in the management of OAM protocols and provides support for nested OAM workflows (i.e., performing OAM functions at different levels through a unified interface). The YANG data model in this document conforms to the Network Management Datastore Architecture. This document presents a base YANG Data model for the management of Operations, Administration, and Maintenance (OAM) protocols that use connectionless communications. The data model is defined using the YANG data modeling language, as specified in RFC 7950. It provides a technology-independent abstraction of key OAM constructs for OAM protocols that use connectionless communication. The base model presented here can be extended to include technology-specific details. There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at the same level or different levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same level through a unified interface). This document presents a retrieval method YANG data model for connectionless Operations, Administration, and Maintenance (OAM) protocols. It provides technology-independent RPC operations for OAM protocols that use connectionless communication. The retrieval methods model herein presented can be extended to include technology- specific details. There are two key benefits of this approach: First, it leads to uniformity between OAM protocols. Second, it supports both nested OAM workflows (i.e., performing OAM functions at different or the same levels through a unified interface) as well as interactive OAM workflows (i.e., performing OAM functions at the same levels through a unified interface). The Transport Profile of Multiprotocol Label Switching (MPLS-TP) is a packet-based transport technology based on the MPLS Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane architectures. This document describes a framework to support a comprehensive set of Operations, Administration, and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM requirements for fault, performance, and protection-switching management and that do not rely on the presence of a control plane. This document is a product of a joint Internet Engineering Task Force (IETF) / International Telecommunications Union Telecommunication Standardization Sector (ITU-T) effort to include an MPLS Transport Profile within the IETF MPLS and Pseudowire Emulation Edge-to-Edge (PWE3) architectures to support the capabilities and functionalities of a packet transport network as defined by the ITU-T. This document is not an Internet Standards Track specification; it is published for informational purposes. This document specifies a reference framework for Operations, Administration, and Maintenance (OAM) in Transparent Interconnection of Lots of Links (TRILL) networks. The focus of the document is on the fault and performance management aspects of TRILL OAM. This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK] This document describes a simple and efficient mechanism to detect data-plane failures in Multiprotocol Label Switching (MPLS) Label Switched Paths (LSPs). It defines a probe message called an "MPLS echo request" and a response message called an "MPLS echo reply" for returning the result of the probe. The MPLS echo request is intended to contain sufficient information to check correct operation of the data plane and to verify the data plane against the control plane, thereby localizing faults. This document obsoletes RFCs 4379, 6424, 6829, and 7537, and updates RFC 1122. 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. This document describes the Connectivity Provisioning Profile (CPP) and proposes a CPP template to capture IP/MPLS connectivity requirements to be met within a service delivery context (e.g., Voice over IP or IP TV). The CPP defines the set of IP transfer parameters to be supported by the underlying transport network together with a reachability scope and bandwidth/capacity needs. Appropriate performance metrics, such as one-way delay or one-way delay variation, are used to characterize an IP transfer service. Both global and restricted reachability scopes can be captured in the CPP. Such a generic CPP template is meant to (1) facilitate the automation of the service negotiation and activation procedures, thus accelerating service provisioning, (2) set (traffic) objectives of Traffic Engineering functions and service management functions, and (3) improve service and network management systems with 'decision- making' capabilities based upon negotiated/offered CPPs. 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 provides a framework for the operation and management of Layer 3 Virtual Private Networks (L3VPNs). This framework intends to produce a coherent description of the significant technical issues that are important in the design of L3VPN management solutions. The selection of specific approaches, and making choices among information models and protocols are outside the scope of this document. This memo provides information for the Internet community. Constraint-based path computation is a fundamental building block for traffic engineering systems such as Multiprotocol Label Switching (MPLS) and Generalized Multiprotocol Label Switching (GMPLS) networks. Path computation in large, multi-domain, multi-region, or multi-layer networks is complex and may require special computational components and cooperation between the different network domains. This document specifies the architecture for a Path Computation Element (PCE)-based model to address this problem space. This document does not attempt to provide a detailed description of all the architectural components, but rather it describes a set of building blocks for the PCE architecture from which solutions may be constructed. This memo provides information for the Internet community. In situ Operations, Administration, and Maintenance (IOAM) is an example of an on-path hybrid measurement method. IOAM defines a method for producing operational and telemetry information that may be exported using the in-band or out-of-band method. RFCs 9197 and 9326 discuss the data fields and associated data types for IOAM. This document defines a YANG module for the configuration of IOAM functions. This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). This document defines the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specifies it using the YANG data modeling language (RFC 7950). The data model is compliant with the Network Management Datastore Architecture (NMDA). This document defines an extension to BGP route reflectors. On route reflectors, BGP route selection is modified in order to choose the best route from the standpoint of their clients, rather than from the standpoint of the route reflectors themselves. Depending on the scaling and precision requirements, route selection can be specific for one client, common for a set of clients, or common for all clients of a route reflector. This solution is particularly applicable in deployments using centralized route reflectors, where choosing the best route based on the route reflector's IGP location is suboptimal. This facilitates, for example, a "best exit point" policy ("hot potato routing"). The solution relies upon all route reflectors learning all paths that are eligible for consideration. BGP route selection is performed in the route reflectors based on the IGP cost from configured locations in the link-state IGP. Watsen Networks Huawei Nokia This document defines a YANG-based configuration template mechanism whereby repetitive configuration data can be factored out into templates and applied where needed. This avoids the redundant definition of identical configuration and ensures the consistency of it, thus allowing configuration data to be managed more conveniently and efficiently.

Examples This section includes a non-exhaustive list of examples to illustrate the use of the models defined in this document.

Create a TWAMP OAM test defines a YANG model for TWAMP. The following example demonstrates how scheduled test results from mounted device models surface through NMDA retrieval from the operational datastore. It shows a single OAM unitary test (one schedule, one unitary-test-status) for a recurring TWAMP performance measurement. Two ne-config entries target the session-sender and session-reflector nodes respectively; both use test-type "twamp", with different mounted TWAMP subtrees under root. Within the sender configuration, "Test1" and "Test2" are two test-session list entries in the mounted TWAMP model on one node—they are not two unitary tests and not two sequence steps. Separate unitary tests or sequence steps would be used only when each procedure needs its own schedule or place in an ordered diagnosis workflow (for example, ping then TWAMP). This example uses the "twamp" identity defined in the ietf-oam-unitary-test module (derived from "test-type"). The TWAMP device model configuration is mounted at the "root" of each "ne-config" entry and has been applied in the operational datastore. An example of a request message body to create a TWAMP OAM test is shown in . Session-Sender and Session-Reflector as expanded for illustrative purposes. The TWAMP Test scheduled in this configuration is a one-hour performance monitoring test that runs daily at 9 AM UTC. This test session is configured to start on October 17, 2023, at 09:00 UTC and recur at the same time every day. The duration of each test run is one hour, as specified by the unint32 format "3600", with the test status marked as "configured". The test provides insight into network performance by monitoring the selected parameters, allowing for the detection of any potential degradations in service quality over time.

Example of a Message Body to Create a TWAMP OAM test

Ping OAM Test Template Ping OAM Test Template can be defined using YANG-based configuration template specified in as follows:

Example of OAM Test Template Definition ]]>

Template application is indicated using the "apply-templates" metadata. For example, the following OAM unitary tests configuration may be provided with the container node "oam-unitary-tests" applying the template defined in . As described in , a template node can be overriden by having its value changed, but it can't be deleted. As an example of overriding a node in a template, a client may configure physically present OAM Unitary Tests "lsp-ping", "ip-ping" and "srmpls-ping" inheriting the template defined in , but the "ne-id" value of "srmpls-ping" needs to be "203.0.113.4":

Example of Applying OAM Test Template lsp-ping eth0 true ... ip-ping srmpls-ping 203.0.113.4 ... ]]>

And the above OAM Unitary Tests configuration renders the following expanded configuration: lsp-ping eth0 true ... 2025-10-01T08:00:00Z hourly ip-ping eth1 true ... 2025-10-01T08:00:00Z hourly srmpls-ping 203.0.113.4 ... ]]>

Change between Revision v10 - v11

• Clarify the relationship between OAM unitary test and OAM sequence test;
• Clarify TWAMP Appendix example (multi-node and multi-session within one unitary test);

v07 - v08 * Change ne-id data type to inet:host;

• Add Child identities for unitary-test-type;
• Add references for imported types and used reference in the YANG model section;
• Change recurrence-basic to recurrence-utc;
• Point counter wrapp-around to RFC9922;
• Explain when operators set managed to false;
• Align stop transitions in unitary and sequence state machines;
• Operational Consideration Update;
• Sample OAM Test Scheduling Network Model Usage;

v06 - v07

• Some Editorial changes based on Hansai's comments;
• Add schedule status descrption in the section OAM Unitary Test;
• Change temporal parameter into YANG statement;
• Change to Both Frequency and Interval are required;
• Fix indentation issue based on Hansai's comments;
• Fix indentation issue based on Hansai's comments;
• Change two yang module prefixes;
• Follow Security Considerations template defined by RFC 9907;
• OAM Teminology Consistency;
• Fix ne-id description;