<?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.29 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-geng-fantel-fantel-gap-analysis-01" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.29.0 -->
  <front>
    <title abbrev="Gap Analysis of Fantel">Gap Analysis of Fast Notification for Traffic Engineering and Load Balancing</title>
    <seriesInfo name="Internet-Draft" value="draft-geng-fantel-fantel-gap-analysis-01"/>
    <author initials="X." surname="Geng" fullname="Xuesong Geng">
      <organization>Huawei</organization>
      <address>
        <email>gengxuesong@huawei.com</email>
      </address>
    </author>
    <author initials="P." surname="Huo" fullname="PengFei Huo">
      <organization>ByteDance</organization>
      <address>
        <email>huopengfei@bytedance.com</email>
      </address>
    </author>
    <author initials="W." surname="Cheng" fullname="Weiqiang Cheng">
      <organization>China Mobile</organization>
      <address>
        <email>chengweiqiang@chinamobile.com</email>
      </address>
    </author>
    <author initials="D." surname="Li" fullname="Dan Li">
      <organization>Tsinghua University</organization>
      <address>
        <email>tolidan@tsinghua.edu.cn</email>
      </address>
    </author>
    <author initials="Y." surname="Zhu" fullname="Yongqing Zhu">
      <organization>China Telecom</organization>
      <address>
        <email>zhuyq8@chinatelecom.cn</email>
      </address>
    </author>
    <author initials="Z." surname="Han" fullname="Zhengxin Han">
      <organization>China Unicom</organization>
      <address>
        <email>hanzx21@chinaunicom.cn</email>
      </address>
    </author>
    <date year="2025" month="July" day="07"/>
    <area>Routing Area</area>
    <workgroup>FANTEL</workgroup>
    <abstract>
      <?line 58?>

<t>Modern networks require fast, adaptive Traffic Engineering (TE) to support demanding applications like AI training and real-time services. Existing mechanisms for load balancing, protection, and flow control often lack responsiveness and scalability. This document analyzes key gaps in current TE solutions and proposes fast notification as a low-latency, event-driven enhancement. Fast notification enables real-time network awareness and quicker reactions to dynamic conditions, improving overall network efficiency and reliability.</t>
    </abstract>
  </front>
  <middle>
    <?line 62?>

<section anchor="fast-notification-for-traffic-engineering-and-load-balancing-gap-analysis">
      <name>Fast Notification for Traffic Engineering and Load Balancing: Gap Analysis</name>
      <section anchor="introduction">
        <name>Introduction</name>
        <t>In use cases such as AI training, a lossless and adaptive network is required to ensure reliable and congestion-free data transfer. These workloads demand high throughput, low latency, and zero packet loss across dynamically shifting traffic patterns.</t>
        <t>To meet these demands, networks rely on Traffic Engineering (TE) mechanisms, including load balancing, protection, and flow control. However, existing solutions face limitations in responsiveness, coverage, and operational overhead, especially in high-speed, large-scale environments.</t>
        <t>This document provides a gap analysis focused on three key TE areas:</t>
        <ul spacing="normal">
          <li>
            <t>Load Balancing</t>
          </li>
          <li>
            <t>Protection</t>
          </li>
          <li>
            <t>Flow Control</t>
          </li>
        </ul>
        <t>For each area, we analyze current limitations and explore how fast notification mechanisms can help fill these gaps.</t>
        <t>It is important to clarify that the mechanisms discussed in this document, such as BFD, IOAM, and traditional transport-layer flow control, are not necessarily alternatives to fast notification. Instead, these mechanisms can complement notification-based approaches. For instance, measurement results from BFD or IOAM can serve as triggers for fast notifications. Similarly, existing flow control mechanisms at the transport layer can work in coordination with network-layer flow control enabled by notifications. Therefore, the "gaps" identified in this document reflect potential enhancements when relying solely on these mechanisms without fast notification, rather than suggesting they should be replaced.</t>
      </section>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>TBD</t>
      </section>
      <section anchor="gap-analysis-for-load-balancing">
        <name>Gap Analysis for Load Balancing</name>
        <t>Load balancing ensures efficient utilization of available bandwidth and reduces congestion. In modern networks, dynamic load balancing is essential but often lacks real-time responsiveness.</t>
        <section anchor="ioam-telemetry-limitations">
          <name>IOAM Telemetry Limitations</name>
          <t>In-situ OAM (IOAM) provides visibility into traffic by embedding telemetry data directly in packets. It enables measurement of path latency, loss, and performance metrics.</t>
          <t>However, IOAM has notable drawbacks:</t>
          <ul spacing="normal">
            <li>
              <t>Telemetry Export Delays: IOAM data is extracted and reported by the device CPU to a controller. This adds latency and limits responsiveness.</t>
            </li>
            <li>
              <t>Controller Reaction Time: Centralized controllers typically process telemetry in software, resulting in delayed decision-making.</t>
            </li>
          </ul>
          <t>Gap: These factors reduce the effectiveness of real-time load balancing.</t>
        </section>
        <section anchor="role-of-fast-notification">
          <name>Role of Fast Notification</name>
          <t>To address the above:</t>
          <ul spacing="normal">
            <li>
              <t>Proactive Signaling: Fast notification can signal network conditions (e.g., congestion) before service degradation occurs.</t>
            </li>
            <li>
              <t>Event-Driven Control: Control loops can dynamically adjust traffic distribution without relying on polling or telemetry aggregation.</t>
            </li>
            <li>
              <t>Lightweight Signaling: Avoids the overhead of traditional telemetry processing.</t>
            </li>
          </ul>
        </section>
      </section>
      <section anchor="gap-analysis-for-protection">
        <name>Gap Analysis for Protection</name>
        <t>Protection mechanisms ensure service continuity in case of failures. While existing tools like BFD and FRR are widely deployed, they have inherent limitations in speed and scope.</t>
        <section anchor="bidirectional-forwarding-detection-bfd">
          <name>Bidirectional Forwarding Detection (BFD)</name>
          <t>BFD is designed for rapid fault detection by sending frequent control packets between peers. While widely used, it presents the following limitations:</t>
          <ul spacing="normal">
            <li>
              <t>Overhead vs. Frequency Tradeoff: Higher probe frequency improves detection time but increases CPU and bandwidth usage.</t>
            </li>
            <li>
              <t>Scalability Issues: Maintaining many BFD sessions in large-scale networks strains the control plane.</t>
            </li>
            <li>
              <t>Path Detection Limitations: In scenarios with multiple ECMP paths, BFD struggles to detect the status of specific paths, making it difficult to identify partial failures or asymmetrical degradations.</t>
            </li>
          </ul>
          <t>Gap: BFD struggles to balance detection speed with system overhead.</t>
          <section anchor="fast-notification-enhancement">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Targeted Notifications: Fast notification provides event-driven alerts rather than continuous probing.</t>
              </li>
              <li>
                <t>Improved Scalability: Reduces resource usage while preserving rapid failure detection.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="fast-reroute-frr">
          <name>Fast Reroute (FRR)</name>
          <t>FRR reroutes traffic upon link or node failures. However:</t>
          <ul spacing="normal">
            <li>
              <t>Local-Only Protection: Typically protects against only adjacent failures.</t>
            </li>
          </ul>
          <t>Gap: FRR lacks flexibility and responsiveness in complex topologies.</t>
          <section anchor="fast-notification-enhancement-1">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Instant Failure Alerts: Enables immediate detection and rerouting across the network.</t>
              </li>
              <li>
                <t>Minimized Packet Loss: Reduces the time between failure detection and redirection.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="routing-convergence">
          <name>Routing Convergence</name>
          <t>Routing Convergence mechanisms depend on routing protocol convergence, which may take hundreds of milliseconds.</t>
          <t>Gap: Delay-sensitive services cannot tolerate slow failover.</t>
          <section anchor="fast-notification-enhancement-2">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Real-Time Failover: Triggers immediate switching to standby paths.</t>
              </li>
              <li>
                <t>Service Continuity: Ensures uninterrupted performance for critical applications.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="multi-path-routing-eg-ecmp">
          <name>Multi-Path Routing (e.g., ECMP)</name>
          <t>Equal-Cost Multi-Path (ECMP) routing uses multiple paths for load sharing. However:</t>
          <t>Gap: It lacks fast detection of path degradation or failure, making real-time traffic rebalancing difficult.</t>
          <section anchor="fast-notification-enhancement-3">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>On-the-Fly Path Reallocation: Shifts traffic to healthy paths based on real-time failure or degradation alerts.</t>
              </li>
              <li>
                <t>Improved Reliability: Maintains availability during partial failures.</t>
              </li>
            </ul>
          </section>
        </section>
      </section>
      <section anchor="gap-analysis-for-flow-control">
        <name>Gap Analysis for Flow Control</name>
        <t>Flow control ensures congestion-free transmission and optimal throughput. Current mechanisms either react too slowly or lack granular, real-time information.</t>
        <section anchor="sender-based-congestion-control">
          <name>Sender-Based Congestion Control</name>
          <t>Congestion control is based on end-to-end feedback such as packet loss or RTT increases.</t>
          <ul spacing="normal">
            <li>
              <t>End-to-End Delay Sensitivity: Sender-driven control relies on detecting congestion from end-to-end signals, often after at least one RTT. In bursty traffic scenarios such as data centers, this delay may result in buffer bloat or packet loss.</t>
            </li>
            <li>
              <t>Ambiguity in Signal Source: It's also hard to distinguish between congestion and transient fluctuations, leading to overreaction or misjudgment in rate adaptation.</t>
            </li>
          </ul>
          <t>Gap: These signals are slow and reactive, especially in high-latency or long-RTT environments.</t>
          <section anchor="fast-notification-enhancement-4">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Mid-Path Feedback: Intermediate nodes can issue real-time congestion alerts.</t>
              </li>
              <li>
                <t>Faster Rate Adjustment: Prevents packet loss and improves flow responsiveness.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="receiver-based-tcp-congestion-control">
          <name>Receiver Based TCP Congestion Control</name>
          <t>Receiver driven congestion control uses feedback signals from the receiver to adjust transmission rate of the sender.</t>
          <ul spacing="normal">
            <li>
              <t>Control Loop Latency: These signals still traverse the network and are subject to RTT delays, especially problematic in high-speed dynamic environments.</t>
            </li>
            <li>
              <t>Bandwidth Overhead: In large-scale or short-flow-intensive environments like data centers, signaling from massive numbers of receivers can impose significant bandwidth and processing overhead.</t>
            </li>
          </ul>
          <section anchor="fast-notification-enhancement-5">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Direct Congestion Signals: Reduces RTT-related lag by injecting congestion indicators directly into the network fabric.</t>
              </li>
              <li>
                <t>Efficient Scaling: Enables scalable control even in environments with many short-lived flows.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="explicit-congestion-notification-ecn">
          <name>Explicit Congestion Notification (ECN)</name>
          <t>ECN marks packets to indicate congestion, avoiding drops. However:</t>
          <t>Gap: ECN still relies on end-to-end signaling and lacks precise real-time feedback.</t>
          <section anchor="fast-notification-enhancement-6">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Granular Congestion Updates: Real-time alerts from within the network augment ECN markings.</t>
              </li>
              <li>
                <t>Proactive Shaping: Faster congestion mitigation before queue buildup.</t>
              </li>
            </ul>
          </section>
        </section>
        <section anchor="inband-network-telemetry-int">
          <name>Inband Network Telemetry (INT)</name>
          <t>INT provides path-level telemetry by inserting metadata at each hop, which is returned to the sender via the ACK. Some congestion control algorithms, such as HPCC, utilize INT for precise load-awareness.</t>
          <t>However:</t>
          <ul spacing="normal">
            <li>
              <t>RTT Dependency: INT-based telemetry still incurs a one-RTT delay before feedback is received by the sender.</t>
            </li>
            <li>
              <t>Feedback Loop Latency: This delay limits responsiveness, especially in dynamic high-speed environments.</t>
            </li>
          </ul>
          <section anchor="fast-notification-enhancement-7">
            <name>Fast Notification Enhancement</name>
            <ul spacing="normal">
              <li>
                <t>Immediate Inline Feedback: Enables mid-network nodes to send congestion indicators directly, bypassing RTT delays.</t>
              </li>
              <li>
                <t>Enhanced Responsiveness: Combines the accuracy of INT with faster notification paths for congestion control.</t>
              </li>
            </ul>
          </section>
        </section>
      </section>
      <section anchor="conclusion">
        <name>Conclusion</name>
        <t>This document highlights the following gaps in Traffic Engineering mechanisms and how fast notification can enhance each area:</t>
        <table>
          <thead>
            <tr>
              <th align="left">Area</th>
              <th align="left">Key Gap</th>
              <th align="left">Fast Notification Enhancement</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">Load Balancing</td>
              <td align="left">Slow telemetry export and software control delays</td>
              <td align="left">Event-driven signaling for immediate adjustment</td>
            </tr>
            <tr>
              <td align="left">Protection</td>
              <td align="left">BFD/FRR trade off speed for overhead; slow convergence</td>
              <td align="left">Lightweight, fast fault alerts across the network topology</td>
            </tr>
            <tr>
              <td align="left">Flow Control</td>
              <td align="left">TCP/ECN feedback too slow for real-time adaptation</td>
              <td align="left">Real-time congestion feedback from network infrastructure</td>
            </tr>
          </tbody>
        </table>
        <t>Fast notification mechanisms provide a low-latency, low-overhead method for improving responsiveness across load balancing, protection, and flow control. These capabilities are increasingly vital to support demanding applications like distributed AI training and real-time cloud services.</t>
      </section>
    </section>
  </middle>
  <back>
    <references anchor="sec-informative-references">
      <name>Informative References</name>
      <reference anchor="RFC3168">
        <front>
          <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
          <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/>
          <author fullname="S. Floyd" initials="S." surname="Floyd"/>
          <author fullname="D. Black" initials="D." surname="Black"/>
          <date month="September" year="2001"/>
          <abstract>
            <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="3168"/>
        <seriesInfo name="DOI" value="10.17487/RFC3168"/>
      </reference>
      <reference anchor="RFC5880">
        <front>
          <title>Bidirectional Forwarding Detection (BFD)</title>
          <author fullname="D. Katz" initials="D." surname="Katz"/>
          <author fullname="D. Ward" initials="D." surname="Ward"/>
          <date month="June" year="2010"/>
          <abstract>
            <t>This document describes a protocol intended to detect faults in the bidirectional path between two forwarding engines, including interfaces, data link(s), and to the extent possible the forwarding engines themselves, with potentially very low latency. It operates independently of media, data protocols, and routing protocols. [STANDARDS-TRACK]</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="5880"/>
        <seriesInfo name="DOI" value="10.17487/RFC5880"/>
      </reference>
      <reference anchor="RFC7490">
        <front>
          <title>Remote Loop-Free Alternate (LFA) Fast Reroute (FRR)</title>
          <author fullname="S. Bryant" initials="S." surname="Bryant"/>
          <author fullname="C. Filsfils" initials="C." surname="Filsfils"/>
          <author fullname="S. Previdi" initials="S." surname="Previdi"/>
          <author fullname="M. Shand" initials="M." surname="Shand"/>
          <author fullname="N. So" initials="N." surname="So"/>
          <date month="April" year="2015"/>
          <abstract>
            <t>This document describes an extension to the basic IP fast reroute mechanism, described in RFC 5286, that provides additional backup connectivity for point-to-point link failures when none can be provided by the basic mechanisms.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="7490"/>
        <seriesInfo name="DOI" value="10.17487/RFC7490"/>
      </reference>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA6VaXXPbxhV914z+w07zUGeGYB33K2FfIlNSoqnsaGRl0ual
swSW5MYgAGMBSfTkx/ecu7vAgqTTupUzEQXux937ce65d5Fl2fmZ63RV/EuX
dWUWqmt7c36W685s6na/UK4rMKJf7axztq4e9g0G3Vw9XJ+f2aaV8a579fLl
Ny9fnZ+VutoslKnOz87POtuVGPqdbtRFpcu9s07Va3WtXafe1p1dW2yCFdW6
btVDq9d4oK6qja2MaW21URBK3da6UK811s3x6PxMr1ateTy1atWZ8vysqPNK
77BtgQW7bGOqTbaW7+KvjW4yHWZmL786P6tXri5NZ9zi/KxvCu0/faH4aaFe
vXz15+zlX/Gf4qF0a/RC3dd9Rwkv8Nf52VPdvt+0dd8s1PXF24erWxnYd9u6
XfCjgoqVspVbqH/M1XeG51DKi/mP3rgaK8WndbvRlf0oilmo73v9ZCyfm522
5ULxPM9+yrdb+XKe17vJFndzTKvHHe4w5drY+HC6wet9Zy6hW5Psse3rBnPW
xn67wtcFvz7a5ae5Wm4nJ/nJ2A8W5h+fT7dabm2l1Zt6Zct0t5yjn8Lcb3MO
2smYoy0v5+rWjvtB7PD3dJ8HB8tAN+rHyj6a1tlun2zX1aXFib7twqi5Kfp5
Xk02+udc/bztx53+CW1/oLnD01PnejCl8QLHnT5u+/2Hr/2JOv8tNlJqstXP
MJauxq1+pjaebRWfntoK55rutNXVx+dXX/mtevlWjsR/tkJ07TD/0Sw45f56
+cev/vJ1/Pznr79+GT//9U/fvFz4WVmWKb1yXavzjn+/qQvTVqoyHX3dqdZ8
6G1r1BqxPFO60A03OBnELx6uvoTWleubpm47VUDoqpDwbpoyQIBTpX1v1MUN
0ETbKgY/oqvMOrszypn20ebGzdXVs3USezuT4+DW7ZwASEmgWEWgmKmmrTuT
c/GZrLUu6yeV11XX1iUAozOVKnX+Hnu4BgJA/Mo4J0NdjmXggvCcuXrYAmCA
Kv3OVJ0S4PhonHpv9gpI4mBGlfdtyy8frhSQpPcH4kKQoakdRlNPqkoxT2ME
ZH7KSjhHle9nykCCLitaSgIE3TLsuOfcI+Zktqn0qjQuUVAwjdJPQKjhJLBS
/t60HJd7sWCJYg9fg5WgjMLK05myO8j6SLXWiBldlsOChha1FDGYpLRRN9FT
drYoGNP+3xf/F8JPkV3W+0Ld0GpFL0fgo5tK9c6oXFO3rs+3VGfiPDPRrXNl
1MPgofFUdvDhgioxlevhzv5wpZE5UM/GOG6ZrVtjmA40d6jc2rT0CwMRuBg9
zwW/Vlu72apui2yw2TY9goNuN9iYIz6atlYNXM90IqTSectfwSzQ/V65rV2L
k3dBaY3uOkSgE50/1HB+zO5EBL8xbJhEJ5aA1j8ZjmPowPJVXvYSj58TQYCt
+gke28JvY0COvr/WuUFE72wXohtBMo2zGRaio22MXxsZp5WxuhQP3BpdYGnX
mNyKRrACVZvhicE3pW43JmOgGhjv0bZ1xVgJ+pmErDh2YRhvCFgVUz98MocT
FVQU7AUDM6QRwszwTnAwO/BNYnem7ga1+L+vqZZlABbhCNfwdgTcVpaaqScT
YWNAilQ3PL55bsoaDrjFUsdYkSBdjqS3NWWj1hYx6h2AMCTnvuno1whl4Cy4
Dh07h6Lseo+RWvwlXauwDhqgCixVkOhsNgTV6+vLmbr54eKNNxPc0UMGzCSh
wK0AYXtgTOoeMx6dh4BTArUdhIANdUkfllwkQHR00jki3XVien+0g5MjsTWl
gOJkWrbSPAXySVtD7cwSNAESbEcQnWEZzfiWifDDvuxg/rbe8XhIsXJA2YBp
xvDcXWs3G5AHQa4jObHBO1gQui33SQBMUkwielD9oDDlFcYNPRjxZHVbkCjQ
3k+228ZoPqHcgP6I1f2hVACl1kBkIwpUv6Nr/E7B+ysOO2FpqGMNaoIogVNj
kC7T1OPUE/iI4EkI8IAsR9ahyODEx6qaKcQ1pKIHQr/9RjCVyLY1xLm6L3EQ
Qm+DdGyKeYD8e4/OXopbUMMeWCHB/foyDJmUALTTYa1wfnY7gbQA827IaZ0C
YJWBXrGK0I8gVJIBVnD3J1vAED7rIftg4pgT6KpqN6VFsyG1TqGUUYkgCPpd
QU0j/0hz+BQigya+8N5JfrkzXbsH5x2ww+fCDBS3Vxz0gkO/HBHv0TrrczUM
j4CL2QSOY3YrUwjsd8PKkuEKaD3vPOL6LAW/ArJEypHGEjSGxLQd8xvzmUcK
4LkQT3iS4uo29wca0oacaotQg7eIxlGwPa2okYC944mvniVqLg1iAZxZZoqs
1OuzkFSGv9iJI31oMAAKQ9aolnc/Em90jKDSJ3BM1wVSdxBfVhBkdoem8Ei/
HGbDPT2hUg+WtH0JbYA12Y+mSPYAjOybkNFhEwJhom3o18EPyNdmAZXEVypI
zaAv8Du3LLmznX6Pr0R/cPpF4B7Isl3duuCccl44NlNT4LIwz+hcU5ccnOse
MX2yKg9EAwpqRW6srle1VBEhC2rZCUi4QRAKdTsmqgKqMmCgXiPtVC/MfDOf
JVH1JaCA8BX5PlSwQcoJ8ZkjfUZbXAlbvvRsORhmMaThsq4bnzJSVqWLX3oI
GKMA+Q9+ueoHzCWARazDowZGlI9tYjW92bRmE7KVSHILWtKhgMX/U11cPNa2
8HqLhIZ6nmTQYdXgHaNhjsFtpB0ckZCQBIUDjY3KoyfaqvfhL2yZEqwBcUTB
ufppa0mfYvrq6roMhRjzIqPh+v5eMjmQkMhfAKTrvfHpeY/ohfltxZxzwGno
2yRqoZwCuxsc7rX1CONVgDyNABAcujTxRC+w/ZccTzGYrAxdCKtRD61uLD5p
hAu+iFMQ78BXWWdNYk+BYroMKAbXgpngLRCsHU4fTkYmCC5Mtmic5Bwabg0P
qJ+EG4+HCwHwQzTqI+mG3xMYAs5dmHq9Xqjv4RFACpgW6W09DPCVlnGJ8BKf
TAvg4iSf+JKIRd2Naah3SIDB5d6NBaq6ca43QMU3KH26UDsDdvdiQ2ekZycG
SSnzUCo4KZn8aQd9ASPiTneE99EySe5ZMAG6HGmhtbUnAGpHDANDU1fLN3eS
GpANRI6uReYvPe3zB5ctQdC6XoBKmH6odDjLQx4tUlhGK82NuYHKIGJ0K9k0
ejOjVLv9zucafJEghxuR80gYj4gmsYZ3XDmP24ON7ob4jT58qsK9GllTSF9U
N1NROsydwsghXU86ADBTy0SUsKcQzzU0Rq8iWngr3XifKlLHWCBHedIC7dR9
izOKC4HS0e/Fz1up+GNEiSJHRQwRKxLfo2rtO6NeABIkNgkNrX/oBkjtkTQR
K9V7mqMCO0rQJmT+obKCqNkPFWJvxDJktjRh8ilS9IYeCrJReQgHS6y6ZF01
GJcieU4FTvscmY/nBZMmj42lxDNcADBfb6xxn2XdG6ktOgz1WrsQay0w0LMk
C0csLHhF4lhekDa0jkPVzygI0RiM+QYxvBMmceebBLcYN1pTKgkBjABnR4aL
jDXCbJLr/dbIkjDExkjb9/zsxONJmWgaU0mZHEWnaeocSJGPM2b0K9SMOw3m
pZFCtn0F5lBIcKNUKq0zzPxJLAqfy4C24K8kErHHx7zN0rEDNWmpQldKWWxL
BuJnmeme9IcUTQzF6XCxWNqNNnKIdjZPN9Ko5GXIau+BKAJuyKjLIaPS1L6Y
6AG5qGvbvmG0p7yX6SpvcTjiUdrtHCzyhoCZCchGKwRORASVOLv60OMMyxpn
TUa/kO8Hi/TMGQP6iuRjU9RtdStYkUagWOCmi/FCVY4OFHn9hH210dMGcB7J
ZYz/1oxFz4Dbn2WxH6oMHp5dExdELdijrPPQAH/HvtgIN7AWcLnstsFayjcC
6KqDaDE8IH96HA+vh/h5P3Y3x4zqYlno8aTopZF2mIA+SdzS/pAA57SU9050
2GyUXkG4cQsNMpyGnHFoLc7VMnSTUgZoJV1Iv5eETmKHNXvru91QQNWDCcwS
DQ1XBAlUvEPImzZ7LfpcDsKl50iextPYxAJYIOvqjNCxRkJlZTd0ldLuJyS7
f3gYqY/vKsMxZDp+eZygRIITYpogXkiVcXu2b8kEqujKMNOoWN/xScTydQm4
hq/GNf7fsldTGi3pxlAwqfNXqDtg+eh2I+uJB5JqlHkJuDILHRaRmnDoazsm
nVWP+qxVK4Rlx4MnegieeLFb2U1k7L6aUO8kezNafw9XLB2cHpRZmJRn7r11
2yEdJAcOHTvoTTJm2eddr0PDH4csAuARFuMFAaWC2/3SFxup8Nm4JUJKA310
kaQKDVqUMkGAOlzcSHF4soUby23Bp2qT0fxHPdz/Fi/e2MIj4nVwMvJSmCFC
O0mIrwQtiXLi9qmiUjDgpqzwOftCKkbutgBNEX429V4edmD00qT7RBPn3uSG
15HKh9TD8u4TYTUMHJ37MMwE7cegCgYQ9yY7aOMKbHkMJe8IJ2JQlqIk4BJI
IeZi9XyL6lndeisdmhmSlNL75dWqSemLv2ihF/SrX4Tg1xLZEghu4glkryh9
YdJ82tgfGmgTf/B2eT2UQrH0khIkLWvgUW7LjjQtkTEtiyEmq/kCdxqwLpbt
Xok77WRa1e9WJArSR/E6Da6047WeTBPXRKBM+4VjPf+/FQ+Xwt1SD/FYkPBA
qDYD4GmSjlJvWAHb6pdj1LOoirENG0VJa4/NwMR0a71C1RRbK0N3lOWENDMi
rfU3o+VYKzIkaMKJhn0tyBrUW6O0zK20yRgPV8+kQ3ZyxolOwHDeegK0fIvF
WKzGQp51oD9VGsUzpOnaCqgVbd24E3yHS3kHHlPFUUKI95KeGaFOykFdU0IR
Au+zDPpdyLvpcX8M75p4liprh6JPvJBalHZ9EmG9R+WoEogaoyPpx21Rz8Vu
HK8Zxh1RvFvfu4p9tg+96dl7sGXRN2PHuaI7q7dh27ET++Lm7YMYBb/HupXc
Kyuh6rSlJf4ISh/u6jstIYe8Jzdj27qJFYNcxXZ9W/mr2BGV1KPV8ufF8u9z
ZMEpZkcP1OWmBsfe8i4zpuPv75bLWejtG0VZScSiKUmKs+GePO1Kh9qUqHUp
VY9HQCwQrpjG43k3AmsBNVCabCEbwC4qd4BoOaIAyNCZDsAbUk4ceIi8A484
2ZY+zK4RPBM8/Z/z6s1QHN1UCAmT5NcIBjuk3uiZPs2yejKTq/NT8DODDhrt
0XFMEBF8vCCk4ulR2doFNapCAazZCtbkEGsxryDO2vv7tLcylELHrhMZO0Iy
L3sXe96T6zGqsmRr97AhGN/9OHXHnl798ZWAk5e6zCPhqm28LBYH/FVeK1Pj
z6/q72YvhcXn//z628b+T7MhTXbwc/TgM37+n7mYTd0cXMn/qt6RdY2Bafxl
kTSew/XKgBXe0xLdXKUdt4QF8PZ4CAA9kMAj3UxeBpAVX19f/oF9KPb5ybLW
oZ/IJSMV+Jsnykn3xM9NbhJm3mN8mztkheOOUexe7YM001cRsCJo5h+YLAYk
iiWhb6WPeWeg96Nu7k8x5WEhSVHD2zTVutVsq6LAaI3XDQrd33qRISSPw5eg
+MdwXQKDbusiWCO+n3T4vpZXyue9u+Ipba4bX9OTCdBNQg2KBYCnKDRZbv93
L64NV0mw9KdfYsvLui/GV9niC1P8929jSC1GhysAAA==

-->

</rfc>
