draft-ietf-idr-ix-bgp-route-server-05.txt   draft-ietf-idr-ix-bgp-route-server-06.txt 
IDR Working Group E. Jasinska IDR Working Group E. Jasinska
Internet-Draft Netflix, Inc Internet-Draft Netflix, Inc
Intended status: Standards Track N. Hilliard Intended status: Standards Track N. Hilliard
Expires: December 11, 2014 INEX Expires: June 13, 2015 INEX
R. Raszuk R. Raszuk
NTT MCL Inc. Mirantis Inc.
N. Bakker N. Bakker
Akamai Technologies B.V. Akamai Technologies B.V.
June 9, 2014 December 10, 2014
Internet Exchange Route Server Internet Exchange Route Server
draft-ietf-idr-ix-bgp-route-server-05 draft-ietf-idr-ix-bgp-route-server-06
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 December 11, 2014. This Internet-Draft will expire on June 13, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
skipping to change at page 7, line 50 skipping to change at page 7, line 50
to a route server client, then route server clients would no longer to a route server client, then route server clients would no longer
depend on receiving a single best path to a particular prefix; depend on receiving a single best path to a particular prefix;
consequently, the path hiding problem described in Section 2.3.1 consequently, the path hiding problem described in Section 2.3.1
would disappear. would disappear.
We present two methods which describe how such increased path We present two methods which describe how such increased path
diversity could be implemented. diversity could be implemented.
2.3.2.2.1. Diverse BGP Path Approach 2.3.2.2.1. Diverse BGP Path Approach
The Diverse BGP Path proposal as defined in The Diverse BGP Path proposal as defined in [RFC6774] is a simple way
[I-D.ietf-grow-diverse-bgp-path-dist] is a simple way to distribute to distribute multiple prefix paths from a route server to a route
multiple prefix paths from a route server to a route server client by server client by using a separate BGP session from the route server
using a separate BGP session from the route server to a client for to a client for each different path.
each different path.
The number of paths which may be distributed to a client is The number of paths which may be distributed to a client is
constrained by the number of BGP sessions which the server and the constrained by the number of BGP sessions which the server and the
client are willing to establish with each other. The distributed client are willing to establish with each other. The distributed
paths may be established from the global BGP Loc-RIB on the route paths may be established from the global BGP Loc-RIB on the route
server in addition to any per-client Loc-RIB. As there may be more server in addition to any per-client Loc-RIB. As there may be more
potential paths to a given prefix than configured BGP sessions, this potential paths to a given prefix than configured BGP sessions, this
method is not guaranteed to eliminate the path hiding problem in all method is not guaranteed to eliminate the path hiding problem in all
situations. Furthermore, this method may significantly increase the situations. Furthermore, this method may significantly increase the
number of BGP sessions handled by the route server, which may number of BGP sessions handled by the route server, which may
skipping to change at page 9, line 47 skipping to change at page 9, line 46
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[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.
6.2. Informative References 6.2. Informative References
[I-D.ietf-grow-diverse-bgp-path-dist]
Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.
Kumaki, "Distribution of diverse BGP paths.",
draft-ietf-grow-diverse-bgp-path-dist-08 (work in
progress), July 2012.
[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", "Advertisement of Multiple Paths in BGP",
draft-ietf-idr-add-paths-09 (work in progress), draft-ietf-idr-add-paths-10 (work in progress),
October 2013. October 2014.
[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, October 1995. mesh routing", RFC 1863, October 1995.
[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.
[RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K.
Kumaki, "Distribution of Diverse BGP Paths", RFC 6774,
November 2012.
Authors' Addresses Authors' Addresses
Elisa Jasinska Elisa Jasinska
Netflix, Inc Netflix, Inc
100 Winchester Circle 100 Winchester Circle
Los Gatos, CA 95032 Los Gatos, CA 95032
USA USA
Email: elisa@netflix.com Email: elisa@netflix.com
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
Robert Raszuk Robert Raszuk
NTT MCL Inc. Mirantis Inc.
101 S Ellsworth Avenue Suite 350 615 National Ave. #100
San Mateo, CA 94401 Mt View, CA 94043
US USA
Phone:
Fax:
Email: robert@raszuk.net Email: robert@raszuk.net
URI:
Niels Bakker Niels Bakker
Akamai Technologies B.V. Akamai Technologies B.V.
Kingsfordweg 151 Kingsfordweg 151
Amsterdam 1043 GR Amsterdam 1043 GR
NL NL
Email: nbakker@akamai.com Email: nbakker@akamai.com
 End of changes. 12 change blocks. 
23 lines changed or deleted 23 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/