draft-ietf-grow-ix-bgp-route-server-operations-01.txt   draft-ietf-grow-ix-bgp-route-server-operations-02.txt 
GROW Working Group N. Hilliard GROW Working Group N. Hilliard
Internet-Draft INEX Internet-Draft INEX
Intended status: Informational E. Jasinska Intended status: Informational E. Jasinska
Expires: March 01, 2014 Microsoft Corporation Expires: September 4, 2014 Netflix, Inc
R. Raszuk R. Raszuk
NTT I3 NTT I3
N. Bakker N. Bakker
AMS-IX B.V. Akamai Technologies B.V.
August 28, 2013 March 3, 2014
Internet Exchange Route Server Operations Internet Exchange Route Server Operations
draft-ietf-grow-ix-bgp-route-server-operations-01 draft-ietf-grow-ix-bgp-route-server-operations-02
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 eBGP
sessions between exchange participants were historically the most sessions between exchange participants were historically the most
common means of exchanging reachability information over an IXP, the common means of exchanging reachability information over an IXP, the
overhead associated with this interconnection method causes serious overhead associated with this interconnection method causes serious
operational and administrative scaling problems for IXP participants. operational and administrative scaling problems for IXP participants.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 01, 2014. This Internet-Draft will expire on September 4, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . 5
4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. Path Hiding . . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6 4.2. Route Server Scaling . . . . . . . . . . . . . . . . . . 6
4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 6 4.2.1. Tackling Scaling Issues . . . . . . . . . . . . . . . 6
4.2.1.1. View Merging and Decomposition . . . . . . . . . 7 4.2.1.1. View Merging and Decomposition . . . . . . . . . 7
4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 7 4.2.1.2. Destination Splitting . . . . . . . . . . . . . . 7
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 . . . . . . . . . . . . . . . . . 8 4.4. Route Server Redundancy . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . 9
4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9 4.6.1. BGP Communities . . . . . . . . . . . . . . . . . . . 9
4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9 4.6.2. Internet Routing Registry . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . 10
4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 10 4.8. BGP NEXT_HOP Hijacking . . . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
Internet exchange points (IXPs) provide IP data interconnection Internet exchange points (IXPs) provide IP data interconnection
facilities for their participants, typically using shared Layer-2 facilities for their participants, typically using shared Layer-2
networking media such as Ethernet. The Border Gateway Protocol (BGP) networking media such as Ethernet. The Border Gateway Protocol (BGP)
[RFC4271] is normally used to facilitate exchange of network [RFC4271] is normally used to facilitate exchange of network
reachability information over these media. reachability 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
[I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP [I-D.ietf-idr-ix-bgp-route-server] are often deployed by IXP
operators to provide a simple and convenient means of interconnecting operators to provide a simple and convenient means of interconnecting
skipping to change at page 3, line 48 skipping to change at page 4, line 5
participant wishes to implement an open interconnection policy - i.e. participant wishes to implement an open interconnection policy - i.e.
a policy of interconnecting with as many other IXP participants as a policy of interconnecting with as many other IXP participants as
possible - it is necessary for the participant to liaise with each of possible - it is necessary for the participant to liaise with each of
their intended interconnection partners. Interconnection can then be their intended interconnection partners. Interconnection can then be
implemented bilaterally by configuring a BGP session on both implemented bilaterally by configuring a BGP session on both
participants' routers to exchange network reachability information. participants' routers to exchange network reachability information.
If each exchange participant interconnects with each other If each exchange participant interconnects with each other
participant, a full mesh of BGP sessions is needed, as shown in participant, a full mesh of BGP sessions is needed, as shown in
Figure 1. Figure 1.
___ ___ ___ ___
/ \ / \ / \ / \
..| AS1 |..| AS2 |.. ..| AS1 |..| AS2 |..
: \___/____\___/ : : \___/____\___/ :
: | \ / | :
: | \ / | : : | \ / | :
: | \ / | : : IXP | \/ | :
: IXP | \/ | : : | /\ | :
: | /\ | : : | / \ | :
: | / \ | : : _|_/____\_|_ :
: _|_/____\_|_ : : / \ / \ :
: / \ / \ : ..| 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 number: AS1, AS2, AS3 and
AS4. Each of these four participants wishes to exchange traffic with AS4. Each of these four participants wishes to exchange traffic with
all other participants; this is accomplished by configuring a full all other participants; this is accomplished by configuring a full
mesh of BGP sessions on each router connected to the exchange, mesh of BGP sessions on each router connected to the exchange,
resulting in 6 BGP sessions across the IXP fabric. resulting in 6 BGP sessions across the IXP fabric.
skipping to change at page 5, line 17 skipping to change at page 5, line 19
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
information from these new participants without necessarily having to information from these new participants without necessarily having to
modify their configurations. modify their configurations.
___ ___ ___ ___
/ \ / \ / \ / \
..| AS1 |..| AS2 |.. ..| AS1 |..| AS2 |..
: \___/ \___/ : : \___/ \___/ :
: \ / : : \ / :
: \ / : : \ / :
: \__/ : : \__/ :
: 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. which also connect to the route server.
4. Operational Considerations for Route Server Installations 4. Operational Considerations for Route Server Installations
skipping to change at page 10, line 50 skipping to change at page 11, line 5
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 Section 5.1.3(2) of [RFC4271] allows eBGP speakers to change the
NEXT_HOP address of an NLRI update to be a different internet address NEXT_HOP address of an NLRI update to be a different internet address
on the same subnet. This is the mechanism which allows route servers on the same subnet. This is the mechanism which allows route servers
to operate on a shared layer 2 IXP network. However, the mechanism to operate on a shared layer 2 IXP network. However, the mechanism
can be abused by route server clients to redirect traffic for their can be abused by route server clients to redirect traffic for their
prefixes to other IXP participant routers. 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 prefixes for For example in Figure 3, if AS1 and AS2 both announce prefixes 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 prefixes to be the address of AS2's router, thereby diverting AS99's prefixes 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
skipping to change at page 12, line 38 skipping to change at page 12, line 41
include route server capabilities which are compliant with this include route server capabilities which are compliant with this
document. document.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-idr-ix-bgp-route-server] [I-D.ietf-idr-ix-bgp-route-server]
Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker,
"Internet Exchange Route Server", draft-ietf-idr-ix-bgp- "Internet Exchange Route Server", draft-ietf-idr-ix-bgp-
route-server-02 (work in progress), February 2013. route-server-03 (work in progress), August 2013.
[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, March 1997.
8.2. Informative References 8.2. Informative References
[RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP
Communities Attribute", RFC 1997, August 1996. Communities Attribute", RFC 1997, August 1996.
[RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D., [RFC2622] Alaettinoglu, C., Villamizar, C., Gerich, E., Kessens, D.,
skipping to change at page 13, line 18 skipping to change at page 13, line 23
[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, February 2006.
[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, April 2006.
[RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS
Number Space", RFC 4893, May 2007. Number Space", RFC 4893, May 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[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, June
2010. 2010.
[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/research/95-603.ps.Z>. <http://www.cs.usc.edu/research/95-603.ps.Z>.
Authors' Addresses Authors' Addresses
Nick Hilliard Nick Hilliard
INEX INEX
4027 Kingswood Road 4027 Kingswood Road
Dublin 24 Dublin 24
IE IE
Email: nick@inex.ie Email: nick@inex.ie
Elisa Jasinska Elisa Jasinska
Microsoft Corporation Netflix, Inc
One Microsoft Way 100 Winchester Circle
Redmond, WA 98052 Los Gatos, CA 95032
US USA
Email: ejas@microsoft.com Email: elisa@netflix.com
Robert Raszuk Robert Raszuk
NTT I3 NTT I3
101 S Ellsworth Avenue Suite 350 101 S Ellsworth Avenue Suite 350
San Mateo, CA 94401 San Mateo, CA 94401
US US
Email: robert@raszuk.net Email: robert@raszuk.net
Niels Bakker Niels Bakker
AMS-IX B.V. Akamai Technologies B.V.
Westeinde 12 Kingsfordweg 151
Amsterdam, NH 1017 ZN Amsterdam 1043 GR
NL NL
Email: niels.bakker@ams-ix.net Email: nbakker@akamai.com
 End of changes. 17 change blocks. 
70 lines changed or deleted 65 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/