A YANG Data Model for Scenario-based Network Resilience Validation

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

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 6 May 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

Network resilience refers to the ability of a network to absorb and contain disruptions, maintain acceptable service levels, and restore services within defined objectives [I-D.zhao-opsawg-network-resilience-ps].¶

Existing protection and recovery mechanisms improve network availability, but their presence does not necessarily guarantee service continuity under complex disruptive conditions. For example, multiple simultaneous failures may exceed available backup capacity, or recovery mechanisms may depend on control or management functions that are unavailable during a disruption.¶

Network resilience validation therefore requires evaluating service behavior under explicitly defined failure and degradation scenarios.¶

Such validation may be performed through simulation, emulation, or isolated laboratory testing. Although these environments may use different techniques, their evaluation results need a common representation to support interpretation and comparison.¶

IETF benchmarking methodologies, such as [RFC6414] and [RFC8456], provide examples of specifying test conditions, performance metrics, and reporting requirements. However, resilience validation systems may use different representations of disruptive scenarios and evaluation results, limiting interoperability.¶

This document addresses this gap by defining a vendor-neutral YANG data model for describing network resilience validation scenarios and reporting their outcomes.¶

The objective is to standardize what conditions are evaluated, what service requirements are assessed, and how the observed outcomes are represented, without standardizing how a validation engine executes the test.¶

2. Scope and Standardization Points

This document specifies a declarative information model for scenario-based network resilience validation.¶

The initial scope covers validation within one administrative domain using simulation, emulation, or isolated laboratory environments.¶

The model standardizes four information elements:¶

1. Validation Scenario: Identifies the scenario revision, network and service context, and traffic profile against which validation is performed.¶

2. Disruptive Conditions: Describes the affected resources, impairment types, event timing, and conditions required to verify disruption realization.¶

3. Evaluation Criteria: Specifies the evaluated services, performance metrics, measurement methods, observation windows, and acceptance thresholds.¶

4. Validation Results: Records disruption realization, observed service performance, evaluation verdicts, and supporting evidence.¶

These elements constitute a common validation contract that can be exchanged between heterogeneous validation systems.¶

        +--------------------------------+
        |       Validation Scenario      |
        |   Identity / Context / Traffic |
        +--------------------------------+
                       |
             +---------+---------+
             |                   |
             v                   v
   +-------------------+  +---------------------+
   | Disruptions       |  | Evaluation Criteria |
   | Targets / Timing  |  | Metrics / Thresholds|
   +-------------------+  +---------------------+
             |                   |
             +---------+---------+
                       |
                       v
        +--------------------------------+
        |      Validation Environment    |
        |           (External)           |
        +--------------------------------+
                       |
                       v
        +--------------------------------+
        |       Validation Report        |
        | Events / Measurements / Verdict|
        +--------------------------------+

This specification does not define network topology or inventory models, traffic generators, simulation engines, recovery algorithms, or fault-injection protocols.¶

It also does not define a standardized interface for starting or stopping validation runs.¶

A validation scenario is a declarative data object. Creating, storing, or modifying a scenario MUST NOT, by itself, trigger a disruption or change network forwarding, control, or management state.¶

3. Evaluation Semantics

This section defines the common rules for interpreting validation scenarios and results.¶

These rules ensure that different validation implementations can evaluate the same declared conditions and report outcomes with consistent meanings.¶

4. YANG Data Model

This section specifies an initial YANG 1.1 [RFC7950] module implementing the information elements defined in Section 2 and the evaluation semantics defined in Section 3.¶

The module contains two principal data structures:¶

• scenario: Configurable declarations of validation scenarios, including disruptions and evaluation objectives.¶

• report: Read-only operational records containing event realization, observed measurements, and validation verdicts.¶

The model uses external references for network context, traffic profiles, measurement methods, and evidence, avoiding duplication of existing topology and measurement models.¶

The namespace and module name are provisional until IANA registration.¶

<CODE BEGINS> file "ietf-resilience-validation@2026-11-02.yang"

module ietf-resilience-validation {
  yang-version 1.1;

  namespace
    "urn:ietf:params:xml:ns:yang:ietf-resilience-validation";

  prefix rv;

  import ietf-inet-types {
    prefix inet;
    reference "RFC 6991";
  }

  import ietf-yang-types {
    prefix yang;
    reference "RFC 6991";
  }

  organization
    "IETF Operations and Management Area";

  contact
    "Editor: Jing Zhao
     <mailto:zhaoj501@chinaunicom.cn>";

  description
    "Declarative network resilience validation scenarios
     and operational validation reports.

     This module does not execute disruptions or modify
     production network state.";

  revision 2026-11-02 {
    description "Initial revision.";
    reference
      "draft-zhao-opsawg-resilience-validation-00";
  }

  typedef validation-verdict {
    type enumeration {
      enum pass;
      enum fail;
      enum inconclusive;
    }
    description "Outcome of validation evaluation.";
  }

  typedef service-metric {
    type enumeration {
      enum minimum-throughput-bps {
        description "Minimum service throughput in bit/s.";
      }
      enum maximum-packet-loss-ppm {
        description "Maximum packet loss in ppm.";
      }
      enum maximum-restoration-time-ms {
        description
          "Service restoration time in milliseconds.";
      }
    }
    description "Service-level evaluation metrics.";
  }

  container resilience-validation {
    description
      "Validation scenarios and their results.";

    list scenario {
      key "scenario-id revision-id";

      description
        "Immutable, version-qualified validation scenario.";

      leaf scenario-id {
        type string;
        description "Scenario identifier.";
      }

      leaf revision-id {
        type string;
        description "Scenario revision.";
      }

      leaf context-ref {
        type inet:uri;
        mandatory true;
        description
          "Immutable or version-qualified network
           and service context reference.";
      }

      leaf traffic-profile-ref {
        type inet:uri;
        mandatory true;
        description
          "Immutable or version-qualified traffic profile.";
      }

      leaf description {
        type string;
        description "Scenario purpose.";
      }

      list disruption {
        key "event-id";
        min-elements 1;

        description "Declared disruptive conditions.";

        leaf event-id {
          type string;
          description "Event identifier.";
        }

        leaf target-ref {
          type inet:uri;
          mandatory true;
          description "Affected resource reference.";
        }

        leaf kind {
          type enumeration {
            enum resource-unavailable;
            enum capacity-limited;
            enum packet-loss;
            enum management-unreachable;
          }
          mandatory true;
          description "Disruption type.";
        }

        leaf start-offset-ms {
          type uint32;
          mandatory true;
          description "Start offset from scenario start.";
        }

        leaf duration-ms {
          type uint32 {
            range "1..max";
          }
          mandatory true;
          description "Declared duration.";
        }

        leaf timing-tolerance-ms {
          type uint32;
          mandatory true;
          description "Permitted event timing deviation.";
        }

        leaf realization-method-ref {
          type inet:uri;
          mandatory true;
          description
            "Version-qualified event verification method.";
        }

        leaf reduced-capacity-bps {
          when "../kind = 'capacity-limited'";
          type uint64;
          mandatory true;
          description "Declared capacity limit.";
        }

        leaf loss-ppm {
          when "../kind = 'packet-loss'";
          type uint32 {
            range "0..1000000";
          }
          mandatory true;
          description "Declared packet-loss impairment.";
        }
      }

      list objective {
        key "objective-id";
        min-elements 1;

        description "Service evaluation criteria.";

        leaf objective-id {
          type string;
          description "Objective identifier.";
        }

        leaf service-ref {
          type inet:uri;
          mandatory true;
          description "Evaluated service reference.";
        }

        leaf metric {
          type service-metric;
          mandatory true;
          description "Evaluation metric.";
        }

        leaf threshold {
          type uint64;
          mandatory true;
          must
            "not(../metric = 'maximum-packet-loss-ppm')"
            + " or . <= 1000000";
          description
            "Acceptance threshold in the metric unit.";
        }

        leaf method-ref {
          type inet:uri;
          mandatory true;
          description
            "Version-qualified measurement methodology.";
        }

        leaf window-start-ms {
          type uint32;
          mandatory true;
          description "Observation window start.";
        }

        leaf window-end-ms {
          type uint32;
          mandatory true;
          must ". > ../window-start-ms";
          description "Observation window end.";
        }
      }
    }

    list report {
      config false;
      key "run-id";

      description
        "Published results of a validation run.";

      leaf run-id {
        type string;
        description "Unique run identifier.";
      }

      leaf scenario-id {
        type string;
        mandatory true;
        description "Evaluated scenario identifier.";
      }

      leaf revision-id {
        type string;
        mandatory true;
        description "Evaluated scenario revision.";
      }

      leaf context-ref {
        type inet:uri;
        mandatory true;
        description "Context actually evaluated.";
      }

      leaf traffic-profile-ref {
        type inet:uri;
        mandatory true;
        description "Traffic profile actually evaluated.";
      }

      leaf environment {
        type enumeration {
          enum simulation;
          enum emulation;
          enum isolated-laboratory;
        }
        mandatory true;
        description "Validation environment.";
      }

      leaf engine-ref {
        type inet:uri;
        description
          "Validation engine and version reference.";
      }

      leaf started-at {
        type yang:date-and-time;
        mandatory true;
        description "Validation run start time.";
      }

      leaf completed-at {
        type yang:date-and-time;
        mandatory true;
        description "Report completion time.";
      }

      leaf verdict {
        type validation-verdict;
        mandatory true;
        description "Overall validation verdict.";
      }

      list event-result {
        key "event-id";

        description "Disruption realization result.";

        leaf event-id {
          type string;
          description "Declared event identifier.";
        }

        leaf realization {
          type enumeration {
            enum realized;
            enum not-realized;
            enum unknown;
          }
          mandatory true;
          description "Event realization status.";
        }

        leaf observed-start-ms {
          type uint32;
          description "Observed onset offset.";
        }

        leaf observed-end-ms {
          type uint32;
          description "Observed end offset.";
        }

        leaf actual-method-ref {
          type inet:uri;
          description
            "Event verification method actually applied.";
        }

        leaf-list evidence-ref {
          type inet:uri;
          description "Event verification evidence.";
        }
      }

      list objective-result {
        key "objective-id";

        description "Service criterion evaluation result.";

        leaf objective-id {
          type string;
          description "Evaluated objective identifier.";
        }

        leaf verdict {
          type validation-verdict;
          mandatory true;
          description "Objective verdict.";
        }

        leaf observed-value {
          type uint64;
          description
            "Observed metric value in the metric unit.";
        }

        leaf actual-method-ref {
          type inet:uri;
          description
            "Measurement method actually applied.";
        }

        leaf-list evidence-ref {
          type inet:uri;
          description "Supporting measurement evidence.";
        }
      }
    }
  }
}

<CODE ENDS>

The scenario list represents the validation contract, while the report list represents the observed outcome of an external validation run.¶

The schema provides the identifiers and fields required to associate reported measurements with their corresponding scenario definitions. Implementations are responsible for applying the consistency and verdict rules in Section 3 when publishing reports.¶

The module defines neither an RPC for executing a validation scenario nor a protocol for submitting results. NETCONF, RESTCONF, or other management interfaces may be used to expose the data.¶

5. Example: Correlated Failures and Limited Backup Capacity

This section illustrates the use of the data model for evaluating service continuity under correlated failures.¶

Consider a network supporting two services, A and B, with separate primary paths and a shared backup path.¶

The validation objective is to determine whether both services can maintain their required performance when the primary paths become unavailable and the shared backup capacity is limited.¶

The scenario is identified as follows:¶

• Scenario ID: dual-primary-failure¶

• Revision: 1¶

• Context: urn:example:resilience:context:v42¶

• Traffic profile: urn:example:resilience:traffic:profile-1¶

The traffic profile specifies an offered load of 7 Gbit/s for Service A and 6 Gbit/s for Service B.¶

Three disruptive conditions are declared:¶

The scenario specifies the following evaluation criteria:¶

Each disruption and criterion references an appropriate verification or measurement method.¶

Assume that the validation system reports the following illustrative observations:¶

If all three disruptive conditions are confirmed as realized and the measurements are valid, the overall verdict is FAIL, because Service B did not satisfy its minimum-throughput requirement.¶

If the system cannot confirm realization of the backup capacity restriction, the overall verdict is INCONCLUSIVE, regardless of the observed throughput values.¶

This example demonstrates that different validation engines can exchange a common scenario and interpret its results consistently, even when their internal execution mechanisms differ.¶

6. Relationship to Existing Work

The network topology model [RFC8345] and the SIMAP concept [I-D.ietf-nmop-simap-concept] provide relevant means of representing network and service context. This document does not duplicate those models but provides validation scenarios and results that may reference them.¶

Service Assurance for Intent-Based Networking [RFC9417] and its YANG model [RFC9418] provide service assurance information. The model specified here complements that work by associating explicit disruptive conditions with service-level evaluation criteria and validation outcomes.¶

Network incident management [I-D.ietf-nmop-network-incident-yang] addresses operational incidents. Hypothetical or laboratory disruptions represented by this model are not operational incidents and do not create or resolve incidents in that model.¶

IETF benchmarking methodologies, including [RFC6414] and [RFC8456], define metrics and procedures for evaluating particular network behaviors. Such methodologies may be referenced by resilience validation criteria where applicable.¶

This document differs from those specifications by defining a common information model for exchanging resilience validation scenarios and results rather than prescribing a specific benchmarking procedure.¶

As noted in [RFC6815], laboratory benchmarking procedures should not be applied to production networks in ways that may disrupt operational traffic. This specification does not define or authorize production fault injection.¶

7. Security Considerations

TBD.¶

8. IANA Considerations

TBD.¶

9. References

Authors' Addresses