draft-jasinska-ix-bgp-route-server-02.xml

<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/rfc2629.dtd"[
  <!ENTITY RFC1997 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1997.xml">
  <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
  <!ENTITY RFC4271 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4271.xml">
  <!ENTITY RFC4360 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4360.xml">
  <!ENTITY RFC4456 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4456.xml">
  <!ENTITY I-D.ietf-idr-add-paths PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-add-paths.xml">
  <!ENTITY I-D.ietf-grow-diverse-bgp-path-dist PUBLIC '' "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-grow-diverse-bgp-path-dist.xml">
  <!ENTITY RFC1863 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1863.xml">
  <!ENTITY RFC4223 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4223.xml">
  <!ENTITY RFC4760 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml">
  <!ENTITY RFC5065 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5065.xml">
  <!ENTITY RFC5226 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5226.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-jasinska-ix-bgp-route-server-02"
     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>Limelight Networks</organization>
      <address>
        <postal>
          <street>2220 W 14th St</street>
          <city>Tempe</city> 
          <region>AZ</region>
          <code>85281</code>
          <country>US</country>
        </postal>
        <email>elisa@llnw.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>Cisco Systems</organization>
      <address>
        <postal>
          <street>170 West Tasman Drive</street>
          <city>San Jose</city> 
          <region>CA</region>
          <code>95134</code>
          <country>US</country>
        </postal>
        <email>raszuk@cisco.com</email>
      </address>
    </author>

    <author initials="N" surname="Bakker" fullname="Niels Bakker">
      <organization>AMS-IX B.V.</organization>
      <address>
        <postal>
          <street>Westeinde 12</street>
          <city>Amsterdam</city> 
          <region>NH</region>
          <code>1017 ZN</code>
          <country>NL</country>
        </postal>
        <email>niels.bakker@ams-ix.net</email>
      </address>
    </author>

    <date month="March" year="2011" />
    <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, which 
        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="Specification of Requirements">
        <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 by 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 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 and SHOULD be passed on to other route server 
          clients.
        </t>

        <section title="NEXT_HOP Attribute">
          <t>
            The NEXT_HOP, a well-known mandatory BGP attribute, 
            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. If
            applied to an NLRI UPDATE sent to a route server, the attribute
            (contrary to section 5.1.4 of <xref target="RFC4271" />) SHOULD
            be propagated to other route server clients and the route server 
            SHOULD NOT modify the value of this attribute.
          </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 for ensuring 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", which is described in <xref target="path_hiding" />.
        </t>
        <t>
          Route server implementations SHOULD implement one of the methods described 
          in <xref target="no_path_hiding" />, for the operator to be able to 
          allow the control of path distribution on a per-client basis 
          without the occurrence of "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 the possibility for policy control, 
            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="Implementing Per-Client Policy Control" anchor="no_path_hiding"> 
        <t>
          In this section, we describe the alternatives to provide per-client policy 
          control while preventing the occurrence of path hiding.
        </t>
          <section title="Multiple Route Server RIBs" anchor="multiple_ribs">
            <t>
              The most portable means 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>
    </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.
      </t>
    </section>

    <section title="IANA Considerations">
      <t>
        The new set of mechanism 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, Chris Hall, 
        Bruno Decraene and Pierre Francois for their valuable input.
      </t>
      <t>
        In addition, the authors would like to acknowledge the developers of
        BIRD, OpenBGPD and Quagga, whose open source BGP implementations
        include route server capabilities which are compliant with this
        document.
      </t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.1997"?> <!-- BGP Communities -->
      <?rfc include="reference.RFC.2119"?> <!-- key words -->
      <?rfc include="reference.RFC.4271"?> <!-- BGP-4 -->
      <?rfc include="reference.RFC.4360"?> <!-- Extendend Communities -->
      <?rfc include="reference.RFC.4456"?> <!-- Route Reflector IBGP -->
      <?rfc include="reference.I-D.ietf-idr-add-paths"?>
      <?rfc include="reference.I-D.ietf-grow-diverse-bgp-path-dist"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.1863"?> <!-- old route server rfc -->
      <?rfc include="reference.RFC.4223"?> <!-- Reclassification of old route server RFC 1863 -->
      <?rfc include="reference.RFC.4760"?> <!-- BGP-4 MP ext -->
      <?rfc include="reference.RFC.5065"?> <!-- BGP confederations -->
      <?rfc include="reference.RFC.5226"?> <!-- IANA Considerations Section Guidelines -->
    </references>
  </back>

</rfc>