<?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-grow-bmp-sync-options-and-state-01" category="std" consensus="true" submissionType="IETF" version="3">
  <!-- xml2rfc v2v3 conversion 3.30.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-01"/>
    <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="August" day="25"/>
    <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+TtuTIy0jljLd
8bIkpOYF/3W8AP5OpJp3iE5DT2ejmGsNE5zPE1ile3R+7Hk8UR2Sqkynuzs7
L3d2PaoY7ZD+2dCbSXUB62dJh7wZ9H/xLtgcukIYKVKmBEv9Q0TU82iWTqXq
eMT3COFCd8hpi7wB9KFpKTqlIu+QagLkfqJISYe8zeiMcXIOTBAykhPONMCw
mPKoQ5ADgop/TQ1QK5AxfAt4CgQdMP47N/MFMhMp0vh6ygWt4DBskd9gZAWL
4TQTM8Ck6L4FLp/MGG1nuBVGnpAqhiUuQSKEDI5f775sv3Cvz5+0n7jXF+3n
e/jqcTFeGPAURuQDXjzdywc8e573vtx59rLjea1Wy/N83yd0pFNFAxDN+ZRr
AoqVxUykJFEykZppEjOQWKhJKsmYBjziqEyAuFIsQGYQOSYHb87IQGYp6nE3
xwk+HVDNgMMBKCLXKRMB8AnahBIhhR9yrbIEkScxFYIpMlYyJumUWZVnIoQ+
WDfveS2jCBaVyuEe8zCMmOc9QjVTMswsQp8faRb4HLu+IFkMtYMpWsV2P/zd
H3QP/K7YJicywHdjeXl/P0uBxhjQNTjhEFBvIJx9RBucMANtuxIZ8WCOHAsY
GI2YtAx8xbbPlExlICOyCWRsIeQlD2FuJCwuwZZwI++dHD9smy85pu+dID8Y
LKpjEO/3TuIfWgSJxwGXnM1qgpgDy+dEBkGmyIilM8ZEwWZtGW+mhmaQc52E
GUNxAFc0BQ5EUuttAsaN1k/GEU0SoGIbTSqlI9SU+baZZUyzKNUtkBKsUVGy
bTJjJGRjLti3q9km0Ln1QMr26BEZsD8yrhiirckJaEAGLLDaBc6OoLfTZKP3
bni+sW3/k9O+eR8c/ftdd3B0iO/Dt/snJ8WL5yCGb/vvTg7Lt3Lk636vd3R6
aAdDL6l1eRu9/V83LI83+mfn3f7p/skG0lxjMwE/jZSN0BbBHScKtoCQUO2B
DgaKj6ABYw5en/33P+098vnz39DztNsvv3xxDXQ40JhNmbCrSRHNXRP4NfdA
9Iwqw+0oIgFNQHwRKAfVRE/lTJApUwwY+ff3yJkPHfLTKEjae69cBxJc68x5
Vus0PFvuWRpsmbiia8UyBTdr/QucruO7/2utnfO90vnTzxGqtN9+8fMrD90T
6hMqLvMHbKyYnuY2tOB0rS1oVFmw17WjSAq7Mtk8PzhsbwH/aUpgkkyDGEHK
uggymNHlwvxr+q6X9L0w8xY5hlc5QyvDj+AGYzQygJkymnuGhCk/YdBwfRyx
rmN7dvjOeaDFbgfdf3d+5A+OjgdHw7cFbZYHRiPfux3QujkbsYRkNLduEfbD
D1YbOZik9QZmYmwgARDceDZ+eUr8+mqe13PLHZtxEMWAwH6I0h/3j7vbZJiN
fBwJb9D+YZL+SNIsicD7g3sJje3A3F+/foU9lZAdsvy0V/Ttruh74mZow9cn
ZA8wfUaekxfk5W36cI5/+N/4g5Nc1ZED2usd5nvOnAJ+WMBd3Q8myNjPEGpi
1PzPjbqaOLltuJ09ZhCV4aaTYa9VByMkt58aR3izXNFD3krx6lrmG1bB3zAE
FdfkmMYcHGQ3BKPmYw7msbkLm23KUr2F0AUL/Zwe7LJW3baAWzAtge878HuK
Ohq5aEM5M1KwITGdVnCd8XT6GP8AHIFAYATBZWiNjxzzCDw/MmWzPzjeMqMw
VvxgV2nD7yGEryoooiQ0/RGbcCEcK+kCApsHcjDYIjJxoZWdaXf1TOBu1k1z
tHKap8ZmmWbqkoWGZ5bFwCeNlIO3vIbbORPt3n30kcYoZVg903nqtdKzaqtV
dgWI5kzUAcD5Z0h/qNAuN8r3tpoqWKdQCSlWPLXwwjgA8nUVXPFYPwPm5tvH
zIDszzt8/xV8dSsKadigLUTJ2NKE1z5XjYBK5CGWUhc2jjVSNQxrNocZpBMW
AK5BuUsBM5tOAFFmxB6DgWP4HICBAD5JpiYmF2uIQUxCjhFmNL8Ve6pyGPRI
T09ay3LAPVaTT0xJxCyW4GMWxvst9/g1OTqbrSQQvVz/xrnC3ITDGvbeVr6Z
dmkKBiRWxE2ZK53jtJgsyKrhJE6pVpF8dKP6Hz28+lt1q+h/U7qwVCDyCOuO
zDFlnWYSbeZk6vvuvoBkt7HjxA3ZRborilp5uHttvLti3Gavv7Uc9e7eHPVW
s2o315r4975i3zWUF0Hw+u84Pg8+lveSb4ouifetsSXxvj2eW1BOFzxW1LPW
gh1+AeLq/nE4juhEr8fhhIlJOq19v38cIKCpC9J9h6inVWkPC7iHwaGuOOtx
2H0oHBYeuyNeB3H1AEoJBIqGjBD3xoi6w73eS6CD/QXLKCbfcNlDnlVsky64
Q4ixsY6/kALn8X1ZViwj9UrZ0HY+gV9XZXSJyh1WShTzbVG0XCmROi06fWd/
1WnR3UaMQkaj+URg1EJhhxjxFHcfC94tlp1NGcArMyj375jDMUFHEbhRLFZy
bd5dwcqAj7BSgHDKJRZYSM6NvUTGMBjRgR0ZV9+0ySP83cqpNSu7gRBsRDgT
knqbPBDh75TV2KFGM8scyaJhN8YZjyIs92mWkt8w/qwM/avsKjfvGv+HuwIe
/FlKS2Gs/r77YDgsP9/BI5eECr9dLLLy+70y4k/zyHto9UCE/st5w4L1+iZn
WAoJa0I21EdQE8i7whAmMTAx5KjFWVer5iXXFnCuSzO69jRrXATzOgBmKC63
MVJ/g/G/KeFg6M3wtAqIm2KJzx2FmRxHtQ2z7Puu5Vz37HKPZAIYr9Nt24qz
KHXtAiKiI4acd5CEOqc+RqeOuWlNPIKMQCI2N0HcEkYvmNI2b0hnstZbnkDe
By5zl7e2SpL14qGYrWPUy2Crz8lcRXxFfStPQcv/Sz4EiRw6sZis1mG0WaKy
5S88TjYLZrtw+uq0B83VUQSpd8qN6eRUJPkJLdZPTW9BQIdYwm5Z02tQ0bty
5YyuQScCRBOpUrJc0hgaCSxVhVaU7Jce+B5Xikd1pWk4QV21Ss1qOHyNAjYc
nZtMM/CyNIPFFCdgrH7hVYmmK0rrSi3zF3SrZhMLggOrKNY39RAHnDvfpcqE
WGJtzTY7d1K8K7/XN2qMYStpPzYh5u5WjoW/UJ+kggB8XmNpyKIqpbcVTKVm
dhstKplUFDPtFtJwfFELRe+A1ZvVgr2rrCre5aYprnfI9yj0vWZC//NlfkfH
kQu+4fA8wlgSfJPhd9OO60Vb0ZF87/+uHsEh8SDK4TYxezhRX/eGQ5KGK64/
I7mdm1/gd8PBC0HUN3qiRuPWbm0Nl8UdsAwBCoq/C8ErjeuONuFOHrr7p/vA
I6F56E58dH4TkAqK1wUODhFuyIJM8XS+CAsUmcuqfijxbIYMzw7dYTCN8SCg
BkzNzbKhu5rWbuPoIn8hNEmARSZGrpx2tEgXw1B8LZc0EEXw6a4pKXvXzNZy
XKai7Z2rEavlKyZatXdq+Sc8PoDQzNzQhfcKC0N2yQMM8rv2hkyk8TYYRFWX
zFWM6hfGQgnqJSQmsPZeJV53nCPfOWIOEY/OuVhnDJ63I2NTxUcZLO7O08s8
LGESE7mYhqyW2Qb5GEPqIuvwIo+5vwYYmDT1EdkPLoScgbpM7J08u5BlBWTE
MotCyFgvzMU3WsLaozpmj5rx6pBIstSdDX38+NFdLB3BCFCq/wGIsatcuy0A
AA==

-->

</rfc>
