draft-ietf-grow-ix-bgp-route-server-operations-05.txt | rfc7948.txt | |||
---|---|---|---|---|
GROW Working Group N. Hilliard | Internet Engineering Task Force (IETF) N. Hilliard | |||
Internet-Draft INEX | Request for Comments: 7948 INEX | |||
Intended status: Informational E. Jasinska | Category: Informational E. Jasinska | |||
Expires: December 10, 2015 BigWave IT | ISSN: 2070-1721 BigWave IT | |||
R. Raszuk | R. Raszuk | |||
Mirantis Inc. | Bloomberg LP | |||
N. Bakker | N. Bakker | |||
Akamai Technologies B.V. | Akamai Technologies B.V. | |||
June 8, 2015 | September 2016 | |||
Internet Exchange BGP Route Server Operations | Internet Exchange BGP Route Server Operations | |||
draft-ietf-grow-ix-bgp-route-server-operations-05 | ||||
Abstract | Abstract | |||
The popularity of Internet exchange points (IXPs) brings new | The popularity of Internet Exchange Points (IXPs) brings new | |||
challenges to interconnecting networks. While bilateral eBGP | challenges to interconnecting networks. While bilateral External BGP | |||
sessions between exchange participants were historically the most | (EBGP) sessions between exchange participants were historically the | |||
common means of exchanging reachability information over an IXP, the | most common means of exchanging reachability information over an IXP, | |||
overhead associated with this interconnection method causes serious | the overhead associated with this interconnection method causes | |||
operational and administrative scaling problems for IXP participants. | serious operational and administrative scaling problems for IXP | |||
participants. | ||||
Multilateral interconnection using Internet route servers can | Multilateral interconnection using Internet route servers can | |||
dramatically reduce the administrative and operational overhead | dramatically reduce the administrative and operational overhead | |||
associated with connecting to IXPs; in some cases, route servers are | associated with connecting to IXPs; in some cases, route servers are | |||
used by IXP participants as their preferred means of exchanging | used by IXP participants as their preferred means of exchanging | |||
routing information. | routing information. | |||
This document describes operational considerations for multilateral | This document describes operational considerations for multilateral | |||
interconnections at IXPs. | interconnections at IXPs. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This document is not an Internet Standards Track specification; it is | |||
provisions of BCP 78 and BCP 79. | published for informational purposes. | |||
Internet-Drafts are working documents of the Internet Engineering | ||||
Task Force (IETF). Note that other groups may also distribute | ||||
working documents as Internet-Drafts. The list of current Internet- | ||||
Drafts is at http://datatracker.ietf.org/drafts/current/. | ||||
Internet-Drafts are draft documents valid for a maximum of six months | This document is a product of the Internet Engineering Task Force | |||
and may be updated, replaced, or obsoleted by other documents at any | (IETF). It represents the consensus of the IETF community. It has | |||
time. It is inappropriate to use Internet-Drafts as reference | received public review and has been approved for publication by the | |||
material or to cite them other than as "work in progress." | Internet Engineering Steering Group (IESG). Not all documents | |||
approved by the IESG are a candidate for any level of Internet | ||||
Standard; see Section 2 of RFC 7841. | ||||
This Internet-Draft will expire on December 10, 2015. | Information about the current status of this document, any errata, | |||
and how to provide feedback on it may be obtained at | ||||
http://www.rfc-editor.org/info/rfc7948. | ||||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 | |||
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 | |||
2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3 | 2. Bilateral BGP Sessions . . . . . . . . . . . . . . . . . . . 3 | |||
3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4 | 3. Multilateral Interconnection . . . . . . . . . . . . . . . . 4 | |||
4. Operational Considerations for Route Server Installations . . 5 | 4. Operational Considerations for Route Server Installations . . 6 | |||
4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5 | 4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6 | 4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6 | |||
4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 7 | 4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 7 | |||
4.2.1.1. View Merging and Decomposition . . . . . . . . . 7 | 4.2.1.1. View Merging and Decomposition . . . . . . . . . 7 | |||
4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 8 | 4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 8 | |||
4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8 | 4.2.1.3. NEXT_HOP Resolution . . . . . . . . . . . . . . . 8 | |||
4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8 | 4.3. Prefix Leakage Mitigation . . . . . . . . . . . . . . . . 8 | |||
4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 9 | 4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 9 | |||
4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9 | 4.5. AS_PATH Consistency Check . . . . . . . . . . . . . . . . 9 | |||
4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 9 | 4.6. Export Routing Policies . . . . . . . . . . . . . . . . . 10 | |||
4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 10 | 4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 10 | |||
4.6.2. Internet Routing Registries . . . . . . . . . . . . . 10 | 4.6.2. Internet Routing Registries . . . . . . . . . . . . . 10 | |||
4.6.3. Client-accessible Databases . . . . . . . . . . . . . 10 | 4.6.3. Client-Accessible Databases . . . . . . . . . . . . . 10 | |||
4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 10 | 4.7. Layer 2 Reachability Problems . . . . . . . . . . . . . . 11 | |||
4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 11 | 4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 11 | |||
4.9. BGP Operations and Security . . . . . . . . . . . . . . . 13 | ||||
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 | |||
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 | 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | |||
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 | 6.1. Normative References . . . . . . . . . . . . . . . . . . 13 | |||
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 | 6.2. Informative References . . . . . . . . . . . . . . . . . 14 | |||
8.1. Normative References . . . . . . . . . . . . . . . . . . 13 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
8.2. Informative References . . . . . . . . . . . . . . . . . 14 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 | |||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 | ||||
1. Introduction | 1. Introduction | |||
Internet exchange points (IXPs) provide IP data interconnection | Internet Exchange Points (IXPs) provide IP data interconnection | |||
facilities for their participants, using data link layer protocols | facilities for their participants, using data link-layer protocols | |||
such as Ethernet. The Border Gateway Protocol (BGP) [RFC4271] is | such as Ethernet. The Border Gateway Protocol (BGP) [RFC4271] is | |||
normally used to facilitate exchange of network reachability | normally used to facilitate exchange of network reachability | |||
information over these media. | information over these media. | |||
As bilateral interconnection between IXP participants requires | As bilateral interconnection between IXP participants requires | |||
operational and administrative overhead, BGP route servers | operational and administrative overhead, BGP route servers [RFC7947] | |||
[I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP | are often deployed by IXP operators to provide a simple and | |||
operators to provide a simple and convenient means of interconnecting | convenient means of interconnecting IXP participants with each other. | |||
IXP participants with each other. A route server redistributes BGP | A route server redistributes BGP routes received from its BGP clients | |||
routes received from its BGP clients to other clients according to a | to other clients according to a prespecified policy, and it can be | |||
pre-specified policy, and it can be viewed as similar to an eBGP | viewed as similar to an EBGP equivalent of an Internal BGP (IBGP) | |||
equivalent of an iBGP [RFC4456] route reflector. | [RFC4456] route reflector. | |||
Route servers at IXPs require careful management and it is important | Route servers at IXPs require careful management, and it is important | |||
for route server operators to thoroughly understand both how they | for route server operators to thoroughly understand both how they | |||
work and what their limitations are. In this document, we discuss | work and what their limitations are. In this document, we discuss | |||
several issues of operational relevance to route server operators and | several issues of operational relevance to route server operators and | |||
provide recommendations to help route server operators provision a | provide recommendations to help route server operators provision a | |||
reliable interconnection service. | reliable interconnection service. | |||
1.1. Notational Conventions | 1.1. Notational Conventions | |||
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
skipping to change at page 3, line 45 ¶ | skipping to change at page 3, line 45 ¶ | |||
The phrase "BGP route" in this document should be interpreted as the | The phrase "BGP route" in this document should be interpreted as the | |||
term "Route" described in [RFC4271]. | term "Route" described in [RFC4271]. | |||
2. Bilateral BGP Sessions | 2. Bilateral BGP Sessions | |||
Bilateral interconnection is a method of interconnecting routers | Bilateral interconnection is a method of interconnecting routers | |||
using individual BGP sessions between each pair of participant | using individual BGP sessions between each pair of participant | |||
routers on an IXP, in order to exchange reachability information. If | routers on an IXP, in order to exchange reachability information. If | |||
an IXP participant wishes to implement an open interconnection policy | an IXP participant wishes to implement an open interconnection policy | |||
- i.e. a policy of interconnecting with as many other IXP | -- i.e., a policy of interconnecting with as many other IXP | |||
participants as possible - it is necessary for the participant to | participants as possible -- it is necessary for the participant to | |||
liaise with each of their intended interconnection partners. | liaise with each of their intended interconnection partners. | |||
Interconnection can then be implemented bilaterally by configuring a | Interconnection can then be implemented bilaterally by configuring a | |||
BGP session on both participants' routers to exchange network | BGP session on both participants' routers to exchange network | |||
reachability information. If each exchange participant interconnects | reachability information. If each exchange participant interconnects | |||
with each other participant, a full mesh of BGP sessions is needed, | with each other participant, a full mesh of BGP sessions is needed, | |||
as shown in Figure 1. | as shown in Figure 1. | |||
___ ___ | ___ ___ | |||
/ \ / \ | / \ / \ | |||
..| AS1 |..| AS2 |.. | ..| AS1 |..| AS2 |.. | |||
skipping to change at page 4, line 23 ¶ | skipping to change at page 4, line 23 ¶ | |||
: | / \ | : | : | / \ | : | |||
: _|_/____\_|_ : | : _|_/____\_|_ : | |||
: / \ / \ : | : / \ / \ : | |||
..| AS3 |..| AS4 |.. | ..| AS3 |..| AS4 |.. | |||
\___/ \___/ | \___/ \___/ | |||
Figure 1: Full-Mesh Interconnection at an IXP | Figure 1: Full-Mesh Interconnection at an IXP | |||
Figure 1 depicts an IXP platform with four connected routers, | Figure 1 depicts an IXP platform with four connected routers, | |||
administered by four separate exchange participants, each of them | administered by four separate exchange participants, each of them | |||
with a locally unique autonomous system number: AS1, AS2, AS3 and | with a locally unique Autonomous System (AS) number: AS1, AS2, AS3, | |||
AS4. The lines between the routers depict BGP sessions; the dotted | and AS4. The lines between the routers depict BGP sessions; the | |||
edge represents the IXP border. Each of these four participants | dotted edge represents the IXP border. Each of these four | |||
wishes to exchange traffic with all other participants; this is | participants wishes to exchange traffic with all other participants; | |||
accomplished by configuring a full mesh of BGP sessions on each | this is accomplished by configuring a full mesh of BGP sessions on | |||
router connected to the exchange, resulting in 6 BGP sessions across | each router connected to the exchange, resulting in six BGP sessions | |||
the IXP fabric. | across the IXP fabric. | |||
The number of BGP sessions at an exchange has an upper bound of | The number of BGP sessions at an exchange has an upper bound of | |||
n*(n-1)/2, where n is the number of routers at the exchange. As many | n*(n-1)/2, where n is the number of routers at the exchange. As many | |||
exchanges have large numbers of participating networks, the amount of | exchanges have large numbers of participating networks, the amount of | |||
administrative and operation overhead required to implement an open | administrative and operation overhead required to implement an open | |||
interconnection scales quadratically. New participants to an IXP | interconnection scales quadratically. New participants to an IXP | |||
require significant initial resourcing in order to gain value from | require significant initial resourcing in order to gain value from | |||
their IXP connection, while existing exchange participants need to | their IXP connection, while existing exchange participants need to | |||
commit ongoing resources in order to benefit from interconnecting | commit ongoing resources in order to benefit from interconnecting | |||
with these new participants. | with these new participants. | |||
3. Multilateral Interconnection | 3. Multilateral Interconnection | |||
Multilateral interconnection is implemented using a route server | Multilateral interconnection is implemented using a route server | |||
configured to distribute BGP routes among client routers. The route | configured to distribute BGP routes among client routers. The route | |||
server preserves the BGP NEXT_HOP attribute from all received BGP | server preserves the BGP NEXT_HOP attribute from all received BGP | |||
routes and passes them with unchanged NEXT_HOP to its route server | routes and passes them with unchanged NEXT_HOP to its route server | |||
clients according to its configured routing policy, as described in | clients according to its configured routing policy, as described in | |||
[I-D.ietf-idr-ix-bgp-route-server]. Using this method of exchanging | [RFC7947]. Using this method of exchanging BGP routes, an IXP | |||
BGP routes, an IXP participant router can receive an aggregated list | participant router can receive an aggregated list of BGP routes from | |||
of BGP routes from all other route server clients using a single BGP | all other route server clients using a single BGP session to the | |||
session to the route server instead of depending on BGP sessions with | route server instead of depending on BGP sessions with each router at | |||
each other router at the exchange. This reduces the overall number | the exchange. This reduces the overall number of BGP sessions at an | |||
of BGP sessions at an Internet exchange from n*(n-1)/2 to n, where n | Internet exchange from n*(n-1)/2 to n, where n is the number of | |||
is the number of routers at the exchange. | routers at the exchange. | |||
Although a route server uses BGP to exchange reachability information | Although a route server uses BGP to exchange reachability information | |||
with each of its clients, it does not forward traffic itself and is | with each of its clients, it does not forward traffic itself and is | |||
therefore not a router. | therefore not a router. | |||
In practical terms, this allows dense interconnection between IXP | In practical terms, this allows dense interconnection between IXP | |||
participants with low administrative overhead and significantly | participants with low administrative overhead and significantly | |||
simpler and smaller router configurations. In particular, new IXP | simpler and smaller router configurations. In particular, new IXP | |||
participants benefit from immediate and extensive interconnection, | participants benefit from immediate and extensive interconnection, | |||
while existing route server participants receive reachability | while existing route server participants receive reachability | |||
skipping to change at page 5, line 36 ¶ | skipping to change at page 5, line 36 ¶ | |||
: IXP / \ : | : IXP / \ : | |||
: | RS | : | : | RS | : | |||
: \____/ : | : \____/ : | |||
: / \ : | : / \ : | |||
: / \ : | : / \ : | |||
: __/ \__ : | : __/ \__ : | |||
: / \ / \ : | : / \ / \ : | |||
..| AS3 |..| AS4 |.. | ..| AS3 |..| AS4 |.. | |||
\___/ \___/ | \___/ \___/ | |||
Figure 2: IXP-based Interconnection with Route Server | Figure 2: IXP-Based Interconnection with Route Server | |||
As illustrated in Figure 2, each router on the IXP fabric requires | As illustrated in Figure 2, each router on the IXP fabric requires | |||
only a single BGP session to the route server, from which it can | only a single BGP session to the route server, from which it can | |||
receive reachability information for all other routers on the IXP | receive reachability information for all other routers on the IXP | |||
which also connect to the route server. | that also connect to the route server. | |||
Multilateral and bilateral interconnections between different | ||||
autonomous systems are not exclusive to each other, and it is not | ||||
unusual to have both sorts of sessions configured in parallel at an | ||||
IXP. This configuration will lead to additional paths being | ||||
available to the BGP Decision Process, which will calculate a best | ||||
path as normal. | ||||
4. Operational Considerations for Route Server Installations | 4. Operational Considerations for Route Server Installations | |||
4.1. Path Hiding | 4.1. Path Hiding | |||
"Path hiding" is a term used in [I-D.ietf-idr-ix-bgp-route-server] to | "Path hiding" is a term used in [RFC7947] to describe the process | |||
describe the process whereby a route server may mask individual paths | whereby a route server may mask individual paths by applying | |||
by applying conflicting routing policies to its Loc-RIB. When this | conflicting routing policies to its Loc-RIB. When this happens, | |||
happens, route server clients receive incomplete information from the | route server clients receive incomplete information from the route | |||
route server about network reachability. | server about network reachability. | |||
There are several approaches which may be used to mitigate against | There are several approaches that may be used to mitigate against the | |||
the effect of path hiding; these are described in | effect of path hiding; these are described in [RFC7947]. However, | |||
[I-D.ietf-idr-ix-bgp-route-server]. However, the only method which | the only method that does not require explicit support from the route | |||
does not require explicit support from the route server client is for | server client is for the route server itself to maintain an | |||
the route server itself to maintain a individual Loc-RIB for each | individual Loc-RIB for each client that is the subject of conflicting | |||
client which is the subject of conflicting routing policies. | routing policies. | |||
4.2. Route Server Scaling | 4.2. Route Server Scaling | |||
While deployment of multiple Loc-RIBs on the route server presents a | While deployment of multiple Loc-RIBs on the route server presents a | |||
simple way to avoid the path hiding problem noted in Section 4.1, | simple way to avoid the path-hiding problem noted in Section 4.1, | |||
this approach requires significantly more computing resources on the | this approach requires significantly more computing resources on the | |||
route server than where a single Loc-RIB is deployed for all clients. | route server than where a single Loc-RIB is deployed for all clients. | |||
As the [RFC4271] BGP decision process must be applied to all Loc-RIBs | As the BGP Decision Process [RFC4271] must be applied to all Loc-RIBs | |||
deployed on the route server, both CPU and memory requirements on the | deployed on the route server, both CPU and memory requirements on the | |||
host computer scale approximately according to O(P * N), where P is | host computer scale approximately according to O(P * N), where P is | |||
the total number of unique paths received by the route server and N | the total number of unique paths received by the route server, and N | |||
is the number of route server clients which require a unique Loc-RIB. | is the number of route server clients that require a unique Loc-RIB. | |||
As this is a super-linear scaling relationship, large route servers | As this is a super-linear scaling relationship, large route servers | |||
may derive benefit from deploying per-client Loc-RIBs only where they | may derive benefit from deploying per-client Loc-RIBs only where they | |||
are required. | are required. | |||
Regardless of whether any Loc-RIB optimization technique is | Regardless of whether any Loc-RIB optimization technique is | |||
implemented, the route server's theoretical upper-bound network | implemented, the route server's theoretical upper-bound network | |||
bandwidth requirements will scale according to O(P_tot * N), where | bandwidth requirements will scale according to O(P_tot * N), where | |||
P_tot is the total number of unique paths received by the route | P_tot is the total number of unique paths received by the route | |||
server and N is the total number of route server clients. In the | server, and N is the total number of route server clients. In the | |||
case where P_avg (the arithmetic mean number of unique paths received | case where P_avg (the arithmetic mean number of unique paths received | |||
per route server client) remains roughly constant even as the number | per route server client) remains roughly constant even as the number | |||
of connected clients increases, the total number of prefixes will | of connected clients increases, the total number of prefixes will | |||
equal the average number of prefixes multiplied by the number of | equal the average number of prefixes multiplied by the number of | |||
clients. Symbolically, this can be written as P_tot = P_avg * N. If | clients. Symbolically, this can be written as P_tot = P_avg * N. If | |||
we assume that in the worst case, each prefix is associated with a | we assume that in the worst case, each prefix is associated with a | |||
different set of BGP path attributes, so must be transmitted | different set of BGP path attributes, so must be transmitted | |||
individually, the network bandwidth scaling function can be rewritten | individually, the network bandwidth scaling function can be rewritten | |||
as O((P_avg * N) * N) or O(N^2). This quadratic upper bound on the | as O((P_avg * N) * N) or O(N^2). This quadratic upper bound on the | |||
network traffic requirements indicates that the route server model | network traffic requirements indicates that the route server model | |||
may not scale well for larger numbers of clients. | may not scale well for larger numbers of clients. | |||
In practice, most prefixes will be associated with a limited number | In practice, most prefixes will be associated with a limited number | |||
of BGP path attribute sets, allowing more efficient transmission of | of BGP path attribute sets, allowing more efficient transmission of | |||
BGP routes from the route server than the theoretical analysis | BGP routes from the route server than the theoretical analysis | |||
suggests. In the analysis above, P_tot will increase monotonically | suggests. In the analysis above, P_tot will increase monotonically | |||
according to the number of clients, but will have an upper limit of | according to the number of clients, but it will have an upper limit | |||
the size of the full default-free routing table of the network in | of the size of the full default-free routing table of the network in | |||
which the IXP is located. Observations from production route servers | which the IXP is located. Observations from production route servers | |||
have shown that most route server clients generally avoid using | have shown that most route server clients generally avoid using | |||
custom routing policies and consequently the route server may not | custom routing policies, and consequently, the route server may not | |||
need to deploy per-client Loc-RIBs. These practical bounds reduce | need to deploy per-client Loc-RIBs. These practical bounds reduce | |||
the theoretical worst-case scaling scenario to the point where route- | the theoretical worst-case scaling scenario to the point where route | |||
server deployments are manageable even on larger IXPs. | server deployments are manageable even on larger IXPs. | |||
4.2.1. Tackling Scaling Issues | 4.2.1. Tackling Scaling Issues | |||
The problem of scaling route servers still presents serious practical | The problem of scaling route servers still presents serious practical | |||
challenges and requires careful attention. Scaling analysis | challenges and requires careful attention. Scaling analysis | |||
indicates problems in three key areas: route processor CPU overhead | indicates problems in three key areas: route processor CPU overhead | |||
associated with BGP decision process calculations, the memory | associated with BGP Decision Process calculations, the memory | |||
requirements for handling many different BGP path entries, and the | requirements for handling many different BGP path entries, and the | |||
network traffic bandwidth required to distribute these BGP routes | network traffic bandwidth required to distribute these BGP routes | |||
from the route server to each route server client. | from the route server to each route server client. | |||
4.2.1.1. View Merging and Decomposition | 4.2.1.1. View Merging and Decomposition | |||
View merging and decomposition, outlined in [RS-ARCH], describes a | View merging and decomposition, outlined in [RS-ARCH], describes a | |||
method of optimising memory and CPU requirements where multiple route | method of optimizing memory and CPU requirements where multiple route | |||
server clients are subject to exactly the same routing policies. In | server clients are subject to exactly the same routing policies. In | |||
this situation, multiple Loc-RIB views can be merged into a single | this situation, multiple Loc-RIB views can be merged into a single | |||
view. | view. | |||
There are several variations of this approach. If the route server | There are several variations of this approach. If the route server | |||
operator has prior knowledge of interconnection relationships between | operator has prior knowledge of interconnection relationships between | |||
route server clients, then the operator may configure separate Loc- | route server clients, then the operator may configure separate | |||
RIBs only for route server clients with unique routing policies. As | Loc-RIBs only for route server clients with unique routing policies. | |||
this approach requires prior knowledge of interconnection | As this approach requires prior knowledge of interconnection | |||
relationships, the route server operator must depend on each client | relationships, the route server operator must depend on each client | |||
sharing their interconnection policies, either in a internal | sharing their interconnection policies either in an internal | |||
provisioning database controlled by the operator, or else in an | provisioning database controlled by the operator or in an external | |||
external data store such as an Internet Routing Registry Database. | data store such as an Internet Routing Registry Database. | |||
Conversely, the route server implementation itself may implement | Conversely, the route server implementation itself may implement | |||
internal view decomposition by creating virtual Loc-RIBs based on a | internal view decomposition by creating virtual Loc-RIBs based on a | |||
single in-memory master Loc-RIB, with delta differences for each | single in-memory master Loc-RIB, with delta differences for each | |||
prefix subject to different routing policies. This allows a more | prefix subject to different routing policies. This allows a more | |||
fine-grained and flexible approach to the problem of Loc-RIB scaling, | fine-grained and flexible approach to the problem of Loc-RIB scaling, | |||
at the expense of requiring a more complex in-memory Loc-RIB | at the expense of requiring a more complex in-memory Loc-RIB | |||
structure. | structure. | |||
Whatever method of view merging and decomposition is chosen on a | Whatever method of view merging and decomposition is chosen on a | |||
route server, pathological edge cases can be created whereby they | route server, pathological edge cases can be created whereby they | |||
will scale no better than fully non-optimised per-client Loc-RIBs. | will scale no better than fully non-optimized per-client Loc-RIBs. | |||
However, as most route server clients connect to a route server for | However, as most route server clients connect to a route server for | |||
the purposes of reducing overhead, rather than implementing complex | the purposes of reducing overhead, rather than implementing complex | |||
per-client routing policies, edge cases tend not to arise in | per-client routing policies, edge cases tend not to arise in | |||
practice. | practice. | |||
4.2.1.2. Destination Splitting | 4.2.1.2. Destination Splitting | |||
Destination splitting, also described in [RS-ARCH], describes a | Destination splitting, also described in [RS-ARCH], describes a | |||
method for route server clients to connect to multiple route servers | method for route server clients to connect to multiple route servers | |||
and to send non-overlapping sets of prefixes to each route server. | and to send non-overlapping sets of prefixes to each route server. | |||
As each route server computes the best path for its own set of | As each route server computes the best path for its own set of | |||
prefixes, the quadratic scaling requirement operates on multiple | prefixes, the quadratic scaling requirement operates on multiple | |||
smaller sets of prefixes. This reduces the overall computational and | smaller sets of prefixes. This reduces the overall computational and | |||
memory requirements for managing multiple Loc-RIBs and performing the | memory requirements for managing multiple Loc-RIBs and performing the | |||
best-path calculation on each. | best-path calculation on each. | |||
In practice, the route server operator would need all route server | In practice, the route server operator would need all route server | |||
clients to send a full set of BGP routes to each route server. The | clients to send a full set of BGP routes to each route server. The | |||
route server operator could then selectively filter these prefixes | route server operator could then selectively filter these prefixes | |||
for each route server by using either BGP Outbound Route Filtering | for each route server by using either BGP Outbound Route Filtering | |||
[RFC5291] or else inbound prefix filters configured on client BGP | [RFC5291] or inbound prefix filters configured on client BGP | |||
sessions. | sessions. | |||
4.2.1.3. NEXT_HOP Resolution | 4.2.1.3. NEXT_HOP Resolution | |||
As route servers are usually deployed at IXPs where all connected | As route servers are usually deployed at IXPs where all connected | |||
routers are on the same layer 2 broadcast domain, recursive | routers are on the same Layer 2 broadcast domain, recursive | |||
resolution of the NEXT_HOP attribute is generally not required, and | resolution of the NEXT_HOP attribute is generally not required and | |||
can be replaced by a simple check to ensure that the NEXT_HOP value | can be replaced by a simple check to ensure that the NEXT_HOP value | |||
for each received BGP route is a network address on the IXP LAN's IP | for each received BGP route is a network address on the IXP LAN's IP | |||
address range. | address range. | |||
4.3. Prefix Leakage Mitigation | 4.3. Prefix Leakage Mitigation | |||
Prefix leakage occurs when a BGP client unintentionally distributes | Prefix leakage occurs when a BGP client unintentionally distributes | |||
BGP routes to one or more neighboring BGP routers. Prefix leakage of | BGP routes to one or more neighboring BGP routers. Prefix leakage of | |||
this form to a route server can cause serious connectivity problems | this form to a route server can cause serious connectivity problems | |||
at an IXP if each route server client is configured to accept all BGP | at an IXP if each route server client is configured to accept all BGP | |||
routes from the route server. It is therefore RECOMMENDED when | routes from the route server. It is therefore RECOMMENDED when | |||
deploying route servers that, due to the potential for collateral | deploying route servers that, due to the potential for collateral | |||
damage caused by BGP route leakage, route server operators deploy | damage caused by BGP route leakage, route server operators deploy | |||
prefix leakage mitigation measures in order to prevent unintentional | prefix leakage mitigation measures in order to prevent unintentional | |||
prefix announcements or else limit the scale of any such leak. | prefix announcements or else limit the scale of any such leak. | |||
Although not foolproof, per-client inbound prefix limits can restrict | Although not foolproof, per-client inbound prefix limits can restrict | |||
the damage caused by prefix leakage in many cases. Per-client | the damage caused by prefix leakage in many cases. Per-client | |||
inbound prefix filtering on the route server is a more deterministic | inbound prefix filtering on the route server is a more deterministic | |||
and usually more reliable means of preventing prefix leakage, but | and usually more reliable means of preventing prefix leakage but | |||
requires more administrative resources to maintain properly. | requires more administrative resources to maintain properly. | |||
If a route server operator implements per-client inbound prefix | If a route server operator implements per-client inbound prefix | |||
filtering, then it is RECOMMENDED that the operator also builds in | filtering, then it is RECOMMENDED that the operator also builds in | |||
mechanisms to automatically compare the Adj-RIB-In received from each | mechanisms to automatically compare the Adj-RIB-In received from each | |||
client with the inbound prefix lists configured for those clients. | client with the inbound prefix lists configured for those clients. | |||
Naturally, it is the responsibility of the route server client to | Naturally, it is the responsibility of the route server client to | |||
ensure that their stated prefix list is compatible with what they | ensure that their stated prefix list is compatible with what they | |||
announce to an IXP route server. However, many network operators do | announce to an IXP route server. However, many network operators do | |||
not carefully manage their published routing policies and it is not | not carefully manage their published routing policies, and it is not | |||
uncommon to see significant variation between the two sets of | uncommon to see significant variation between the two sets of | |||
prefixes. Route server operator visibility into this discrepancy can | prefixes. Route server operator visibility into this discrepancy can | |||
provide significant advantages to both operator and client. | provide significant advantages to both operator and client. | |||
4.4. Route Server Redundancy | 4.4. Route Server Redundancy | |||
As the purpose of an IXP route server implementation is to provide a | As the purpose of an IXP route server implementation is to provide a | |||
reliable reachability brokerage service, it is RECOMMENDED that | reliable reachability brokerage service, it is RECOMMENDED that | |||
exchange operators who implement route server systems provision | exchange operators who implement route server systems provision | |||
multiple route servers on each shared Layer-2 domain. There is no | multiple route servers on each shared Layer 2 domain. There is no | |||
requirement to use the same BGP implementation or operating system | requirement to use the same BGP implementation or operating system | |||
for each route server on the IXP fabric; however, it is RECOMMENDED | for each route server on the IXP fabric; however, it is RECOMMENDED | |||
that where an operator provisions more than a single server on the | that where an operator provisions more than a single server on the | |||
same shared Layer-2 domain, each route server implementation be | same shared Layer 2 domain, each route server implementation be | |||
configured equivalently and in such a manner that the path | configured equivalently and in such a manner that the path | |||
reachability information from each system is identical. | reachability information from each system is identical. | |||
4.5. AS_PATH Consistency Check | 4.5. AS_PATH Consistency Check | |||
[RFC4271] requires that every BGP speaker which advertises a BGP | [RFC4271] requires that every BGP speaker that advertises a BGP route | |||
route to another external BGP speaker prepends its own AS number as | to another external BGP speaker prepends its own AS number as the | |||
the last element of the AS_PATH sequence. Therefore the leftmost AS | last element of the AS_PATH sequence. Therefore, the leftmost AS in | |||
in an AS_PATH attribute should be equal to the autonomous system | an AS_PATH attribute should be equal to the AS number of the BGP | |||
number of the BGP speaker which sent the BGP route. | speaker that sent the BGP route. | |||
As [I-D.ietf-idr-ix-bgp-route-server] suggests that route servers | As [RFC7947] suggests that route servers should not modify the | |||
should not modify the AS_PATH attribute, a consistency check on the | AS_PATH attribute, a consistency check on the AS_PATH of a BGP route | |||
AS_PATH of an BGP route received by a route server client would | received by a route server client would normally fail. It is | |||
normally fail. It is therefore RECOMMENDED that route server clients | therefore RECOMMENDED that route server clients disable the AS_PATH | |||
disable the AS_PATH consistency check towards the route server. | consistency check towards the route server. | |||
4.6. Export Routing Policies | 4.6. Export Routing Policies | |||
Policy filtering is commonly implemented on route servers to provide | Policy filtering is commonly implemented on route servers to provide | |||
prefix distribution control mechanisms for route server clients. A | prefix distribution control mechanisms for route server clients. A | |||
route server "export" policy is a policy which affects prefixes sent | route server "export" policy is a policy that affects prefixes sent | |||
from the route server to a route server client. Several different | from the route server to a route server client. Several different | |||
strategies are commonly used for implementing route server export | strategies are commonly used for implementing route server export | |||
policies. | policies. | |||
4.6.1. BGP Communities | 4.6.1. BGP Communities | |||
Prefixes sent to the route server are tagged with specific standard | Prefixes sent to the route server are tagged with specific standard | |||
[RFC1997] or extended [RFC4360] BGP community attributes, based on | BGP Communities [RFC1997] or Extended Communities [RFC4360] | |||
pre-defined values agreed between the operator and all clients. | attributes, based on predefined values agreed between the operator | |||
Based on these community tags, BGP routes may be propagated to all | and all clients. Based on these Communities values, BGP routes may | |||
other clients, a subset of clients, or none. This mechanism allows | be propagated to all other clients, a subset of clients, or none. | |||
route server clients to instruct the route server to implement per- | This mechanism allows route server clients to instruct the route | |||
client export routing policies. | server to implement per-client export routing policies. | |||
As both standard and extended BGP community values are currently | As both standard BGP Communities and Extended Communities values are | |||
restricted to 6 octets or fewer, it is not possible for both the | restricted to 6 octets or fewer, it is not possible for both the | |||
global and local administrator fields in the BGP community to fit a | global and local administrator fields in the BGP Communities value to | |||
4-octet autonomous system number. Bearing this in mind, the route | fit a 4-octet AS number. Bearing this in mind, the route server | |||
server operator SHOULD take care to ensure that the predefined BGP | operator SHOULD take care to ensure that the predefined BGP | |||
community values mechanism used on their route server is compatible | Communities values mechanism used on their route server is compatible | |||
with [RFC4893] 4-octet ASNs. | with 4-octet AS numbers [RFC6793]. | |||
4.6.2. Internet Routing Registries | 4.6.2. Internet Routing Registries | |||
Internet Routing Registry databases (IRRDBs) may be used by route | Internet Routing Registry databases (IRRDBs) may be used by route | |||
server operators to construct per-client routing policies. [RFC2622] | server operators to construct per-client routing policies. "Routing | |||
Routing Policy Specification Language (RPSL) provides an | Policy Specification Language (RPSL)" [RFC2622] provides a | |||
comprehensive grammar for describing interconnection relationships, | comprehensive grammar for describing interconnection relationships, | |||
and several toolsets exist which can be used to translate RPSL policy | and several toolsets exist that can be used to translate RPSL policy | |||
description into route server configurations. | description into route server configurations. | |||
4.6.3. Client-accessible Databases | 4.6.3. Client-Accessible Databases | |||
Should the route server operator not wish to use either BGP community | Should the route server operator not wish to use either BGP | |||
tags or the public IRRDBs for implementing client export policies, | Communities or the public IRRDBs for implementing client export | |||
they may implement their own routing policy database system for | policies, they may implement their own routing policy database system | |||
managing their clients' requirements. A database of this form SHOULD | for managing their clients' requirements. A database of this form | |||
allow a route server client operator to update their routing policy | SHOULD allow a route server client operator to update their routing | |||
and provide a mechanism for allowing the client to specify whether | policy and provide a mechanism for allowing the client to specify | |||
they wish to exchange all their prefixes with any other route server | whether they wish to exchange all their prefixes with any other route | |||
client. Optionally, the implementation may allow a client to specify | server client. Optionally, the implementation may allow a client to | |||
unique routing policies for individual prefixes over which they have | specify unique routing policies for individual prefixes over which | |||
routing policy control. | they have routing policy control. | |||
4.7. Layer 2 Reachability Problems | 4.7. Layer 2 Reachability Problems | |||
Layer 2 reachability problems on an IXP can cause serious operational | Layer 2 reachability problems on an IXP can cause serious operational | |||
problems for IXP participants which depend on route servers for | problems for IXP participants that depend on route servers for | |||
interconnection. Ethernet switch forwarding bugs have occasionally | interconnection. Ethernet switch forwarding bugs have occasionally | |||
been observed to cause non-transitive reachability. For example, | been observed to cause non-transitive reachability. For example, | |||
given a route server and two IXP participants, A and B, if the two | given a route server and two IXP participants, A and B, if the two | |||
participants can reach the route server but cannot reach each other, | participants can reach the route server but cannot reach each other, | |||
then traffic between the participants may be dropped until such time | then traffic between the participants may be dropped until such time | |||
as the layer 2 forwarding problem is resolved. This situation does | as the Layer 2 forwarding problem is resolved. This situation does | |||
not tend to occur in bilateral interconnection arrangements, as the | not tend to occur in bilateral interconnection arrangements, as the | |||
routing control path between the two hosts is usually (but not | routing control path between the two hosts is usually (but not | |||
always, due to IXP inter-switch connectivity load balancing | always, due to IXP inter-switch connectivity load-balancing | |||
algorithms) the same as the data path between them. | algorithms) the same as the data path between them. | |||
Problems of this form can be partially mitigated by using [RFC5881] | Problems of this form can be partially mitigated by using | |||
bidirectional forwarding detection. However, as this is a bilateral | Bidirectional Forwarding Detection (BFD) [RFC5881]. However, as this | |||
protocol configured between routers, and as there is currently no | is a bilateral protocol configured between routers, and as there is | |||
protocol to automatically configure BFD sessions between route server | currently no protocol to automatically configure BFD sessions between | |||
clients, BFD does not currently provide an optimal means of handling | route server clients, BFD does not currently provide an optimal means | |||
the problem. Even if automatic BFD session configuration were | of handling the problem. Even if automatic BFD session configuration | |||
possible, practical problems would remain. If two IXP route server | were possible, practical problems would remain. If two IXP route | |||
clients were configured to run BFD between each other and the | server clients were configured to run BFD between each other and the | |||
protocol detected a non-transitive loss of reachability between them, | protocol detected a non-transitive loss of reachability between them, | |||
each of those routers would internally mark the other's prefixes as | each of those routers would internally mark the other's prefixes as | |||
unreachable via the BGP path announced by the route server. As the | unreachable via the BGP path announced by the route server. As the | |||
route server only propagates a single best path to each client, this | route server only propagates a single best path to each client, this | |||
could cause either sub-optimal routing or complete connectivity loss | could cause either sub-optimal routing or complete connectivity loss | |||
if there were no alternative paths learned from other BGP sessions. | if there were no alternative paths learned from other BGP sessions. | |||
4.8. BGP NEXT_HOP Hijacking | 4.8. BGP NEXT_HOP Hijacking | |||
Section 5.1.3(2) of [RFC4271] allows eBGP speakers to change the | Item 2 in Section 5.1.3 of [RFC4271] allows EBGP speakers to change | |||
NEXT_HOP address of a received BGP route to be a different internet | the NEXT_HOP address of a received BGP route to be a different | |||
address on the same subnet. This is the mechanism which allows route | Internet address on the same subnet. This is the mechanism that | |||
servers to operate on a shared layer 2 IXP network. However, the | allows route servers to operate on a shared Layer 2 IXP network. | |||
mechanism can be abused by route server clients to redirect traffic | However, the mechanism can be abused by route server clients to | |||
for their prefixes to other IXP participant routers. | redirect traffic for their prefixes to other IXP participant routers. | |||
____ | ____ | |||
/ \ | / \ | |||
| AS99 | | | AS99 | | |||
\____/ | \____/ | |||
/ \ | / \ | |||
/ \ | / \ | |||
__/ \__ | __/ \__ | |||
/ \ / \ | / \ / \ | |||
..| AS1 |..| AS2 |.. | ..| AS1 |..| AS2 |.. | |||
: \___/ \___/ : | : \___/ \___/ : | |||
: \ / : | : \ / : | |||
: \ / : | : \ / : | |||
: \__/ : | : \__/ : | |||
: IXP / \ : | : IXP / \ : | |||
: | RS | : | : | RS | : | |||
: \____/ : | : \____/ : | |||
: : | : : | |||
.................... | .................... | |||
Figure 3: BGP NEXT_HOP Hijacking using a Route Server | Figure 3: BGP NEXT_HOP Hijacking Using a Route Server | |||
For example in Figure 3, if AS1 and AS2 both announce BGP routes for | For example, in Figure 3, if AS1 and AS2 both announce BGP routes for | |||
AS99 to the route server, AS1 could set the NEXT_HOP address for | AS99 to the route server, AS1 could set the NEXT_HOP address for | |||
AS99's routes to be the address of AS2's router, thereby diverting | AS99's routes to be the address of AS2's router, thereby diverting | |||
traffic for AS99 via AS2. This may override the routing policies of | traffic for AS99 via AS2. This may override the routing policies of | |||
AS99 and AS2. | AS99 and AS2. | |||
Worse still, if the route server operator does not use inbound prefix | Worse still, if the route server operator does not use inbound prefix | |||
filtering, AS1 could announce any arbitrary prefix to the route | filtering, AS1 could announce any arbitrary prefix to the route | |||
server with a NEXT_HOP address of any other IXP participant. This | server with a NEXT_HOP address of any other IXP participant. This | |||
could be used as a denial of service mechanism against either the | could be used as a denial-of-service mechanism against either the | |||
users of the address space being announced by illicitly diverting | users of the address space being announced by illicitly diverting | |||
their traffic, or the other IXP participant by overloading their | their traffic or the other IXP participant by overloading their | |||
network with traffic which would not normally be sent there. | network with traffic that would not normally be sent there. | |||
This problem is not specific to route servers and it can also be | This problem is not specific to route servers, and it can also be | |||
implemented using bilateral BGP sessions. However, the potential | implemented using bilateral BGP sessions. However, the potential | |||
damage is amplified by route servers because a single BGP session can | damage is amplified by route servers because a single BGP session can | |||
be used to affect many networks simultaneously. | be used to affect many networks simultaneously. | |||
Because route server clients cannot easily implement next-hop policy | Because route server clients cannot easily implement next-hop policy | |||
checks against route server BGP sessions, route server operators | checks against route server BGP sessions, route server operators | |||
SHOULD check that the BGP NEXT_HOP attribute for BGP routes received | SHOULD check that the BGP NEXT_HOP attribute for BGP routes received | |||
from a route server client matches the interface address of the | from a route server client matches the interface address of the | |||
client. If the route server receives an BGP route where these | client. If the route server receives a BGP route where these | |||
addresses are different and where the announcing route server client | addresses are different and where the announcing route server client | |||
is in a different autonomous system to the route server client which | is in a different AS to the route server client that uses the next- | |||
uses the next hop address, the BGP route SHOULD be dropped. | hop address, the BGP route SHOULD be dropped. Permitting next-hop | |||
rewriting for the same AS allows an organization with multiple | ||||
connections into an IXP configured with different IP addresses to | ||||
direct traffic off the IXP infrastructure through any of their | ||||
connections for traffic engineering or other purposes. | ||||
Permitting next-hop rewriting for the same autonomous system allows | 4.9. BGP Operations and Security | |||
an organisation with multiple connections into an IXP configured with | ||||
different IP addresses to direct traffic off the IXP infrastructure | BGP route servers SHOULD be configured and operated in compliance | |||
through any of their connections for traffic engineering or other | with [RFC7454] with the exception of Section 11, "BGP Community | |||
purposes. | Scrubbing", which may not necessarily apply on a route server, | |||
depending on the route server operator policy. | ||||
5. Security Considerations | 5. Security Considerations | |||
On route server installations which do not employ path hiding | On route server installations that do not employ path-hiding | |||
mitigation techniques, the path hiding problem outlined in | mitigation techniques, the path-hiding problem outlined in | |||
Section 4.1 could be used by an IXP participant to prevent the route | Section 4.1 could be used by an IXP participant to prevent the route | |||
server from sending any BGP routes for a particular prefix to other | server from sending any BGP routes for a particular prefix to other | |||
route server clients, even if there were a valid path to that | route server clients, even if there was a valid path to that | |||
destination via another route server client. | destination via another route server client. | |||
If the route server operator does not implement prefix leakage | If the route server operator does not implement prefix leakage | |||
mitigation as described in Section 4.3, it is trivial for route | mitigation as described in Section 4.3, it is trivial for route | |||
server clients to implement denial of service attacks against | server clients to implement denial-of-service attacks against | |||
arbitrary Internet networks by leaking BGP routes to a route server. | arbitrary Internet networks by leaking BGP routes to a route server. | |||
Route server installations SHOULD be secured against BGP NEXT_HOP | Route server installations SHOULD be secured against BGP NEXT_HOP | |||
hijacking, as described in Section 4.8. | hijacking, as described in Section 4.8. | |||
6. IANA Considerations | 6. References | |||
There are no IANA considerations. | ||||
7. Acknowledgments | ||||
The authors would like to thank Chris Hall, Ryan Bickhart, Steven | ||||
Bakker and Eduardo Ascenco Reis for their valuable input. | ||||
8. References | ||||
8.1. Normative References | ||||
[I-D.ietf-idr-ix-bgp-route-server] | 6.1. Normative References | |||
Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, | ||||
"Internet Exchange Route Server", draft-ietf-idr-ix-bgp- | ||||
route-server-06 (work in progress), December 2014. | ||||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | ||||
<http://www.rfc-editor.org/info/rfc2119>. | ||||
8.2. Informative References | [RFC7947] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, | |||
"Internet Exchange BGP Route Server", RFC 7947, | ||||
DOI 10.17487/RFC7947, September 2016, | ||||
<http://www.rfc-editor.org/info/rfc7947>. | ||||
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP | 6.2. Informative References | |||
Communities Attribute", RFC 1997, August 1996. | ||||
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities | ||||
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, | ||||
<http://www.rfc-editor.org/info/rfc1997>. | ||||
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., | [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., | |||
Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, | Meyer, D., Bates, T., Karrenberg, D., and M. Terpstra, | |||
"Routing Policy Specification Language (RPSL)", RFC 2622, | "Routing Policy Specification Language (RPSL)", RFC 2622, | |||
June 1999. | DOI 10.17487/RFC2622, June 1999, | |||
<http://www.rfc-editor.org/info/rfc2622>. | ||||
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway | [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A | |||
Protocol 4 (BGP-4)", RFC 4271, January 2006. | Border Gateway Protocol 4 (BGP-4)", RFC 4271, | |||
DOI 10.17487/RFC4271, January 2006, | ||||
<http://www.rfc-editor.org/info/rfc4271>. | ||||
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended | |||
Communities Attribute", RFC 4360, February 2006. | Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, | |||
February 2006, <http://www.rfc-editor.org/info/rfc4360>. | ||||
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route | [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route | |||
Reflection: An Alternative to Full Mesh Internal BGP | Reflection: An Alternative to Full Mesh Internal BGP | |||
(IBGP)", RFC 4456, April 2006. | (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, | |||
<http://www.rfc-editor.org/info/rfc4456>. | ||||
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS | ||||
Number Space", RFC 4893, May 2007. | ||||
[RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering | [RFC5291] Chen, E. and Y. Rekhter, "Outbound Route Filtering | |||
Capability for BGP-4", RFC 5291, August 2008. | Capability for BGP-4", RFC 5291, DOI 10.17487/RFC5291, | |||
August 2008, <http://www.rfc-editor.org/info/rfc5291>. | ||||
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection | |||
(BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, June | (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, | |||
2010. | DOI 10.17487/RFC5881, June 2010, | |||
<http://www.rfc-editor.org/info/rfc5881>. | ||||
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet | ||||
Autonomous System (AS) Number Space", RFC 6793, | ||||
DOI 10.17487/RFC6793, December 2012, | ||||
<http://www.rfc-editor.org/info/rfc6793>. | ||||
[RFC7454] Durand, J., Pepelnjak, I., and G. Doering, "BGP Operations | ||||
and Security", BCP 194, RFC 7454, DOI 10.17487/RFC7454, | ||||
February 2015, <http://www.rfc-editor.org/info/rfc7454>. | ||||
[RS-ARCH] Govindan, R., Alaettinoglu, C., Varadhan, K., and D. | [RS-ARCH] Govindan, R., Alaettinoglu, C., Varadhan, K., and D. | |||
Estrin, "A Route Server Architecture for Inter-Domain | Estrin, "A Route Server Architecture for Inter-Domain | |||
Routing", 1995, | Routing", 1995, | |||
<http://www.cs.usc.edu/assets/003/83191.pdf>. | <http://www.cs.usc.edu/assets/003/83191.pdf>. | |||
Acknowledgments | ||||
The authors would like to thank Chris Hall, Ryan Bickhart, Steven | ||||
Bakker, and Eduardo Ascenco Reis for their valuable input. | ||||
Authors' Addresses | Authors' Addresses | |||
Nick Hilliard | Nick Hilliard | |||
INEX | INEX | |||
4027 Kingswood Road | 4027 Kingswood Road | |||
Dublin 24 | Dublin 24 | |||
IE | Ireland | |||
Email: nick@inex.ie | Email: nick@inex.ie | |||
Elisa Jasinska | Elisa Jasinska | |||
BigWave IT | BigWave IT | |||
ul. Skawinska 27/7 | ul. Skawinska 27/7 | |||
Krakow, MP 31-066 | Krakow, MP 31-066 | |||
Poland | Poland | |||
Email: elisa@bigwaveit.org | Email: elisa@bigwaveit.org | |||
Robert Raszuk | Robert Raszuk | |||
Mirantis Inc. | Bloomberg LP | |||
615 National Ave. #100 | 731 Lexington Ave. | |||
Mt View, CA 94043 | New York, NY 10022 | |||
USA | United States of America | |||
Email: robert@raszuk.net | Email: robert@raszuk.net | |||
Niels Bakker | Niels Bakker | |||
Akamai Technologies B.V. | Akamai Technologies B.V. | |||
Kingsfordweg 151 | Kingsfordweg 151 | |||
Amsterdam 1043 GR | Amsterdam 1043 GR | |||
NL | Netherlands | |||
Email: nbakker@akamai.com | Email: nbakker@akamai.com | |||
End of changes. 85 change blocks. | ||||
211 lines changed or deleted | 234 lines changed or added | |||
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |