<?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.1 (Ruby 3.0.2) -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-sheng-lsvr-bgp-spf-for-sdwan-01" category="std" consensus="true" submissionType="IETF" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.18.1 -->
  <front>
    <title abbrev="BGP-LS-SPF for Multi-segment SD-WAN">Usage of BGP-LS-SPF in Multi-segment SD-WAN</title>
    <seriesInfo name="Internet-Draft" value="draft-sheng-lsvr-bgp-spf-for-sdwan-01"/>
    <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" role="editor">
      <organization>Huawei</organization>
      <address>
        <postal>
          <street>Beiqing Road</street>
          <city>Beijing</city>
          <country>China</country>
        </postal>
        <email>shihang9@huawei.com</email>
      </address>
    </author>
    <date year="2023" month="October" day="22"/>
    <area>routing</area>
    <workgroup>LSVR</workgroup>
    <keyword>SDWAN</keyword>
    <abstract>
      <?line 39?>

<t>This document introduces the usage of BGP-LS-SPF protocol in multi-segment SD-WAN scenarios. It allows SD-WAN tunnels to be published as logical links, which can cross the internet, MPLS networks, and various operator network. The BGP-LS-SPF protocol can construct an overlay network topology for logical links and physical links across these heterogeneous networks, and calculate the reachability routes of overlay network nodes based on this topology.</t>
    </abstract>
  </front>
  <middle>
    <?line 43?>

<section anchor="intro">
      <name>Introduction</name>
      <t>As pointed out in <xref target="I-D.draft-ietf-rtgwg-net2cloud-problem-statement"/>, enterprises are migrating their workloads to cloud service. The enterprise branch interconnection and enterprise site to cloud DC connection may cross heterogeneous network such as operator networks, enterprise-owned backbone networks or direct connection lines.</t>
      <t>For large enterprises to access the cloud service and interconnect their branches, a PoP GWs network can be built to provide multi-cloud, multi-tenant, and multi-branch interconnection. Depending on the geographical distribution of the enterprise branches, the PoP GWs network may be a cross-regional or even a global network. The PoP GW can be connected to the operator network or the enterprise-owned backbone network. The PoP GWs devices can also be directly connected through dedicated lines.</t>
      <t>According to <xref target="I-D.draft-ietf-bess-bgp-sdwan-usage"/>, SD-WAN tunnels can be established between two GWs devices connected to the operator network, MPLS VPN network, or internet network through the WAN ports of the two PoP GWs devices. All GWs are under the control of one BGP instance. <xref target="I-D.draft-ietf-idr-sdwan-edge-discovery"/> defines the mechanism for SD-WAN edges to discover each other's properties via BGP update through RR. This allows the interconnection between enterprise branches and multi-cloud to pass through multiple SD-WAN tunnels or direct connection lines, as shown in <xref target="pop-gw"/>.</t>
      <t>This draft provides a way to use the BGP-LS-SPF protocol to collect the identification of PoP GW device node and the topology of SD-WAN tunnel and direct connection lines. In this way, each PoP GW device can learn the PoP GWs network topology, and calculate the route to any other PoP GW.</t>
    </section>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>This specification reuses terms defined in <xref section="5.2" sectionFormat="of" target="I-D.draft-ietf-lsvr-bgp-spf"/> including BGP-LS-SPF Node NLRI, BGP-LS-SPF Link NLRI, Dijkstra Algorithm.</t>
      <ul spacing="normal">
        <li>
          <t>PoP GW: Point of Presence Gateway</t>
        </li>
        <li>
          <t>SD-WAN: Software Defined Wide Area Network. In this document, "SD-WAN" refers to policy-driven transporting IP packets over multiple different underlay networks to get better WAN bandwidth management, visibility and control.</t>
        </li>
        <li>
          <t>RR: Route Reflector</t>
        </li>
        <li>
          <t>Cloud DC: Off-Premise Data Centers that usually host applications and workload owned by different organizations or tenants.</t>
        </li>
      </ul>
      <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="usage-of-bgp-ls-spf-in-multi-segment-sd-wan">
      <name>Usage of BGP-LS-SPF in Multi-segment SD-WAN</name>
      <figure anchor="pop-gw">
        <name>PoP GWs network</name>
        <artwork><![CDATA[
   + - - - +- - - - - - - - - - - -|RR| - - - - - - - - - -+ - - - - +
   |       |                        |                      |         |
   |    +--|--+                  +--|--+                +--|--+      |
   |    | GW1 |------------------| GW2 | -Physical link-| GW3 |      |
   |    +--|--+10.1.1.1  20.1.1.1+-----+                +--|--+      |
   |       |     SD-WAN Tunnel  /                 Physical |30.1.1.1 |
   |       |    ----------------                      Link |         |
   |       |   / over Internet                             |40.1.1.1 |
   |    +--|--+                                         +--|--+      |
   |+--+| GW5 |---------SD-WAN Tunnel over MPLS---------| GW4 |+-----+
        +--|--+                                         +--|--+
           |                                               |
+ - -+   + - -+                                         + - -+   + - -+
|User|---|CPE1|                                         |CPE2|---|APPs|
+ - -+   + - -+                                         + - -+   + - -+
]]></artwork>
      </figure>
      <t>As shown in <xref target="pop-gw"/>, GW1, GW2, GW5 are connected to the same internet/ISP network. The GW2 and GW3 are connected through direct dedicated links. GW5 and GW4 are connected by MPLS VPN. BGP-SD-WAN neighbors are established between GWs through RR. BGP-LS-SPF neighbors are established between each GW and RR. SD-WAN tunnel links are established between GWs through BGP-SD-WAN neighbors reflecting SD-WAN routes(see <xref target="I-D.draft-ietf-idr-sdwan-edge-discovery"/>), as shown in the SD-WAN Tunnel between GW1 and GW2 with WAN port IP addresses of 10.1.1.1 and 20.1.1.1, respectively. GW nodes reflect the SD-WAN tunnel topology information to all GWs, including dedicated line-connected GWs, through BGP-LS-SPF neighbors with RR.</t>
      <t>GW2-GW3-GW4 are connected through dedicated lines. BGP-LS-SPF neighbors are established between GWs through dedicated lines, and also between GWs and RR. The BGP-LS-SPF neighbors between dedicated lines are used to discover the topology information of the dedicated lines, such as the direct link with port IP addresses of 30.1.1.1 and 40.1.1.1 between GW3 and GW4 shown in the figure. The dedicated line topology information is reflected to all GWs, including SD-WAN tunnel-connected GWs, through BGP-LS-SPF neighbors with RR.</t>
      <t>The BGP-LS-SPF LINK NLRI is used to carry the two endpoint IP address of the SD-WAN tunnel or dedicated lines. The BGP-LS-SPF NODE NLRI is used to carry PoP GW device node identification. They are advertised to other GWs through the RR. In this way, all GW learns the topology of whole PoP GWs network and can calculate the next hop to any other GW using Dijkstra Algorithm.</t>
    </section>
    <section anchor="extensions-to-bgp-ls">
      <name>Extensions to BGP-LS</name>
      <t>The link could be Overlay link (Such as Internet, MPLS, LTE etc.,) and Underlay/Physical link (Such as Dedicated line, Direct link etc.,). Different customer may require different types of link. For example, FinTech customer has very high security requirement and would like to exclude Internet and LTE, only use MPLS or Dedicated line; some customer only wants to use the Dedicated line/Direct link to get the highest quality path; some customer prefers to use LTE only as backup link to save the cost. The calculation of these customized SD-WAN path needs to include or exclude one or more specific link types, therefore, when SD-WAN link information is advertised through BGP-LS-SPF Link NLRI, the SD-WAN link type needs to be explicitly indicated.</t>
      <t>In this document, a new BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is added to identify a SD-WAN link type, called Link-Type TLV. The format of the Link-Type TLV is defined as follows:</t>
      <figure anchor="link-type-tlv">
        <name>Link-Type TLV Format</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             |             Length            |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   Link-Type   | 
       +-+-+-+-+-+-+-+-+
]]></artwork>
      </figure>
      <t>where:
Type: TBA</t>
      <t>Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value <bcp14>MUST</bcp14> be 1.</t>
      <t>Link-Type:</t>
      <ul spacing="normal">
        <li>
          <t>0: Reserved</t>
        </li>
        <li>
          <t>1: Physical/Dedicated Line/Direct link</t>
        </li>
        <li>
          <t>2: Internet</t>
        </li>
        <li>
          <t>3: MPLS</t>
        </li>
        <li>
          <t>4: LTE</t>
        </li>
      </ul>
      <t>This BGP-LS-SPF Attribute TLV of the BGP-LS-SPF Link NLRI is defined to indicate the Link-Type of the SD-WAN link.</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>TBD.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references anchor="sec-normative-references">
        <name>Normative References</name>
        <reference anchor="I-D.draft-ietf-bess-bgp-sdwan-usage">
          <front>
            <title>BGP Usage for SD-WAN Overlay Networks</title>
            <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Ali Sajassi" initials="A." surname="Sajassi">
              <organization>Cisco</organization>
            </author>
            <author fullname="John Drake" initials="J." surname="Drake">
              <organization>Juniper</organization>
            </author>
            <author fullname="Basil Najem" initials="B." surname="Najem">
              <organization>Bell Canada</organization>
            </author>
            <date day="5" month="October" year="2023"/>
            <abstract>
              <t>   The document discusses the usage and applicability of BGP as the
   control plane for multiple SD-WAN scenarios. The document aims to
   demonstrate how the BGP-based control plane is used for large-
   scale SD-WAN overlay networks with little manual intervention.

   SD-WAN edge nodes are commonly interconnected by multiple types of
   underlay networks owned and managed by different network
   providers.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bess-bgp-sdwan-usage-17"/>
        </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="Kausik Majumdar" initials="K." surname="Majumdar">
              <organization>Microsoft Azure</organization>
            </author>
            <author fullname="Susan Hares" initials="S." surname="Hares">
              <organization>Hickory Hill Consulting</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="14" month="October" year="2023"/>
            <abstract>
              <t>   The document describes the encoding of BGP UPDATE messages for the
   SD-WAN edge node property discovery.

   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-12"/>
        </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>
      <references anchor="sec-informative-references">
        <name>Informative References</name>
        <reference anchor="I-D.draft-ietf-rtgwg-net2cloud-problem-statement">
          <front>
            <title>Dynamic Networks to Hybrid Cloud DCs: Problem Statement and Mitigation Practices</title>
            <author fullname="Linda Dunbar" initials="L." surname="Dunbar">
              <organization>Futurewei</organization>
            </author>
            <author fullname="Andrew G. Malis" initials="A. G." surname="Malis">
              <organization>Malis Consulting</organization>
            </author>
            <author fullname="Christian Jacquenet" initials="C." surname="Jacquenet">
              <organization>Orange</organization>
            </author>
            <author fullname="Mehmet Toy" initials="M." surname="Toy">
              <organization>Verizon</organization>
            </author>
            <author fullname="Kausik Majumdar" initials="K." surname="Majumdar">
              <organization>Microsoft</organization>
            </author>
            <date day="22" month="September" year="2023"/>
            <abstract>
              <t>   This document describes the network-related problems enterprises
   face at the moment of writing this specification when
   interconnecting their branch offices with dynamic workloads in
   third-party data centers (DC) (a.k.a. Cloud DCs). The Net2Cloud
   problem statements are mainly for enterprises with traditional VPN
   services who want to leverage those networks (instead of altogether
   abandoning them). Other problems are out of the scope of this
   document.
   This document also describes the mitigation practices to alleviate
   the issues caused by the identified problems.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-rtgwg-net2cloud-problem-statement-30"/>
        </reference>
        <reference anchor="I-D.draft-ietf-lsvr-bgp-spf">
          <front>
            <title>BGP Link-State Shortest Path First (SPF) Routing</title>
            <author fullname="Keyur Patel" initials="K." surname="Patel">
              <organization>Arrcus, Inc.</organization>
            </author>
            <author fullname="Acee Lindem" initials="A." surname="Lindem">
              <organization>LabN Consulting, LLC</organization>
            </author>
            <author fullname="Shawn Zandi" initials="S." surname="Zandi">
              <organization>LinkedIn</organization>
            </author>
            <author fullname="Wim Henderickx" initials="W." surname="Henderickx">
              <organization>Nokia</organization>
            </author>
            <date day="29" month="August" year="2023"/>
            <abstract>
              <t>   Many Massively Scaled Data Centers (MSDCs) have converged on
   simplified layer 3 routing.  Furthermore, requirements for
   operational simplicity has led many of these MSDCs to converge on BGP
   as their single routing protocol for both their fabric routing and
   their Data Center Interconnect (DCI) routing.  This document
   describes extensions to BGP to use BGP Link-State distribution and
   the Shortest Path First (SPF) algorithm.  In doing this, it allows
   BGP to be efficiently used as both the underlay protocol and the
   overlay protocol in MSDCs.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-lsvr-bgp-spf-28"/>
        </reference>
      </references>
    </references>
    <?line 153?>

<section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Donglei Pang for his contribution to the document.</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>Shunwan Zhuang
Huawei
Email: zhuangshunwan@huawei.com</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA7Va7Xbbthn+z6vAnB9rZ1GxZHdttK6dYjmNzxRbs5z2dDs7
OxAJSagpgCVIK2rsXsuuZVe25wVAiqToNek2+RyLBIH3+5sKwzAwOVfxP3ii
lRixPCtEEPFcrHS2GzGTx4EpFhtpjNTqdpdiy+XF7atAppndbPLhycmLk2GQ
cLUaMaGCIJd5gm1vDV8Jppfs5TezcDoP57NXTCr2pkhyGRqx2giVs/kk/G58
FfDFIhP3o/rWpc6698Y6UnwDBHHGl3lo1kKtwsTcZ+FilYYmXYY4Gpp4y1V4
Mgj0wuhE5MKMgiKNub14xuhixIYnw9NwcBIOXrAwtGtMGraUSSJiopUXud7w
XEY8SXZssWPvNskwW0ZMLpnSOVvJe2KYZ4KPWKaLXKpVsNXZ3Qo36YhN59/e
BMHddhQwFoJ+Ij8A0LXOsBRiVSozYud9NicucO84O6e7ak1nK67kT6BDqxF7
XfCtkFg2eSZEDpkJ+SPwshvNYyxHMt/ZxR+kPS02XCZQJAGL6N+f1hZCP9Kb
Gg2viQZZUfCaWwLk0+gruHKNvS8aUCELsgARy1xnH05qpAuVk9Wdr6XiQRBC
KXyBwzzKg+B2Dd1A+YU1BomdOi4iYVi+FqzoMLY007mOdEKa3HRYEjORUDyT
2vTZZc6gY7015bO8UEokAK7ZQrC0WCQSIowZNyzRK7IIlkh1Z3psu5bRmkVc
sSjTxpED6kSmRN5jb2bTOcMVWQU2w9PYPeEsDNOpyDgEVD7us1sc7WLAAtcK
kigiEKqYvhdZwnflSVCZapC1s17ToM9iTNc7U1+qCDWCreEbmV4JJYimJqU4
EhUJuQUxBSuP1nwhE6jNWjtkD4m3aVE6xoMFN5CWVjgpTUVf3yl1I+M4EQH8
8NKrkYyLvX9mtfoYBGPDUk1CBIiClM3ev//6Mpz0nc9LkS/DLF9tVyGwDqNE
F3EIaS0SsQkRznJBan587CEegbs0kwYkwU2BeQWZkw2CI5kxojiBNVpFWzjM
iOxeRsJpY3+eLTKuoGirWihDCUc0yam2y0iSVglrcs5qWzeQkhN9p9CZKQCf
HxqGqfMR6q2CWBY8ulsgYld74KcslhlQ1VFC4cJA6q/ILni2Eg2JgE4ewYWc
0TbYt3zVefUCc1IQZCBspmfsm+/29JOZwlkWhUxygg2N3MtYeOez4Hv+Jofn
qdxZmVvpFm+fTUQqVEwas8Yk2Epo6DBdW4OOJZxCLgrLLIwx79IZUUsP2vSS
PkAvd0oJM7ECFACFrAQCOx6sEr3AQsNBHZSSWU8qNAKGCUlbeQStSdUTGqxD
R6ATpAVj0fDE2Cjk1ItMVEO6hiOu1tgeS8racaXxcRTpzMoNhL1//5uW9yyg
dZcwbaK08ZMcphX+PJcCTlVGwAXIFZAOiG5S+kuS8MHw29nVfgVPy1i5D2ae
J4JBtKQ6y02pXMLaklGfjZPELpCHFyoWTuIgCNEksTFK2cBKqQ7FDjn3oURk
XFYNIl6JEJYVUWjbPT4C0ZKkaqFuBIKgkmZjY60XF52w7lSeYhQrmcaB7LeG
HAGyyCX23EtuKXG1SMXrzQ2pH5HSZ6EqidR8uRR8h33X/Mh5MXkft37t4Ntn
aSLa+n06aPQoEpk1bNWF31Sn4Wr7+NgvMzFJrnRxEMC28CagLYzLFl15jOKi
RnHlognDQZXLJRmud1/vW06xNpNYzqziyxSHbQ0m7I6nIh8SjMtAoK7nlNLE
QQaeCJ6pzghRIu1Mh5QBbQhVO6dpf7xPie1WZBup7GEvMJOKaM9sJgobgbHN
ePuKnaDnnoHP+kPitZ326pUuTFOqKCmsm9cEfkWCu5reXPbqq1Mkf786kT/c
UV0Fz0GdL/P1hjKzp3+Eb9ie1UeGEgH+wr4B1xBhEHrZj9hcL/MtOdzEE/8d
hfoxigR2VQa0Uvhl1dZjR+74Efhfisy6DCQso10YZ1RMo6XgypDHE0uXM1hx
dCfI/cmpKiuO5RLHqZSz7l4rPyzIFaIJvAXCtQFkAeVtZZzDDbhCnHOk3Esj
fTFjleuiRR8s3tyMUKKSdm/EkqwVRWzIzn1GH7Hr5TKEZDbkgROec3ZuXZK8
jYMiU9h2Ya0NarU0TbzKnZOWBQfzSWBX46VeaVvXdFmSovmzZ6DlxwJWTsQb
NkXNXYAVsi3B7sSOAKOKOXrzdn571HPf7OraXt9c/OXt5c3FhK7nr8fTaXUR
+B3z19dvp5P91f7k+fWbNxdXE3cYq6yxFBy9GX9/5Lzj6Hp2e3l9NZ4ekR03
9G4Ds6ukpQteIre1dIDQESF/O9t/eT771z8HZxSbb16dDweDFzBwd/PF4PMz
3GzRwDhsWkHE7hautwsgaHixbdoSKphTmSNt1oIY/FNAkL/7G0nm7yP25SJK
B2df+QViuLFYyqyxaGV2uHJw2AmxY6kDTSXNxnpL0k16x9837ku51xa//JrC
HwsHX3z9VUDh6GOa8eDnn39GN8aO0bPS33HIOv8ebm4eutaPq8tjAvPA3Kf8
Pvg88WC//FCBOQ7DhxAIDj5PPGgs78E8IMoNGJ60P/RgiMfhrN4x2eXTkqAD
agYn/QH9MTb0V8cW2IdSU337tHbr0hp7fsBlRdXDaYnzEEybp27p2mTQJWL/
/dxF3MuyOPtPn4ezQ2qe1NQTnw7ZYOmYJP9ZTVNNEVkSqahsKPDMHiUFBJ3Q
P5yaoLb0pPk+8XkIjp0zeEf6COTNc8HDW/RkJIKH89nF4MPpoO1De248m5n/
HT0UHt6P2DNXETJm531/PGrVTkeuje+oIHvkffRv2LPapeRw0DwYvtmPUZ5f
zmfNNonclNIA+WXrfNkRuYqw0RjdoSC0GO3Js9ZJ5OKyQenbOOmNTQm5Wi90
5vqLrlaI2K5X8rUg+8uHbVGKgpSIosPN4tZPbD4AcSfFmStgqJjyz9zg5hMj
xEf1QJ82+wFSUdMX9yQNvHyHbIvKsmrhqJrjcYyK0rjBURU3aXsZOnsgmSrl
HNVgsiN1+YGS56SO2Yuo6gykQku2cfU11eWuK+zVauRmmxzudW/31SV5oD7L
C/QTBOAshN2Fhxb0VDf+cQZRV2oLkqt9/Dxgv7s0ndb8cI+q3NwC5xpm47yu
al0b3VZdpr4FP6CpnFvZh87tyGydyDpVf1pXfZU99iydVi7asLilXBWZn8w1
qegmWFZm41jssIiGKf1Kg2iJfXp59WfbZxH+UroRz7JdNcEQKrbzzZpgSuk2
bZv687YxtdBdXU8unkDX0U43e24LbGfNgMf3NKLw510/W7dEoo1srNFQO4G6
BtoctOnbtU4Oe2rXSatWN63EuxwtU9psqAG7MKSmzob1Gbt4hxbJ2HYJ55xQ
nD6sAUa6SMiv2LWfUdvVT+beXi8bU/oem95eMJFH/d6nlsi3vrV83igG98cn
DcVQU703fQemj7WyuYsKk+sNNbGgI3O9XK33y3epcw063mc0rxXv+AbNbo+9
kupW0DuGEsQa2CksszWMkRkRFZmdye87RN9rEvuJvLPNl3hHNi/2JR1tAcs9
10vR3MamP2BucvYHZoB1j921XtSY1uc9zTPP68LwHTntIoIR89iP6JGJ5JTn
6zb8dD8bIOCkFYuSGzszLdIKquH3wo/6TO4co7SqfbwyJWj5E4jz7kV4YXPC
Df5dOBB28OulRBND3G40tFRObjxe0pTtOkEnHvdsG1oCtltaMajuWocRpTaW
qfl/hWpPJc1h39E4QdIMWCovbzjC4ZyF49i2jmWcuzm5YLfTb8tY00WFIzh2
YcBHC8j+gK4eiZrek9LJkN4ME2SnBMd9iaWxgcCX4y4odKntvHNUNZ32c9JR
hQ461oYda6c1KAPsOGVn7DP2e/Y5+4K9+Ji1Es5x+F/+lYBalbuVSP3TfD4V
agUbrT//v1C01w7dP4miqvptQ0wGEObJfVX8N3X8yuqfOoAteckocD8cuH05
DgLH14jNnVP5qXriuPUWc8+TgrK9QPj6RPZFv2dft++ztsVk45c7Z7eaT22d
YCeqNPNHHs99unQA7aAHXjSAy1QEj2jweTJiN4LefIkYd4NR1Wk/34e1aSus
YeNwVEVT3J2ObADF1dmIopaf+/5aJyy9xMYnR0TLnZoVg00clBTnZT44R16E
B2duoNh+gx5ryN6J1b9Kt4mX4kaVUaIGBAv9cnw1PoT8cuJf7VKEpm3j6E7p
bUJthJ1YuqzsfvtgWpkpX3PwPdFqlQjJZvTTA3q3QtTaqWz5fs+3hiUHlpzz
cgPABsF8XShkJvbXdQEogf+xwoX7qcJPdtG4LfXfK/wb8CYr8wUjAAA=

-->

</rfc>
