One document matched: draft-ietf-idr-ix-bgp-route-server-08.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 RFC6774 PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.6774.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">
]>
<?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-08"
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="IXP BGP Route Server">
Internet Exchange BGP Route Server
</title>
<author initials="E" surname="Jasinska" fullname="Elisa Jasinska">
<organization>BigWave IT</organization>
<address>
<postal>
<street>ul. Skawinska 27/7</street>
<city>Krakow</city>
<region>MP</region>
<code>31-066</code>
<country>Poland</country>
</postal>
<email>elisa@bigwaveit.org</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 fullname='Robert Raszuk' initials='R' surname='Raszuk'>
<organization>Mirantis Inc.</organization>
<address>
<postal>
<street>615 National Ave. #100</street>
<city>Mt View</city>
<region>CA</region>
<code>94043</code>
<country>USA</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="August" year="2015" />
<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="RFC6774"></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.
Please note that <xref target="RFC1863" /> has been made historical
by <xref target="RFC4223" />.
</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/bibxml/reference.RFC.6774.xml"?> <!-- diverse paths -->
<?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.4223.xml"?> <!-- RFC 1863 to Historic -->
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.4456.xml"?> <!-- Route Reflector IBGP -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 21:50:01 |