A YANG Data Model for Scenario-based Network Resilience Validation

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 . 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 and , 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.

Requirements Language The key words MUST, MUST NOT, SHOULD, and MAY in this document are to be interpreted as described in BCP 14 RFC2119 when, and only when, they appear in all capitals.

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:

Validation Scenario: Identifies the scenario revision, network and service context, and traffic profile against which validation is performed.
Disruptive Conditions: Describes the affected resources, impairment types, event timing, and conditions required to verify disruption realization.
Evaluation Criteria: Specifies the evaluated services, performance metrics, measurement methods, observation windows, and acceptance thresholds.
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.

Scenario-based Resilience Validation Information Model 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.

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.

Scenario and Evaluation Conditions A validation scenario is uniquely identified by a scenario-id and revision-id. The identifier pair MUST refer to an immutable scenario definition. Any change to the scenario conditions or evaluation criteria requires a new revision. Each scenario MUST reference an immutable or version-qualified network context and traffic profile. The network context identifies the topology, resources, service relationships, and relevant network state used during evaluation. The traffic profile identifies the workload used to assess service behavior, including relevant offered-load and traffic-distribution characteristics. Baseline performance may be measured before introducing the declared disruptions. Such measurements can help distinguish degradation caused by disruptions from limitations already present in the evaluation environment. A validation report MUST identify the actual scenario revision, context, and traffic profile used. An implementation unable to resolve the declared evaluation context, or unable to reproduce materially compatible conditions, MUST report an INCONCLUSIVE result.

Disruption Realization A scenario may contain multiple disruptive events, including simultaneous or overlapping conditions. Each event specifies its target, impairment type, start offset, duration, verification method, and timing tolerance. Initial disruption types include:

Resource unavailability.
Capacity limitation.
Packet loss.
Management connectivity unavailability.

A disruption is considered realized only when the observed condition satisfies its declared characteristics and verification requirements. An implementation MUST NOT infer successful realization solely from issuing a fault-injection command. For each event, the validation report records one of the following states:

Realized: The declared condition was confirmed.
Not realized: The condition was not achieved as specified.
Unknown: Available evidence was insufficient to determine realization.

An event reported as realized MUST include observed timing, the verification method actually applied, and supporting evidence. If any required disruption is not confirmed, the overall validation verdict MUST be INCONCLUSIVE.

Service Performance Evaluation Service performance is evaluated using explicit acceptance criteria. The initial model supports three service-level metrics:

Metric	Purpose	Acceptance Rule
Minimum throughput	Evaluate service continuity during disruption	Observed value ≥ threshold
Maximum packet loss	Evaluate service degradation	Observed value ≤ threshold
Maximum restoration time	Evaluate recovery within a specified objective	Observed value ≤ threshold

Throughput is expressed in bit/s, packet loss in parts per million, and restoration time in milliseconds. Each criterion specifies a measurement method reference and an observation window relative to the scenario start. The measurement method defines how the observed value is obtained and interpreted, including any required sampling intervals, counting rules, or aggregation procedures. For restoration-time evaluation, the measurement method MUST define the disruption reference point and the condition under which the service is considered restored. The restoration condition may include a stabilization interval during which the service must maintain acceptable performance. The specified observation window MUST be sufficient to determine whether the acceptance threshold was satisfied. If a required measurement is missing, invalid, or obtained using an incompatible method, the corresponding criterion MUST be reported as INCONCLUSIVE. This document does not define new packet measurement algorithms or prescribe specific traffic-generation procedures.

Validation Verdict The overall validation verdict is determined by both disruption realization and service performance evaluation. Three verdicts are defined:

PASS: All declared disruptions were confirmed, all required criteria were evaluated, and all criteria passed.
FAIL: All declared disruptions were confirmed, all required criteria were evaluated, and at least one criterion failed.
INCONCLUSIVE: One or more disruptions were not confirmed, required observations were unavailable or invalid, or evaluation conditions were incompatible with the declared scenario.

The decision rules are summarized below.

Disruption Realization	Criteria Evaluation	Overall Verdict
All confirmed	All passed	PASS
All confirmed	At least one failed, all evaluated	FAIL
One or more unconfirmed	Any	INCONCLUSIVE
All confirmed	One or more inconclusive	INCONCLUSIVE

A validation report MUST contain a realization result for every declared disruption and an evaluation result for every declared criterion. A PASS or FAIL result MUST include observed values, actual measurement methods, and evidence sufficient to support the reported outcome. A missing measurement MUST NOT be interpreted as a successful measurement.

Result Comparability Validation results are meaningful only in relation to their evaluation conditions. Different validation engines may use different algorithms while evaluating the same declarative scenario. Their results may be compared when the scenario revision, network context, traffic profile, disruption realization, measurement methods, and observation windows are compatible. Results obtained under materially different conditions MUST NOT be reported as directly comparable without qualification. Repeated validation runs may be used to assess variability or consistency. However, this document does not define a statistical aggregation method or a composite network resilience score.

YANG Data Model This section specifies an initial YANG 1.1 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. 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 "; 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."; } } } } }

]]>


      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.


    
      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:
      
        
          
            Event
            Condition
            Start
            Duration
          
        
        
          
            E1
            Primary link A unavailable
            0 ms
            30,000 ms
          
          
            E2
            Primary link B unavailable
            0 ms
            30,000 ms
          
          
            E3
            Shared backup capacity limited to 10 Gbit/s
            0 ms
            30,000 ms
          
        
      
      The scenario specifies the following evaluation criteria:
      
        
          
            Criterion
            Metric
            Acceptance Threshold
            Window
          
        
        
          
            C1: Service A
            Minimum throughput
            ≥ 6 Gbit/s
            5–30 s
          
          
            C2: Service B
            Minimum throughput
            ≥ 4 Gbit/s
            5–30 s
          
          
            C3: Service A
            Restoration time
            ≤ 60 s
            0–90 s
          
        
      
      Each disruption and criterion references an appropriate verification or measurement method.
      Assume that the validation system reports the following illustrative observations:
      
        
          
            Criterion
            Observed Value
            Verdict
          
        
        
          
            C1
            6.1 Gbit/s
            PASS
          
          
            C2
            3.4 Gbit/s
            FAIL
          
          
            C3
            35,000 ms
            PASS
          
        
      
      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.
    
    
      Relationship to Existing Work
      The network topology model  and the 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  and its YANG model  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  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  and , 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 , 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.
    
    
      Security Considerations
      TBD.
    
    
      IANA Considerations
      TBD.

Event	Condition	Duration
E1	Primary link A unavailable	30,000 ms
E2	Primary link B unavailable	30,000 ms
E3	Shared backup capacity limited to 10 Gbit/s	30,000 ms

Criterion	Metric	Acceptance Threshold	Window
C1: Service A	Minimum throughput	≥ 6 Gbit/s	5–30 s
C2: Service B	Minimum throughput	≥ 4 Gbit/s	5–30 s
C3: Service A	Restoration time	≤ 60 s	0–90 s