<?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.3.8) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-sheng-idr-gw-exchange-in-sd-wan-03" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.28.1 -->
  <front>
    <title abbrev="Gateway Info Exchange in SDWAN">Associated Gateway Exchange in Multi-segment SD-WAN</title>
    <seriesInfo name="Internet-Draft" value="draft-sheng-idr-gw-exchange-in-sd-wan-03"/>
    <author initials="C." surname="Sheng" fullname="Cheng Sheng">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Beiqing Road</street>
          <city>Beijing</city>
        </postal>
        <email>shengcheng@huawei.com</email>
      </address>
    </author>
    <author initials="H." surname="Shi" fullname="Hang Shi">
      <organization>Huawei</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>shihang9@huawei.com</email>
      </address>
    </author>
    <author initials="J." surname="Dong" fullname="Jie Dong" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <country>China</country>
        </postal>
        <email>jie.dong@huawei.com</email>
      </address>
    </author>
    <author initials="L." surname="Dunbar" fullname="Linda Dunbar">
      <organization>Futurewei</organization>
      <address>
        <email>linda.dunbar@futurewei.com</email>
      </address>
    </author>
    <author initials="G." surname="Mishra" fullname="Gyan Mishra">
      <organization>Verizon</organization>
      <address>
        <email>gyan.s.mishra@verizon.com</email>
      </address>
    </author>
    <date year="2025" month="May" day="17"/>
    <area>Routing</area>
    <workgroup>Inter-Domain Routing</workgroup>
    <keyword>Multi-segment SD-WAN</keyword>
    <abstract>
      <?line 54?>

<t>The document describes the control plane enhancement for multi-segment SD-WAN to exchange the associated GW information between edges.</t>
    </abstract>
    <note removeInRFC="true">
      <name>Discussion Venues</name>
      <t>Discussion of this document takes place on the
    Inter-Domain Routing Working Group mailing list (idr@ietf.org),
    which is archived at <eref target="https://mailarchive.ietf.org/arch/browse/idr/"/>.</t>
      <t>Source for this draft and an issue tracker can be found at
    <eref target="https://github.com/VMatrix1900/draft-sheng-idr-gw-exchange-in-sd-wan"/>.</t>
    </note>
  </front>
  <middle>
    <?line 58?>

<section anchor="intro">
      <name>Introduction</name>
      <t><xref target="I-D.draft-dmk-rtgwg-multisegment-sdwan"/> describes how enterprises leverage Cloud Providers’ backbone infrastructure to interconnect their branch offices. As illustrated in Figure 1, CPE-1 and CPE-2 establish connections to their respective Cloud Gateways (GW) in distinct regions. CPE-1 and CPE-2 maintain the pairwise IPsec Security Associations (SAs). The IPsec encrypted traffic from CPE-1 to CPE-2 is encapsulated by the GENEVE header <xref target="RFC8926"/>, with the outer destination address being the GW1.</t>
      <t><xref target="I-D.draft-dmk-rtgwg-multisegment-sdwan"/> specifies a set of sub-TLVs to convey information about the GWs associated with the destination branches, such as GW3 for CPE-2, along with additional attributes. To accomplish this, CPE-1 must be aware of the associated GW addresses of their peers. This document proposes a BGP extension building upon <xref target="I-D.draft-ietf-idr-sdwan-edge-discovery"/>, enabling a CPE to advertise its directly connected GW address to other CPEs.</t>
      <figure anchor="Scenario">
        <name>Multi-segment SD-WAN</name>
        <artwork><![CDATA[
  (^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^)
  (            Region2             )
  (            +-----+             )
  (            | GW2 |             )
  (            +-----+             )
  (           /       \            )
  (          /  Cloud  \           )
  (         /  Backbone \          )
  ( Region1/             \Region3  )
  ( +-----+               +-----+  )
  ( | GW1 |---------------| GW3 |  )
  ( +--+--+               +--+--+  )
  (^^^^|^^^^^^^^^^^^^^^^^^^^^|^^^^^)
       |                     |
    +--+--+               +--+--+
    |CPE 1|               |CPE 2|
    +-----+               +-----+
]]></artwork>
      </figure>
    </section>
    <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?>

<t>The following acronyms and terms are used in this document:</t>
      <ul spacing="normal">
        <li>
          <t>Cloud DC: Off-Premises Data Center, managed by 3rd party, that hosts applications, services, and workload for different organizations or tenants.</t>
        </li>
        <li>
          <t>CPE: Customer (Edge) Premises Equipment.</t>
        </li>
        <li>
          <t>OnPrem: On Premises data centers and branch offices.</t>
        </li>
        <li>
          <t>RR: Route Reflector.</t>
        </li>
        <li>
          <t>SD-WAN: Software Defined Wide Area Network. In this document, “SD-WAN” refers to a policy-driven transporting of IP packets over multiple underlay networks for better WAN bandwidth management, visibility, and control.</t>
        </li>
        <li>
          <t>VPN: Virtual Private Network.</t>
        </li>
      </ul>
    </section>
    <section anchor="extension-to-sd-wan-underlay-update-for-associated-gws">
      <name>Extension to SD-WAN Underlay UPDATE for Associated GWs</name>
      <t>The Client Routes Update is the same as described in <xref section="5" sectionFormat="of" target="I-D.draft-ietf-idr-sdwan-edge-discovery"/>.</t>
      <section anchor="nlri-sd-wan-safi-route-type-for-gw">
        <name>NLRI SD-WAN SAFI Route Type For GW</name>
        <t>Adding a new attribute (Associated-Gateway Sub-TLV) to the SD-WAN-Hybrid Tunnel Encoding which is included in the SD-WAN SAFI (=74) Underlay Tunnel Update:</t>
        <artwork><![CDATA[
+------------------+
|    Route Type    | 2 octet
+------------------+
|     Length       | 2 Octet
+------------------+
|   Type Specific  |
~ Value (Variable) ~
|                  |
+------------------+
]]></artwork>
        <t>NLRI Route-Type = 2: For advertising the detailed properties of the transit gateways for the edge. The SD-WAN NLRI Route-Type =2 has the following encoding:</t>
        <artwork><![CDATA[
+------------------+
|  Route Type = 2  | 2 octet
+------------------+
|     Length       | 2 Octet
+------------------+
|   SD-WAN Color   | 4 octets
+------------------+
|  SD-WAN-Node-ID  | 4 or 16 octets
+------------------+
]]></artwork>
        <t>SD-WAN-Color: To represent a group of tunnels that correlate with the Color-Extended-community included in a client route UPDATE. When multiple SD-WAN edges can reach a client route co-located at one site, the SD-WAN- Color can represent a group of tunnels terminated at those SD-WAN edges co-located at the site, which effectively represents the site.</t>
        <t>SD-WAN Node ID: The node's IPv4 or IPv6 address.</t>
      </section>
      <section anchor="associated-gw-sub-tlv">
        <name>Associated GW Sub-TLV</name>
        <t>The Associated GW Sub-TLV, within the SD-WAN-Hybrid Tunnel TLV (code point 25), carries the associated GW address(es) with which the SD-WAN edge is associated.</t>
        <t>The following is the structure of the associated GW Sub-TLV:</t>
        <artwork><![CDATA[
    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=TBD    |    length     |  Priority         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Associated GW Addr Family     | Address                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (variable)                    +
   ~                                                               ~
   |             Associated GW Address                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
        <t>Priority (1-255) indicate the preference of the GW. The higher the value, the more preference is the GW.</t>
        <t>Priority = 0 represents that the connection exists but request Cloud Backbone not to choose the GW if possible.</t>
      </section>
    </section>
    <section anchor="manageability-considerations">
      <name>Manageability Considerations</name>
      <t>Effective management of SD-WAN edge nodes and the exchange of associated cloud gateway information are critical aspects in ensuring a robust and scalable SD-WAN deployment.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>This document does not introduce any new security considerations.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>Need IANA to assign a new Sub-TLV Type under the SD-WAN-Hybrid Tunnel TLV.</t>
      <ul spacing="normal">
        <li>
          <t>SD-WAN Associated GW Sub-TLV.</t>
        </li>
      </ul>
    </section>
  </middle>
  <back>
    <references anchor="sec-normative-references">
      <name>Normative References</name>
      <reference anchor="I-D.draft-dmk-rtgwg-multisegment-sdwan">
        <front>
          <title>Multi-segment SD-WAN via Cloud DCs</title>
          <author fullname="Kausik Majumdar" initials="K." surname="Majumdar">
            <organization>Microsoft</organization>
          </author>
          <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
            <organization>Futurewei</organization>
          </author>
          <author fullname="Venkit Kasiviswanathan" initials="V." surname="Kasiviswanathan">
            <organization>Arista</organization>
          </author>
          <author fullname="Ashok Ramchandra" initials="A." surname="Ramchandra">
            <organization>Microsoft</organization>
          </author>
          <author fullname="Aseem Choudhary" initials="A." surname="Choudhary">
            <organization>Aviatrix</organization>
          </author>
          <date day="20" month="February" year="2024"/>
          <abstract>
            <t>   This document describes a method for SD-WAN CPEs using GENEVE
   Encapsulation (RFC8926) to encapsulate the IPsec encrypted
   packets and send them to their closest Cloud GWs, who can
   steer the IPsec encrypted payload through the Cloud Backbone
   without decryption to the egress Cloud GWs which then forward
   the original IPsec encrypted payload to the destination CPEs.
   This method is for Cloud Backbone to connect multiple
   segments of SD-WAN without the Cloud GWs decrypting and re-
   encrypting the payloads.

            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-dmk-rtgwg-multisegment-sdwan-07"/>
      </reference>
      <reference anchor="RFC8926">
        <front>
          <title>Geneve: Generic Network Virtualization Encapsulation</title>
          <author fullname="J. Gross" initials="J." role="editor" surname="Gross"/>
          <author fullname="I. Ganga" initials="I." role="editor" surname="Ganga"/>
          <author fullname="T. Sridhar" initials="T." role="editor" surname="Sridhar"/>
          <date month="November" year="2020"/>
          <abstract>
            <t>Network virtualization involves the cooperation of devices with a wide variety of capabilities such as software and hardware tunnel endpoints, transit fabrics, and centralized control clusters. As a result of their role in tying together different elements of the system, the requirements on tunnels are influenced by all of these components. Therefore, flexibility is the most important aspect of a tunneling protocol if it is to keep pace with the evolution of technology. This document describes Geneve, an encapsulation protocol designed to recognize and accommodate these changing capabilities and needs.</t>
          </abstract>
        </front>
        <seriesInfo name="RFC" value="8926"/>
        <seriesInfo name="DOI" value="10.17487/RFC8926"/>
      </reference>
      <reference anchor="I-D.draft-ietf-idr-sdwan-edge-discovery">
        <front>
          <title>BGP UPDATE for SD-WAN Edge Discovery</title>
          <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
            <organization>Futurewei</organization>
          </author>
          <author fullname="Susan Hares" initials="S." surname="Hares">
            <organization>Huawei</organization>
          </author>
          <author fullname="Kausik Majumdar" initials="K." surname="Majumdar">
            <organization>Oracle</organization>
          </author>
          <author fullname="Robert Raszuk" initials="R." surname="Raszuk">
            <organization>Arrcus</organization>
          </author>
          <author fullname="Venkit Kasiviswanathan" initials="V." surname="Kasiviswanathan">
            <organization>Arista</organization>
          </author>
          <date day="17" month="February" year="2025"/>
          <abstract>
            <t>   The document describes the BGP mechanisms for SD-WAN edge node
   property discovery.  These mechanisms include a new tunnel type and
   subTLVs for the BGP Tunnel-Encapsulation Attribute (RFC9012) and set
   of NLRI (network layer reachability information) for Software-Defined
   Wide-Area Network (SD-WAN) underlay information.

   In the context of this document, BGP Route Reflector (RR) is the
   component of the SD-WAN Controller that receives the BGP UPDATE from
   SD-WAN edges and in turns propagates the information to the intended
   peers that are authorized to communicate via the SD-WAN overlay
   network.


            </t>
          </abstract>
        </front>
        <seriesInfo name="Internet-Draft" value="draft-ietf-idr-sdwan-edge-discovery-22"/>
      </reference>
      <reference anchor="RFC2119">
        <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="RFC8174">
        <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>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7VZ63LbxhX+j6c4lX9UqgVGpC+JOXESWqRkZnSrKEuTadrO
EliSG4NYeBcQw1jW5DU60870WfooeZJ+ZxcACYmWk0kLeSRycXbP/ZzvrMMw
DGwu0vjvItGp7FJuChlEIpdTbZZdsnkc2GI8V9YqnV4sM5AMBxcHgcqMI7Z5
Z2/vxV4nSEQ67ZJMgyBXeQKynrU6UjgppkP8XoglDX6MZiCTpFI6LpJchVZO
5zLNadQPr3ongRiPjbzu1huG6UQ3do36TBbrKBVz8IiNmOShncl0GqrYhNNF
KEvqUKWhjcOFSMO9J4EeW53IXNpuUGSxcB8eEX/oUmev0wn3+B+FoVsjZWmi
kgSig6cocj0XuYpEkixpvKQf50nHTCJSE0p1TlN1zWoLI0WXts51kat0uhUs
tHk7NbrIsDhMc2nCPo7BeTVF8HbRDYjCzbYIwHemDShCEKnUdmm/RSPWFd+9
/vv8rV7TZipS9RNE1WmXXhdiIRWWbW6kzLv0Sqp34Av+IsZypPKlW/xBud0S
wiXwOB8W8a9vZu6EVqTnazK8ZhlULcFr4QRQH2dfn6vYLy8ap1KkizTnQNuf
qVSssfm2RX29pum3SlYLRnN4yVjl2nyS7Q9KtmJ9R5mPsz0C2yIdC1MzPlJp
LFaLTW4HRV4Y2WCYMH0rdvTfTKr3d4x42KJjZWdG1GwOlyJdrTW5XEqjftLp
iscUxC3bmjvyb679a8ciCELEsBjD5yLKg+BiJgnZUrjAiqWNjBpLSzmWIw0T
6IQyZK5E4sI7kXR0E21oviEkKddUpZc7Qqyl+BU0w8a5k5nGMl9ImcJLU2lb
Xqq5iuNEBsi7IXOOi8iRvn+k+OuHIHj//g/DsN/ySR3P34Ymny6moROllAQp
jYz+8GFNl5leQHrkV2ZAZSmRMIiAhPuJLmI6M/paxdLYX37+B41F9HaMOsey
GgEjQQY4iBVTfARsksooZ+WUobGBSWakJxMVQQtUNEJRKNi2uS8NB2rK29u7
tH82CNuEQuo+dUiiqo4TOIjKM6GqZT7+aCNtxovXlZhlxbO0fXi1w0fHyqJK
QBYjp7y3dY8FF5OcCwq7IhPKLKA/Dc+sjGgko8Igwesq7Nhvj3p2p0UcFJ5M
ppFZZqwMdGI1aWL0vOQEYT0jVEMQiswWiVMcJZBZHg5OBpcDmkkB8xKcd36w
/8WLzvMPH3ZpofKZI0Ktw0t4C8r40BBxDO0tQoSLkTvoqt36bd5n46mJgrcF
WZnDRYQuFV4cXTobw+TXctkISDGGJCU3ux64taTrMnrPS7uLYxEBwmLXE5cX
ziK7xN1y6vdCH8WbREIizxGT0BjeutAkIqRk5oIgnylbBckcEQTtSSzQMlj0
+6lU2gj6+deImEwihtl38Ead0ZnRmbbODK8Oz5CcuUytU6BQScz2LTJOsXXT
KplPXLN0xgw5Q0MEW6SRNkv2nUw5crFXsMBsTxHjHXuBVA7uyiB00QrLyG6I
zOQaEjtLcebf3t6icG3/7RPPDhPR2nPuwr6zvkT3iB6H/Dx+mOgG4nXw+3ef
9Fn59/sHiEDjE7pB1SQCzauqEH1/l8jr3f6M1p/v/eqTimiTtGs6eCLWu003
YfO5caF8s3bS440nPV6dxP652ei1m9p37rmhTc9N0DhyEyNHccPR1r57hlvt
1Gd8XG0Xae+79GgUIYKN0kQOib7c2gSvtj5wIzqX7wpEM69bOkJfK9A4fNd8
iwICCBdb2jp+M7rY2vV/6eTUfT4f/PnN8HzQ58+j172jo/pDUFKMXp++Oeqv
Pq127p8eHw9O+n4zVqmxFGwd977DGy70W6dnF8PTk97RFrk6v577wvetsfSt
KzOSM1HYoGqNrkO92j/7z7/bT8vy3Gm3X6B8lrW6/flTfFkA63luOkVS+6/I
4GUgskwK4yBwkhAagMpFgjKGcmjRdVOUfiOR4n/6C1vmr136chxl7adflQus
cGOxsllj0dns/sq9zd6IG5Y2sKmt2Vi/Y+mmvL3vGt8ru68tfvk1iqKksP3F
118FPkYmOkn0wpXKyOh0ObfOjvAGf4J/Cuu90PBcF3CoLBL9/S6dTibhGWLQ
gZe+yFF1HZzZRYNPEY6u3z4xMVq8yZfsGpED9FhELByUYCxxzR2tSpprBire
mTx+JED6rmvFajKBrxA168gS3cVA2FQg+lss09kAiBjdSc9Rv7cH6Aw7VIs2
QKpkLD+Tnqa8DuHTFUHMskdOdm+HO/gJ287Pu278kci8SYLeoQ0v+5Ts0khP
ctcU+3ICW8d0BeRGPQxWdAJACY1awI5Na+7SLz//0x/wy8//AlqaMHtuWpRp
WGcZxoYHNEY4qc204dmL2+rwDBaN3krYkVufR7xZAqelwDMJps/U87TOhEC0
jGQYBo+h3ELF6P3eQ16Ma2XVWCWKfcTal/ia9bs8g3KXyuQFQMIZxOEZs9KI
69CgbtwQvATbbyox3pz1excDJ8T6TH1lfRDuJ4od68xq6U1WDbCMKixmC07X
Rkl4/37k8Sg9c3b4tciAJX1EJ0fnw0rEUe9gWPqTrwboACIeXgVBL449fkjl
YgWKaHslflhN+CMP23ZKaFyeHL5ejo2K6aIAwkhokEbanbiYKQQUlAMyToq4
Si7ZEGj75edPd1bmK8/whul6QPI4vPc8DlznWdPGNbQOaSCc/IEddIRZGbFQ
tcAOnT68wx0+8gg24vZ4S5ciKWCfS7QtYC9k3W2woZfebD6TFQqcW5zwoTv/
JXW6zh8VdqvAdiwxM/DNBmNHflODTJ8hKqdpNYtwyPELjgQ/NpR2vsetQzPh
Q25VE2XptU/YfM3iEPr/ZPNS7n2dQCXe8dTzsB/dUgbiiY5lOOyXWwy1nz+4
0fmi3OqYdXkQMBLd2bqmTe5KyFncxaX19TzSxkierlbziNseusqAQA8xSsyL
lEe69dhHwfXpb5wVfalo0RWa+Kqglcq7WRxtPIU8gqea5t5Ih4mOXG2BQIxN
EQtydz0rS/v5Ix5SCQ2QRyl/VI5mdVeIBi9XqRwvn98SzcrNxoAjNR9bk7Uq
CxM7h4b9rgvNFF/+aFHWr52j8Pd5NZT4ytUonlXh8TV04ys/xTYKzJ26BCLa
jliITAOEUefZzi6sY4wq71g2TnXb0u54N3t11+oXW4fL22pf6y7SqCp7fXex
cYAsVehW8xfRHrWRJk8Qxc/oOX1OX9CL37IWOKD9O3+CDTMCJ/7Li1f9en5I
VqmN7+iW2l1kNKaJ/5EkTbejaxk6EHOVLEvuvXKm3fz8Oklo+7qu6hseJ8nt
Rzj82uf2vmHvq/ZxRX6LOp80rKuAtde222Hn2TO+0IoZqPprw8yBNLSHOngP
r3x7makpXx3w0jW3RF995to0NpUpgE1rnF4iShvFoiwsq+s3kj8qRs3AIqB8
V0iblzC8nsb5Op/vj2aaS5Znwtf8mbYAd4l0YO3YgT7hsR5KInomoIZH1EEw
qIrXGjhkNdcznEtVOSpwd62uVEG1lsWRE63sxc27LJgDcM79jwR28EUiIyI0
XFsYD7yMHvMtE7OwoOLwqySIZZbopQfy0Ka+KbyrSPOmKdaQmM2jyrtbVJx0
6QCerU6IGie404e9k969k08k1HNvGKbDstO0xIpl2fJowOHwB4svXyxXam0s
4eXNM1/7Bv8F9PCg7esaAAA=

-->

</rfc>
