<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="yes"?>

<rfc category="std" docName="draft-hilliard-grow-no-export-via-rs-00" ipr="trust200902" updates="1997, 7947">
  <front>
    <title abbrev="BGP Large Communities">The BGP NO_EXPORT_VIA_RS Community for Route Servers</title>

    <author initials="N" surname="Hilliard" fullname="Nick Hilliard">
      <organization abbrev="INEX">Internet Neutral Exchange Association CLG</organization>
      <address>
        <postal>
          <street>4027 Kingswood Road</street>
          <city>Dublin</city>
          <code>24</code>
          <country>Ireland</country>
        </postal>
        <email>nick@inex.ie</email>
      </address>
    </author>

    <author initials="W" surname="Hargrave" fullname="Will Hargrave">
      <organization abbrev="LONAP">LONAP Ltd</organization>
      <address>
        <postal>
          <street>5 Fleet Place</street>
          <city>London</city>
          <code>EC4M 7RD</code>
          <country>United Kingdom</country>
        </postal>
        <email>will@lonap.net</email>
      </address>
    </author>

    <date/>

    <area>Operations &amp; Management Area</area>
    <workgroup>GROW</workgroup>
    <keyword>BGP</keyword>
    <keyword>communities</keyword>

    <abstract>
      <t>

        This document describes a BGP Well-known Community called
        NO_EXPORT_VIA_RS.  This community allows BGP route server clients to
        instruct an Internet Exchange BGP Route Server to tag prefixes
        destined for other route server clients with the NO_EXPORT
        Well-Known Community.  This mechanism allows route server clients
        to transitively control distribution of their prefixes in other
        Autonomous Systems connected to the Internet Exchange Route Server.

      </t>
    </abstract>

    <note title="Requirements Language">
      <t>
        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
        this document are to be interpreted as described in
        <xref target="RFC2119" />.
      </t>
    </note>

  </front>

  <middle>
    <section title="Introduction">
      <t>

        Internet Exchange Route Servers <xref target="RFC7947" /> use BGP to
        broker network reachability information among their clients.  BGP
        operators often wish to control distribution of their prefixes in
        adjacent autonomous systems.  When using bilateral BGP sessions,
        prefix distribution control can be achieved using the BGP NO_EXPORT
        community defined in <xref target="RFC1997" />.

      </t>
      <t>

        <xref target="RFC1997" /> states that the NO_EXPORT community must
        not be announced outside a BGP confederation boundary, so all BGP
        speakers that strictly interpret this document will refuse to
        forward prefixes tagged with this community to a EBGP peer.

      </t>
      <t>

        Some Internet Exchange route server operators ignored the strict
        interpretation of <xref target="RFC1997" /> on this point because
        although it is technically more correct to interpret the NO_EXPORT
        community on the route server, the point of a route server is to act
        as a broker rather than a router.  Consequently it has been argued
        that it is more useful for route server clients if prefixes tagged
        with the NO_EXPORT community are passed unaltered through the route
        server rather than being blocked.  This approach gives route server
        clients the flexibility of being able to use the NO_EXPORT community
        to signal adjacent ASNs, even if this behaviour is not technically
        correct according to <xref target="RFC1997" />.

      </t>
      <t>

        As there is no consensus among IXP route server operators about
        which is the more appropriate behaviour, the Internet Exchange Route
        Server <xref target="RFC7947" /> specification document stayed quiet
        on the issue, noting only in Section 2.2.4 that a route server may
        interpret, modify or remove specific BGP communities, as defined by
        local policy.  This formally allowed the practice of treating the
        NO_EXPORT community as a transparent transitive attribute, but did
        not define whether NO_EXPORT should be interpreted or passed through
        the route server.

      </t>
      <t>

        This allowed an operational ambiguity to continue, namely that there
        was no consistent way for a route server client to limit propagation
        of any prefixes announced to a route server.

      </t>
      <t>

        This document resolves this ambiguity by creating a new BGP
        Well-Known Community called NO_EXPORT_VIA_RS, which allows BGP route
        server clients to instruct an Internet Exchange BGP Route Server to
        tag prefixes destined for other route server clients with the
        NO_EXPORT Well-Known Community.  This mechanism provides an
        unambiguous and consistent way for route server clients to
        transitively control distribution of their prefixes in other
        Autonomous Systems connected to the Internet Exchange Route Server.

      </t>
    </section>

    <section title="The BGP NO_EXPORT_VIA_RS Community" anchor="community_definition">
      <t>

        The BGP NO_EXPORT_VIA_RS Community is a community interpreted only
        by <xref target="RFC7947" /> Internet Exchange Route Servers.  If a
        route server client announces a prefix tagged with NO_EXPORT_VIA_RS
        to a route server, the route server MUST attach the <xref
        target="RFC1997" /> NO_EXPORT community to all outbound
        announcements of that prefix to other route server clients.  The
        route server SHOULD strip the NO_EXPORT_VIA_RS community from
        the outbound prefix announcement.

      </t>

      <t>

        If a route server client announces a prefix tagged with both the
        NO_EXPORT and NO_EXPORT_VIA_RS communities to a route server, the
        route server MUST ignore the NO_EXPORT community, and otherwise MUST
        handle the prefix and its attributes as specified in the previous
        paragraph.
        
      </t>

      <t>

        If a BGP speaker that is not a route server receives a prefix
        tagged with NO_EXPORT_VIA_RS from a BGP peer, the BGP speaker MUST
        ignore the NO_EXPORT_VIA_RS community, MUST NOT treat the UPDATE as
        an error according to <xref target="RFC7606" /> and SHOULD strip the
        NO_EXPORT_VIA_RS community from the prefix.

        <!--

        TODO: Need to think more carefully about this, otherwise the DFZ
        will end up full of announcements with this community attached.

        -->

      </t>

      <t>

        This document formally updates the NO_EXPORT definition in <xref
        target="RFC1997" /> and overrides the ambiguity in Section 2.2.4 of
        <xref target="RFC7947" /> in respect of this specific community.

      </t>

    </section>

    <section title="Operator Implementation Recommendations">
      <t>

        It is possible to implement the semantics described above in many
        BGP implementations by using standard BGP policy language
        statements.

<!--
        For example, this can be handled in BIRD syntax using
        the following code:
-->

<!--

Needs work:
- define "pair" variables for noexport and noexportviars
- check "interpret communities" switch
- this function needs to be split into two filters, one for ingress
  filtering (f_import_fvliid_autsys) and the other for egress (new export
  filter in protocol bgp pb_fvliid_autsys).

- ref: https://github.com/inex/IXP-Manager/blob/master/resources/views/api/v4/router/server/bird/neighbors.foil.php

-->

<!--
<figure align="center"><artwork><![CDATA[

filter f_rs_client
{
    // strip NO_EXPORT
    if (65535, 65281) ~ bgp_community then {
        bgp_community.delete((65535, 65281));
    }

    // add NO_EXPORT outbound; remove NO_EXPORT_VIA_RS outbound
    if (65535, 65285) ~ bgp_community then {
        bgp_community.add((65535, 65281));
        bgp_community.delete((65535, 65282));
    }

    accept;
}

]]></artwork></figure>

-->
        <!--

        TODO: note sure if it's advisable to provide actual code here,
        bearing in mind that this sort of stuff rots over time.

        -->

      
      </t>
      
    </section>

    <section title="Vendor Implementation Recommendations">
      <t>

        Route server implementations MUST provide a configuration switch to
        implement the behaviour specified in <xref
        target="community_definition" />.  This configuration switch SHOULD
        be enabled by default.

      </t>
    </section>

    <section title="Security Considerations">
      <t>

        The purpose of the NO_EXPORT_VIA_RS BGP Community is to control
        the NO_EXPORT Community, so there are no additional security
        considerations outside those associated with the NO_EXPORT
        community.

      </t>
      <t>

        Network administrators should note the recommendations in
        Section 11 of BGP Operations and Security <xref
        target="RFC7454" />.

      </t>
    </section>
   
    <section title="IANA Considerations">
      <t>
        IANA is requested to register NO_EXPORT_VIA_RS in the "BGP
        Well-known Communities" registry.
        
        <list>
          <t>
            NO_EXPORT_VIA_RS (= TBD) (IANA suggested: 0xFFFFFF05)
          </t>
        </list>
      </t>
    </section>

<!--
    <section title="Acknowledgments">
        <t>

            The authors would like to thank XXX for their support,
            insightful review and comments.

        </t>
    </section>
-->

  </middle>

  <back>
      <references title="Normative References">
          <?rfc include="reference.RFC.1997"?>
          <?rfc include="reference.RFC.2119"?>
<!--          <?rfc include="reference.RFC.4271"?> -->
          <?rfc include="reference.RFC.7606"?>
          <?rfc include="reference.RFC.7947"?>
      </references>
      <references title="Informative References">
          <?rfc include="reference.RFC.7454"?>
      </references>
  </back>
</rfc>
