]> Telefonica

luismiguel.contrerasmurillo@telefonica.com

Nokia

victor.lopez@nokia.com

Operations and Management Operations and Management Area Working Group OAM Scheduling Test sequences This document defines a YANG data model for network diagnosis on-demand using Operations, Administration, and Maintenance (OAM) tests. This document defines both 'oam-unitary-test' and 'oam-test-sequence' data models to enable activation of network diagnosis procedures. 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 functionalities of the network management. Given the emerging of data models and their utilization in Service Provider's management, the management of OAM tests represent also an area of interest for operators, which requires to be defined as a data model. OAM functionalities provide the means to identify and isolate faults, measure and report of performance. defines the three main areas involved in OAM:

• Fault management, which allows network operators to quickly identify and isolate faults in the network. The OAM framework defines mechanisms for fault detection and isolation, such as 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 frame delay measurement, frame delay variation measurement, and frame loss measurement.
• Security management defines mechanisms to protect OAM communications from unauthorized access and tampering.

defines several use cases for OAM tools, including:

• Continuity Check: This function verifies that a path exists between two points in a network and that the path is operational.
• Loopback: This function allows a device to loop back a received packet back to the sender for diagnostic purposes.
• Link Trace: This function allows a network operator to trace a path through a network from one device to another.
• Performance Monitoring: This function allows a network operator to monitor the performance of a network and to identify and diagnose performance issues.
• Security Management: This function allows a network operator to protect OAM communications from unauthorized access and tampering.
• Configuration Management: This function allows a network operator to manage the configuration of network devices.

More recently, Incident Management also considers the possibility of incident diagnosis, which can be favoured by dynamic invocation of OAM tests. , and, defined YANG models for OAM technologies. On the other hand, 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, PBB-TE OAM, and G.7713.1 OAM. provides a generic YANG data model that can be used to configure, control and monitor connectionless OAM protocols such as BFD (Bidirectional Forwarding Detection), LBM (Loopback Messaging) and VCCV (Virtual Circuit Connectivity Verification). provides a YANG data model that can be used to retrieve information related to OAM protocols such as Bidirectional Forwarding Detection (BFD), Loopback Messaging (LBM) and Virtual Circuit Connectivity Verification (VCCV). specifies a YANG data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). Previous RFCs defined the parameters required for each of the different tests that are used in network elements today. This document covers how to use OAM for network-wide use cases. Following, some illustrative examples are presented. The YANG data model resulting from this document will conform to the Network Management Datastore Architecture (NMDA) .

Terminology and Notations This document assumes that the reader is familiar with the contents of , , and . Following terms are used for the representation of this data model.

• OAM unitary test: it is a set of parameters that define a type of OAM test to be invoked. As an example, it includes the type test, configuration parameters, and target results.
• OAM test sequence: it is a set of OAM unitary tests that are run based on a set of time constraints, number of repetitions, order, and reporting outputs.

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-tests	RFCXXX
oamts	ietf-oam-test-sequence	RFCXXX
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.

Network-wide OAM Use Cases

Troubleshooting After the detection of a problem in the network, OAM tests are performed to find the root cause for the detected issue. However, a problem detected can be caused by a variety of factors, such as a misconfiguration, hardware failure, or a software bug. OAM tests can help to find the root cause by testing specific components of the network and looking for anomalies or issues. There are a variety of different OAM tests that can be executed depending on the nature of the scenario. For example, if the issue is related to a L2 capability, tests can be run to check the status of the path via Ethernet Linktrace and later run an Ethernet Loopback to a concrete network element. If these tests are correct, the operator may want to check the availability of the service or its performance. Even though the troubleshooting process may be different depending on the problem detected, there are certain common procedures or logic that can be executed in order to narrow down the cause of the problem.

Birth Certificate The aim of a birth certificate process is to validate that all relevant parameters are correct for a specific 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 and meets the requirements defined by the operator. The process requires running a set of OAM tests to verify that the service is performing as expected. The set of OAM tests done 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, Ethernet CFM tests will be executed. Once the birth certificate process has been completed and the OAM tests have been run, the test results are stored as part of the documentation process performed by the operator.

Proactive Supervision There are communication services that require to fulfill Service Level Agreements (SLAs). SLAs define performance parameters that the service must fulfill in order to meet the requirements of the customer or end user. Proactive testing ensures the SLAs are met. Proactive supervision requires running tests on service components to identify and resolve issues before they impact the customer or end user, or to minimize the impact of the end user. Proactive testing can 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.

Performance-based Path Routing Path Computation Elements (PCEs) allow computing end-to-end paths in a network. PCEs are used to facilitate traffic engineering and can be used to 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. OAM techniques allow obtaining link metrics like delay and loss which can be used in the PCE algorithms.

Modelling the Scheduling of OAM Tests This document proposes two models: OAM unitary test and OAM test sequence models.

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. Inside 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. The test types are out of the scope of this document. Moreover, each OAM unitary test has two temporal parameters: "period-of-time" and "recurrence". Both are imported from the "ietf-schedule" module from . "period-of-time" identifies the period values that contain a precise period of time, while "recurrence" identifies the properties that contain a recurrence rule specification. "unitary-test-status" enumerates the state of the OAM unitary test. contains the tree of the proposed model. Tree diagrams used in this document follow the notation defined in .

OAM unitary test

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.
• "configured": The state where the test is being configured.
• "ready": The state where the test is ready to be executed.
• "on-going": The state where the test is currently running.
• "stop": The state where the test is manually stopped.
• "error": The state where an error occurs during the test.
• "finished": The final state where the test is completed.

OAM unitary test state machine | planned |----->|configured|----->| ready | | +---------+ +----------+ +---------+ | A | | | | | V | | +-------+ | +----------+ | ------| error |<--+----------| on-going | | | +-------+ +----------+ | | | | V | | +---------+ +--------+ | +--| finished|<-----| stop |<------------+ +---------+ +--------+ | A | | | +----------------------------------+ ]]>

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 a OAM unitary test type with its concrete parameters. Each OAM test sequence has two temporal parameters: "period-of-time" and "recurrence". Both are imported from the "ietf-schedule" module from . "period-of-time" identifies the period values that contain a precise period of time, while "recurrence" identifies the properties that contain a recurrence rule specification. "unitary-test-status" enumerates the state of the OAM test. Finally, "test-sequence-status" shows the state of the OAM test sequence. An example of the proposed structure .

OAM test sequence

The 'test-sequence-status' state machine is shown in . The state machine includes the following states:

• "planned": The initial state where the test is planned.
• "configured": The state where the test is being configured.
• "ready": The state where the test is ready to be executed.
• "on-going": The state where the test is currently running.
• "stop": The state where the test is manually stopped.
• "success": The success state when all unitary tests were successful.
• "failure": The success state when One or more tests in the sequence got an error.
• "error": The state where an error occurs during the test.

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

YANG Data Models for Scheduling OAM Tests

YANG Models Overview This document proposes two models: OAM unitary test and OAM test sequence. OAM unitary test is a set of parameters that define a type of OAM test to be invoked. As an example, it includes the type test, configuration parameters, and target results. The OAM test sequences are a set of OAM unitary tests that are run based on a set of time constraints, number of repetitions, order, and reporting outputs.

YANG Model for Scheduling OAM Unitary Test WG List: Author: Luis Miguel Contreras Murillo Author: Victor Lopez "; description "This module defines the 'ietf-oam-unitary-test' YANG model for activation of network diagnosis procedures. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/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 "2024-07-05" { 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 } grouping oam-unitary-test { description "This grouping is defined for OAM unitary test for network diagnosis procedures."; leaf name { type string; description "Name for the test."; } choice test-type { mandatory true; description "Choose the type of test."; // Import OAM models from RFCs RFC8531, RFC8532 and RFC8533 } } 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:period-of-time; uses schedule:recurrence; leaf unitary-test-status { type enumeration { enum "planned" { description "The test is planned."; } enum "configure" { description "The test is configured."; } enum "ready" { description "The test status is ready."; } enum "ongoing" { description "The test is ongoing."; } enum "stop" { description "The test is stopped."; } enum "finish" { description "The test is finished."; } enum "error" { description "The test has an error."; } } description "Status of the test."; } } } } ]]>

YANG Model for OAM Test Sequence WG List: Author: Luis Miguel Contreras Murillo Author: Victor Lopez "; description "This module defines the 'oam-unitary-test' YANG model for activation of network diagnosis procedures. Copyright (c) 2024 IETF Trust and the persons identified as authors of the code. All rights reserved. Redistribution and use in source and binary forms, with or without modification, is permitted pursuant to, and subject to the license terms contained in, the Revised BSD License set forth in Section 4.c of the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info). This version of this YANG module is part of RFC XXXX (https://www.rfc-editor.org/info/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 "2024-07-05" { description "Initial version"; reference "RFCXXXX"; // Update with the correct RFC number when assigned } // Data model definition container oam-test-sequence { description "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"; description "References to the ietf-oam-unitary-tests."; uses "oamut:oam-unitary-test"; leaf numexecutions { type uint32; default 1; description "Number of times the test sequence should be executed."; } } uses schedule:period-of-time; uses schedule:recurrence-utc; leaf test-sequence-status { type enumeration { enum "planned" { description "The test sequence is planned."; } enum "configured" { description "The test sequence is configured."; } enum "ready" { description "The test sequence is ready."; } enum "ongoing" { description "The test sequence status is ongoing."; } enum "stop" { description "The test sequenceis stopped."; } enum "success" { description "All tests in the sequence were successful."; } enum "failure" { description "One or more tests in the sequence got an error."; } enum "error" { description "The test sequence status has an error."; } } description "Status of the test sequence execution."; } } } } ]]>

Using Device Mode Within OAM Scheduling Models This section discusses the problematic of 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 desire OAM test. This approach requires to recreate 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. As an exmaple, we will use , which defines a YANG data model for TWAMP, to illustrate how device models could be used.

Security Considerations The YANG module targeted in this document defines a schema for data that is designed to be accessed via network management protocols such as NETCONF or RESTCONF . The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) . The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS . The NETCONF access control model 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. In which refers to the scheduling of the tests, security considerations in are also applicable here.

IANA Considerations TBC

Implementation Status This section will be used to track the status of the implementations of the model. It is aimed at being removed if the document becomes RFC.

Normative References 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] 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] CMCC Huawei Ciena A network incident refers to an unexpected interruption of a network service, degradation of a network service quality, or sub-health of a network service. Different data sources including alarms, metrics, and other anomaly information can be aggregated into a few amount of network incidents by data correlation analysis and the service impact analysis. This document defines a YANG Module for the network incident lifecycle management. This YANG module is meant to provide a standard way to report, diagnose, and help resolve network incidents for the sake of network service health and 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). 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). Datastores are a fundamental concept binding the data models written in the YANG data modeling language to network management protocols such as the Network Configuration Protocol (NETCONF) and RESTCONF. This document defines an architectural framework for datastores based on the experience gained with the initial simpler model, addressing requirements that were not well supported in the initial model. This document updates RFC 7950. YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols. This document describes the syntax and semantics of version 1.1 of the YANG language. YANG version 1.1 is a maintenance release of the YANG language, addressing ambiguities and defects in the original specification. There are a small number of backward incompatibilities from YANG version 1. This document also specifies the YANG mappings to the Network Configuration Protocol (NETCONF). This document defines an abstract (generic, or base) YANG data model for network/service topologies and inventories. The data model serves as a base model that is augmented with technology-specific details in other, more specific topology and inventory data models. This document defines a YANG data model for Layer 3 network topologies. This document defines a YANG data model for representing, retrieving, and manipulating Traffic Engineering (TE) Topologies. The model serves as a base model that other technology-specific TE topology models can augment. 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. Huawei Huawei Orange Lancaster University This document defines a common schedule YANG module which is designed to be applicable for scheduling purposes such as event, policy, services, or resources based on date and time. For the sake of better modularity, the module includes basic, intermediate, and advanced versions of recurrence related groupings. 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. 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 describes a method for invoking and running the Network Configuration Protocol (NETCONF) within a Secure Shell (SSH) session as an SSH subsystem. This document obsoletes RFC 4742. [STANDARDS-TRACK] This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. [STANDARDS-TRACK] The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) 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 protocol access for particular users to a pre-configured subset of all available NETCONF protocol operations and content. This document defines such an access control model. [STANDARDS-TRACK]

Acknowledgments TODO acknowledge.