draft-ietf-idr-ix-bgp-route-server-05.xml

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc PUBLIC '' "http://xml2rfc.tools.ietf.org/authoring/rfc2629.dtd"[
  <!ENTITY RFC1863 PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1863.xml">
  <!ENTITY RFC1997 PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml">
  <!ENTITY RFC2119 PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC4271 PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml">
  <!ENTITY RFC4360 PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml">
  <!ENTITY RFC4456 PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml">
  <!ENTITY I-D.ietf-idr-add-paths PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-add-paths.xml">
  <!ENTITY I-D.ietf-grow-diverse-bgp-path-dist PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-diverse-bgp-path-dist.xml">
]>
<?xml-stylesheet type='text/xsl' 

href="http://greenbytes.de/tech/webdav/rfc2629xslt/rfc2629.xslt" ?>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std"
     docName="draft-ietf-idr-ix-bgp-route-server-05"
     ipr="trust200902"
     obsoletes=""
     updates=""
     submissionType="IETF"
     xml:lang="en">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->
  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="IX BGP Route Server">
      Internet Exchange Route Server
    </title>

    <author initials="E" surname="Jasinska" fullname="Elisa Jasinska">
      <organization>Netflix, Inc</organization>
      <address>
        <postal>
          <street>100 Winchester Circle</street>
          <city>Los Gatos</city> 
          <region>CA</region>
          <code>95032</code>
          <country>USA</country>
        </postal>
        <email>elisa@netflix.com</email>
      </address>
    </author>
      
    <author initials="N" surname="Hilliard" fullname="Nick Hilliard">
      <organization>INEX</organization>
      <address>
        <postal>
          <street>4027 Kingswood Road</street>
          <city>Dublin</city> 
          <code>24</code>
          <country>IE</country>
        </postal>
        <email>nick@inex.ie</email>
      </address>
    </author>


    <author initials="R" surname="Raszuk" fullname="Robert Raszuk">
      <organization>NTT MCL Inc.</organization>
      <address>
        <postal>
        <street>101 S Ellsworth Avenue Suite 350</street>
        <city>San Mateo</city>
        <region>CA</region>
        <code>94401</code>
        <country>US</country>
        </postal>
        <email>robert@raszuk.net</email>
      </address>
    </author> 

    <author initials="N" surname="Bakker" fullname="Niels Bakker">
      <organization>Akamai Technologies B.V.</organization>
      <address>
        <postal>
          <street>Kingsfordweg 151</street>
          <city>Amsterdam</city>
          <code>1043 GR</code>
          <country>NL</country>
        </postal>
        <email>nbakker@akamai.com</email>
      </address>
    </author>

    <date month="June" year="2014" />
    <area>Routing</area>
    <workgroup>IDR Working Group</workgroup>
    <keyword>I-D</keyword>
    <keyword>Internet-Draft</keyword>
    <keyword>IDR</keyword>

    <abstract>
      <t>
        This document outlines a specification for multilateral
        interconnections at Internet exchange points (IXPs). Multilateral 
        interconnection is a method of exchanging routing information between 
        three or more exterior BGP speakers using a single intermediate broker
        system, referred to as a route server. Route servers are typically 
        used on shared access media networks, such as Internet exchange points
        (IXPs), to facilitate simplified interconnection between multiple 
        Internet routers.
      </t> 
    </abstract>

  </front>

  <middle>

     <section title="Introduction to Multilateral Interconnection">
      <t>
        Internet exchange points (IXPs) provide IP data interconnection
        facilities for their participants, typically using shared Layer-2
        networking media such as Ethernet. The Border Gateway Protocol (BGP)
        <xref target="RFC4271" />, an inter-Autonomous System routing
        protocol, is commonly used to facilitate exchange of network
        reachability information over such media.
      </t>
      <t>
        While
        bilateral exterior BGP sessions between exchange participants were
        previously the most common means of exchanging reachability
        information, the overhead associated with dense interconnection has
        caused substantial operational scaling problems for Internet exchange
        point participants.
      </t>
      <t>
        Multilateral interconnection is a method of interconnecting BGP
        speaking routers using a third party brokering system, commonly
        referred to as a route server and typically managed by the IXP
        operator. Each of the multilateral interconnection participants
        (usually referred to as route server clients) announces network
        reachability information to the route server using exterior BGP, and
        the route server in turn forwards this information to each other
        route server client connected to it, according to its configuration.
        Although a route server uses BGP to exchange reachability information 
        with each of its clients, it does not forward traffic itself and is 
        therefore not a router.
      </t>
      <t>
        A route server can be viewed as similar in function to an <xref
        target="RFC4456" /> route reflector, except that it operates using
        EBGP instead of iBGP. Certain adaptions to <xref target="RFC4271" /> 
        are required to enable an EBGP router to operate as a route server; 
        these are outlined in <xref target="spec" /> of this document. 
      </t>
      <t>
        The term "route server" is often in a different context used to
        describe a BGP node whose purpose is to accept BGP feeds from
        multiple clients for the purpose of operational analysis and
        troubleshooting. A system of this form may alternatively be known
        as a "route collector" or a "route-views server". This document
        uses the term "route server" exclusively to describe multilateral
        peering brokerage systems.
      </t>
      <section title="Notational Conventions">
        <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
          <xref target="RFC2119" />.
        </t>
      </section>

    </section>


    <section title="Technical Considerations for Route Server Implementations" anchor="spec">

      <section title="Client UPDATE Messages">
        <t>
          A route server MUST accept all UPDATE messages received
          from each of its clients for inclusion in its Adj-RIB-In. These
          UPDATE messages MAY be omitted from the route
          server's Loc-RIB or Loc-RIBs, due to filters configured for the
          purposes of implementing routing policy. The route server SHOULD
          perform one or more BGP Decision Processes to select routes for
          subsequent advertisement to its clients, taking into account
          possible configuration to provide multiple NLRI paths to a
          particular client as described in <xref target="multiple_paths"
          /> or multiple Loc-RIBs as described in <xref
          target="multiple_ribs" />. The route server SHOULD forward
          UPDATE messages where appropriate from its Loc-RIB or Loc-RIBs to
          its clients.
        </t>
      </section>

      <section title="Attribute Transparency">
        <t>
          As a route server primarily performs a brokering service,
          modification of attributes could cause route server clients to alter
          their BGP best path selection process for received prefix
          reachability information, thereby changing the intended routing
          policies of exchange participants. Therefore, contrary to what is
          specified in section 5. of <xref target="RFC4271" />, route servers
          SHOULD NOT by default (unless explicitly configured) update 
          well-known BGP attributes received from route server clients before
          redistributing them to their other route server clients. Optional 
          recognized and unrecognized BGP attributes, whether transitive or 
          non-transitive, SHOULD NOT be updated by the route server (unless 
          enforced by local IX operator configuration) and SHOULD be passed 
          on to other route server clients.
        </t>

        <section title="NEXT_HOP Attribute">
          <t>
            The NEXT_HOP is a well-known mandatory BGP attribute which
            defines the IP address of the router
            used as the next hop to the destinations listed in the Network
            Layer Reachability Information field of the UPDATE message. As the
            route server does not participate in the actual routing of
            traffic, the NEXT_HOP attribute MUST be passed unmodified to the
            route server clients, similar to the "third party" next hop
            feature described in section 5.1.3. of <xref target="RFC4271" />.
          </t>
        </section>

        <section title="AS_PATH Attribute" anchor="as_path_attr">
          <t>
            AS_PATH is a well-known mandatory attribute which identifies the
            autonomous systems through which routing information carried in
            the UPDATE message has passed.
          </t>
          <t>
            As a route server does not participate in the process of
            forwarding data between client routers, and because modification
            of the AS_PATH attribute could affect route server client
            best path calculations, the route server SHOULD NOT prepend
            its own AS number to the AS_PATH segment nor modify the AS_PATH
            segment in any other way.
          </t>
        </section>
 
        <section title="MULTI_EXIT_DISC Attribute">
          <t>
            MULTI_EXIT_DISC is an optional non-transitive attribute intended
            to be used on external (inter-AS) links to discriminate among
            multiple exit or entry points to the same neighboring AS.
            Contrary to section 5.1.4 of <xref target="RFC4271" />, if
            applied to an NLRI UPDATE sent to a route server, this attribute
            SHOULD be propagated to other route server clients and the route
            server SHOULD NOT modify its value.
          </t>
        </section>

        <section title="Communities Attributes">
          <t>
            The BGP COMMUNITIES (<xref target="RFC1997" />) and Extended
            Communities (<xref target="RFC4360" />) attributes are
            attributes intended for labeling information carried in 
            BGP UPDATE messages. Transitive as well as non-transitive
            Communities attributes applied to an NLRI UPDATE sent
            to a route server SHOULD NOT be modified, processed or
            removed. However, if such an attribute is intended for processing
            by the route server itself, it MAY be modified or removed.
          </t>
        </section>

       </section>

      <section title="Per-Client Policy Control in Multilateral Interconnection" anchor="policy"> 
        <t>
          While IXP participants often use route servers with the intention
          of interconnecting with as many other route server participants as
          possible, there are circumstances where control of path
          distribution on a per-client basis is important to ensure that
          desired interconnection policies are met.
        </t>
        <t>
          The control of path distribution on a per-client basis can lead to a
          path being hidden from the route server client. We refer to this as 
          "path hiding".
        </t>

        <section title="Path Hiding on a Route Server" anchor="path_hiding"> 

          <figure title="Per-Client Policy Controlled Interconnection at an IXP" anchor="ixp_policy_interconnection">
            <preamble></preamble>
            <artwork align="center">
     ___      ___
    /   \    /   \
 ..| AS1 |..| AS2 |..
:   \___/    \___/   :
:       \    / |     :
:        \  /  |     :
: IXP     \/   |     :
:         /\   |     :
:        /  \  |     :
:    ___/____\_|_    :
:   /   \    /   \   :
 ..| AS3 |..| AS4 |..
    \___/    \___/
            </artwork>
            <postamble></postamble>
          </figure>

          <t>
            Using the example in <xref target="ixp_policy_interconnection"
            />, AS1 does not directly exchange prefix information with either
            AS2 or AS3 at the IXP, but only interconnects with AS4.
          </t>
          <t> 
            In the traditional bilateral interconnection model, per-client 
            policy control to a third party exchange participant is 
            accomplished either by not engaging in a bilateral interconnection
            with that participant or else by implementing outbound filtering 
            on the BGP session towards that participant. However, in a
            multilateral interconnection environment, only the route server
            can perform outbound filtering in the direction of the
            route server client; route server clients depend on the
            route server to perform their outbound filtering for them.
          </t>
          <t>
            Assuming a traditional best path selection, when the same prefix 
            is advertised to a route server from multiple route server 
            clients, the route server will select a single best path for 
            propagation to all connected clients. If, however, the route
            server has been configured to filter the calculated best path
            from reaching a particular route server client, then that client 
            will not receive a path for that prefix, although alternate paths
            received by the route server might have been policy compliant for
            that client. This phenomenon is referred to as "path hiding".
          </t>
          <t>
            For example, in <xref target="ixp_policy_interconnection" />, if
            the same prefix were sent to the route server via AS2 and AS4, and
            the route via AS2 was preferred according to BGP's traditional
            best path selection, but AS1's policy prevents AS2's path from 
            being accepted, then AS1 would never receive a path to this 
            prefix, even though the route server had
            previously received a valid alternative path via AS4. This happens
            because the best path selection is performed only once on the
            route server for all clients.
          </t>
          <t>
            Path hiding will only occur on route servers which employ
            per-client policy control; if an IXP operator deploys a route
            server without implementing a per-client routing policy control
            system, then path hiding does not occur as all paths are
            considered equally valid from the point of view of the route
            server.
          </t>
        </section>

        <section title="Mitigation of Path Hiding" anchor="no_path_hiding"> 
        <t>
          There are several approaches which can be taken to mitigate
          against path hiding.
        </t>
          <section title="Multiple Route Server RIBs" anchor="multiple_ribs">
            <t>
              The most portable method to allow for per-client policy control
              without the occurrence of path hiding, is by using a route 
              server BGP implementation which performs the per-client best 
              path calculation for each set of paths to a prefix, which 
              results after the route server's client policies have been taken
              into consideration. This can be implemented by using per-client
              Loc-RIBs, with path filtering implemented between the Adj-RIB-In
              and the per-client Loc-RIB. Implementations MAY optimize this by
              maintaining paths not subject to filtering policies in a
              global Loc-RIB, with per-client Loc-RIBs stored as deltas.
            </t>
            <t>
              This implementation is highly portable, as it
              makes no assumptions about the feature capabilities of the route
              server clients.
            </t>
          </section>

          <section title="Advertising Multiple Paths" anchor="multiple_paths">
            <t>
              The path distribution model described above assumes standard
              BGP session encoding where the route server sends a single path
              to its client for any given prefix. This path is selected using
              the BGP path selection decision process described in <xref
              target="RFC4271" />. If, however, it were possible for the route
              server to send more than a single path to a route server client,
              then route server clients would no longer depend on receiving 
              a single best path to a particular prefix; consequently, the 
              path hiding problem described in <xref target="path_hiding" /> 
              would disappear.
            </t>
            <t>
              We present two methods which describe how such
              increased path diversity could be implemented.
            </t>

            <section title="Diverse BGP Path Approach" anchor="diverse_bgp"> 
              <t>
                The Diverse BGP Path proposal as defined in <xref
                target="I-D.ietf-grow-diverse-bgp-path-dist"></xref> is a
                simple way to distribute multiple prefix paths from a route
                server to a route server client by using a separate BGP
                session from the route server to a client
                for each different path.
              </t>
              <t>
                The number of paths which may be distributed to a client is
                constrained by the number of BGP sessions which the server and
                the client are willing to establish with each other. The
                distributed paths may be established from the global BGP
                Loc-RIB on the route server in addition to any per-client
                Loc-RIB. As there may be more potential paths to a given
                prefix than configured BGP sessions, this method is not
                guaranteed to eliminate the path hiding problem in all
                situations. Furthermore, this method may significantly
                increase the number of BGP sessions handled by the route
                server, which may negatively impact its performance.
              </t>
            </section>

            <section title="BGP ADD-PATH Approach"> 
              <t>
                The <xref target="I-D.ietf-idr-add-paths"></xref> Internet
                draft proposes a different approach to multiple path
                propagation, by allowing a BGP speaker to forward multiple
                paths for the same prefix on a single BGP session. As <xref
                target="RFC4271" /> specifies that a BGP listener must
                implement an implicit withdraw when it receives an UPDATE
                message for a prefix which already exists in its Adj-RIB-In,
                this approach requires explicit support for the feature both
                on the route server and on its clients. 
              </t>
              <t>
                If the ADD-PATH capability is negotiated bidirectionally
                between the route server and a route server client, and the
                route server client propagates multiple paths for the same
                prefix to the route server, then this could potentially cause
                the propagation of inactive, invalid or suboptimal paths to
                the route server, thereby causing loss of reachability to
                other route server clients. For this reason, ADD-PATH
                implementations on a route server SHOULD enforce send-only
                mode with the route server clients, which would result in 
                negotiating receive-only mode from the client to the route 
                server.
              </t>
            </section>
          </section>
        </section>
        <section title="Implementation Recommendations">
        <t>
          A route server SHOULD implement one of the methods described in
          <xref target="no_path_hiding" /> to allow per-client routing
          policy control without "path hiding".
        </t>
        </section>
      </section>
    </section>

    <section title="Security Considerations">
      <t>
        The path hiding problem outlined in section <xref
        target="path_hiding" /> can be used in certain circumstances to
        proactively block third party path announcements from other route
        server clients. Route server operators should be aware that
        security issues may arise unless steps are taken to mitigate against
        path hiding.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
        The new set of mechanisms for route servers does not require any new
        allocations from IANA.
      </t>
    </section>

    <section title="Acknowledgments">
      <t>
        The authors would like to thank Ryan Bickhart, Steven Bakker, Martin 
        Pels, Chris Hall, Aleksi Suhonen, Bruno Decraene, 
        Pierre Francois and Eduardo Ascenco Reis for their valuable input.
      </t>
      <t>
        In addition, the authors would like to acknowledge the developers of
        BIRD, OpenBGPD, Quagga and IOS whose BGP implementations
        include route server capabilities which are compliant with this
        document.
      </t>
      <t>
        Route server functionality was described in 1995 in <xref
        target="RFC1863" /> and modern route server implementations are
        based on concepts developed in the 1990s by the Routing Arbiter
        Project and the Route Server Next Generation Project, managed by ISI
        and Merit. Although the original RSNG code is no longer in use at
        any IXPs, the IXP community owes a debt of gratitude to the many
        people who were involved in route server development in the 1990s.
      </t>
      
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1997.xml"?> <!-- BGP Communities -->
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?> <!-- keywords -->
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"?> <!-- BGP-4 -->
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4360.xml"?> <!-- Extended Communities -->
    </references>

    <references title="Informative References">
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-idr-add-paths.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-grow-diverse-bgp-path-dist.xml"?>
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.1863.xml"?> <!-- old route server rfc -->
      <?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml"?> <!-- Route Reflector IBGP -->
    </references>
  </back>

</rfc>