<?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.24 (Ruby 3.2.3) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-geng-grow-bmp-sync-options-and-state-00" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.0 -->
  <front>
    <title abbrev="BMP Sync Mechanism">Synchronizing BMP Monitoring Options and State</title>
    <seriesInfo name="Internet-Draft" value="draft-geng-grow-bmp-sync-options-and-state-00"/>
    <author initials="N." surname="Geng" fullname="Nan Geng">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>gengnan@huawei.com</email>
      </address>
    </author>
    <author initials="S." surname="Zhuang" fullname="Shunwan Zhuang">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>zhuangshunwan@huawei.com</email>
      </address>
    </author>
    <date year="2025" month="March" day="03"/>
    <area>OPS</area>
    <workgroup>GROW</workgroup>
    <keyword>Internet-Draft</keyword>
    <abstract>
      <?line 45?>

<t>This document proposes methods to facilitate correction of BGP Routing Information Base inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector.</t>
    </abstract>
  </front>
  <middle>
    <?line 49?>

<section anchor="sec-intro">
      <name>Introduction</name>
      <t>The generation of BGP Adj-RIB-In, Loc-RIB and Adj-RIB-Out comes from BGP route exchange and route policy processing. BGP Monitoring Protocol (BMP) provides the monitoring of BGP Adj-RIB-In <xref target="RFC7854"/>, BGP Loc-RIB <xref target="RFC9069"/> and BGP Adj-RIB-Out <xref target="RFC8671"/>. The RIB view inconsistency may occur between the BMP sender and BMP collector due to message loss, network flapping, instability, and faults. In this document, we define methods to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner from the BMP Sender to the BMP Collector.</t>
      <section anchor="requirements-language">
        <name>Requirements Language</name>
        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
appear in all capitals, as shown here.</t>
        <?line -18?>

</section>
    </section>
    <section anchor="bmp-route-refresh-message">
      <name>BMP Route-Refresh message</name>
      <t>This document defines a new BMP Route-Refresh message type (TBD1) that is used to synchronize the RIB view from the BMP sender to the BMP collector. Following the common BMP header and per-peer header is a Route-Refresh PDU. The Route-Refresh PDU is a ROUTE-REFRESH message defined in <xref target="RFC2918"/> and updated by <xref target="RFC7313"/>, and its format is as follows:</t>
      <t>Type: 5 - ROUTE-REFRESH</t>
      <t>Message Format: One &lt;AFI, Sub-Type, SAFI&gt; tuple encoded as:</t>
      <figure>
        <name>ROUTE-REFRESH Message</name>
        <artwork><![CDATA[
    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              AFI              |    Sub-Type   |     SAFI      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>The meaning, usage, and encoding of this &lt;AFI, Sub-Type, SAFI&gt; tuple are defined in <xref target="RFC2918"/> and updated by <xref target="RFC7313"/> as follows:</t>
      <ul spacing="normal">
        <li>
          <t>AFI - Address Family Identifier (2 octets)</t>
        </li>
        <li>
          <t>Sub-Type - Message Subtype (1 octet):  </t>
          <ul spacing="normal">
            <li>
              <t>0 - Normal route refresh request <xref target="RFC2918"/> with/without Outbound Route Filtering (ORF) <xref target="RFC5291"/></t>
            </li>
            <li>
              <t>1 - Demarcation of the beginning of a route refresh (BoRR) operation</t>
            </li>
            <li>
              <t>2 - Demarcation of the ending of a route refresh (EoRR) operation</t>
            </li>
            <li>
              <t>255 - Reserved</t>
            </li>
          </ul>
        </li>
        <li>
          <t>SAFI - Subsequent Address Family Identifier (1 octet).</t>
        </li>
      </ul>
      <section anchor="example-of-using-bmp-route-refresh-messages">
        <name>Example of using BMP Route-Refresh messages</name>
        <t>The sequences of BMP messages transmissions shown as follows:</t>
        <figure>
          <name>An example of using BMP Route-Refresh messages</name>
          <artwork><![CDATA[
  BMP Sender                    BMP Collector
     ~                             ~
     | ------- BMP BoRR ---------> | Sender notifies BoRR operation
     |                             |
     |                             | Collector marks the routes of 
     |                             |  the specific RIB view as  
     |                             |  stale/historical or purges
     |                             |  them directly
     |                             |
     | ------- BMP RM Msg.-------> | Sender sends zero or more 
     | --------........----------> |  Route Monitoring Messages for
     | ------- BMP RM Msg.-------> |  the specific RIB view 
     |                             | Collector uses the new routes
     |                             |  to update the stale/historical
     |                             |  routes 
     | ------- BMP EoRR ---------> | Sender notifies EoRR operation
     |                             |
     |                             | Collector purges the routes
     |                             |  remaining the stale/historical
     |                             |  state 
     |                             |
     ~                             ~
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="bmp-monitoring-options-message">
      <name>BMP Monitoring Options message</name>
      <t>This document defines a new Monitoring Options (MO) message type (TBD2) that is used to synchronize the monitoring options from the BMP sender to BMP collector. Following the common BMP header and per-peer header is a BMP Monitoring Options PDU. The BMP Monitoring Options PDU is defined as follows:</t>
      <figure>
        <name>The BMP Monitoring Options PDU</name>
        <artwork><![CDATA[
 0                   1                   2                   3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |             SubType           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Flags            |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              AFI1             |      Res.     |     SAFI1     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              AFI2             |      Res.     |     SAFI2     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ......                            | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              AFIn             |      Res.     |     SAFIn     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>Where:</t>
      <ul spacing="normal">
        <li>
          <t>Type - 2 octets, It indicates as follows:  </t>
          <ul spacing="normal">
            <li>
              <t>1 - Adj-RIB-In</t>
            </li>
            <li>
              <t>2 - Adj-RIB-Out</t>
            </li>
            <li>
              <t>3 - Loc-RIB</t>
            </li>
          </ul>
        </li>
        <li>
          <t>SubType - 2 octets, It indicates as follows:  </t>
          <ul spacing="normal">
            <li>
              <t>1 - pre-policy</t>
            </li>
            <li>
              <t>2 - post-policy</t>
            </li>
          </ul>
        </li>
        <li>
          <t>Flags - 2 octets, the least significant bit of Flags Indicates whether the options are enabled or disabled, and other bits are reserved.</t>
        </li>
        <li>
          <t>Length - 2 octets</t>
        </li>
        <li>
          <t>The list of (AFI, SAFI) follows the Length field.  </t>
          <ul spacing="normal">
            <li>
              <t>AFI - Address Family Identifier (2 octets)</t>
            </li>
            <li>
              <t>SAFI - Subsequent Address Family Identifier (1 octet)</t>
            </li>
            <li>
              <t>Res. - Reserved field that will be set Zero (1 octet)</t>
            </li>
          </ul>
        </li>
      </ul>
      <figure>
        <name>The BMP Monitoring Options PDU</name>
        <artwork><![CDATA[
 0                   1                   2                   3 
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Type             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|              Flags            |             Length            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Stat Type 1         |           Stat Type 2         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                             ......                            | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Stat Type n-1       |           Stat Type n         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>Where:</t>
      <ul spacing="normal">
        <li>
          <t>Type - 2 octets, It indicates as follows:  </t>
          <ul spacing="normal">
            <li>
              <t>4 - Stats</t>
            </li>
          </ul>
        </li>
        <li>
          <t>Flags - 2 octets, the least significant bit of Flags Indicates whether the options are enabled or disabled, and other bits are reserved.</t>
        </li>
        <li>
          <t>Length - 2 octets</t>
        </li>
        <li>
          <t>The list of Stat Types follows the Length field.  </t>
          <ul spacing="normal">
            <li>
              <t>Stat Type - Defines the type of the statistic <xref target="RFC7854"/>. (2 octets)</t>
            </li>
          </ul>
        </li>
      </ul>
      <section anchor="example-of-using-bmp-monitoring-options-message">
        <name>Example of using BMP Monitoring Options message</name>
        <t>In the following scenario, a BGP session is established between Router1 and Router2, and IPv4 unicast, IPv4 multicast, and IPv4 labeled unicast address families are enabled on both the BGP speakers. The two BGP speakers exchange IPv4 unicast, IPv4 multicast, and IPv4 labeled unicast address family routes. Router1 as the BMP Sender sends BMP messages to the BMP Collector.</t>
        <figure>
          <name>BGP Monitoring Example</name>
          <artwork><![CDATA[
   BMP Collector
      |
      |
      |                 BGP Session  
   Router1(BMP Sender)----------------Router2
]]></artwork>
        </figure>
        <t>Sender initiates the BMP protocol with the Collector:</t>
        <figure>
          <name>Sender sends Initial Export to Collector</name>
          <artwork><![CDATA[
BMP Sender                    BMP Collector
   ~                             ~
   |------ Initial Export -------> | Sender Sends Route Monitoring 
   |                               |  messages for IPv4 unicast,
   |                               |  IPv4 multicast and IPv4 
   |                               |  labeled unicast address
   |                               |  families
   |                               | Collector stores the RIB info
   |                               |  for the Sender
]]></artwork>
        </figure>
        <t>Sender disabled the monitoring on IPv4 multicast address family:</t>
        <figure>
          <name>Sender disabled the monitoring on IPv4 multicast address family</name>
          <artwork><![CDATA[
BMP Sender                    BMP Collector
   |-MO with(AFI 1/SAFI 2) disable-| Sender sends an MO message 
   |                               |  to Collector
   |                               | Collector purges the IPv4 
   |                               |  multicast RIB view of the
   |                               |  specific BGP peer
]]></artwork>
        </figure>
        <t>Sender disabled the monitoring on IPv4 labeled unicast address family:</t>
        <figure>
          <name>Sender disabled the monitoring on IPv4 labeled unicast address family</name>
          <artwork><![CDATA[
BMP Sender                    BMP Collector
   |-MO with(AFI 1/SAFI 4) disable-| Sender sends an MO message
   |                               |  to Collector
   |                               | Collector purges the IPv4
   |                               |  labeled unicast RIB view
   |                               |  of the specific BGP peer
   |                               |
]]></artwork>
        </figure>
        <t>Sender enabled the monitoring on IPv4 multicast address family:</t>
        <figure>
          <name>Sender enabled the monitoring on IPv4 multicast address family</name>
          <artwork><![CDATA[
BMP Sender                    BMP Collector
   |-MO with(AFI 1/SAFI 2) enabled-| Sender sends an MO message
   |                               |  to Collector
   |-------BMP RM(AFI 1/SAFI 2)--> | Sender sends zero or more
   |                               |  Route Monitoring Messages 
   |                               |  for theIPv4 multicast 
   |                               |  address family of the
   |                               |  specific BGP peer
   |                               | Collector stores the RIB 
   |                               |  info for IPv4 multicast
   |                               |  address family of the
   |                               |  specific BGP peer
]]></artwork>
        </figure>
      </section>
    </section>
    <section anchor="sec-iana">
      <name>IANA Considerations</name>
      <t>TBD</t>
    </section>
    <section anchor="security-considerations-of-inter-domain-spd">
      <name>Security Considerations of Inter-domain SPD</name>
      <t>The same considerations as in Section 11 of <xref target="RFC7854"/> apply to this document. Implementations of this protocol <bcp14>SHOULD</bcp14> require that sessions only be established with authorized and trusted monitoring devices. It is also believed that this document does not introduce any additional security considerations.</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>The following people made significant contributions to this document:</t>
      <t>To be added.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to acknowledge the review and inputs from xxx.</t>
    </section>
  </middle>
  <back>
    <references anchor="sec-combined-references">
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="RFC2918" target="https://www.rfc-editor.org/info/rfc2918" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2918.xml">
          <front>
            <title>Route Refresh Capability for BGP-4</title>
            <author fullname="E. Chen" initials="E." surname="Chen"/>
            <date month="September" year="2000"/>
            <abstract>
              <t>This document defines a new Border Gateway Protocol (BGP) capability termed 'Route Refresh Capability', which would allow the dynamic exchange of route refresh request between BGP speakers and subsequent re-advertisement of the respective Adj-RIB-Out. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2918"/>
          <seriesInfo name="DOI" value="10.17487/RFC2918"/>
        </reference>
        <reference anchor="RFC7313" target="https://www.rfc-editor.org/info/rfc7313" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7313.xml">
          <front>
            <title>Enhanced Route Refresh Capability for BGP-4</title>
            <author fullname="K. Patel" initials="K." surname="Patel"/>
            <author fullname="E. Chen" initials="E." surname="Chen"/>
            <author fullname="B. Venkatachalapathy" initials="B." surname="Venkatachalapathy"/>
            <date month="July" year="2014"/>
            <abstract>
              <t>In this document, we enhance the existing BGP route refresh mechanisms to provide for the demarcation of the beginning and the ending of a route refresh. The enhancement can be used to facilitate correction of BGP Routing Information Base (RIB) inconsistencies in a non-disruptive manner. This document updates RFC 2918.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7313"/>
          <seriesInfo name="DOI" value="10.17487/RFC7313"/>
        </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="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>
      </references>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="RFC5291" target="https://www.rfc-editor.org/info/rfc5291" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5291.xml">
          <front>
            <title>Outbound Route Filtering Capability for BGP-4</title>
            <author fullname="E. Chen" initials="E." surname="Chen"/>
            <author fullname="Y. Rekhter" initials="Y." surname="Rekhter"/>
            <date month="August" year="2008"/>
            <abstract>
              <t>This document defines a BGP-based mechanism that allows a BGP speaker to send to its BGP peer a set of Outbound Route Filters (ORFs) that the peer would use to constrain/filter its outbound routing updates to the speaker. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5291"/>
          <seriesInfo name="DOI" value="10.17487/RFC5291"/>
        </reference>
        <reference anchor="RFC7854" target="https://www.rfc-editor.org/info/rfc7854" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml">
          <front>
            <title>BGP Monitoring Protocol (BMP)</title>
            <author fullname="J. Scudder" initials="J." role="editor" surname="Scudder"/>
            <author fullname="R. Fernando" initials="R." surname="Fernando"/>
            <author fullname="S. Stuart" initials="S." surname="Stuart"/>
            <date month="June" year="2016"/>
            <abstract>
              <t>This document defines the BGP Monitoring Protocol (BMP), which can be used to monitor BGP sessions. BMP is intended to provide a convenient interface for obtaining route views. Prior to the introduction of BMP, screen scraping was the most commonly used approach to obtaining such views. The design goals are to keep BMP simple, useful, easily implemented, and minimally service affecting. BMP is not suitable for use as a routing protocol.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7854"/>
          <seriesInfo name="DOI" value="10.17487/RFC7854"/>
        </reference>
        <reference anchor="RFC8671" target="https://www.rfc-editor.org/info/rfc8671" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8671.xml">
          <front>
            <title>Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)</title>
            <author fullname="T. Evens" initials="T." surname="Evens"/>
            <author fullname="S. Bayraktar" initials="S." surname="Bayraktar"/>
            <author fullname="P. Lucente" initials="P." surname="Lucente"/>
            <author fullname="P. Mi" initials="P." surname="Mi"/>
            <author fullname="S. Zhuang" initials="S." surname="Zhuang"/>
            <date month="November" year="2019"/>
            <abstract>
              <t>The BGP Monitoring Protocol (BMP) only defines access to the Adj-RIB-In Routing Information Bases (RIBs). This document updates BMP (RFC 7854) by adding access to the Adj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguish between Adj-RIB-In and Adj-RIB-Out.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8671"/>
          <seriesInfo name="DOI" value="10.17487/RFC8671"/>
        </reference>
        <reference anchor="RFC9069" target="https://www.rfc-editor.org/info/rfc9069" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9069.xml">
          <front>
            <title>Support for Local RIB in the BGP Monitoring Protocol (BMP)</title>
            <author fullname="T. Evens" initials="T." surname="Evens"/>
            <author fullname="S. Bayraktar" initials="S." surname="Bayraktar"/>
            <author fullname="M. Bhardwaj" initials="M." surname="Bhardwaj"/>
            <author fullname="P. Lucente" initials="P." surname="Lucente"/>
            <date month="February" year="2022"/>
            <abstract>
              <t>The BGP Monitoring Protocol (BMP) defines access to local Routing
Information Bases (RIBs). This document updates BMP (RFC 7854) by
adding access to the Local Routing Information Base (Loc-RIB), as
defined in RFC 4271. The Loc-RIB contains the routes that have been
selected by the local BGP speaker's Decision Process.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9069"/>
          <seriesInfo name="DOI" value="10.17487/RFC9069"/>
        </reference>
      </references>
    </references>
    <?line 315?>



  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA90aa1MbOfL7/AodqdqCO8bBhLy8e9mDAImrMOZsUlu7qXyQ
Z2Rby4w0K83gOCH5Lfdb7pddt6R5+QEDgU3tDQWMNC2p3+puyfd9L+VpxDpk
OBfBVEnBP3ExIQe9M9KDRioVNvtJyqXQhIqQDFOaMo+ORopddgwgDiU9Fkyp
4Dr2QhkIGsOUoaLj1J8wMfEnSs78UZz4GmB9aafzYTpf43T+zo4nR1pGLGW6
42VJSM0L/ut4AfydSDXvEJ2Gns5GMdcaJjifJ7BK9+j82PN4ojokVZlOd3d2
Xu7selQx2iH9s6E3k+oC1s+SDnkz6P/iXbA5dIUwUqRMCZb6h4io59EsnUrV
8YjvEcKF7pDTFnkD6EPTUnRKRd4h1QTI/USRkg55m9EZ4+QcmCBkJCecaYBh
MeVRhyAHBBX/mhqgViBj+BbwFAg6YPx3buYLZCZSpPH1lAtawWHYIr/ByAoW
w2kmZoBJ0X0LXD6ZMdrOcCuMPCFVDEtcgkQIGRy/3n3ZfuFenz9pP3GvL9rP
9/DV42K8MOApjMgHvHi6lw949jzvfbnz7GXH81qtluf5vk/oSKeKBiCa8ynX
BBQri5lISaJkIjXTJGYgsVCTVJIxDXjEUZkAcaVYgMwgckwO3pyRgcxS1ONu
jhN8OqCaAYcDUESuUyYC4BO0CSVCCj/kWmUJIk9iKgRTZKxkTNIpsyrPRAh9
sG7e81pGESwqlcM95mEYMc97hGqmZJhZhD4/0izwOXZ9QbIYagdTtIrtfvi7
P+ge+F2xTU5kgO/G8vL+fpYCjTGga3DCIaDeQDj7iDY4YQbadiUy4sEcORYw
MBoxaRn4im2fKZnKQEZkE8jYQshLHsLcSFhcgi3hRt47OX7YNl9yTN87QX4w
WFTHIN7vncQ/tAgSjwMuOZvVBDEHls+JDIJMkRFLZ4yJgs3aMt5MDc0g5zoJ
M4biAK5oChyIpNbbBIwbrZ+MI5okQMU2mlRKR6gp820zy5hmUapbICVYo6Jk
22TGSMjGXLBvV7NNoHPrgZTt0SMyYH9kXDFEW5MT0IAMWGC1C5wdQW+nyUbv
3fB8Y9v+J6d98z44+ve77uDoEN+Hb/dPTooXz0EM3/bfnRyWb+XI1/1e7+j0
0A6GXlLr8jZ6+79uWB5v9M/Ou/3T/ZMNpLnGZgJ+GikboS2CO04UbAEhodoD
HQwUH0EDxhy8Pvvvf9p75PPnv6HnabdffvniGuhwoDGbMmFXkyKauybwa+6B
6BlVhttRRAKagPgiUA6qiZ7KmSBTphgw8u/vkTMfOuSnUZC09165DiS41pnz
rNZpeLbcszTYMnFF14plCm7W+hc4Xcd3/9daO+d7pfOnnyNUab/94udXHron
1CdUXOYP2FgxPc1taMHpWlvQqLJgr2tHkRR2ZbJ5fnDY3gL+05TAJJkGMYKU
dRFkMKPLhfnX9F0v6Xth5i1yDK9yhlaGH8ENxmhkADNlNPcMCVN+wqDh+jhi
Xcf27PCd80CL3Q66/+78yB8cHQ+Ohm8L2iwPjEa+dzugdXM2YgnJaG7dIuyH
H6w2cjBJ6w3MxNhAAiC48Wz88pT49dU8r+eWOzbjIIoBgf0QpT/uH3e3yTAb
+TgS3qD9wyT9kaRZEoH3B/cSGtuBub9+/Qp7KiE7ZPlpr+jbXdH3xM3Qhq9P
yB5g+ow8Jy/Iy9v04Rz/8L/xBye5qiMHtNc7zPecOQX8sIC7uh9MkLGfIdTE
qPmfG3U1cXLbcDt7zCAqw00nw16rDkZIbj81jvBmuaKHvJXi1bXMN6yCv2EI
Kq7JMY05OMhuCEbNxxzMY3MXNtuUpXoLoQsW+jk92GWtum0Bt2BaAt934PcU
dTRy0YZyZqRgQ2I6reA64+n0Mf4BOAKBwAiCy9AaHznmEXh+ZMpmf3C8ZUZh
rPjBrtKG30MIX1VQRElo+iM24UI4VtIFBDYP5GCwRWTiQis70+7qmcDdrJvm
aOU0T43NMs3UJQsNzyyLgU8aKQdveQ23cybavfvoI41RyrB6pvPUa6Vn1Var
7AoQzZmoA4Dzz5D+UKFdbpTvbTVVsE6hElKseGrhhXEA5OsquOKxfgbMzbeP
mQHZn3f4/iv46lYU0rBBW4iSsaUJr32uGgGVyEMspS5sHGukahjWbA4zSCcs
AFyDcpcCZjadAKLMiD0GA8fwOQADAXySTE1MLtYQg5iEHCPMaH4r9lTlMOiR
np60luWAe6wmn5iSiFkswccsjPdb7vFrcnQ2W0kgern+jXOFuQmHNey9rXwz
7dIUDEisiJsyVzrHaTFZkFXDSZxSrSL56Eb1P3p49bfqVtH/pnRhqUDkEdYd
mWPKOs0k2szJ1PfdfQHJbmPHiRuyi3RXFLXycPfaeHfFuM1ef2s56t29Oeqt
ZtVurjXx733FvmsoL4Lg9d9xfB58LO8l3xRdEu9bY0vifXs8t6CcLnisqGet
BTv8AsTV/eNwHNGJXo/DCROTdFr7fv84QEBTF6T7DlFPq9IeFnAPg0Ndcdbj
sPtQOCw8dke8DuLqAZQSCBQNGSHujRF1h3u9l0AH+wuWUUy+4bKHPKvYJl1w
hxBjYx1/IQXO4/uyrFhG6pWyoe18Ar+uyugSlTuslCjm26JouVIidVp0+s7+
qtOiu40YhYxG84nAqIXCDjHiKe4+FrxbLDubMoBXZlDu3zGHY4KOInCjWKzk
2ry7gpUBH2GlAOGUSyywkJwbe4mMYTCiAzsyrr5pk0f4u5VTa1Z2AyHYiHAm
JPU2eSDC3ymrsUONZpY5kkXDbowzHkVY7tMsJb9h/FkZ+lfZVW7eNf4PdwU8
+LOUlsJY/X33wXBYfr6DRy4JFX67WGTl93tlxJ/mkffQ6oEI/ZfzhgXr9U3O
sBQS1oRsqI+gJpB3hSFMYmBiyFGLs65WzUuuLeBcl2Z07WnWuAjmdQDMUFxu
Y6T+BuN/U8LB0JvhaRUQN8USnzsKMzmOahtm2fddy7nu2eUeyQQwXqfbthVn
UeraBURERww57yAJdU59jE4dc9OaeAQZgURsboK4JYxeMKVt3pDOZK23PIG8
D1zmLm9tlSTrxUMxW8eol8FWn5O5iviK+laegpb/l3wIEjl0YjFZrcNos0Rl
y194nGwWzHbh9NVpD5qrowhS75Qb08mpSPITWqyfmt6CgA6xhN2yptegonfl
yhldg04EiCZSpWS5pDE0EliqCq0o2S898D2uFI/qStNwgrpqlZrVcPgaBWw4
OjeZZuBlaQaLKU7AWP3CqxJNV5TWlVrmL+hWzSYWBAdWUaxv6iEOOHe+S5UJ
scTamm127qR4V36vb9QYw1bSfmxCzN2tHAt/oT5JBQH4vMbSkEVVSm8rmErN
7DZaVDKpKGbaLaTh+KIWit4BqzerBXtXWVW8y01TXO+Q71Hoe82E/ufL/I6O
Ixd8w+F5hLEk+CbD76Yd14u2oiP53v9dPYJD4kGUw21i9nCivu4NhyQNV1x/
RnI7N7/A74aDF4Kob/REjcat3doaLos7YBkCFBR/F4JXGtcdbcKdPHT3T/eB
R0Lz0J346PwmIBUUrwscHCLckAWZ4ul8ERYoMpdV/VDi2QwZnh26w2Aa40FA
DZiam2VDdzWt3cbRRf5CaJIAi0yMXDntaJEuhqH4Wi5pIIrg011TUvauma3l
uExF2ztXI1bLV0y0au/U8k94fAChmbmhC+8VFobskgcY5HftDZlI420wiKou
masY1S+MhRLUS0hMYO29SrzuOEe+c8QcIh6dc7HOGDxvR8amio8yWNydp5d5
WMIkJnIxDVktsw3yMYbURdbhRR5zfw0wMGnqI7IfXAg5A3WZ2Dt5diHLCsiI
ZRaFkLFemItvtIS1R3XMHjXj1SGRZKk7G/r48aO7WDqCEaBU/wM5bUxjuy0A
AA==

-->

</rfc>
