opsawg J. Zhao Internet-Draft S. Zhang, Ed. Intended status: Standards Track China Unicom Expires: 6 May 2027 2 November 2026 A YANG Data Model for Scenario-based Network Resilience Validation draft-zhao-opsawg-resilience-validation-00 Abstract Network resilience validation evaluates whether network services can maintain acceptable performance and recover within specified objectives under disruptive conditions. Such validation may be performed using simulation, emulation, or controlled laboratory testing. However, differences in scenario descriptions, evaluation criteria, and result representations make validation results difficult to exchange, reproduce, and compare across implementations. This document specifies a YANG data model for scenario-based network resilience validation. The model standardizes the representation of validation scenarios, disruptive conditions, service-level evaluation criteria, and validation results. It also defines common evaluation semantics to support consistent interpretation of results across validation environments. The specification focuses on interoperable representation of validation information. It does not define simulation algorithms, fault-injection procedures, or mechanisms for modifying production networks. 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. Zhao & Zhang Expires 6 May 2027 [Page 1] Internet-Draft Scenario-based Resilience Validation November 2026 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Scope and Standardization Points . . . . . . . . . . . . . . 3 3. Evaluation Semantics . . . . . . . . . . . . . . . . . . . . 5 3.1. Scenario and Evaluation Conditions . . . . . . . . . . . 5 3.2. Disruption Realization . . . . . . . . . . . . . . . . . 6 3.3. Service Performance Evaluation . . . . . . . . . . . . . 6 3.4. Validation Verdict . . . . . . . . . . . . . . . . . . . 7 3.5. Result Comparability . . . . . . . . . . . . . . . . . . 8 4. YANG Data Model . . . . . . . . . . . . . . . . . . . . . . . 9 5. Example: Correlated Failures and Limited Backup Capacity . . 17 6. Relationship to Existing Work . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.2. Informative References . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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. Zhao & Zhang Expires 6 May 2027 [Page 2] Internet-Draft Scenario-based Resilience Validation November 2026 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. 1.1. Requirements Language The key words *MUST*, *MUST NOT*, *SHOULD*, and *MAY* in this document are to be interpreted as described in BCP 14 RFC2119 [RFC8174] when, and only when, they appear in all capitals. 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. Zhao & Zhang Expires 6 May 2027 [Page 3] Internet-Draft Scenario-based Resilience Validation November 2026 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| +--------------------------------+ Figure 1: 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. Zhao & Zhang Expires 6 May 2027 [Page 4] Internet-Draft Scenario-based Resilience Validation November 2026 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. 3.1. 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. Zhao & Zhang Expires 6 May 2027 [Page 5] Internet-Draft Scenario-based Resilience Validation November 2026 3.2. 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. 3.3. Service Performance Evaluation Service performance is evaluated using explicit acceptance criteria. The initial model supports three service-level metrics: Zhao & Zhang Expires 6 May 2027 [Page 6] Internet-Draft Scenario-based Resilience Validation November 2026 +==================+=============================+=================+ | Metric | Purpose | Acceptance Rule | +==================+=============================+=================+ | Minimum | Evaluate service continuity | Observed value | | throughput | during disruption | ≥ threshold | +------------------+-----------------------------+-----------------+ | Maximum packet | Evaluate service | Observed value | | loss | degradation | ≤ threshold | +------------------+-----------------------------+-----------------+ | Maximum | Evaluate recovery within a | Observed value | | restoration time | specified objective | ≤ threshold | +------------------+-----------------------------+-----------------+ Table 1 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. 3.4. Validation Verdict The overall validation verdict is determined by both disruption realization and service performance evaluation. Three verdicts are defined: Zhao & Zhang Expires 6 May 2027 [Page 7] Internet-Draft Scenario-based Resilience Validation November 2026 * *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, | FAIL | | | all evaluated | | +------------------------+----------------------+-----------------+ | One or more | Any | INCONCLUSIVE | | unconfirmed | | | +------------------------+----------------------+-----------------+ | All confirmed | One or more | INCONCLUSIVE | | | inconclusive | | +------------------------+----------------------+-----------------+ Table 2 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. 3.5. Result Comparability Validation results are meaningful only in relation to their evaluation conditions. Zhao & Zhang Expires 6 May 2027 [Page 8] Internet-Draft Scenario-based Resilience Validation November 2026 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. 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. 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"; } Zhao & Zhang Expires 6 May 2027 [Page 9] Internet-Draft Scenario-based Resilience Validation November 2026 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."; Zhao & Zhang Expires 6 May 2027 [Page 10] Internet-Draft Scenario-based Resilience Validation November 2026 } 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."; Zhao & Zhang Expires 6 May 2027 [Page 11] Internet-Draft Scenario-based Resilience Validation November 2026 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."; } Zhao & Zhang Expires 6 May 2027 [Page 12] Internet-Draft Scenario-based Resilience Validation November 2026 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."; Zhao & Zhang Expires 6 May 2027 [Page 13] Internet-Draft Scenario-based Resilience Validation November 2026 } 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."; } Zhao & Zhang Expires 6 May 2027 [Page 14] Internet-Draft Scenario-based Resilience Validation November 2026 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"; Zhao & Zhang Expires 6 May 2027 [Page 15] Internet-Draft Scenario-based Resilience Validation November 2026 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."; } Zhao & Zhang Expires 6 May 2027 [Page 16] Internet-Draft Scenario-based Resilience Validation November 2026 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. 5. Example: Correlated Failures and Limited Backup Capacity This section illustrates the use of the data model for evaluating service continuity under correlated failures. Zhao & Zhang Expires 6 May 2027 [Page 17] Internet-Draft Scenario-based Resilience Validation November 2026 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 | 0 ms | 30,000 ms | | | limited to 10 Gbit/s | | | +-------+----------------------------+-------+-----------+ Table 3 The scenario specifies the following evaluation criteria: Zhao & Zhang Expires 6 May 2027 [Page 18] Internet-Draft Scenario-based Resilience Validation November 2026 +===============+=============+======================+========+ | Criterion | Metric | Acceptance Threshold | Window | +===============+=============+======================+========+ | C1: Service A | Minimum | ≥ 6 Gbit/s | 5–30 s | | | throughput | | | +---------------+-------------+----------------------+--------+ | C2: Service B | Minimum | ≥ 4 Gbit/s | 5–30 s | | | throughput | | | +---------------+-------------+----------------------+--------+ | C3: Service A | Restoration | ≤ 60 s | 0–90 s | | | time | | | +---------------+-------------+----------------------+--------+ Table 4 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 | +-----------+----------------+---------+ Table 5 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. Zhao & Zhang Expires 6 May 2027 [Page 19] Internet-Draft Scenario-based Resilience Validation November 2026 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 9.1. Normative References Zhao & Zhang Expires 6 May 2027 [Page 20] Internet-Draft Scenario-based Resilience Validation November 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", RFC 6991, DOI 10.17487/RFC6991, July 2013, . [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", RFC 7950, DOI 10.17487/RFC7950, August 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration Access Control Model", STD 91, RFC 8341, DOI 10.17487/RFC8341, March 2018, . 9.2. Informative References [RFC6414] Poretsky, S., Papneja, R., Karthik, J., and S. Vapiwala, "Benchmarking Terminology for Protection Performance", RFC 6414, DOI 10.17487/RFC6414, November 2011, . [RFC6815] Bradner, S., Dubray, K., McQuaid, J., and A. Morton, "Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC6815, November 2012, . [RFC8345] Clemm, A., Medved, J., Varga, R., Bahadur, N., Ananthakrishnan, H., and X. Liu, "A YANG Data Model for Network Topologies", RFC 8345, DOI 10.17487/RFC8345, March 2018, . [RFC8456] Bhuvaneswaran, V., Basil, A., Tassinari, M., Manral, V., and S. Banks, "Benchmarking Methodology for Software- Defined Networking (SDN) Controller Performance", RFC 8456, DOI 10.17487/RFC8456, October 2018, . Zhao & Zhang Expires 6 May 2027 [Page 21] Internet-Draft Scenario-based Resilience Validation November 2026 [RFC9417] Claise, B., Quilbeuf, J., Lopez, D., Voyer, D., and T. Arumugam, "Service Assurance for Intent-Based Networking Architecture", RFC 9417, DOI 10.17487/RFC9417, July 2023, . [RFC9418] Claise, B., Quilbeuf, J., Lucente, P., Fasano, P., and T. Arumugam, "A YANG Data Model for Service Assurance", RFC 9418, DOI 10.17487/RFC9418, July 2023, . [I-D.ietf-nmop-simap-concept] Havel, O., Claise, B., de Dios, O. G., and T. Graf, "SIMAP: Concept, Requirements, and Use Cases", Work in Progress, Internet-Draft, draft-ietf-nmop-simap-concept- 15, 23 October 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-20, 16 October 2026, . [I-D.zhao-opsawg-network-resilience-ps] Zhao, J., Pang, R., Lv, W., Dong, J., and S. Zhang, "Problem Statement for Network Resilience", Work in Progress, Internet-Draft, draft-zhao-opsawg-network- resilience-ps-02, 2 November 2026, . Authors' Addresses Jing Zhao China Unicom Beijing China Email: zhaoj501@chinaunicom.cn Shuai Zhang (editor) China Unicom Beijing China Email: zhangs366@chinaunicom.cn Zhao & Zhang Expires 6 May 2027 [Page 22]