<?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.43 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-zhao-opsawg-network-resilience-ps-02" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.35.0 -->
  <front>
    <title abbrev="Problem Statement for Network Resilience">Problem Statement for Network Resilience</title>
    <seriesInfo name="Internet-Draft" value="draft-zhao-opsawg-network-resilience-ps-02"/>
    <author initials="J." surname="Zhao" fullname="Jing Zhao" role="editor">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhaoj501@chinaunicom.cn</email>
      </address>
    </author>
    <author initials="R." surname="Pang" fullname="Ran Pang" role="editor">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>pangran@chinaunicom.cn</email>
      </address>
    </author>
    <author initials="W." surname="Lv" fullname="Wenxiang Lv" role="editor">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>lvwx28@chinaunicom.cn</email>
      </address>
    </author>
    <author initials="J." surname="Dong" fullname="Jie Dong" role="editor">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author initials="S." surname="Zhang" fullname="Shuai Zhang" role="editor">
      <organization>China Unicom</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhangs366@chinaunicom.cn</email>
      </address>
    </author>
    <date year="2026" month="November" day="02"/>
    <area>Operations and Management Area</area>
    <workgroup>opsawg</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 75?>

<t>This document examines the problem space for network resilience, focusing on the ability of networks to maintain acceptable service levels and recover from disruptive conditions. It identifies limitations of existing protection and recovery mechanisms under correlated, cascading, or evolving failures, and when resources or systems required for recovery are themselves impaired. It analyzes resilience challenges across risk anticipation, disruption absorption and adaptation, service recovery, and continuous improvement, and identifies corresponding capability gaps to be addressed.</t>
    </abstract>
  </front>
  <middle>
    <?line 79?>

<section anchor="intro">
      <name>Introduction</name>
      <t>Current IP network reliability mechanisms are largely built around redundancy, fast failure detection, protection switching, and topology convergence. These mechanisms are effective for many anticipated and relatively well-bounded failures. However, as network scale, service dependency, and operational complexity increase, failures may become correlated across layers, evolve dynamically, consume the resources needed for recovery, or degrade service without causing a clear binary "up/down" state. In these conditions, static protection alone may not be sufficient to preserve service continuity.</t>
      <t>In this document, network resilience refers to the ability of a network to anticipate and reduce risks, absorb and contain disruptions, maintain an acceptable level of service under adverse conditions, adapt to changing network conditions, and restore the intended service level within defined recovery objectives.</t>
      <t>Network resilience builds upon existing reliability, protection, and survivability mechanisms rather than replacing them. These mechanisms provide important capabilities for maintaining service continuity and recovering from network failures. However, their effectiveness may be limited when the assumptions underlying protection and recovery no longer hold, such as when failures are correlated, backup resources become insufficient, or the control and management functions required for recovery are impaired.</t>
      <t>The fundamental concern of network resilience is therefore not only whether a failure can be detected or a protection mechanism can be activated, but whether the network can continue to provide acceptable service, contain the impact of disruptions, and restore service under changing and potentially degraded conditions.</t>
      <t>This definition of network resilience is aligned with common resilience framing; it is distinguished from classical reliability, which focuses primarily on failure detection and fast restoration under independent-failure assumptions.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The key words "<strong>MUST</strong>", "<strong>MUST NOT</strong>", "<strong>REQUIRED</strong>", "<strong>SHALL</strong>", "<strong>SHALL NOT</strong>", "<strong>SHOULD</strong>", "<strong>SHOULD NOT</strong>", "<strong>RECOMMENDED</strong>", "<strong>NOT RECOMMENDED</strong>", "<strong>MAY</strong>", and "<strong>OPTIONAL</strong>" in this document are to be interpreted as described in BCP 14 <xref target="RFC8174">RFC2119</xref> when, and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="network-resilience-problem-statement">
      <name>Network Resilience Problem Statement</name>
      <t>Existing IP networks employ redundancy, failure detection, protection switching, routing convergence, and traffic engineering mechanisms to maintain service continuity and recover from network failures. These mechanisms are effective in handling many anticipated and relatively well-bounded failures. However, their effectiveness may be limited when disruptions involve correlated failures, evolving network conditions, resource constraints, or degradation of the systems required for recovery.</t>
      <t>The fundamental network resilience problem is not simply the occurrence of failures, but the possibility that existing protection and recovery mechanisms cannot maintain acceptable service levels or achieve the intended recovery objectives under adverse conditions.</t>
      <t>For example, protection mechanisms may successfully restore connectivity after a single link failure, but may not provide the expected protection when multiple paths share an underlying physical dependency. Similarly, rerouting traffic to an alternative path may restore reachability but introduce congestion and service degradation if the available resources are insufficient.</t>
      <t>These situations illustrate how network disruptions can expose limitations in existing protection and recovery mechanisms, resulting in service degradation, failure propagation, or incomplete recovery.</t>
      <t>The following subsections examine representative disruptions and latent vulnerabilities, the limitations they expose in existing mechanisms, and the resulting consequences for service continuity and recovery.</t>
      <figure anchor="fig-1">
        <name>How Disruptions Expose Network Resilience Limitations</name>
        <sourcecode type="text"><![CDATA[
+-------------------------------------------------------------------------+
| Disruptions and Latent Vulnerabilities                                  |
|                                                                         |
|   Physical, configuration, design, protocol, performance, and security  |
|   conditions; hidden dependencies and evolving disruptions              |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
| Limitations of Existing Protection and Recovery                         |
|                                                                         |
|   - Incomplete failure coverage and hidden dependencies                |
|   - Insufficient resources for protection and recovery                 |
|   - Incomplete awareness of network and service conditions             |
|   - Uncoordinated recovery actions                                      |
|   - Degradation of recovery systems                                     |
+-------------------------------------------------------------------------+
                                     |
                                     v
+-------------------------------------------------------------------------+
| Consequences for Service Continuity and Recovery                        |
|                                                                         |
|   - Correlated or cascading failures and expanded impact               |
|   - Service degradation despite retained connectivity                  |
|   - Prolonged, unstable, or incomplete recovery                         |
|   - Residual risks after service restoration                            |
+-------------------------------------------------------------------------+
]]></sourcecode>
      </figure>
      <section anchor="disruptions-and-latent-vulnerabilities">
        <name>Disruptions and Latent Vulnerabilities</name>
        <t>Network disruptions may originate from a variety of physical, operational, design, protocol, performance, and security-related conditions. Representative sources include:</t>
        <ul spacing="normal">
          <li>
            <t><strong>Physical Interruptions:</strong> Failures of links, ports, devices, or supporting infrastructure that affect network connectivity or forwarding capabilities.</t>
          </li>
          <li>
            <t><strong>Configuration Errors:</strong> Incorrect or inconsistent configurations introduced during provisioning, maintenance, or policy changes, potentially affecting reachability, routing, traffic engineering, or service isolation.</t>
          </li>
          <li>
            <t><strong>Planning and Design Defects:</strong> Latent weaknesses in network topology, protection design, dependency assumptions, or capacity planning that may remain undetected during normal operation.</t>
          </li>
          <li>
            <t><strong>Control-plane and Protocol Anomalies:</strong> Abnormal protocol behavior, inconsistent control-plane state, or unstable interactions between routing and protection mechanisms.</t>
          </li>
          <li>
            <t><strong>Implicit Deterioration (Gray Failures):</strong> Conditions in which network components remain operational while traffic experiences unacceptable packet loss, delay, jitter, or other performance degradation.</t>
          </li>
          <li>
            <t><strong>Security Incidents:</strong> Malicious or unauthorized activities that affect network resources, compromise control or management information, or disrupt normal forwarding and recovery operations.</t>
          </li>
        </ul>
        <t>These conditions do not necessarily result in service disruption individually. Some may be handled effectively by existing protection mechanisms, while others may remain latent until the network experiences additional stress or failures.</t>
        <t>For example, a network may contain hidden shared-risk dependencies between nominally redundant paths. Such dependencies may not affect normal operation but can cause simultaneous failures when a common underlying resource becomes unavailable.</t>
        <t>Moreover, different disruptive conditions may interact. A physical failure may trigger traffic redistribution, which increases resource utilization and causes performance degradation. The resulting instability may further trigger routing changes or additional protection actions.</t>
        <t>Consequently, network resilience challenges cannot be characterized solely by identifying individual failure sources. It is also necessary to consider how latent vulnerabilities and disruptive conditions interact with existing protection and recovery mechanisms.</t>
      </section>
      <section anchor="limitations-of-existing-protection-and-recovery-mechanisms">
        <name>Limitations of Existing Protection and Recovery Mechanisms</name>
        <t>Existing protection and recovery mechanisms operate under certain assumptions concerning failure scenarios, resource availability, network state, and the availability of supporting control and management functions. Under complex disruptive conditions, these assumptions may no longer hold.
The following limitations are particularly relevant to network resilience.</t>
        <section anchor="incomplete-failure-coverage-and-hidden-dependencies">
          <name>Incomplete Failure Coverage and Hidden Dependencies</name>
          <t>Protection mechanisms typically address specified failure scenarios using redundant resources or alternative forwarding paths. Their effectiveness depends in part on the independence and availability of those resources. However, nominally independent network components may share physical infrastructure, control-plane functions, management systems, or other underlying dependencies. When a common dependency fails, multiple components or paths may become unavailable simultaneously, exceeding the failure coverage anticipated by the protection design.</t>
          <t>Furthermore, an initial failure may propagate through traffic redistribution, protocol interactions, or shared-resource contention, causing additional failures or degradation beyond the original fault domain.</t>
        </section>
        <section anchor="insufficient-resources-for-protection-and-recovery">
          <name>Insufficient Resources for Protection and Recovery</name>
          <t>Protection and recovery mechanisms may assume that sufficient resources are available to accommodate traffic after a failure.</t>
          <t>In practice, alternative forwarding paths may have limited bandwidth, forwarding plane capacity, or queue resources. A recovery action that is valid from a connectivity perspective may therefore cause congestion or unacceptable performance degradation under the actual traffic load.</t>
          <t>Resource constraints may also affect the control and management planes. Excessive protocol processing, repeated recovery actions, or telemetry overload may consume resources required for fault diagnosis, routing convergence, and recovery coordination.</t>
          <t>Consequently, the existence of a backup path or recovery mechanism does not necessarily guarantee that acceptable service can be maintained during disruption.</t>
        </section>
        <section anchor="incomplete-awareness-of-network-and-service-conditions">
          <name>Incomplete Awareness of Network and Service Conditions</name>
          <t>Conventional failure detection and protection mechanisms often rely on observable changes in component or protocol state. However, service degradation does not always correspond to an explicit link or node failure. A network path may remain operational while affected traffic experiences excessive delay, packet loss, jitter, or intermittent forwarding problems.</t>
          <t>Although OAM and telemetry mechanisms provide information about network conditions, the available observations may be fragmented across devices, layers, and operational domains.</t>
          <t>Without sufficient correlation between network state, resource conditions, and service performance, recovery mechanisms may fail to recognize the extent of degradation or select an appropriate mitigation action.</t>
        </section>
        <section anchor="uncoordinated-protection-and-recovery-actions">
          <name>Uncoordinated Protection and Recovery Actions</name>
          <t>Networks may employ multiple protection, routing, traffic engineering, and management mechanisms that operate independently or at different timescales.
Under complex failure conditions, actions taken by one mechanism may change the operating conditions observed by another. For example, protection switching may redistribute traffic and cause congestion, while subsequent routing changes may further alter traffic distribution.</t>
          <t>Such interactions may lead to repeated switching, routing oscillation, forwarding instability, or additional service disruption.</t>
          <t>Therefore, mechanisms that function correctly in isolation may not necessarily produce an effective recovery outcome when operating together.</t>
        </section>
        <section anchor="degradation-of-recovery-systems">
          <name>Degradation of Recovery Systems</name>
          <t>Network recovery increasingly depends on monitoring systems, control and management connectivity, controllers, orchestration platforms, and other operational functions.</t>
          <t>These systems may themselves be affected by the same disruption that they are expected to mitigate.</t>
          <t>For example, management connectivity may become unavailable, telemetry information may be delayed or incomplete, or control-plane resources may be exhausted during a large-scale failure.</t>
          <t>In such circumstances, the network may retain usable forwarding resources but lack the operational capabilities required to assess the situation, coordinate mitigation, or verify the recovery outcome.</t>
          <t>This creates a particular resilience challenge: the mechanisms required for recovery may themselves become unavailable or unreliable when they are most needed.</t>
        </section>
      </section>
      <section anchor="consequences-for-service-continuity-and-recovery">
        <name>Consequences for Service Continuity and Recovery</name>
        <t>The limitations described above may prevent network disruptions from being contained within their original scope and may reduce the effectiveness of protection and recovery.</t>
        <t>A localized disruption can evolve into a larger service-impacting event through correlated failures, traffic redistribution, resource contention, or interactions among recovery mechanisms.</t>
        <t>For example, a physical link failure may trigger traffic rerouting to an alternative path. If the alternative path lacks sufficient capacity, congestion and packet loss may occur. The resulting degradation may trigger additional protocol or recovery actions, further expanding the affected scope.</t>
        <t>In such scenarios, successful activation of a protection mechanism does not necessarily imply successful preservation of service continuity.</t>
        <t>The impact on service continuity also extends beyond binary availability. A network may remain connected while providing degraded service performance, or it may restore connectivity without recovering the capacity and performance required by affected services.</t>
        <t>The consequences of a disruption therefore need to be considered in terms of:</t>
        <ul spacing="normal">
          <li>
            <t><strong>Impact Scope:</strong> The services, traffic flows, network resources, or domains affected by the disruption.</t>
          </li>
          <li>
            <t><strong>Degradation Severity:</strong> The extent to which service performance deviates from its acceptable operating level.</t>
          </li>
          <li>
            <t><strong>Impact Duration:</strong> The period during which service performance remains degraded or unavailable, including intermittent or recurring disruption.</t>
          </li>
          <li>
            <t><strong>Recovery Effectiveness:</strong> The ability to restore the intended service level within the applicable recovery objectives and maintain a stable recovered state.</t>
          </li>
        </ul>
        <t>The acceptable degree and duration of degradation depend on the requirements and criticality of individual services. A short interruption may be tolerable for one service but unacceptable for another.</t>
        <t>Moreover, service restoration does not necessarily eliminate the underlying resilience risk. A network may recover traffic forwarding while continuing to operate with reduced redundancy, insufficient spare capacity, or unresolved shared-risk dependencies.</t>
        <t>Therefore, the network resilience problem extends beyond detecting failures and restoring connectivity. It concerns the ability to anticipate and reduce exposure to disruptive conditions, absorb and contain their effects, adapt protection and recovery actions to changing conditions, maintain acceptable service levels, and achieve effective and sustainable recovery.</t>
        <t>These challenges reveal capability gaps across the pre-event, in-event, and post-event stages of the failure lifecycle, as discussed in the following section.</t>
      </section>
    </section>
    <section anchor="resilience-gap-analysis-across-the-failure-lifecycle">
      <name>Resilience Gap Analysis Across the Failure Lifecycle</name>
      <t>The network resilience challenges identified in the previous section reveal limitations in the ability to anticipate disruptive conditions, maintain service continuity during disruption, and achieve effective recovery.</t>
      <t>These limitations can be analyzed across three stages of the failure lifecycle: pre-event, in-event, and post-event.</t>
      <t>The three stages represent complementary aspects of network resilience rather than strictly separated operational phases. Risk assessment, monitoring, mitigation, and recovery activities may overlap and interact throughout a disruption.</t>
      <t>The following subsections identify the major capability gaps at each stage.</t>
      <figure anchor="fig-2">
        <name>Resilience Capability Gaps Across the Failure Lifecycle</name>
        <sourcecode type="text"><![CDATA[
+----------------------+   +----------------------+   +----------------------+
| PRE-EVENT            |   | IN-EVENT             |   | POST-EVENT           |
| Risk & readiness     |-->| Containment & adapt. |-->| Assure & improve     |
+----------------------+   +----------------------+   +----------------------+
|                      |   |                      |   |                      |
| Hidden dependencies  |   | Service-impact gaps  |   | Incomplete service   |
|                      |   |                      |   | recovery checks      |
| Untested compound    |   | Propagation gaps     |   |                      |
| failure scenarios    |   |                      |   | Recovery outcomes    |
|                      |   | Resource blindness   |   | poorly assessed      |
| Unvalidated recovery |   |                      |   |                      |
| resources            |   | Recovery conflicts   |   | Residual risks       |
|                      |   |                      |   |                      |
| Limited degraded-    |   | Impaired recovery    |   | Limited validated    |
| mode preparedness    |   | functions            |   | feedback             |
|                      |   |                      |   |                      |
+----------------------+   +----------------------+   +----------------------+
                                                                  |
            <-----------------------------------------------------+
                      Validated feedback to preparedness
]]></sourcecode>
      </figure>
      <section anchor="pre-event-insufficient-risk-awareness-and-preparedness">
        <name>Pre-event: Insufficient Risk Awareness and Preparedness</name>
        <t>Before a disruptive event occurs, network resilience depends on the ability to identify potential vulnerabilities, assess their consequences, and prepare protection and recovery strategies for adverse conditions.</t>
        <t>Existing network planning, configuration management, and operational monitoring mechanisms provide important foundations for these activities. However, several limitations may remain.</t>
        <ul spacing="normal">
          <li>
            <t>Incomplete Awareness of Latent Risks and Dependencies: Network topology and operational information may not adequately represent shared-risk dependencies, hidden failure correlations, or vulnerabilities introduced by network design and configuration. As a result, potential common-cause failures and failure propagation paths may remain unidentified before a disruption occurs.</t>
          </li>
          <li>
            <t>Insufficient Assessment of Complex Failure Scenarios: Protection and recovery planning may focus primarily on individual or anticipated failures, with limited evaluation of concurrent failures, cascading effects, or interactions between different network mechanisms. Consequently, the network's ability to withstand complex disruptions may not be adequately assessed.</t>
          </li>
          <li>
            <t>Limited Validation of Recovery Resources: The capacity and availability of backup paths, forwarding resources, and control and management functions may not be sufficiently evaluated under realistic failure and traffic conditions. Recovery strategies that appear effective during normal operation may therefore become ineffective when activated under disruption.</t>
          </li>
          <li>
            <t>Insufficient Preparation for Degraded Operation: Network planning may emphasize restoration to normal operation without adequately considering how critical services can be maintained when parts of the network or its control and management systems remain unavailable.</t>
          </li>
          <li>
            <t>These limitations expose a fundamental pre-event resilience gap: the network may lack sufficient understanding of its vulnerabilities and may not be adequately prepared to maintain acceptable service levels under complex disruptive conditions.</t>
          </li>
        </ul>
      </section>
      <section anchor="in-event-insufficient-disruption-absorption-containment-and-adaptation">
        <name>In-event: Insufficient Disruption Absorption, Containment, and Adaptation</name>
        <t>During a disruption, network resilience depends on the ability to understand evolving network conditions, limit the propagation of failures, maintain acceptable service levels, and adapt recovery actions to the resources and functions that remain available.</t>
        <t>Although existing OAM, protection, and recovery mechanisms support fault detection and mitigation, several capability gaps may limit their effectiveness under complex disruptive conditions.</t>
        <ul spacing="normal">
          <li>
            <t>Insufficient Awareness of Service Impact: Network component and protocol status may not adequately reflect the actual performance of affected services. Fragmented observations across devices, layers, and domains may prevent timely assessment of the scope, severity, and evolution of service degradation. Consequently, recovery actions may not adequately reflect service continuity objectives.</t>
          </li>
          <li>
            <t>Limited Awareness of Failure Propagation: Existing mechanisms may detect individual faults without sufficient understanding of the dependencies and interactions through which their effects propagate. This may prevent the timely identification and containment of correlated or cascading failures.</t>
          </li>
          <li>
            <t>Insufficient Adaptation to Dynamic Resource Conditions: Protection and recovery actions may not adequately account for the changing availability of bandwidth, forwarding plane capacity, processing resources, or alternative paths. Traffic may therefore be redirected to resources that cannot sustain the additional load, causing further service degradation.</t>
          </li>
          <li>
            <t>Limited Coordination of Recovery Mechanisms: Independent protection, routing, traffic engineering, and management mechanisms may react to the same disruption without sufficient coordination. Their combined actions may introduce instability, repeated switching, or additional resource contention, rather than effectively containing the disruption.</t>
          </li>
          <li>
            <t>Insufficient Recovery Capability Under Degraded Conditions: The sensing, decision-making, control, and management functions required for recovery may themselves become degraded or unavailable. Existing recovery processes may not adequately support continued operation or safe mitigation when these supporting functions are impaired.</t>
          </li>
        </ul>
        <t>These limitations expose a central in-event resilience gap: the network may be able to detect a failure and initiate recovery, but still lack the ability to contain its effects, adapt to changing conditions, and maintain acceptable service performance throughout the disruption.</t>
      </section>
      <section anchor="post-event-insufficient-recovery-assurance-and-continuous-improvement">
        <name>Post-event: Insufficient Recovery Assurance and Continuous Improvement</name>
        <t>After a disruption, network resilience depends not only on restoring network connectivity and operational state, but also on verifying service recovery, identifying remaining vulnerabilities, and improving preparedness for future disruptions.
Existing fault and incident management processes provide important information for these activities. However, several capability gaps remain.</t>
        <ul spacing="normal">
          <li>
            <t>Insufficient Service-oriented Recovery Verification: Recovery may be considered complete when failed components, protocol sessions, or forwarding paths return to an operational state. However, these indicators do not necessarily demonstrate that affected services have recovered their required performance or that the network has returned to a stable operating condition.</t>
          </li>
          <li>
            <t>Limited Assessment of Recovery Effectiveness: Recovery processes may not systematically evaluate the duration and severity of service degradation, the effectiveness of containment actions, or the resources consumed during recovery. This limits the ability to determine whether recovery objectives were achieved and which mechanisms contributed to successful or unsuccessful outcomes.</t>
          </li>
          <li>
            <t>Incomplete Identification of Residual Risks: Following service restoration, the network may continue to operate with reduced redundancy, depleted resources, temporary configurations, or unresolved dependencies. Without adequate assessment of these conditions, the network may remain vulnerable to subsequent disruptions despite appearing to have recovered.</t>
          </li>
          <li>
            <t>Limited Feedback into Resilience Improvement: Information obtained from disruptive events, including failure propagation, service impact, recovery actions, and recovery outcomes, may not be systematically incorporated into subsequent risk assessment, network planning, and protection strategies. In addition, changes derived from operational experience may not be sufficiently validated before deployment, potentially introducing new vulnerabilities.</t>
          </li>
        </ul>
        <t>These limitations expose a post-event resilience gap: restoring network operation does not necessarily ensure that service recovery has been verified, residual vulnerabilities have been addressed, or the network is better prepared for future disruptions.</t>
        <t>The capability gaps across the three lifecycle stages are closely related. Incomplete risk awareness before a disruption can limit the effectiveness of protection and containment during the event, while insufficient recovery assurance and feedback afterward may allow the same vulnerabilities to persist.
Addressing these gaps requires complementary capabilities for proactive risk assessment, disruption absorption and containment, resource-aware adaptation, service-oriented recovery, and continuous resilience improvement. These capabilities are further discussed in the following section.</t>
      </section>
    </section>
    <section anchor="technical-capabilities-for-network-resilience-enhancement">
      <name>Technical Capabilities for Network Resilience Enhancement</name>
      <t>The resilience capability gaps identified in the previous section indicate that maintaining service continuity under complex disruptive conditions requires capabilities beyond individual failure detection, protection switching, and recovery mechanisms.</t>
      <t>These capabilities are intended to complement existing network reliability, protection, OAM, and service assurance mechanisms. They address the need to anticipate risks, absorb and contain disruptions, adapt to changing network conditions, and achieve effective recovery.
The following technical capabilities are identified for network resilience enhancement:</t>
      <ul spacing="normal">
        <li>
          <t><strong>Proactive Risk and Dependency Assessment:</strong> The capability to identify latent vulnerabilities and dependencies that may affect network resilience, including shared-risk dependencies, configuration and design weaknesses, and insufficient protection resources. This capability supports the assessment of potential failure propagation and service impact before disruptions occur.</t>
        </li>
        <li>
          <t><strong>Service-impact and Failure-propagation Awareness:</strong> The capability to correlate network state, resource conditions, dependency relationships, and service performance information to assess the scope, severity, and evolution of disruptions. This includes identifying service degradation that may not be reflected by conventional failure indicators and understanding how the effects of a disruption may propagate through the network.</t>
        </li>
        <li>
          <t><strong>Disruption Containment and Resource-aware Adaptation:</strong> The capability to limit the propagation of failures and adapt forwarding, protection, and recovery actions according to changing network conditions and available resources. This includes considering alternative path capacity, resource contention, and service priorities to maintain acceptable service levels and avoid recovery actions that introduce additional degradation.</t>
        </li>
        <li>
          <t><strong>Coordinated and Survivable Recovery:</strong> The capability to coordinate different protection and recovery mechanisms to avoid conflicting actions, repeated switching, and recovery-induced instability. Recovery capabilities also need to account for the degradation or unavailability of supporting control, management, and monitoring functions, allowing appropriate recovery or continued operation under constrained conditions.</t>
        </li>
        <li>
          <t><strong>Service-oriented Recovery Assurance:</strong> The capability to verify recovery outcomes against applicable service objectives rather than relying solely on the restoration of network component or protocol states. This includes assessing the scope and duration of service degradation, recovery effectiveness, the stability of the restored state, and residual risks that may affect subsequent disruptions.</t>
        </li>
        <li>
          <t><strong>Validated Resilience Improvement:</strong> The capability to use operational evidence, including disruptive conditions, service impact, recovery actions, and recovery outcomes, to improve future risk assessment, protection strategies, and recovery preparedness. Changes derived from operational experience need to be evaluated and validated to avoid introducing additional vulnerabilities.</t>
        </li>
      </ul>
      <t>These capabilities are complementary and may contribute to multiple stages of the failure lifecycle. Their realization may involve device-local mechanisms, distributed network functions, network-level management and control systems, or combinations of these approaches.</t>
      <t>This document does not prescribe a specific implementation architecture or protocol solution. Instead, the identified capabilities provide a basis for evaluating existing mechanisms and determining where further network resilience enhancements may be needed.</t>
      <t>TBD.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>Resilience mechanisms may introduce new attack vectors, for example injection of falsified telemetry data to trigger unnecessary path changes or routing oscillations. Future frameworks for network resilience SHOULD include identity-based authentication for sensing data and policy updates.</t>
      <t>TBD.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>TBD.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC7950" target="https://www.rfc-editor.org/info/rfc7950" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml">
          <front>
            <title>The YANG 1.1 Data Modeling Language</title>
            <author fullname="M. Bjorklund" initials="M." role="editor" surname="Bjorklund"/>
            <date month="August" year="2016"/>
            <abstract>
              <t>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).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7950"/>
          <seriesInfo name="DOI" value="10.17487/RFC7950"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t>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.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8341" target="https://www.rfc-editor.org/info/rfc8341" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml">
          <front>
            <title>Network Configuration Access Control Model</title>
            <author fullname="A. Bierman" initials="A." surname="Bierman"/>
            <author fullname="M. Bjorklund" initials="M." surname="Bjorklund"/>
            <date month="March" year="2018"/>
            <abstract>
              <t>The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or the RESTCONF protocol 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 or RESTCONF protocol access for particular users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model.</t>
              <t>This document obsoletes RFC 6536.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="91"/>
          <seriesInfo name="RFC" value="8341"/>
          <seriesInfo name="DOI" value="10.17487/RFC8341"/>
        </reference>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC4272" target="https://www.rfc-editor.org/info/rfc4272" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml">
          <front>
            <title>BGP Security Vulnerabilities Analysis</title>
            <author fullname="S. Murphy" initials="S." surname="Murphy"/>
            <date month="January" year="2006"/>
            <abstract>
              <t>Border Gateway Protocol 4 (BGP-4), along with a host of other infrastructure protocols designed before the Internet environment became perilous, was originally designed with little consideration for protection of the information it carries. There are no mechanisms internal to BGP that protect against attacks that modify, delete, forge, or replay data, any of which has the potential to disrupt overall network routing behavior.</t>
              <t>This document discusses some of the security issues with BGP routing data dissemination. This document does not discuss security issues with forwarding of packets. This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4272"/>
          <seriesInfo name="DOI" value="10.17487/RFC4272"/>
        </reference>
        <reference anchor="RFC7276" target="https://www.rfc-editor.org/info/rfc7276" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7276.xml">
          <front>
            <title>An Overview of Operations, Administration, and Maintenance (OAM) Tools</title>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <author fullname="N. Sprecher" initials="N." surname="Sprecher"/>
            <author fullname="E. Bellagamba" initials="E." surname="Bellagamba"/>
            <author fullname="Y. Weingarten" initials="Y." surname="Weingarten"/>
            <date month="June" year="2014"/>
            <abstract>
              <t>Operations, Administration, and Maintenance (OAM) is a general term that refers to a toolset for fault detection and isolation, and for performance measurement. Over the years, various OAM tools have been defined for various layers in the protocol stack.</t>
              <t>This document summarizes some of the OAM tools defined in the IETF in the context of IP unicast, MPLS, MPLS Transport Profile (MPLS-TP), pseudowires, and Transparent Interconnection of Lots of Links (TRILL). This document focuses on tools for detecting and isolating failures in networks and for performance monitoring. Control and management aspects of OAM are outside the scope of this document. Network repair functions such as Fast Reroute (FRR) and protection switching, which are often triggered by OAM protocols, are also out of the scope of this document.</t>
              <t>The target audience of this document includes network equipment vendors, network operators, and standards development organizations. This document can be used as an index to some of the main OAM tools defined in the IETF. At the end of the document, a list of the OAM toolsets and a list of the OAM functions are presented as a summary.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7276"/>
          <seriesInfo name="DOI" value="10.17487/RFC7276"/>
        </reference>
        <reference anchor="RFC9197" target="https://www.rfc-editor.org/info/rfc9197" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9197.xml">
          <front>
            <title>Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)</title>
            <author fullname="F. Brockners" initials="F." role="editor" surname="Brockners"/>
            <author fullname="S. Bhandari" initials="S." role="editor" surname="Bhandari"/>
            <author fullname="T. Mizrahi" initials="T." role="editor" surname="Mizrahi"/>
            <date month="May" year="2022"/>
            <abstract>
              <t>In situ Operations, Administration, and Maintenance (IOAM) collects operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document discusses the data fields and associated data types for IOAM. IOAM-Data-Fields can be encapsulated into a variety of protocols, such as Network Service Header (NSH), Segment Routing, Generic Network Virtualization Encapsulation (Geneve), or IPv6. IOAM can be used to complement OAM mechanisms based on, e.g., ICMP or other types of probe packets.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9197"/>
          <seriesInfo name="DOI" value="10.17487/RFC9197"/>
        </reference>
        <reference anchor="RFC9417" target="https://www.rfc-editor.org/info/rfc9417" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9417.xml">
          <front>
            <title>Service Assurance for Intent-Based Networking Architecture</title>
            <author fullname="B. Claise" initials="B." surname="Claise"/>
            <author fullname="J. Quilbeuf" initials="J." surname="Quilbeuf"/>
            <author fullname="D. Lopez" initials="D." surname="Lopez"/>
            <author fullname="D. Voyer" initials="D." surname="Voyer"/>
            <author fullname="T. Arumugam" initials="T." surname="Arumugam"/>
            <date month="July" year="2023"/>
            <abstract>
              <t>This document describes an architecture that provides some assurance that service instances are running as expected. As services rely upon multiple subservices provided by a variety of elements, including the underlying network devices and functions, getting the assurance of a healthy service is only possible with a holistic view of all involved elements. This architecture not only helps to correlate the service degradation with symptoms of a specific network component but, it also lists the services impacted by the failure or degradation of a specific network component.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9417"/>
          <seriesInfo name="DOI" value="10.17487/RFC9417"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+VdWZMb13V+ZxX/Q5dU5Tg0gIi0LFnjJOXRkLJGxS0cSqok
5YdG9wXQYqMb6WWGkJffnrPee24vGNBinkKXSwOg0X2Xs3znnO9cLJfLhw+6
oivdRZK8bup16fbJTZd2bu+qLtnUTfLSdXd18y5549qiLFyVuYcP0vW6cbcf
9JW8zqp0D4/Jm3TTLX/epfWyPrTp3XZZ8eXLxl++PLTLz548fFCv27p0nWsv
Hj7oD3nKf+F/L5Innz35Yvn4MV2XwTvbujleJG2XP3zQ9ut90bZFXb09HuDS
62dvv3n44OGD4tBcJF3Tt92Tzz77Cr+YNi69SF4dXJN2cHmbpFWevEirdMuz
uYTPHz7A0W2buj9cJDzkhw/euSO8m8O9q841MIPlU5wXPiXtu13dwDhhaZOi
ai+S71b/BdOFV7wC3xXVNpF36mabVsXP9PSL5GpXVGnyfVVk9R4+dPu0KC8S
XKuffvfZ4z9m+HFPn66yCi5oatw4lxdd3cDLrOhgCb52xU/wBHxd91WHq0L3
NQN6s3qd0hU8oDdplcgb54znAJc2afXxhvPj6vmtH8yPrnpfwBMSeu+c8ZS3
d++f/P7jDee71dParM53hUvkjXg03/bpnSuSty7bVXVZbwvXhkH9VLhVDt/6
446uWvGI/9Eh3aAEmTHdwF2LRN87U4iqbfvbL774xevE/6vqZg8PvHUg6Mmb
b66ePH78lfz55Ve/+0z+/P3jLz/XP3/7+eML0sJqM/ju50++fKLfffLlF/Ln
V4+/+lL//Pzxl/Td1WrFj18ul0m6brsmzUjp3u6KNgEb05Pauvfpvqhcm3Q7
lxzERrWHNHNkn8TgJMHgLOD9rG9RMeuKvpWu4aPumNQbvRzuViewmFUH/0/S
LHOHLoU7J61rbgu4deluXckmpHFZfeuaZNPU+yQv2qY/4HxhLStYZrQ0q+S6
S4ocRltsQHCSstgXnRgheKZ7X7QdDgdG37kM37c3PiZ7kDrY9HbfJn2Vw6Oy
umlcCYYwXyRZ2mZpDl9fgGwk7rYub/FeG5CEHia9oFvd7VyFS1D3TQYDgAvb
YwtWvIU3/6cvGpfTYvkngq3Eldm3rryF64v9IcWLaCJgMcvjz641S5rA+MrS
VVt4N82auoUPi/YdXNoVWXGgqS782uD0wNg3Bz/TNE8PnVylK6xj4QnAYsIS
9XVPg2ngE9x8/sysLC1Me8CVhzXI0oNu7TY90J6uYbfzHK5pYTYqXPsiz0vH
wvYpWvmmznveh798WuDLv+FHVz3cHCTu+rWRqrLQR5hdwuUr02brymOy7osS
Fg1cCm1pDv9JqwymtUnbTrcpyZ3s/MJKQXtXdKjCW55oVx/Q9hxxNWBptrj0
q+TtzrVu+HS32eA9blkJ9ml1DJsBm83iVZJiwhjvXFku1zhCFASRnFXybX0H
Yt7Aw1s/YxC20oVdyt3BwbdoQnjTWt1rWsIo94cShBvWpqgy8K4t6p7cHcYE
awN7vHdGnFV6yvToGpBdEmd4yhFMYQFPLuExMPkWVJ80N4h05Vw+kGJSiNyB
/8qD4sKK7uq+A9lgE5AmWenSJlmDvQPB/6Q//Ete31WfALqAAYHAk4lorTov
6LMii/S1rCtHc6rqDqWs7TcbWG6UFxC7AwwUBhCGIfIMa0NSSE8xVm0xYbfg
zw0sCt5uYLRSfzV8FrZZdhlE2ZE6oi1AvVt7jULjFrQSPg8mL7J6ZO3wSTp8
NkNpDss8WBpSZRwHiuMWV1jHFl1FI2vBCfE+wlMdCV9kX2mzcIhuAxbeGMR6
/RNLd0ur93K8Vqh1OZhLMAXBvhpttWrGw2l7ePLthDKDPO9gsh28hjscyjTD
e6F1nNA9NE1gj9BI1U0HexGMENonVkZeY7zLWBys5Sc7jl5Fl3BCNWEcRRPU
HRyhqha7GSfGn0SmBcXhreYdLI+n3E5VJyDVW5j7ri7B07R9tkNTQPfzeozW
xvqjdZq96w9GM0XJAdt4lSDNxBHhvAGS0HP3AYpv+irjYc67J++TGBI4/FKe
4tfJ9IAQNJXx6FY4CgILoE4ofqivdYVGcOdoo1NvlDPY8bXaZhhDjR+a1fL7
rlemuAeyDGBj9I44U68FcKXstmPLwAIzxhgLr6KkITDdrMMJRQprFSlWTq9/
eMkBxgzPRAOqFjG3ACXAKlQ1enN+7dKy2KI6onaikd/Xlb1i0yAg2/4hKTq8
Omfl64t2h9uI4pyVIIlozmONvNsVIGAEzhxqUrFPmwIGXFdjN0mzIg/Ksyef
IzMvKvVK3VK/aER/pY7+rWtgoORRVYYg1Esw1muTTx49evH9zdtHjz5Z6N/J
y1f+9Ztn//H99ZtnT/X1zbeXz59HL+zVN9+++v750/hVfLerVy9ePHv5NNwQ
Pk0m3n5x+Z/0J04fXr56/fb61ctLfHJSDHwIgziCPGheG/BB5GFxk9usKdbw
Ar7z9dXr5PHnyX8Lrv8z/YVY/s+k6OLWRUEqMjiggIcDOk10FGWJJg7wbNkS
UGh34D4TVK+Vxg+fTmQJxukEvPKZmuqAsVqIag5lfRxgpzNhE8Auup9BTIKl
IIQHa5Q4VBLHttbYcQv/TxvpOQt9DyyD+8IHeUnP/YXw7FwfYCwHPJ+hlcFe
IWTwUcSU71bLTkAMlhFWqTVQK1XjgVbrZJQxabknTI4GdSDbaKxbMIWwKHj7
OssIk8NF8MAwfjS+FA4ClizEo4P/7j4o1AJLjY87IwpEvwDyBi9iMDOBV2aR
Ey3GNxjBQTx7QIg95Wh4X8ERg2NtNz2ac7X+cKuKHkLyuenIkyHERfxWVF40
eXUUqar7wXG79wf2c+bJJDf7vuwKGFMC0rlDDUdRTqsIQ+yObNFDQLBKbkD4
IAxC0N441URVPIKqYD4wpUaCTnengemUIGSAecv+4agLCc1othBs+v0L4UgQ
wYJFML2FedOuBUhC+MHgEZVE2JG26HoJzYuy7FHAAUmDTfOSabUIvTksW926
KKgvqg+RNFIpXGK42pgbM5dg8OBuh3Qrb9ZogTnK6tyEWtVlWd8RzOzXrRNE
JfkShLIYlFQdL76dFY4TTQL4kNu+rCCiUwBLtiaaKrkDWQI7bTs9srccrck0
0XSASUDNZVB82sYexZX8/e9/79x78BS/WX6sf795+OCvydPB5J/z5H+IJ5/c
+++veLOP9U9u9lo0i+Dgptj2jaZTwEJuxfHVWQ0XQOxN6Tbv5GDT+wbXUm8W
7M0fkl2R5+gUVGFxhvglb/ytSAxH9lE34NzlOOu6248uHc/jdJ3HKK9jzX6j
mn3Phn6cf3KzZXIdLICPW3AcEEvRsKa2ef5eJm0RzCUq6JwZO2dc6R0YXEIl
JqawZjuI5fS9vod7ASovKsIpIQzMJoTz3gV7GsMUfzfFKmfe7P+TBlwNzfWN
bNxVbK7vU4H/Gw24ChAWhubz4SZFgVbt/SElUCaB9My9biaABBhaiG/QfSEO
5MA5QK35cYF9oPxJvgCk1BJynPPZ908SI6e8x5AZM3kC8EKuPMTAp1fsowoG
uOOHD/5ykXwKbmn5OKHa8r99AmFJ5FCfMTiYCAGNYf3kbxIqfnqmM7Z5P+uo
ED/WTbElW8GxWZrcpk3hOFd68O7UpKo/yJkuVdhsgedNjKbUcsJWl33uqJ71
KHn0SJ05l5J10BePHiXfqLDCGBGuA2zCDGKLQ8M95hCr7Q/4LiPFTZMCPO2z
rqcsKoQ3KYWANmoLcgrfhvmAJY5LI4XkUHF0VxZgJM+apm5obGjKQcUw/cTS
W7XgAnFTIkjSBnyeJ3nfCPq9LbA6T9E4xVKu4jVFp1KXRXbkVJWjGYc0Fc+F
07YhDPAR/WIqguc1EqUo2rqkcfn5vS4hpNOU2FPacfgPPoamKYJ259J36Kxo
+0xmnWsvUVymUhOCHptoWrA5AnOD63/Qh9NOcZiD60FRlCQYZdGo3loGAbUb
hOnSJd6LvftrkdfksqrhO7CbOJPLtdxCxTlZu116W9TNYrR/5oZU8qBRq73i
zJH62TWshcNCooRylFmcilL9gK/BzgGc6GCZ4T6F2qhf/6mB+avI/zMO+SpA
gKKSVGCQ4/2hrmC8ra6ZLTPBtTBQLw0QxDYFe6q+MjE7bMM71yVl3ZJOlSls
5U9F12ECBWZcU6bWKL11AX4+NwqoQSWo7EjL/SLFSWJtkpaOSSHFz1TOIu0r
qDw9VlAPsRY0RzBWRRuS4ly405y4L6VL5CdGT4XF6HaEz/xKtSbINXgrrykP
AHYCRJ7zrRymRaFoqNwW8M1b8kQlRviY2ZdUE6WzYM4+D4XFz+NkIGyDQ94+
Wv7WqoUEoD3YgzLKoNsdTnOeBywAmEJCmE3IkI1SKqFQhg/S9LogZEpr5Esq
XEdoWcUeNAy8CudcOBXZcUYE1gFLI9GXNMGiOz5QaUpnUC0g7SnrgDkW0EEU
Io9bKPmSaordZFt8Co5rKyTpmuagWb+oG1dTbjAvYABUtp6kJtA4VclXyWVI
5GgwgRd04FCxDqRKBvOHTW0KmASJI6urFnnbMD74vBSyChcdU87tz6gZJk2j
ZAhaISnIwTA2fcP1FBmOT+6y/6A8XBAIG7FkQQM8lu0wLzWRbjRcBkkBrulN
XCHHao1MNZZu4R4cebiqGn7xRL2ZAIKVk7b2qnakKina4pxKbHczORdauOnN
043jUswHpJxWgrU+NLR94e8QZevPyKay5PvilGs4p2oqklKzM8g9aTMAC+A2
bNZZBF3QgKclsOvSTJO9iOrWATfdV3JcQbTJHBtiL0yv/EJIAXb8rPG2ZLoa
5uFs4gxzkIcUxpT1lCPFhL+7TZkvMBZL2bFPbVwtDhR8p4n3v2Vr9tQYI/zq
68lscnc8MK1CWTFJe3AZcmny8SYkzJgIxi8iFNlMrnFGYiDfTpQo2F6Sv8eF
UDZWKN9lPKPhZoJ3bU021xRCgoU2NcApGEFZdEpje3sX4+nFABp58VhYoZGU
gQEQxkhbd7BKfoxsuQGMuMx4V82xm1EiQqaMu+HKGEsfeQ00Zu595lwu7ISp
bFCoMK2PypeLsewqIafJhnZfN6RTCZWEBz5BM9EYeoAh3u5mvYMHoRZMMlQX
l2sqShQA4Lc8QSdYdO8YB8WmtTvWovgS+uG1iGHyGrGE0R2T33oT5bdmLN5A
deasGy4I2QIJxCbTaFQ18ZuH9Y+MxCGnRZTF08qNzFXZQQdaNwpFT+gZjQOA
fqj7rWHEd0Xe7RbRxSTTGprQVoBH7COluhzm2Xhm4MVuAe7mGlpHMSbYeLQf
NDbCDZ5lwTDHVG0YKRt4Pg0JxF+QTQfFhI3VhSrrlLkfbybqkbwh6G0Ff50g
m9BiwISfvUe/TIUoFVj4g96jSjKo7GT6kcksYLz3rkPADZ/h2BRiklAEIYgq
oSKkRbqtagjJTpSr/UN9IlTDkhjPcB2PojsuiqZKyKHqmiXRBPZKXrt2FAVs
e0A8oI6aWhhXP4X0ogXSEL+GcGHKa13abPBLkw02SUVxszK/W7YJxgDFPJDp
SmkNmoTEFGaQ1GscNo1f4WJRBWObSIqbtl2of96tTFUX/Zql5V16tMxTqWxC
mMKhLxVfkYlc594oo3qpWzJlz5nYlmXY5ZNBrvNiK0FtFOiaCJes7x5fc+uG
NwZcXmdMeFkiPRKM+avLF4ymvGBPsdxCTJqka6RVThEG4iqsbETATGuiDG1R
FwMB1Ce9lAk6JJeyZedB/yicTmN1ldbA7kHitxgrWq8TERN1u6MM4JzVxw3F
HcfPtxVEB6KCtMrI1rLVBkxOlWiOsPJ9QA/aFGj8YVeKbWpCFa83ceVjDpZf
Zl5dXiprBgcnzJlQvzecx9N5tIGNtJARrYGieQOzSkoxpp2JOLsCYlPkC+M2
xag6gBOz9pJm6tJ3sFtrVFtDoGF7SqrLnp6FgY2lBkQsXIxv0oog2SqZY1V4
mpBon0ctxhtrzGpcl6YsqKhOhncUiNpglfy1v6FFRrTJlDmIsmz45dKlOUuV
OJ0JSlPdZkVZKj8g6LOJmheDkHicz9GkELvpxWijFfcmkgEmaB1Sqz7NYT3H
QTgaaAQ93ykkpPqOgCwlN8ImdvWWyJJe8gdlOi/rN4y5Y96vfCYZCCS9HH14
gaOsK2x4ISqEQvYZNGDxjL+oJBNUNxkEfZ0kcAA2dGge1DbRZlsLFSJKwy6R
GqOAI+2vWBsbL8i8TfdR3o12g7l3jaHqIE+NjYcbp7tmpjUTTiyMrbeGXWw0
eRcusYUCFqe4o0gpQB35onu/Aw0y6e2UeyOWZBqGQJdIxlnRZP0exLjKlHNi
E3dciINwlByKEX1DOgZ3UIIjtKaCmxIsHduDMXTZmPHnLiLPAVoEuGWNNM0a
+dmbo/BaYtkOdFoUxw6hvwn1J3NNF3QjyzqfJD6P5GYUExKuZlpt6Tz1m6Vm
X7edNEpoAuhDK7vKLbKZjEAnBQxwq9Ghu7Wxty3RUeSwdpqMYegoVH+mMvoo
rs1g70RFj9rLQA42yiRgXW86SGNQA2AIZI1Sd0aliLzFLEgwwLXKpa8gLblU
jOPkyWigO8mZnIt+J4NbhWNq81OwUNvZRN0gh+1TFpbWN5On9ay7SbbdKrkW
ktyQhoe600aAygeLA+qdgZtcfEVO5jCTa1GQHeggXUvoOyL6a4il3pTL+Jri
8EaT5CQyISZ1GOiSStAXnzJD5p8Mh5h0am4lLT3+ZjOdPW8Nd3+aSoxRKuHF
vNVMhjQj2cSXjRhMsCB2nRi+BSM8QOZhyd0MnEUB1CrkBH9Uu6RMIwpF0FrM
pI03Ebu3Vuuj2RR+sPd/MeuP1j9ycL4jw7FFXjufHmeqOsYv+EVfTr/mhb3B
3cdCHD5Enxo0clPWd+1iquiGeSSOI0b+dwCR8GkWkdxgZIjNs/JUAfwwaq6F
TCw6xTTkDcgAFl1rg+qAhIhUvBpM8anU2PV5GP/V3qPOP5PFpA3SwHmX4POZ
ocC40cSHrIR9MxXP47A8HHtmDbGOTpO1hGDP7fIihT5g0Cxs3TF5mh2B8rET
qVHLlXjfTnEQjSKsLk7fsSPJld8wCM4YLmoSWgR6T3lYigJgt9HoSg7a1Hq8
mIOGtru66XglVa4FBXV1iTUdxisU2egiIFSJUmF4gQYvcTFviu8zaa0c+ueK
k7NuUDn07YRF+25sVbinwatOwFZsX9RwsUvRMJDKT+yd4x5XS7LGpuxmkHVE
qNKiB85ny6/DCMWCwYkmgYEllUTRkA3GCygIxJs9KtNJGaqNmixn+yqJ+dxz
o81MpWii59I2bPieybkimg+LTU+lvf/9DQocoWiLQojJuO2xxS9HKmeZAqEY
iojOAmhpqpaEDVcT3JKQEm68/sXtZ23Hr1FFt2z9bY2iLGBMx4zwDbWMZT12
aCdiFgyT3YX8CLcWGT7Zn9JDcond6S1A78swLq2TPdenqIU4Xf31feV+HIhq
iechw9A1GXD/5yVnRkROtRqNcqpzuzmxe3Zc2qLI3ft52Dc0jPfsysU5W+vt
bnRL32YgqR9q80GppkJBO9NlaHtuEUxT4qF1YECY5mkCusMOKQer5A0dOEBB
HHdQh6B/EcVuI+USgg6BV0zegxTRsQJaXBfYj3gonUidzPRZKDOAA7v0J+GC
RarTJUht46U6s8XhN0mS/AMfIY309Ztny2c/PHv5NuKE0v+vX44/kY9ev7p5
O/qQaKm04r9Cel5eUBhGnyyX/06EYZRnSj38iu3bSj66bMle/krPcbiHmfoL
5jvNgZX/f+BHeL9vp5j0/KWbKGLk3dWlDZUP1e5TROh7xxcqQTuHMVoY3/cg
sC0TU/cHOm7Cf+l1aBuSwZ0x3zEB4JzxvRkkQ1p/v5NfUkITxLS5CBN/dKhr
ZEewZrs8mi9VIuOi3C/Y35A9mp8UEl4BoXat+SgiZpv7ffAg7hnfc6npKpZf
hi9dSzN8RCjnj/RbYa30fnssSIF1Rlimay5fCg34o/FtIDrDkuJ4fB93vh/b
Hkw/6EP+Dfov/nX6Uff8mx3JD35//ArzwSF+ewaE+ydKuDcI6Cp4mD+hmp8C
QYZy/1q9+8WAIoEWPtRrmXBsB/Twwdccs6cW2jDSo0RQO0mxM6n5AVbyXtNT
wcctiCFTWzRRTkEQCY9wFk9zS+dWj+OYacX13DZfphX+9qAPzyTZx0VKU3c4
eUbIBq214LQNH43ROoNNolo0snliyBnyQRKfz1XbheH+hltIiAQffNmFL8b7
c4aG8xmWBaj+ncPyw32JwaZYby6YWyjZNtT/fJ2W8zFD8qNpKVgfQzqZyfsS
U4XdgHgWk+2ceDT9BMK7WnItLwoFJzprDZnGc/RNMLAeijwmE0jY/fIbHbr0
kBR34Erqn6qNN+pbL4bFXS+vvnGAqop4OkZ8NoZJRVDiIJC8QnKaAnTlBDlw
Bb3PgWC8KwdbhetDE5UPUocpa62qh3KvTySE7HWoL3h2ilz1T61Vexwflnvy
Ee0yMCs7PrzLS5siAll09XNiR4dlQ8/2uqAMVZTJHBIMDWOmXUzWl8KhZCdP
r5k8DwrTM7wDMFqmNwGELtHcZF4a7REVcZ/R2IoxP4dP5Ajh4EwvyYCX5Q/n
CV9k1rmeZCMjHKUAIxlnp8D3R/v1VLON/rTNYFwicXZ7DN+QNWFTWkiAHQ5b
M9JGADQ5jDdD+rSm6HxGboKhRJPDWpwPdlVqKSPezu1pOMhC7EHMt3+UjANu
aYpPo+MtfBxt3SEg8otRkZOql2aNaR9IR6j4v6HRTlHFp7VFgcSZBxv293Og
tYR4XU1ih9DGl1z60/4WNjJkJbr0Z//h/Z5qidjmOz4IQYR1On2MCW2VkmC9
5Y+OETk7s0b5u6mEXXxGHbkbbxxIbUWeYmnyJCzP6H91+WJ8YtkUJUmI7sos
jGhyNgmiMGKYkiDJ05UZMbbPlYqhC7QYRAvMXNgIdiFQ8ZTS57l4fTuNNjal
UjuFG2orH1hfGlWikm8C0ywiop2inWmJyNa1kdrkfZA6d+IOYC1K1pey3CqI
/bBQGDW+xH5yJEonpj+RMhwcjxd8Y7QRCkFMbuAidIAMaG4sSXGLC0hY6+3y
KUtF9bThMRMRmNDKOheyovR4IJpjUbkYbAOmG3krFKBlptvIZKEI6ZzuE58U
XW+dUJ2f8jmUIV0RqKrz+O3EHiIBvJeDtKm+6s9sGyGSc2jcga48KHIOy/vY
kCHgYggHiL/QeHJRMF5krqQhSooGrHqhhI+050Dc15L9lLzHYnllOM0RaAvt
RuhcQkfHx+AxMrqn/G49ybiakOyIfC09LWC31gQt7D6Hg4oiNt4UnS9m6E2y
RWw23HZXinxrdf40RvOLanIEzMn0aM1KM5fSK+a+5y6jJu7lPn2nITCipNH6
3ndw4zR/aaY4vQrWKARDLOJuUp3U+en5iiZ4Je5tuomotkqOQl5e6A8LU5g6
ZXIO40EY1zUUIZ8J7xCdSRuI2NY0Av/ccmOOiOBzu2A5yjIw2wzu0doiwsJB
ZXGuchiX08cYx7pTUwSZkDXMIflC0DCJ5FnKmPlPtavrKpzofB1OdCb4Iy0w
Z0JAf4AnH0Mp+ZbJMxCG+QxhguPCEg0H7sC0Pns2a9gA2+zJwA3/GuenqlyK
G0yvNwlWavro6cAGE+CuTLqJgRtLALeYR70qXvzHSSSbnDkziTREf4MkktlE
LXDU2HaAFszv6g+4YOJ1L8LbIuOGwONTUv78WC1VULeb6RNDTOUTQqMep8bB
+lXCaBvtZnwsIh1KluPo6may1z13e+4a6qIjNAxm5H6qwDFhcOLNWwQ5G0/T
9fIH4a2MWGimylqZ4K8P0VoELmcYN+H9sWnkoDXtpMVTsw6swJq/5I4HRqsz
8HQxTbm08CrqhYqCHmmB8lwlX6ZmNEfWdES2QJPY0DF1eobuFB3ozqGx5EI4
H5rJ+NEe4oiOijj9tPqGv8enXJjXUq4ap1CvY2RJeyE1H8qkXiTfGH7CiKEz
5i/b83/vpdCAmSsdl7g8pINdBa1PpR4VDmAZcmoGLaiDFMo4ehmc5T3mXVOw
qgaPvZdpg7A5Oz00ifNSwheKVWkg7t9o2YPIuKaoYdwDupZg5eq1ZHWGP71A
bqi15LbJ8xP9STEUio7DrkGYrRKyiPJ6sY4hNb7BvemINRKvTzOkKIxrC4N2
tpDlo5PoFSgufKcJpr9udQWsMQwtYrNZyFARlIw2ilp95KHZo3gUzbJfvRt6
vPuwkWH/DFHR2F8HxDZNbKtaf9rR0EGTrV1jTpqceIEHbzWqqcNMGYkiXex/
D8IbLx1LQVluBCM+ezbrwIXhOk+OYlaMp9QoP4YocSUsFJ8AgNuxssaHZcbH
7VO1B8xyhmzWfcx4a7XFJNPXmNLDLL8iPgdQtSLCb75KSR3L6KKl6RYsYYin
hsuOJU3X4PFDsGaXvPIyhNYpCCHX2g4IQ6Nz9GFeqTCfhno1/0sjmU0/qkVd
0vpO/QpJwDuzP0diz0YPhkrPf45GjQ/RqPhMjtun/JNDlNa+Gq7AxJFqz6od
7pBCaWHhe3LbQDzPYLgJfHJ6bNXJ3y44Iz9ottdOR+iaE0eonPXLKHOdEzOb
4InIFDeplIV068TPu8TpV8rH2l7RoBu2+vWWOm/kZA22LIICAyXwzF/mOP93
NU4yA2O+Wudla7xEQTSmf0YJTLEXtXC+nddJpuPZEvPRAFolihuBtMX/Uwfh
2DyiP0ptfK6W/7GngAHmi9JxRZ8fQwXmcBachHXWMBpxNOcmcN9XmJekFgTi
RogrlKenitBWvIRXpn7a4Cxutwnnk0U8NLyFpHmX9tY+Dzy9Dz5RelbLtDnL
xJfyd8Vhvpk6ilQHnXf3Zs+t1+W1ljMW2yg8n2rZ99IiYEgy6MwsyKaOGTCx
Iw4kTmzvxM9pnnrY0DJzSErAF6GxJHzJEie57y5yUSEdPb1z9xa1TL0qBNYn
Sku+QS3Lag7CT5sgW08v3Ugv/F7Z2u2o+SxktCfToZFY4aGCHlqc+Ytt6W1d
TBHs6XwTn7k1WdmpowCvTF8+nV4hvx8Ej9SQfE67fEtp4E6ccYIWagoNXDmI
tHYaqUyllu2dliDLFFuahLShE8T2n48pE1c1qFEMDjTw+doTZ23ZTmTJOgZi
lDlZKVW/ZM9GCOFXM5nYVcwhZ7+Mf9fG2sVx+sonJac3S7p8RzFgArqFK2k7
llTSTIYi/u0obsGRw+N8o1HgPRgu/ImDSUa6xPZTgXxombWdTpNZHT+rKGbg
uD+cvCcFPGnkyu1Ra03MfR264+nUgN+UwHicCfYndwQJXFGgi2nQgaefabP4
h+N9xCbCVpfgbxRyTAbtgxvaVPAqufqAEN60RAbuEN47xPDePNho3diw+aB9
hP0GnRqVP8vIH49RhzNF7mkd0TIZUZx+DhQk/f0ZrrgvqUE7Ohc0nMaRh1/X
CbZCf0iYWwhNitwSs+z5bFynC2cdSnr8QGHkztnfwNIfUPIZCKQ1Uos7pm/5
gLyMOoJ5kdhsN2B1UQRw+pHSCnrBsB6GgyVSaoYMADvaAP+DYMk6xT6mDf2q
JzP2kI83UaBPpdENM6bcqudMpHkauvtjGsy5AG+/firBpz/v9kr8Na+fHLul
txtUVYMLxWRR2nWYJbiFlakbptNpMztc+ZPoDEGUsuX1COdQgGinVJ+VfvG+
CqdnMlQIR39OnIuChA/WV/xRMscH48yEM/KrXGJVZXu64xJ2AXWth7XEoC3U
V6Q6ymPkVig6zVp+vHqwkteXLy9Hq4gfP/hfCDTYLph7AAA=

-->

</rfc>
