<?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.6.17 (Ruby 3.0.2) -->
<?rfc comments="yes"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-wlin-bess-group-policy-id-extended-community-01" category="std" consensus="true" tocInclude="true" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 3.15.2 -->
  <front>
    <title abbrev="Group Policy ID BGP Extended Community">Group Policy ID BGP Extended Community</title>
    <seriesInfo name="Internet-Draft" value="draft-wlin-bess-group-policy-id-extended-community-01"/>
    <author initials="W." surname="Lin" fullname="Wen Lin">
      <organization>Juniper Networks</organization>
      <address>
        <email>wlin@juniper.net</email>
      </address>
    </author>
    <author initials="J." surname="Drake" fullname="John Drake">
      <organization>Juniper Networks</organization>
      <address>
        <email>jdrake@juniper.net</email>
      </address>
    </author>
    <date year="2022" month="November" day="08"/>
    <area>Routing</area>
    <workgroup>bess</workgroup>
    <keyword>Group Based Policy, BGP Extended Community</keyword>
    <abstract>
      <t>Group Based Policy can be used to achieve micro or macro segmentation of the user traffic. For Group Based Policy, a Group Policy ID, as known as Group Policy Tag, is used to represent a logical group that shares the same policy and access privilege. This specification defines a new BGP extended community that can be used to propagate Group Policy ID through a route advertisement in the control plane. This is to facilitate policy enforcement at the ingress node when the optimization of network bandwidth is desired.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="terminology">
      <name>Terminology</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all
   capitals, as shown here.</t>
      <t>EVPN: Ethernet Virtual Private Networks, as per <xref target="RFC7432"/>.</t>
      <t>GBP: Group Based Policy</t>
      <t>VXLAN: Virtual Extensible LAN</t>
      <t>NVO: Network Virtualization Overlay</t>
    </section>
    <section anchor="introduction">
      <name>Introduction</name>
      <t>In the virtualized overlay network where EVPN with VXLAN encapsulation is used
as the overlay solution, without external management software or controller,
the propagation of a Group Policy ID is done through the data plane.
The source Group Policy ID is encoded in the VXLAN header before the user traffic
is sent to the VXLAN tunnel.   The encoding format of a Group Policy ID in the
VXLAN header is specified in <xref target="I-D.smith-vxlan-group-policy"/>.</t>
      <t>When the source Group Policy ID is propagated through the data plane to the
remote VXLAN tunnel endpoint, the policy enforcement is carried out at the
egress node based on both the source and destination Group Policy tags.
The policy rule for the source and destination Group Policy Tags may result
in the traffic being dropped at the remote VXLAN tunnel endpoint which is the
egress node.  To send the traffic all the way from an ingress node and then
drop it at an egress node is an inefficient use of the network bandwidth.</t>
      <t>To optimizes the network bandwidth usage, it may be desirable to have policy
enforcement done at the head-end of a VXLAN tunnel that is the ingress node
for the user traffic. To accomplish this, there is a need to communicate the
destination Group Policy ID from the egress node to the ingress node.
This document defines a Group Policy ID BGP Extended Community that can be
used in the control plane to achieve the propagation of Group Policy ID from
an ingress node to an egress node.</t>
    </section>
    <section anchor="nvo-use-case">
      <name>NVO Use Case</name>
      <t>In an EVPN VXLAN overlay network, a policy group tag may be assigned based
on the MAC, IP, port, VLAN, etc, or a combination of the above.  Similar
to the MAC/IP addresses in the EVPN network, once the Policy Group ID is
known for a local host/server/VM attached to an EVPN network,
its Group Policy ID can be advertised to other Network Virtualization
Edge devices in the control plane through the Group Policy ID extended
community.  The scheme used for classification and allocation of Policy
Group IDs used for GBP in an EVPN overlay network with VXLAN encapsulation
is outside the scope of this document.</t>
      <t>Policy group tag prorogation in the EVPN/BGP control plane can be applied
to the EVPN type-2 MAC/IP route<xref target="RFC7432"/>, EVPN type-3 Ethernet Inclusive
Multicast route <xref target="RFC7432"/> or EVPN type-5 IP host and prefix route <xref target="RFC9136"/>.
If Policy Group ID is allocated for a MAC address, IP host or prefix
address through the GBP classification scheme, EVPN can encode its Group
Policy ID through the Group Policy ID extended community and advertise
it alongside its corresponding EVPN route.</t>
      <t>For the flows that the ingress VXLAN tunnel endpoint has learned its destination group policy tag through EVPN/BGP control plane signaling, the policy enforcement can be thus carried out right at the ingress node.  Otherwise, policy enforcement can be carried out at the egress node.  If policy enforcement is carried out at the head-end VXLAN tunnel, the ingress node MUST set the GBP applied bit, the A-bit as it is specified in <xref target="I-D.smith-vxlan-group-policy"/>, to 1 in the VXLAN header before forwarding the traffic to the VXLAN tunnel.  Otherwise, the ingress node set the A-bit to 0 in the VXLAN header.</t>
    </section>
    <section anchor="evpn-interworking-with-ipvpn">
      <name>EVPN Interworking with IPVPN</name>
      <t>In the EVPN interworking use case as it is specified in the <xref target="I-D.ietf-bess-evpn-ipvpn-interworking"/>, two or more EVPN networks/domains are interconnected by a layer 3 IP-VPN network with VPN-IPv4/VPN-IPv6 BGP address families. To support ingress policy enforcement, the Policy Group ID extended community needs to be propagated by the GW PEs sitting at the border of an EVPN domain and IP-VPN domain from one domain to another.</t>
      <t>For the Uniform-Propagation-Mode defined in the <xref target="I-D.ietf-bess-evpn-ipvpn-interworking"/>, when propagating an EVPN IP prefix route across the domain boundary to IP-VPN network, the Gateway PE SHOULD propagate communities, extended communities and large communities except for all the EVPN extended communities. The Policy Group ID extended community defined in this document is a new transitive Opaque Extend Community. It is not subject to stripping at the GW PE when the Uniform-Propagation-Mode is used.</t>
    </section>
    <section anchor="the-group-policy-id-extended-community">
      <name>The Group Policy ID Extended Community</name>
      <t>The Group Policy ID BGP Extended Community is a new transitive Opaque
Extended Community with a Type value of 0x03.  This extended community
may be advertised along with an EVPN type-2 MAC/IP route,
EVPN type-3 Ethernet Inclusive Multicast route, and EVPN type-5 IP prefix route.
This new Opaque Extended Community enables the EVPN route it attached to
propagate the Group Policy ID used for Group Based Policy in the control plane.</t>
      <t>When the "Uniformed-Propagation-Mode" is used under the EVPN and IPVPN interworking use case, the Group Policy ID extended community is carried over by the GW PE when a route for a given IP or IPv6 prefix is propagated from one domain to another with a different address family.</t>
      <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=0x03   |   Sub-Type    |           Reserved            |          
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|            Reserved           |    Group Policy ID            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork>
      <t>Group Policy ID (GPI): The GPI field is 16-bit long and it encodes the value of a Group Policy ID.</t>
      <t>The reserved fields MUST be set to zero by the sender and ignored by the receiver.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>For the Group Policy ID extended community defined in this document, IANA has allocated the
following codepoint in the Sub-type registry of Type 0x03 Transitive Opaque Extended Community.</t>
      <artwork><![CDATA[
 Sub-Type     Name                                  Reference
 
 0x17         Group Policy ID Extended Community    [this document]
]]></artwork>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>All the security considerations for BGP extended communities can be applied there.
Attackers may alter the value carried in a BGP extended community. In this case,
the Group Policy ID carried in the Group Policy ID field can be altered by attackers,
which could lead to the wrong policy rule being enforced on the user traffic.</t>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to thank Jeffrey Zhang, Jeff Haas for their careful review and
   valuable feedbacks.</t>
      <t>We also would like to thank Prasad Miriyala and Selvakumar Sivaraj for their contributions.</t>
    </section>
  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <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>
        <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="RFC7432" target="https://www.rfc-editor.org/info/rfc7432" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7432.xml">
          <front>
            <title>BGP MPLS-Based Ethernet VPN</title>
            <author fullname="A. Sajassi" initials="A." role="editor" surname="Sajassi"/>
            <author fullname="R. Aggarwal" initials="R." surname="Aggarwal"/>
            <author fullname="N. Bitar" initials="N." surname="Bitar"/>
            <author fullname="A. Isaac" initials="A." surname="Isaac"/>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <date month="February" year="2015"/>
            <abstract>
              <t>This document describes procedures for BGP MPLS-based Ethernet VPNs (EVPN).  The procedures described here meet the requirements specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7432"/>
          <seriesInfo name="DOI" value="10.17487/RFC7432"/>
        </reference>
        <reference anchor="RFC9136" target="https://www.rfc-editor.org/info/rfc9136" xml:base="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9136.xml">
          <front>
            <title>IP Prefix Advertisement in Ethernet VPN (EVPN)</title>
            <author fullname="J. Rabadan" initials="J." role="editor" surname="Rabadan"/>
            <author fullname="W. Henderickx" initials="W." surname="Henderickx"/>
            <author fullname="J. Drake" initials="J." surname="Drake"/>
            <author fullname="W. Lin" initials="W." surname="Lin"/>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi"/>
            <date month="October" year="2021"/>
            <abstract>
              <t>The BGP MPLS-based Ethernet VPN (EVPN) (RFC 7432) mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or Network Virtualization Overlay (NVO) (RFC 7365) network.  In some networks, there is also a need for dynamic and efficient inter-subnet connectivity across Tenant Systems and end devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols.  This document defines a new EVPN route type for the advertisement of IP prefixes and explains some use-case examples where this new route type is used.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9136"/>
          <seriesInfo name="DOI" value="10.17487/RFC9136"/>
        </reference>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.smith-vxlan-group-policy" target="https://www.ietf.org/archive/id/draft-smith-vxlan-group-policy-05.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.smith-vxlan-group-policy.xml">
          <front>
            <title>VXLAN Group Policy Option</title>
            <author fullname="Michael Smith" surname="Smith">
              <organization>Cisco Systems</organization>
            </author>
            <author fullname="Lawrence Kreeger" surname="Kreeger">
              <organization>Arrcus, Inc.</organization>
            </author>
            <date day="22" month="October" year="2018"/>
            <abstract>
              <t>This document defines a backward compatible extension to Virtual eXtensible Local Area Network (VXLAN) that allows a Tenant System Interface (TSI) Group Identifier to be carried for the purposes of policy enforcement.</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-smith-vxlan-group-policy-05"/>
        </reference>
        <reference anchor="I-D.ietf-bess-evpn-ipvpn-interworking" target="https://www.ietf.org/archive/id/draft-ietf-bess-evpn-ipvpn-interworking-07.txt" xml:base="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-bess-evpn-ipvpn-interworking.xml">
          <front>
            <title>EVPN Interworking with IPVPN</title>
            <author fullname="J. Rabadan" initials="J." surname="Rabadan">
              <organization>Nokia</organization>
            </author>
            <author fullname="A. Sajassi" initials="A." surname="Sajassi">
              <organization>Cisco</organization>
            </author>
            <author fullname="E. Rosen" initials="E." surname="Rosen">
              <organization>Individual</organization>
            </author>
            <author fullname="J. Drake" initials="J." surname="Drake">
              <organization>Juniper</organization>
            </author>
            <author fullname="W. Lin" initials="W." surname="Lin">
              <organization>Juniper</organization>
            </author>
            <author fullname="J. Uttaro" initials="J." surname="Uttaro">
              <organization>AT&amp;T</organization>
            </author>
            <author fullname="A. Simpson" initials="A." surname="Simpson">
              <organization>Nokia</organization>
            </author>
            <date day="6" month="July" year="2022"/>
            <abstract>
              <t>EVPN is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where BGP VPN-IP or IP families provide inter-subnet forwarding, there is a need to specify the interworking aspects between BGP domains of type EVPN, VPN-IP and IP, so that the end to end tenant connectivity can be accomplished. This document specifies how EVPN interworks with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding. The document also addresses the interconnect of EVPN domains for Inter-Subnet Forwarding routes. In addition, this specification defines a new BGP Path Attribute called D-PATH (Domain PATH) that protects gateways against control plane loops. D-PATH modifies the BGP best path selection for multiprotocol BGP routes of SAFI 1, 128 and EVPN IP Prefix routes, and therefore this document updates [RFC4271].</t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-bess-evpn-ipvpn-interworking-07"/>
        </reference>
      </references>
    </references>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA61ZXXfbuBF9x69A05f2VJTtOJtsdE5P6yTerHJiW42dpO2e
fYBISEJMESxAStGm/u+9MwAlUqKy2bbejc0PYDAfd2YuwCRJRGozU8xHsq5m
yfdCVKbK9Ui+drYu5cTmJt3I8Sv54vVEXn6udJHpTL60y2VdmGoj1HTq9Oqb
h2c2LdQS4jOnZlWyzk2RTLX3yZzmJyXPT0yW6Dg3SZu5yemZSFWl59ZtRtJX
mRC+UkWmcltA4EZ7UZqR/Kmy6UB66yqnZx5Xm2W4IEG6qPzPQpjSjWTlal89
Pj19fvpYKKfVSL6zdQVPiDWcQUqJ+3Vj2AvlYUcwb3DMOPF7+WU0mlqTa1fm
UFVO0/LsyYMQqq4WFmsKKRP8k9IUfiQ/DuVbU/B9cMpHXWyfWAct3kBwqZ28
1tXaunvPb/RSmXwkyXd//RQGDAtdia7wN0P5yql73RL/xi6K1sNfXeFTRmP3
18APWXptK4hMVUHLaVfJwrqlqsxKSzdLvawWNbT48uV37354+fjs7PnDAyaF
HwStNZqR0Bo/Tl4NjQYWU+s0fqkSU4VIkkSqqa+cSqHGYVRYlamWNT2qrFTp
wmiIX5rUWdgql4ouvJ4TCrC0LaSdYVme4gAHNZuZdCh/wNi+oKt9jOORl/eF
XRd00Xl5p+YDafxWGadLpz3WhZTczk2qcsmIx/qqkn4BAHrWxSNSMqQB+0ml
KZAoS2dWgNVcD+XdAoJ9qVMDdYMdmZ6ZAgKULPSa0dmkj9ymT1hpz0mls6Wa
E1L387da4MF8AZH4i/cqWyHIxmvyHkLOyqa2qJzNJcBeNJrhfwieqdTkpiLJ
0RhdzKxLw3QoQtORa46MK2ym5Xqhg1BbVmZpftlGqAjIlFO4Y22yakFLZNob
p7NhwMXSZFmugco77ZamsHAxsvEOwu71RmJ25uWjq/e3d48G4a+8vuHrd5d/
ez9+d/mKrm9/vHj7dnsRRhDccX/z/m0cQle7yS9vrq4ur1+F+Xgq9x5dXfwD
f6A3y7mZ3I1vri/ePgruIytsWgeHOE1em5JPKhQPpysESLGdqTNT3ISy8OLl
5OxJJ6vizfdnz57ghrzIK0pb5Jt4C68CTGWplaOlVZ6TqFSVCFDuGcZ+QTBe
aKeH9E5cfphcj+QlZjr4X34wrqqB2QlgSDFtqgXPpfLxE1R49uT88c+IyOsX
k76yKcSHv7+9gNRGGFdQb6a5lnguxPWHm1EjuRnU4OAG6MvVBpWHas+YYJfV
Kb0SYhxws2pmYEUbhzfYWZNlkoySawMEsSaAJHzg6zwsEdNVqJCIjQhv85re
D3gmcoFzyxUwYKkKNQ+I9nZWrSmKKB4xK9AEBoIkNUkW8XxQRxjP6GHbnKNJ
mapUzCsGsrc1sqdvKqywGQOEJwbTFlplCMtUI+n0QZETVEFIbWBuN6eqi0Ln
Q4SfFmSxyFA540p9RHNeU3TW3FWnoNSXL3+hku6XcF+y+gyTOs3+4QGQ+dgk
/3Ezt6UqO+KnaIxweonW1LEJxmSlRWpxLvRVJCyQKudIZQpxKFBCt+rTlKGM
EE5ttWjrSsmGNAVzCCHu6F6puQ8BjIu6GnDHut8sAa3EA2mYqQHVSsQwx0gi
whSjDM4pqWKEwvo1FyAXTMo1dM9CBP6O+mORdRZAteD7NVSYObuU3PFbjlFh
QiFICWnYeRjT9h0W41maJBryN9DYdN+D+j5khiGgTGwFsTUeNoLaI/8GtCY5
CNWT24KiigIwLNSqcbtox5pzLXqKMJuQyQzvjsO4XwY3dQwWTfS6tOGOKAe6
bZkbv+DyzmBzwXooHzpu7MdEZDkAR+MO1LO7aaW2L2PKtjUigLW7yY4OfBsr
b1MDwdSgr7+3SVVPWetTXuxjhUR0oDHkeo7KL98DES+RY1zPMYiLdQjIXjUn
KhazKXIoNW8AoLw38wIWcLoKG+y4ung5kOPJANMcasAHCB1IXWGfgFAqism0
iUEEpZpiUQDxFvjLlRPR6xB0Mp6ADGVkAVwcHcXKbtWzRRpcFL0RXMNlTAS+
OON1c0s8cGF9dQIowciTD1cAZgUvRw5bdCULU/kDR0dKtyVoPNMS9I40U3GZ
zSlVVibdWbAX6laF3V+voZZiSy2HoWN4qL2M3JIMTHOKxpakMpvNyebG0ZEX
NO7xu6mgEMxUov0H7fxID6e+hvLtTRb871NbxjrTyo8hl5fJPoKAZ2cjnlth
PaGc6Xqn8XiJXIcfIjZY02pT6uRxgxOmzoGfETl6eBi0Rp3v6NW4SPPaYzMk
rlDi4TBfRdrdnkxg3U3/DoBm7LBjwRhn5nNn0vOz86fUXMezHhw2kYj+VqRx
A+vBVjLeBMEivuoCA0Hai3GAQLSS3BTIidziVhzuML6Gsdb2heHTYFxQm8G+
f86hJunYLELB0hbMWXh9dgYKzA+xXs9yu/ah1rUraH+XXIAG5iDMVEtIfrtO
B8yU2w6/NeUIXqgkIfuK+VH6ERFFe+AOD3FmvujdLgHDN4SeNZwx+IrEQ1Ij
uy0f6PhWOrRrlm2XDQ63crzD8rraoiRmipyayMAukilF0FPr/s18cUAF7uxr
fBe/QMYZCW0q0892W348sKQxIuiL+ad9y4Ymxpgb0/aNahStzWVqPMHz7SaF
B5n2IGJCSHh9xBs0KXqED0X4sEyvyiIxJf9uyWLXrMNhh3XdruRPMrtUpvC8
1+RZAGmhUyoB0w11I7WBB8+hcNKaF2vt5DoZT1ZPTuLFU2YSTVGYKTRJoz2T
IF+X1GW3fjxE16C3N/akPHEmH/fFLfo/3QRgfZSTS3jLVHRo12B0is0+zCA6
F5tHsJvrRzQtPmF6RVww3nPD5cZJAW2qxvvC0A4omezoTnJF2Ags678KEp91
bPkTKR91ReHtVHI6svKBgkYlp7YuMuU2pG03UsGtr+EiouqTSxlPK3ZnPI1n
EarBob8NMUY4CXRn3hmLoakuq9Ao4m6Ate0TMWQq8A3B7bivzV5Nc46FtC0Q
XTojvCnVv2odqeuOuA7lmMcjasDd9BPQTH7xlTNl2QIFQ2V3wnQ0pPEIgMJP
GX3X05n6jn37xh1h2seNEz2jOfeUvEO/lyuV18xlTj+fnjPjor3/gV9FQ4R3
dJAbZZRVHKUpA/F1aiL3qEk4ZdrjI23wxl0JGdsJX8dCXdBuze8wFXDPu8gt
DxY7CPeRhR1rPDwU7j2obJ03PIpY0NkBGh5tD3CRcdrtVAyV5GghH3wro2k3
2RU1r80+WJvD10DR5ohCQV7GHdfg6O3u4cjxqtbAKTOzGfaldOzYLuCbYTzd
P5WHP2c9zx73PDtvRJzh9bl8Ir+TT+Uz+b18/luesZA/Jf/jfyzl33ScBXz+
mdIm3t/W04RzKt43P+80b8OytkGt9/9nrb62LL/fh1D7/f9Nl+ZTym6ZP7ye
jP84CsVvMpYgInlGGDt7yiSIiwmlAK4Duw/Zu61PB6cOw1AhXWMmS/SBJU4j
x7LyF+1skwJ0CAW88irzAlRm2/SdTjXSwIUSTUfBF9cXqCcFbQQcJ6/f9e5v
SMJjbWgQJNM2YLdVogObmcXtmhKebA+bhVhlCFdUC6Hl3KAJbcgdDDQG392R
ftYuiE0OtiEqr+mb0K/+vNOc1akWMibh57Nn27e/3sdo1E8dH/zMHr7Vae3o
/b6XLyIX8M2AtDOAq1bvtyjiFN09dDgpG4oLKvr32oUTT5VXse4GcDXVktjc
ka9cYAQxkFyKRR8KWmL6XgfAN/qRCpEhN7oNRDhCTW2NgdgkZs3OYu0oOdon
veF4NpJfPj4+ODmEk7+MRvHrNH0kfUnNykzryjofUmeHuVLbMo/9jIbouHbn
Y5KXa53nQ4g92YqF3IuUDp9ynYVvFlF2+DSNKcEacx+PGFVxL9/o2czpjfwn
7rB5pVv5o1K+OcA2jpypZ3UOyK8MOn381kXx4mPYGSj8FG7z1HTJnd72rjRx
ysOPV8aZjcoVp/6tzlfqvl4qJ2/NSjn1qb1u4wGCWvhm1fZix/T/AM1GA3rl
IAAA

-->

</rfc>
