draft-ietf-idr-ix-bgp-route-server-08.txt   draft-ietf-idr-ix-bgp-route-server-09.txt 
IDR Working Group E. Jasinska IDR Working Group E. Jasinska
Internet-Draft BigWave IT Internet-Draft BigWave IT
Intended status: Standards Track N. Hilliard Intended status: Standards Track N. Hilliard
Expires: March 3, 2016 INEX Expires: April 21, 2016 INEX
R. Raszuk R. Raszuk
Mirantis Inc. Mirantis Inc.
N. Bakker N. Bakker
Akamai Technologies B.V. Akamai Technologies B.V.
August 31, 2015 October 19, 2015
Internet Exchange BGP Route Server Internet Exchange BGP Route Server
draft-ietf-idr-ix-bgp-route-server-08 draft-ietf-idr-ix-bgp-route-server-09
Abstract Abstract
This document outlines a specification for multilateral This document outlines a specification for multilateral
interconnections at Internet exchange points (IXPs). Multilateral interconnections at Internet exchange points (IXPs). Multilateral
interconnection is a method of exchanging routing information between interconnection is a method of exchanging routing information between
three or more exterior BGP speakers using a single intermediate three or more exterior BGP speakers using a single intermediate
broker system, referred to as a route server. Route servers are broker system, referred to as a route server. Route servers are
typically used on shared access media networks, such as Internet typically used on shared access media networks, such as Internet
exchange points (IXPs), to facilitate simplified interconnection exchange points (IXPs), to facilitate simplified interconnection
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 3, 2016. This Internet-Draft will expire on April 21, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
2.2. Attribute Transparency . . . . . . . . . . . . . . . . . 4 2.2. Attribute Transparency . . . . . . . . . . . . . . . . . 4
2.2.1. NEXT_HOP Attribute . . . . . . . . . . . . . . . . . 4 2.2.1. NEXT_HOP Attribute . . . . . . . . . . . . . . . . . 4
2.2.2. AS_PATH Attribute . . . . . . . . . . . . . . . . . . 4 2.2.2. AS_PATH Attribute . . . . . . . . . . . . . . . . . . 4
2.2.3. MULTI_EXIT_DISC Attribute . . . . . . . . . . . . . . 4 2.2.3. MULTI_EXIT_DISC Attribute . . . . . . . . . . . . . . 4
2.2.4. Communities Attributes . . . . . . . . . . . . . . . 5 2.2.4. Communities Attributes . . . . . . . . . . . . . . . 5
2.3. Per-Client Policy Control in Multilateral Interconnection 5 2.3. Per-Client Policy Control in Multilateral Interconnection 5
2.3.1. Path Hiding on a Route Server . . . . . . . . . . . . 5 2.3.1. Path Hiding on a Route Server . . . . . . . . . . . . 5
2.3.2. Mitigation of Path Hiding . . . . . . . . . . . . . . 6 2.3.2. Mitigation of Path Hiding . . . . . . . . . . . . . . 6
2.3.2.1. Multiple Route Server RIBs . . . . . . . . . . . 6 2.3.2.1. Multiple Route Server RIBs . . . . . . . . . . . 6
2.3.2.2. Advertising Multiple Paths . . . . . . . . . . . 7 2.3.2.2. Advertising Multiple Paths . . . . . . . . . . . 7
2.3.3. Implementation Recommendations . . . . . . . . . . . 8 2.3.3. Implementation Suggestions . . . . . . . . . . . . . 8
3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Normative References . . . . . . . . . . . . . . . . . . 9 6.1. Normative References . . . . . . . . . . . . . . . . . . 9
6.2. Informative References . . . . . . . . . . . . . . . . . 9 6.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction to Multilateral Interconnection 1. Introduction to Multilateral Interconnection
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], an inter-Autonomous System routing protocol, is commonly [RFC4271], an inter-Autonomous System routing protocol, is commonly
used to facilitate exchange of network reachability information over used to facilitate exchange of network reachability information over
such media. such media.
While bilateral exterior BGP sessions between exchange participants While bilateral exterior BGP sessions between exchange participants
were previously the most common means of exchanging reachability were previously the most common means of exchanging reachability
information, the overhead associated with dense interconnection has information, the overhead associated with dense interconnection can
caused substantial operational scaling problems for Internet exchange cause substantial operational scaling problems for partipants of
point participants. larger Internet exchange points.
Multilateral interconnection is a method of interconnecting BGP Multilateral interconnection is a method of interconnecting BGP
speaking routers using a third party brokering system, commonly speaking routers using a third party brokering system, commonly
referred to as a route server and typically managed by the IXP referred to as a route server and typically managed by the IXP
operator. Each of the multilateral interconnection participants operator. Each of the multilateral interconnection participants
(usually referred to as route server clients) announces network (usually referred to as route server clients) announces network
reachability information to the route server using exterior BGP, and reachability information to the route server using exterior BGP, and
the route server in turn forwards this information to each other the route server in turn forwards this information to each other
route server client connected to it, according to its configuration. route server client connected to it, according to its configuration.
Although a route server uses BGP to exchange reachability information Although a route server uses BGP to exchange reachability information
skipping to change at page 5, line 29 skipping to change at page 5, line 29
While IXP participants often use route servers with the intention of While IXP participants often use route servers with the intention of
interconnecting with as many other route server participants as interconnecting with as many other route server participants as
possible, there are circumstances where control of path distribution possible, there are circumstances where control of path distribution
on a per-client basis is important to ensure that desired on a per-client basis is important to ensure that desired
interconnection policies are met. interconnection policies are met.
The control of path distribution on a per-client basis can lead to a 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 being hidden from the route server client. We refer to this as
"path hiding". "path hiding".
Neither Section 2.3 nor its subsections form part of the normative
specification of this document, but are included for information
purposes only.
2.3.1. Path Hiding on a Route Server 2.3.1. Path Hiding on a Route Server
___ ___ ___ ___
/ \ / \ / \ / \
..| AS1 |..| AS2 |.. ..| AS1 |..| AS2 |..
: \___/ \___/ : : \___/ \___/ :
: \ / | : : \ / | :
: \ / | : : \ / | :
: IXP \/ | : : IXP \/ | :
: /\ | : : /\ | :
skipping to change at page 6, line 52 skipping to change at page 7, line 7
2.3.2.1. Multiple Route Server RIBs 2.3.2.1. Multiple Route Server RIBs
The most portable method to allow for per-client policy control The most portable method to allow for per-client policy control
without the occurrence of path hiding, is by using a route server BGP without the occurrence of path hiding, is by using a route server BGP
implementation which performs the per-client best path calculation implementation which performs the per-client best path calculation
for each set of paths to a prefix, which results after the route for each set of paths to a prefix, which results after the route
server's client policies have been taken into consideration. This server's client policies have been taken into consideration. This
can be implemented by using per-client Loc-RIBs, with path filtering can be implemented by using per-client Loc-RIBs, with path filtering
implemented between the Adj-RIB-In and the per-client Loc-RIB. implemented between the Adj-RIB-In and the per-client Loc-RIB.
Implementations MAY optimize this by maintaining paths not subject to Implementations can optimize this by maintaining paths not subject to
filtering policies in a global Loc-RIB, with per-client Loc-RIBs filtering policies in a global Loc-RIB, with per-client Loc-RIBs
stored as deltas. stored as deltas.
This implementation is highly portable, as it makes no assumptions This implementation is highly portable, as it makes no assumptions
about the feature capabilities of the route server clients. about the feature capabilities of the route server clients.
2.3.2.2. Advertising Multiple Paths 2.3.2.2. Advertising Multiple Paths
The path distribution model described above assumes standard BGP The path distribution model described above assumes standard BGP
session encoding where the route server sends a single path to its session encoding where the route server sends a single path to its
skipping to change at page 8, line 11 skipping to change at page 8, line 16
withdraw when it receives an UPDATE message for a prefix which withdraw when it receives an UPDATE message for a prefix which
already exists in its Adj-RIB-In, this approach requires explicit already exists in its Adj-RIB-In, this approach requires explicit
support for the feature both on the route server and on its clients. support for the feature both on the route server and on its clients.
If the ADD-PATH capability is negotiated bidirectionally between the If the ADD-PATH capability is negotiated bidirectionally between the
route server and a route server client, and the route server client route server and a route server client, and the route server client
propagates multiple paths for the same prefix to the route server, propagates multiple paths for the same prefix to the route server,
then this could potentially cause the propagation of inactive, then this could potentially cause the propagation of inactive,
invalid or suboptimal paths to the route server, thereby causing loss invalid or suboptimal paths to the route server, thereby causing loss
of reachability to other route server clients. For this reason, ADD- of reachability to other route server clients. For this reason, ADD-
PATH implementations on a route server SHOULD enforce send-only mode PATH implementations on a route server should enforce send-only mode
with the route server clients, which would result in negotiating with the route server clients, which would result in negotiating
receive-only mode from the client to the route server. receive-only mode from the client to the route server.
2.3.3. Implementation Recommendations 2.3.3. Implementation Suggestions
A route server SHOULD implement one of the methods described in Route server implementation authors may wish to consider one of the
Section 2.3.2 to allow per-client routing policy control without methods described in Section 2.3.2 to allow per-client route server
"path hiding". policy control without "path hiding".
3. Security Considerations 3. Security Considerations
The path hiding problem outlined in section Section 2.3.1 can be used The path hiding problem outlined in section Section 2.3.1 can be used
in certain circumstances to proactively block third party path in certain circumstances to proactively block third party path
announcements from other route server clients. Route server announcements from other route server clients. Route server
operators should be aware that security issues may arise unless steps operators should be aware that security issues may arise unless steps
are taken to mitigate against path hiding. are taken to mitigate against path hiding.
4. IANA Considerations 4. IANA Considerations
skipping to change at page 8, line 50 skipping to change at page 9, line 6
In addition, the authors would like to acknowledge the developers of In addition, the authors would like to acknowledge the developers of
BIRD, OpenBGPD, Quagga and IOS whose BGP implementations include BIRD, OpenBGPD, Quagga and IOS whose BGP implementations include
route server capabilities which are compliant with this document. route server capabilities which are compliant with this document.
Route server functionality was described in 1995 in [RFC1863] and Route server functionality was described in 1995 in [RFC1863] and
modern route server implementations are based on concepts developed modern route server implementations are based on concepts developed
in the 1990s by the Routing Arbiter Project and the Route Server Next in the 1990s by the Routing Arbiter Project and the Route Server Next
Generation Project, managed by ISI and Merit. Although the original 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 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 debt of gratitude to the many people who were involved in route
server development in the 1990s. Please note that [RFC1863] has been server development in the 1990s.
made historical by [RFC4223].
6. References 6. References
6.1. Normative References 6.1. Normative References
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996, Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>. <http://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 9, line 32 skipping to change at page 9, line 35
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360, Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, <http://www.rfc-editor.org/info/rfc4360>. February 2006, <http://www.rfc-editor.org/info/rfc4360>.
6.2. Informative References 6.2. Informative References
[I-D.ietf-idr-add-paths] [I-D.ietf-idr-add-paths]
Walton, D., Retana, A., Chen, E., and J. Scudder, Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", draft-ietf-idr- "Advertisement of Multiple Paths in BGP", draft-ietf-idr-
add-paths-10 (work in progress), October 2014. add-paths-11 (work in progress), October 2015.
[RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full [RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full
mesh routing", RFC 1863, DOI 10.17487/RFC1863, October mesh routing", RFC 1863, DOI 10.17487/RFC1863, October
1995, <http://www.rfc-editor.org/info/rfc1863>. 1995, <http://www.rfc-editor.org/info/rfc1863>.
[RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic",
RFC 4223, DOI 10.17487/RFC4223, October 2005,
<http://www.rfc-editor.org/info/rfc4223>.
[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, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<http://www.rfc-editor.org/info/rfc4456>. <http://www.rfc-editor.org/info/rfc4456>.
[RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D., [RFC6774] Raszuk, R., Ed., Fernando, R., Patel, K., McPherson, D.,
and K. Kumaki, "Distribution of Diverse BGP Paths", and K. Kumaki, "Distribution of Diverse BGP Paths",
RFC 6774, DOI 10.17487/RFC6774, November 2012, RFC 6774, DOI 10.17487/RFC6774, November 2012,
<http://www.rfc-editor.org/info/rfc6774>. <http://www.rfc-editor.org/info/rfc6774>.
 End of changes. 14 change blocks. 
21 lines changed or deleted 20 lines changed or added

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