Operations and Management Area Working Group L. M. Contreras Internet-Draft Telefonica Intended status: Standards Track V. Lopez Expires: 18 March 2027 Nokia Q. Wu Huawei 14 September 2026 A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests draft-ietf-opsawg-scheduling-oam-tests-08 Abstract 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- test-sequence' YANG modules to manage the lifecycle of network diagnosis procedures, intended for use by external management and orchestration systems (including SDN controllers and network orchestrators), rather than by individual network nodes. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://vlopezalvarez.github.io/draft-ietf-opsawg-scheduling-oam- tests/draft-ietf-opsawg-scheduling-oam-tests.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-opsawg-scheduling-oam- tests/. Discussion of this document takes place on the Operations and Management Area Working Group Working Group mailing list (mailto:opsawg@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/opsawg/. Subscribe at https://www.ietf.org/mailman/listinfo/opsawg/. Source for this draft and an issue tracker can be found at https://github.com/vlopezalvarez/draft-ietf-opsawg-scheduling-oam- tests. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Contreras, et al. Expires 18 March 2027 [Page 1] Internet-Draft Scheduling OAM YANG September 2026 Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 18 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Notations . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 6 1.3. Prefix in Data Node Names . . . . . . . . . . . . . . . . 6 2. Sample OAM Test Scheduling Network Model Usage . . . . . . . 7 3. Network-wide OAM Use Cases . . . . . . . . . . . . . . . . . 8 3.1. Troubleshooting . . . . . . . . . . . . . . . . . . . . . 8 3.2. Birth Certificate . . . . . . . . . . . . . . . . . . . . 9 3.3. Proactive Supervision . . . . . . . . . . . . . . . . . . 9 3.4. Performance-based Traffic Engineering and Routing . . . . 10 4. Modelling the Scheduling of OAM Tests . . . . . . . . . . . . 10 4.1. OAM Unitary Test . . . . . . . . . . . . . . . . . . . . 10 4.2. OAM Test Sequence . . . . . . . . . . . . . . . . . . . . 14 5. YANG Data Models for Scheduling OAM Tests . . . . . . . . . . 18 5.1. YANG Model for Scheduling OAM Unitary Test . . . . . . . 18 5.2. YANG Model for OAM Test Sequence . . . . . . . . . . . . 24 6. Using Device Model Within OAM Scheduling Models . . . . . . . 28 7. Operational Considerations . . . . . . . . . . . . . . . . . 28 7.1. Conflict Resolution and Reporting Among Scheduled OAM Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . 29 Contreras, et al. Expires 18 March 2027 [Page 2] Internet-Draft Scheduling OAM YANG September 2026 7.2. Coverage of Input Parameters and Output Results . . . . . 30 7.3. Use of the Managed Leaf . . . . . . . . . . . . . . . . . 30 7.4. Performance impact and Operational Guidance for concurrent OAM task scheduling . . . . . . . . . . . . . . . . . . . 31 7.5. Impact on Security Operations . . . . . . . . . . . . . . 32 7.6. Schedule Health Verification . . . . . . . . . . . . . . 32 7.7. Operational Considerations for Auditing and Results Tracking . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 9.1. Updates to the IETF XML Registry for New YANG Module . . 34 9.2. Updates to the YANG Module Names Registry for New YANG Module . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. Implementation Status . . . . . . . . . . . . . . . . . . . . 35 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 35 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Normative References . . . . . . . . . . . . . . . . . . . . . 35 Informative References . . . . . . . . . . . . . . . . . . . . 38 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 41 A.1. Create a TWAMP OAM test . . . . . . . . . . . . . . . . . 42 A.2. Ping OAM Test Template . . . . . . . . . . . . . . . . . 44 Appendix B. Change between Revision . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 1. Introduction Operations, Administration, and Maintenance (OAM) tasks are fundamental functions of the network management (see, e.g., [RFC7276]). 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 [RFC8969], 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 [RFC6291] and further characterized according to the classification guidelines in [RFC10014]. 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, [RFC6632]). For example, [RFC5860] defines the three main areas involved in OAM: Contreras, et al. Expires 18 March 2027 [Page 3] Internet-Draft Scheduling OAM YANG September 2026 * 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. [RFC7276] 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 [ITU-T-Y1731], Ethernet OAM Continuity Check [IEEE-8021Q], MPLS-TP BFD CC [RFC6428]. * 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 [RFC0792], [RFC4443], VCCV Ping [RFC5085], LSP Ping [RFC4379] or Ethernet Loopback [IEEE-8021Q]. * 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 [ITU-T-Y1731] or IP traceroute [RFC0792], [RFC4443]. * 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 [RFC5357], STAMP [RFC8762], Alternative Marking [RFC9341], IOAM (In Situ OAM) [RFC9197], or Y.1731 DMM/SLM [ITU-T-Y1731] can obtain performance measurements. More recently, Incident Management [I-D.ietf-nmop-network-incident-yang] focuses on the network incident diagnosis, which can be favored by dynamic invocation of OAM tests. [RFC8531], [RFC8532], [RFC8533] defined YANG models for OAM technologies: Contreras, et al. Expires 18 March 2027 [Page 4] Internet-Draft Scheduling OAM YANG September 2026 o [RFC8531] "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 [RFC6371], TRILL OAM [RFC7174], PBB-TE OAM [IEEE-8021ag], and T-MPLS [ITU-T-G81131] OAM. o [RFC8532] "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) [RFC5880], LBM (Loopback Messaging)[IEEE-8021ag], and VCCV (Virtual Circuit Connectivity Verification)[RFC5085]. o [RFC8533] "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)[RFC5880], LBM (Loopback Messaging) [IEEE-8021ag], and VCCV (Virtual Circuit Connectivity Verification) [RFC5085]. These OAM related YANG data models 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 [RFC8531], [RFC8532], and [RFC8533]. By leveraging these foundational models, this document specifies two YANG data 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 [RFC8531], [RFC8532], and [RFC8533], this document builds upon the generic scheduling framework defined in [RFC9922]. 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 test sequence models defined in this document, enabling precise scheduling, repetition, and conflict reporting for OAM tasks in a network-wide context. The YANG data models resulting from this document will conform to the Network Management Datastore Architecture (NMDA) [RFC8342]. 1.1. Terminology and Notations This document assumes that the reader is familiar with the contents of [RFC7950] "The YANG 1.1 Data Modeling Language". Following terms are used for the representation of this data model. Contreras, et al. Expires 18 March 2027 [Page 5] Internet-Draft Scheduling OAM YANG September 2026 o OAM Unitary Test: A set of parameters that define a type of OAM test to be invoked. As an example, it includes the test type, configuration parameters, and target results. o OAM Test Sequence: A set of OAM Unitary Tests that are run based on a set of time constraints, number of repetitions, order, and reporting outputs. Tree diagrams used in this document follow the notation defined in [RFC8340]. This document adopts the OAM characterization defined in [RFC10014]: 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 [RFC10014]. 1.2. 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 [RFC2119], [RFC8174] when, and only when, they appear in all capitals, as shown here. 1.3. 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. Contreras, et al. Expires 18 March 2027 [Page 6] Internet-Draft Scheduling OAM YANG September 2026 +========+========================+===========+ | Prefix | Yang Module | Reference | +========+========================+===========+ | oamut | ietf-oam-unitary-test | RFCXXXX | +--------+------------------------+-----------+ | oamts | ietf-oam-test-sequence | RFCXXXX | +--------+------------------------+-----------+ | yang | ietf-yang-types | [RFC6991] | +--------+------------------------+-----------+ Table 1: Prefixes and Corresponding YANG Modules 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. 2. 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 [RFC8969] [RFC6241] [RFC8040]. From that standpoint, and considering the architecture depicted in Figure 1, The goal of this document is to provide a mechanism to via a YANG-based interface, manage the lifecycle of network diagnosis procedure from the network controller to network elements with a focus on scheduling Network Diagnosis. In addition, the network controller use schema mount mechanism [RFC8528] to retrieve ietf-yang-library data from the underlying network element and instantiate specific OAM modules the network element supports under the designated data node (labeled as a mount-point). 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 [RFC8528]. Contreras, et al. Expires 18 March 2027 [Page 7] Internet-Draft Scheduling OAM YANG September 2026 +-----------------+ | Customer | +--------+--------+ Customer Service Models | (e.g., L3SM, L2SM) | +--------+--------+ | Service | | Orchestration | +------+---+------+ Network Models | | OAM Test Scheduling (e.g., L3NM, L2NM) | | Network Model +------+---+------+ | Network | | Controller | +--------+--------+ | +---------------------+---------------------+ | Network | +-------------------------------------------+ Figure 1: OAM Test Scheduling Network Model Usage 3. 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 [RFC10014]. The following illustrative examples are provided. 3.1. Troubleshooting After the detection of a problem [RFC9940] 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, Contreras, et al. Expires 18 March 2027 [Page 8] Internet-Draft Scheduling OAM YANG September 2026 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. 3.2. 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 [RFC5357] will be used, while if the service is an E-LINE, ITU-T Y.1731 Ethernet PM tests [ITU-T-Y1731] 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. 3.3. 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) [RFC7297] and Network Slice Service [RFC9543]). As part of service fulfillment and assurance (e.g., Section 2.3.3 of [RFC4176]), 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 Contreras, et al. Expires 18 March 2027 [Page 9] Internet-Draft Scheduling OAM YANG September 2026 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). 3.4. Performance-based Traffic Engineering and Routing Path Computation Elements (PCEs) are used to compute end-to-end paths in a network [RFC4655]. 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 [RFC8233], taking into account its constraints and requirements. In addition to TE Metric Extensions in OSPF [RFC7471] or IS-IS [RFC7810], OAM techniques also allow obtaining link metrics like delay and loss which can be used in the PCE algorithms. 4. Modelling the Scheduling of OAM Tests This document specifies two models: OAM Unitary Test and OAM Test Sequence models. 4.1. 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 references a test type with its concrete parameters. In addition, each OAM unitary test has two temporal parameters: "period" and "recurrence". Both are imported from the "ietf-schedule" module from [RFC9922]. "period" identifies the one Contreras, et al. Expires 18 March 2027 [Page 10] Internet-Draft Scheduling OAM YANG September 2026 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 periodic troubleshooting. Moreover, "schedule:schedule-status" grouping has been imported from [RFC9922] to describe common properties of scheduling status. Wrap-around of the "counter" and "failure-counter" leaves is as specified in [RFC9922]. "unitary-test-status" indicates the state of the OAM unitary test (see the state machine in Figure 3). 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. Figure 2 shows the structure of OAM Unitary Test module: Contreras, et al. Expires 18 March 2027 [Page 11] Internet-Draft Scheduling OAM YANG September 2026 module: ietf-oam-unitary-test +--rw oam-unitary-tests +--rw oam-unitary-test* [name] +--rw name string +--rw ne-config* [ne-id] | +--rw ne-id inet:host | +--rw managed? boolean | +--rw test-type? identityref | +--rw root +--rw state? identityref +--rw version? uint16 +--rw schedule-type? identityref +--ro local-time? yang:date-and-time +--ro last-update? yang:date-and-time +--ro counter? yang:counter32 +--ro last-occurrence? yang:date-and-time +--ro upcoming-occurrence? yang:date-and-time +--ro last-failed-occurrence? yang:date-and-time +--ro failure-counter? yang:counter32 +--ro unitary-test-status? identityref +--rw (schedule-class)? +--:(period) | +--rw period | +--rw period-description? string | +--rw period-start? yang:date-and-time | +--rw time-zone-identifier? sys:timezone-name | +--rw (period-type)? | +--:(explicit) | | +--rw period-end? yang:date-and-time | +--:(duration) | +--rw duration? duration +--:(recurrence) +--rw recurrence +--rw recurrence-first | +--rw start-time-utc? yang:date-and-time | +--rw duration? uint32 +--rw (recurrence-end)? | +--:(until) | | +--rw utc-until? yang:date-and-time | +--:(count) | +--rw count? uint32 +--rw recurrence-description? string +--rw frequency? identityref +--rw interval? uint32 Figure 2: Tree Structure of OAM Unitary Test Contreras, et al. Expires 18 March 2027 [Page 12] Internet-Draft Scheduling OAM YANG September 2026 The 'unitary-test-status' state machine is shown in Figure 3. 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 the network element. * "configured": The state where the test is being configured. This state is triggered when the planned test configuration is applied to the network element. * "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. * "stop": The state where the test is manually stopped. This state is triggered when the test is manually interrupted. A manual stop is not a successful completion and is not an execution error; the next cycle, if any, starts from "planned". * "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". * "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. Contreras, et al. Expires 18 March 2027 [Page 13] Internet-Draft Scheduling OAM YANG September 2026 +---------+ +----------+ +---------+ +->| planned |----->|configured|----->| ready | | +---------+ +----------+ +---------+ | A A A | | | | | | | V | | | | +-------+ | +----------+ | | | ---| error |<--+----------| on-going | | | | +-------+ +----------+ | | | | | | | +--------+ | | | -----------| stop |<------------+ | | +--------+ | | | | | +---------+ | +-| success |<-----------------------------+ +---------+ Figure 3: OAM Unitary Test State Machine 4.2. OAM Test Sequence The OAM test sequence model consists of a collection of OAM unitary tests that are executed based on specified time constraints, repetitions, ordering, and reporting outputs. These sequences provide a structured approach to running multiple OAM tests in a coordinated manner. Each OAM test sequence references an OAM unitary test type with its concrete parameters. Each OAM test sequence has two temporal parameters related to time constraints: "period" and "recurrence" and one constraint related to ordering: "ordered-by user". Time constraints parameters are imported from the "ietf-schedule" module from [RFC9922]. "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. "ordered-by user" YANG statement indicates that the user is responsible for the ordering on a collection of OAM unitary tests. "test-sequence-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 "execution-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 test sequence model consists of a collection of OAM Contreras, et al. Expires 18 March 2027 [Page 14] Internet-Draft Scheduling OAM YANG September 2026 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 test sequence will lead to different reporting output results therefore the user should have full control on the ordering and "ordered-by user" parameters needs to be specified. If two or more tests are to run concurrently, they MUST be run in the order specified by the user. Figure 4 shows the structure of OAM Test Sequence module: Contreras, et al. Expires 18 March 2027 [Page 15] Internet-Draft Scheduling OAM YANG September 2026 module: ietf-oam-test-sequence +--rw oam-test-sequence +--rw test-sequence* [name] +--rw name string +--rw test-ref* [name] | +--rw name string | +--rw ne-config* [ne-id] | +--rw ne-id inet:host | +--rw managed? boolean | +--rw test-type? identityref | +--rw root +--rw state? identityref +--rw version? uint16 +--rw schedule-type? identityref +--ro local-time? yang:date-and-time +--ro last-update? yang:date-and-time +--ro counter? yang:counter32 +--ro last-occurrence? yang:date-and-time +--ro upcoming-occurrence? yang:date-and-time +--ro last-failed-occurrence? yang:date-and-time +--ro failure-counter? yang:counter32 +--ro test-sequence-status? identityref +--rw (schedule-class)? +--:(period) | +--rw period | +--rw period-description? string | +--rw period-start? yang:date-and-time | +--rw time-zone-identifier? sys:timezone-name | +--rw (period-type)? | +--:(explicit) | | +--rw period-end? yang:date-and-time | +--:(duration) | +--rw duration? duration +--:(recurrence) +--rw recurrence +--rw recurrence-first | +--rw start-time-utc? yang:date-and-time | +--rw duration? uint32 +--rw (recurrence-end)? | +--:(until) | | +--rw utc-until? yang:date-and-time | +--:(count) | +--rw count? uint32 +--rw recurrence-description? string +--rw frequency? identityref +--rw interval? uint32 +--rw execution-count? uint32 Contreras, et al. Expires 18 March 2027 [Page 16] Internet-Draft Scheduling OAM YANG September 2026 Figure 4: OAM Test Sequence The 'test-sequence-status' state machine is shown in Figure 5. 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 the network element. * "configured": The state where the test is being configured. This state is triggered when the planned test configuration is applied to the network element. * "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. * "stop": The state where the test is manually stopped. This state is triggered when the test is manually interrupted. A manual stop is not a sequence failure and is not a successful completion; the next cycle, if any, starts from "planned". * "success": The final state where all Unitary Tests are completed. This state is triggered when all tests have been conducted successfully. * "failure": The state when one or more tests in the sequence got an error while the sequence continued to execute remaining tests. * "error": The state where an error occurs during the 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". 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. Contreras, et al. Expires 18 March 2027 [Page 17] Internet-Draft Scheduling OAM YANG September 2026 +---------+ +----------+ +---------+ +->| planned |----->|configured|----->| ready | | +---------+ +----------+ +---------+ | A A A | | | | | | | V | | | | +-------+ | +----------+ | | | +-| error |<--+----------| on-going | | | | +-------+ +----------+ | | | | | | | +--------+ | | | ----------| stop |<------------+ | | +--------+ | | | | | | +---------+ | | ----------| failure |<---------------+ | +---------+ | | | | +---------+ | +-| success |<----------------------------+ +---------+ Figure 5: OAM Test Sequence state machine 5. YANG Data Models for Scheduling OAM Tests 5.1. YANG Model for Scheduling OAM Unitary Test This module imports typedefs from [RFC9922], [RFC8528] and [RFC8294], and it references [RFC8531], [RFC8532], [RFC9617], [RFC8913], [RFC9228], [RFC9107]. file ietf-oam-unitary-test@2026-01-13.yang module ietf-oam-unitary-test { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-oam-unitary-test"; prefix "oamut"; // reference ietf-netmod-schedule-yang import ietf-schedule { prefix schedule; reference "RFC 9922: A Common YANG Data Model for Scheduling"; } import ietf-routing-types { prefix rt-types; reference Contreras, et al. Expires 18 March 2027 [Page 18] Internet-Draft Scheduling OAM YANG September 2026 "RFC 8294: Common YANG Data Types for the Routing Area"; } import ietf-yang-schema-mount { prefix yangmnt; reference "RFC 8528: YANG Schema Mount"; } import ietf-inet-types { prefix inet; reference "RFC 9911: Common YANG Data Types"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; contact "WG Web: 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. The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in BCP 14 (RFC 2119) (RFC 8174) when, and only when, Contreras, et al. Expires 18 March 2027 [Page 19] Internet-Draft Scheduling OAM YANG September 2026 they appear in all capitals, as shown here."; // 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-01-13" { description "Initial version"; reference "RFCXXXX: A YANG Data Model for Network Diagnosis by Scheduling Sequences of OAM Tests"; // Update with the correct RFC number when assigned } /* Identities */ identity unitary-test-status { description "Base identity for unitary-test-status."; } 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; Contreras, et al. Expires 18 March 2027 [Page 20] Internet-Draft Scheduling OAM YANG September 2026 description "Identity for success."; } identity error { base unitary-test-status; description "Identity for error."; } identity resource-contention { base error; description "Identity for resource contention."; } identity priority { base error; description "Identity for priority."; } identity basic-test-type { description "Base identity of basic test type."; } identity connection-oriented-oam { base unitary-test-type; description "Base identity of connection oriented oam test type."; reference "RFC 8531: Connection-Oriented OAM YANG Data Model"; } identity connectionless-oam { base unitary-test-type; description "Base identity of connectionless oam test type."; reference "RFC 8532: Generic YANG Data Model for Connectionless OAM"; } identity in-situ-oam { base unitary-test-type; description "Base identity of In Situ OAM test type."; reference "RFC 9617: In Situ OAM (IOAM) YANG Data Model"; } identity twamp { Contreras, et al. Expires 18 March 2027 [Page 21] Internet-Draft Scheduling OAM YANG September 2026 base unitary-test-type; description "Base identity of TWAMP test type."; reference "RFC 8913: Two-Way Active Measurement Protocol (TWAMP) YANG Data Model"; } identity lsp-ping { base unitary-test-type; description "Base identity of MPLS LSP Ping test type."; reference "RFC 9228: MPLS LSP Ping YANG Data Model"; } identity bfd { base unitary-test-type; description "Base identity of BFD test type."; reference "RFC 9107: BFD (Bidirectional Forwarding Detection) YANG Model"; } grouping oam-unitary-test { description "Specifies a grouping for OAM unitary test for network diagnosis procedures."; 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 inet:host; 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 Contreras, et al. Expires 18 March 2027 [Page 22] Internet-Draft Scheduling OAM YANG September 2026 "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 basic-test-type; } description "Choose the type of test."; } 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 SHALL 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."; Contreras, et al. Expires 18 March 2027 [Page 23] Internet-Draft Scheduling OAM YANG September 2026 } 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; } } } } } 5.2. YANG Model for OAM Test Sequence This module imports typedefs from [RFC9922]. file ietf-oam-test-sequence@2026-01-13.yang module ietf-oam-test-sequence { yang-version 1.1; namespace "urn:ietf:params:xml:ns:yang:ietf-oam-test-sequence"; prefix "oamts"; import ietf-oam-unitary-test { prefix "oamut"; reference "RFC XXXX: A YANG Data Model for Network Diagnosis using Scheduled Sequences of OAM Tests"; } import ietf-schedule { prefix "schedule"; reference "RFC 9922: A Common YANG Data Model for Scheduling"; } organization "IETF OPSAWG (Operations and Management Area Working Group)"; Contreras, et al. Expires 18 March 2027 [Page 24] Internet-Draft Scheduling OAM YANG September 2026 contact "WG Web: WG List: Author: Luis Miguel Contreras Murillo Author: Victor Lopez Author: Qin Wu "; description "This module defines the 'ietf-oam-test-sequence' 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-01-13" { description "Initial version"; reference "RFCXXXX"; } /* Identities */ identity test-sequence-status { description "Base identity for test-sequence-status."; } identity planned { base test-sequence-status; description "Identity for planned."; } identity configured { Contreras, et al. Expires 18 March 2027 [Page 25] Internet-Draft Scheduling OAM YANG September 2026 base test-sequence-status; description "Identity for configured."; } identity ready { base test-sequence-status; description "Identity for ready."; } identity on-going { base test-sequence-status; description "Identity for on-going."; } identity stop { base test-sequence-status; description "Identity for stop."; } identity success { base test-sequence-status; description "Identity for success."; } identity failure { base test-sequence-status; description "Identity for failure"; } identity error { base test-sequence-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-test-sequence { description Contreras, et al. Expires 18 March 2027 [Page 26] Internet-Draft Scheduling OAM YANG September 2026 "Container for executing a sequence of ietf-oam-unitary-tests N times."; list test-sequence { key "name"; description "List of test sequences."; leaf name { type string; description "Unique name for the test sequence."; } list test-ref { key "name"; ordered-by user; description "References to the ietf-oam-unitary-tests."; uses "oamut:oam-unitary-test"; } uses schedule:schedule-status; leaf test-sequence-status { type identityref { base test-sequence-status; } config false; description "Status of the test sequence 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; leaf execution-count { type uint32; description "If set, limits how many times the test sequence is executed for this recurrence. If the leaf is absent, there is no limit: executions follow the recurrence until the test is removed from the system."; Contreras, et al. Expires 18 March 2027 [Page 27] Internet-Draft Scheduling OAM YANG September 2026 } } } } } } 6. 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 "basic-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 "basic-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 "basic-test-type" for other OAM test types. As an example, we will use [RFC8913], which defines a YANG data model for TWAMP, to illustrate how device models could be used in Appendix A.1. 7. Operational Considerations Contreras, et al. Expires 18 March 2027 [Page 28] Internet-Draft Scheduling OAM YANG September 2026 7.1. 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 [RFC9922] 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 test sequence) use the unitary-test-status and test-sequence-status leaves to indicate the current scheduling state of each OAM task. These leaves are of type identityref, allowing extensible 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 status to error or to a more specific error-cause identity derived from error: resource-contention for resource conflicts, or priority for prioritization-related conflicts. This error-cause indication allows operators and management systems to distinguish the reasons for the failure. Operators and management systems SHOULD monitor the scheduling status of OAM tasks and take appropriate action if a conflict is reported. The resolution of conflicts (e.g., rescheduling, prioritization, or cancellation) is implementation-dependent, but the conflict MUST be clearly reported via the YANG model status leaves. To support deterministic operations across heterogeneous multi-vendor environments, implementations RECOMMEND performing a commit-time validation, 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. 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. Contreras, et al. Expires 18 March 2027 [Page 29] Internet-Draft Scheduling OAM YANG September 2026 * 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 test-sequence-status leaf. It must also log the preempted event alongside an error notification to ensure observability across the network management layer. 7.2. 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., [RFC8531], [RFC8532], [RFC8533], [RFC8913]). 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. 7.3. 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. Contreras, et al. Expires 18 March 2027 [Page 30] Internet-Draft Scheduling OAM YANG September 2026 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 test sequence 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. Implementations that cannot disable mount access may keep "managed" as a read-only value of "true". 7.4. 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 [ITU-T-Y1731] and multi-path tracing SHOULD be restricted to maintenance windows, where false alarms must be suppressed. Contreras, et al. Expires 18 March 2027 [Page 31] Internet-Draft Scheduling OAM YANG September 2026 7.5. 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. 7.6. 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 test sequence modules on individual network elements to confirm that the configuration was applied correctly and the elements are primed for the upcoming schedule trigger. Contreras, et al. Expires 18 March 2027 [Page 32] Internet-Draft Scheduling OAM YANG September 2026 7.7. 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-model result or audit nodes should be associated with each schedule 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. 8. Security Considerations This section is modeled after the template described in Section 3.7.1 of [RFC9907]. Both "ietf-oam-unitary-test " YANG module and "ietf-oam-test- sequence" YANG module define data models that are designed to be accessed via YANG-based management protocols, such as the Network Configuration Protocol (NETCONF) [RFC6241] and RESTCONF [RFC8040]. These YANG-based management protocols (1) have to use a secure transport layer (e.g., Secure Shell (SSH) [RFC4252], TLS [RFC8446], and QUIC [RFC9000]) and (2) have to use mutual authentication. The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. 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. Contreras, et al. Expires 18 March 2027 [Page 33] Internet-Draft Scheduling OAM YANG September 2026 * /oamts:oam-test-sequence/oamts:test-sequence: This list specifies all the oam test sequence entries for network diagnosis procedures. Unauthorized write access to this list can allow intruders to modify the entries so as to forge an test sequence name that does not exist or maliciously delete an existing test sequence, 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 [RFC9922] for information as to which nodes may be considered sensitive or vulnerable in network environments. 9. IANA Considerations 9.1. 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 [RFC3688]. URI: urn:ietf:params:xml:ns:yang:ietf-oam-unitary-test Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. URI: urn:ietf:params:xml:ns:yang:ietf-oam-test-sequence Registrant Contact: The IESG. XML: N/A, the requested URI is an XML namespace. 9.2. 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 [RFC6020] within the "YANG Parameters" registry group. Name: ietf-oam-unitary-test Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-oam-unitary-test Prefix: oamut Reference: RFC XXXX Name: ietf-oam-test-sequence Maintained by IANA? N Namespace: urn:ietf:params:xml:ns:yang:ietf-oam-test-sequence Prefix: oamts Reference: RFC XXXX Contreras, et al. Expires 18 March 2027 [Page 34] Internet-Draft Scheduling OAM YANG September 2026 10. 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 and Fung Lim 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252, January 2006, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC5860] Vigoureux, M., Ed., Ward, D., Ed., and M. Betts, Ed., "Requirements for Operations, Administration, and Maintenance (OAM) in MPLS Transport Networks", RFC 5860, DOI 10.17487/RFC5860, May 2010, . Contreras, et al. Expires 18 March 2027 [Page 35] Internet-Draft Scheduling OAM YANG September 2026 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)", RFC 6020, DOI 10.17487/RFC6020, October 2010, . [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., and A. Bierman, Ed., "Network Configuration Protocol (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7471] Giacalone, S., Ward, D., Drake, J., Atlas, A., and S. Previdi, "OSPF Traffic Engineering (TE) Metric Extensions", RFC 7471, DOI 10.17487/RFC7471, March 2015, . [RFC7810] Previdi, S., Ed., Giacalone, S., Ward, D., Drake, J., and Q. Wu, "IS-IS Traffic Engineering (TE) Metric Extensions", RFC 7810, DOI 10.17487/RFC7810, May 2016, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8233] Dhody, D., Wu, Q., Manral, V., Ali, Z., and K. Kumaki, "Extensions to the Path Computation Element Communication Protocol (PCEP) to Compute Service-Aware Label Switched Paths (LSPs)", RFC 8233, DOI 10.17487/RFC8233, September 2017, . [RFC8294] Liu, X., Qu, Y., Lindem, A., Hopps, C., and L. Berger, "Common YANG Data Types for the Routing Area", RFC 8294, DOI 10.17487/RFC8294, December 2017, . Contreras, et al. Expires 18 March 2027 [Page 36] Internet-Draft Scheduling OAM YANG September 2026 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . [RFC8342] Bjorklund, M., Schoenwaelder, J., Shafer, P., Watsen, K., and R. Wilton, "Network Management Datastore Architecture (NMDA)", RFC 8342, DOI 10.17487/RFC8342, March 2018, . [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, . [RFC8528] Bjorklund, M. and L. Lhotka, "YANG Schema Mount", RFC 8528, DOI 10.17487/RFC8528, March 2019, . [RFC8531] Kumar, D., Wu, Q., and Z. Wang, "Generic YANG Data Model for Connection-Oriented Operations, Administration, and Maintenance (OAM) Protocols", RFC 8531, DOI 10.17487/RFC8531, April 2019, . [RFC8532] Kumar, D., Wang, Z., Wu, Q., Ed., Rahman, R., and S. Raghavan, "Generic YANG Data Model for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8532, DOI 10.17487/RFC8532, April 2019, . [RFC8533] Kumar, D., Wang, M., Wu, Q., Ed., Rahman, R., and S. Raghavan, "A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications", RFC 8533, DOI 10.17487/RFC8533, April 2019, . [RFC8913] Civil, R., Morton, A., Rahman, R., Jethanandani, M., and K. Pentikousis, Ed., "Two-Way Active Measurement Protocol (TWAMP) YANG Data Model", RFC 8913, DOI 10.17487/RFC8913, November 2021, . Contreras, et al. Expires 18 March 2027 [Page 37] Internet-Draft Scheduling OAM YANG September 2026 [RFC8969] Wu, Q., Ed., Boucadair, M., Ed., Lopez, D., Xie, C., and L. Geng, "A Framework for Automating Service and Network Management with YANG", RFC 8969, DOI 10.17487/RFC8969, January 2021, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9107] Raszuk, R., Ed., Decraene, B., Ed., Cassar, C., Åman, E., and K. Wang, "BGP Optimal Route Reflection (BGP ORR)", RFC 9107, DOI 10.17487/RFC9107, August 2021, . [RFC9228] Crocker, D., Ed., "Delivered-To Email Header Field", RFC 9228, DOI 10.17487/RFC9228, April 2022, . [RFC9617] Zhou, T., Ed., Guichard, J., Brockners, F., and S. Raghavan, "A YANG Data Model for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9617, DOI 10.17487/RFC9617, August 2024, . [RFC9907] Bierman, A., Boucadair, M., Ed., and Q. Wu, "Guidelines for Authors and Reviewers of Documents Containing YANG Data Models", BCP 216, RFC 9907, DOI 10.17487/RFC9907, March 2026, . [RFC9922] Ma, Q., Ed., Wu, Q., Boucadair, M., Ed., and D. King, "A Common YANG Data Model for Scheduling", RFC 9922, DOI 10.17487/RFC9922, March 2026, . [RFC10014] Pignataro, C., Farrel, A., and T. Mizrahi, "Guidelines for Characterizing the Term "OAM"", BCP 161, RFC 10014, DOI 10.17487/RFC10014, June 2026, . Informative References Contreras, et al. Expires 18 March 2027 [Page 38] Internet-Draft Scheduling OAM YANG September 2026 [I-D.ietf-nmop-network-incident-yang] Hu, T., Contreras, L. M., Wu, Q., Davis, N., and C. Feng, "A YANG Data Model for Network Incident Management", Work in Progress, Internet-Draft, draft-ietf-nmop-network- incident-yang-14, 18 August 2026, . [I-D.tt-netmod-yang-config-templates] Watsen, K., Ma, Q., and D. Rajaram, "YANG Configuration Templates", Work in Progress, Internet-Draft, draft-tt- netmod-yang-config-templates-03, 3 July 2026, . [IEEE-8021ag] "IEEE Standard for Local and Metropolitan Area Networks – Bridges and Bridged Networks – Connectivity Fault Management", 2007, . [IEEE-8021Q] "IEEE Standard for Local and metropolitan area networks - Media Access Control (MAC) Bridges and Virtual Bridged Local Area Networks", October 2012, . [ITU-T-G81131] "Operation and maintenance mechanism for T-MPLS layer networks", April 2007, . [ITU-T-Y1731] "OAM Functions and Mechanisms for Ethernet-based Networks", 13 June 2023, . [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC792, September 1981, . [RFC4176] El Mghazli, Y., Ed., Nadeau, T., Boucadair, M., Chan, K., and A. Gonguet, "Framework for Layer 3 Virtual Private Networks (L3VPN) Operations and Management", RFC 4176, DOI 10.17487/RFC4176, October 2005, . Contreras, et al. Expires 18 March 2027 [Page 39] Internet-Draft Scheduling OAM YANG September 2026 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, DOI 10.17487/RFC4379, February 2006, . [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, . [RFC4655] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, . [RFC5085] Nadeau, T., Ed. and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", RFC 5085, DOI 10.17487/RFC5085, December 2007, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, D., and S. Mansfield, "Guidelines for the Use of the "OAM" Acronym in the IETF", BCP 161, RFC 6291, DOI 10.17487/RFC6291, June 2011, . [RFC6371] Busi, I., Ed. and D. Allan, Ed., "Operations, Administration, and Maintenance Framework for MPLS-Based Transport Networks", RFC 6371, DOI 10.17487/RFC6371, September 2011, . [RFC6428] Allan, D., Ed., Swallow, G., Ed., and J. Drake, Ed., "Proactive Connectivity Verification, Continuity Check, and Remote Defect Indication for the MPLS Transport Profile", RFC 6428, DOI 10.17487/RFC6428, November 2011, . [RFC6632] Ersue, M., Ed. and B. Claise, "An Overview of the IETF Network Management Standards", RFC 6632, DOI 10.17487/RFC6632, June 2012, . Contreras, et al. Expires 18 March 2027 [Page 40] Internet-Draft Scheduling OAM YANG September 2026 [RFC7174] Salam, S., Senevirathne, T., Aldrin, S., and D. Eastlake 3rd, "Transparent Interconnection of Lots of Links (TRILL) Operations, Administration, and Maintenance (OAM) Framework", RFC 7174, DOI 10.17487/RFC7174, May 2014, . [RFC7276] Mizrahi, T., Sprecher, N., Bellagamba, E., and Y. Weingarten, "An Overview of Operations, Administration, and Maintenance (OAM) Tools", RFC 7276, DOI 10.17487/RFC7276, June 2014, . [RFC7297] Boucadair, M., Jacquenet, C., and N. Wang, "IP Connectivity Provisioning Profile (CPP)", RFC 7297, DOI 10.17487/RFC7297, July 2014, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., and T. Zhou, "Alternate-Marking Method", RFC 9341, DOI 10.17487/RFC9341, December 2022, . [RFC9543] Farrel, A., Ed., Drake, J., Ed., Rokui, R., Homma, S., Makhijani, K., Contreras, L., and J. Tantsura, "A Framework for Network Slices in Networks Built from IETF Technologies", RFC 9543, DOI 10.17487/RFC9543, March 2024, . [RFC9940] Davis, N., Ed., Farrel, A., Ed., Graf, T., Wu, Q., and C. Yu, "Some Key Terms for Network Fault and Problem Management", RFC 9940, DOI 10.17487/RFC9940, April 2026, . Appendix A. Examples This section includes a non-exhaustive list of examples to illustrate the use of the models defined in this document. Contreras, et al. Expires 18 March 2027 [Page 41] Internet-Draft Scheduling OAM YANG September 2026 A.1. Create a TWAMP OAM test [RFC8913] defines a YANG model for TWAMP. The following example demonstrates how scheduled test results look like from mounted device models surface through NMDA retrieval. This example uses the "twamp" identity defined in the ietf-oam-unitary-test module (derived from "basic-test-type") to indicate the test type; the TWAMP device model is mounted at the "root" of each "ne-config" entry. The example contains the information for the four configurations (Control-Client, Server, Session-Sender and Session-Reflector). An example of a request message body to create a TWAMP OAM test is shown in Figure 6. 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 ISO 8601 format "PT1H", 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. =============== NOTE: '\' line wrapping per RFC 8792 ================ { "ietf-oam-unitary-test:oam-unitary-tests": { "oam-unitary-test": [ { "name": "TWAMP-Test-scheduled-daily", "recurrence": { "recurrence-first": "2023-10-17T09:00:00Z", "duration": "PT1H", "recurrence-description": "TWAMP Test Reccurence, Daily at \ 9 AM UTC", "frequency": "oam-types:daily", "interval": 1, "unitary-test-status": "configured", "ne-config": [ { "ne-id": "203.0.113.3", "managed": "true", "test-type": "twamp", "twamp": { "session-sender": { "admin-state": true, "test-session": [ { Contreras, et al. Expires 18 March 2027 [Page 42] Internet-Draft Scheduling OAM YANG September 2026 "name": "Test1", "ctrl-connection-name": "RouterA", "fill-mode": "zero", "number-of-packets": 900, "periodic-interval": 1, "sent-packets": 2, "rcv-packets": 2, "last-sent-seq": 1, "last-rcv-seq": 1 }, { "name": "Test2", "ctrl-connection-name": "RouterA", "fill-mode": "random", "number-of-packets": 900, "lambda": 1, "max-interval": 2, "sent-packets": 21, "rcv-packets": 21, "last-sent-seq": 20, "last-rcv-seq": 20 } ] } } }, { "ne-id": "203.0.113.4", "managed": "true", "test-type": "twamp", "twamp": { "session-reflector": { "admin-state": true, "test-session": [ { "sid": 1232, "sender-ip": "203.0.113.3", "sender-udp-port": 54000, "reflector-ip": "203.0.113.4", "reflector-udp-port": 55000, "parent-connection-client-ip": "203.0.113.1", "parent-connection-client-tcp-port": 16341, "parent-connection-server-ip": "203.0.113.2", "parent-connection-server-tcp-port": 862, "test-packet-dscp": 32, "sent-packets": 2, "rcv-packets": 2, "last-sent-seq": 1, Contreras, et al. Expires 18 March 2027 [Page 43] Internet-Draft Scheduling OAM YANG September 2026 "last-rcv-seq": 1 }, { "sid": 178943, "sender-ip": "203.0.113.1", "sender-udp-port": 54001, "reflector-ip": "192.0.2.2", "reflector-udp-port": 55001, "parent-connection-client-ip": "203.0.113.1", "parent-connection-client-tcp-port": 16341, "parent-connection-server-ip": "203.0.113.2", "parent-connection-server-tcp-port": 862, "test-packet-dscp": 32, "sent-packets": 21, "rcv-packets": 21, "last-sent-seq": 20, "last-rcv-seq": 20 } ] } } } ] }} ] } } Figure 6: Example of a Message Body to Create a TWAMP OAM test A.2. Ping OAM Test Template Ping OAM Test Template can be defined using YANG-based configuration template specified in [I-D.tt-netmod-yang-config-templates] as follows: Contreras, et al. Expires 18 March 2027 [Page 44] Internet-Draft Scheduling OAM YANG September 2026 Figure 7: 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 Figure 7. As described in [I-D.tt-netmod-yang-config-templates], 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 Figure 7, but the "ne-id" value of "srmpls-ping" needs to be "203.0.113.4": Contreras, et al. Expires 18 March 2027 [Page 45] Internet-Draft Scheduling OAM YANG September 2026 lsp-ping eth0 true ... ip-ping srmpls-ping 203.0.113.4 ... Figure 8: Example of Applying OAM Test Template And the above OAM Unitary Tests configuration renders the following expanded configuration: Contreras, et al. Expires 18 March 2027 [Page 46] Internet-Draft Scheduling OAM YANG September 2026 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 ... Appendix B. Change between Revision 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; Contreras, et al. Expires 18 March 2027 [Page 47] Internet-Draft Scheduling OAM YANG September 2026 * 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; Authors' Addresses Luis M. Contreras Telefonica Email: luismiguel.contrerasmurillo@telefonica.com Victor Lopez Nokia Email: victor.lopez@nokia.com Qin Wu Huawei Email: bill.wu@huawei.com Contreras, et al. Expires 18 March 2027 [Page 48]