One document matched: draft-ietf-idr-ix-bgp-route-server-10.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 RFC7454 PUBLIC '' "http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7454.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-10"
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>Bloomberg LP</organization>
<address>
<postal>
<street>731 Lexington Ave</street>
<city>New York City</city>
<region>NY</region>
<code>10022</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="April" year="2016" />
<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 external 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 external BGP sessions between exchange participants were
previously the most common means of exchanging reachability
information, the overhead associated with dense interconnection can
cause substantial operational scaling problems for partipants of
larger Internet exchange points.
</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 external 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.
Route server functionality is not mandatory in BGP implementations.``
</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 from its Loc-RIB or Loc-RIBs to its clients as
determined by local policy.
</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 Decision 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 IXP 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
BGP Decision Process, 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. This differs from the behaviour
specified in section 5.1.2 of <xref target="RFC4271" />, which
requires that the BGP speaker prepends its own AS number as
the last element of the AS_PATH segment.
</t>
<t>
In contrast to what is recommended in section 6.3 of <xref
target="RFC4271" />, route server clients need to be able to accept
UPDATE messages where the leftmost AS in the AS_PATH attribute is
not equal to the AS number of the route server that sent the UPDATE
message. If the route server client BGP system has implemented a
check for this, the BGP implementation MUST allow this check to be
disabled and SHOULD allow the check to be disabled on a per-peer
basis.
</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, except as defined by local policy. If a Communities
Attribute is intended for processing by the route server
itself, as determined by local policy, 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>
<t>
Neither <xref target="policy" /> nor its subsections form part of
the normative specification of this document, but are included for
information purposes only.
</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 the <xref target="RFC4271" /> BGP Decision
Process is used, when the same prefix
is advertised to a route server from multiple route server
clients, the route server will select a single 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 the BGP Decision
Process on the route server, but AS2's policy prevented the route
server from sending the path to AS1, 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 BGP Decision Process 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 can 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 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 Suggestions">
<t>
Route server implementation authors may wish to consider one of
the methods described in <xref target="no_path_hiding" /> to allow
per-client route server 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>
<t>
The AS_PATH check described in <xref target="as_path_attr" /> is normally
enabled in order to check for malformed AS paths. If this check is
disabled, the route server client loses the ability to check incoming
UPDATE messages for certain categories of problems. This could
potentially cause corrupted BGP UPDATE messages to be propagated where
they might not be propagated if the check were enabled. Regardless of
any problems relating to malformed UPDATE messages, this check is also
used to detect BGP loops, so removing the check could potentially cause
routing loops to be formed. Consequently, this check SHOULD NOT be
disabled by IXP participants unless it is needed to establish BGP
sessions with a route server, and if possible should only be disabled
for peers which are route servers.
</t>
<t>
Route server operators should carefully consider the security practices
discussed in <xref target="RFC7454" />, "BGP Operations and Security".
</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.
Note that <xref target="RFC1863" /> was 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 -->
<?rfc include="http://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC.7454.xml"?> <!-- BGP Operations and Security -->
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:08:59 |