Network Working Group Pierre Francois Internet-Draft Camilo Cardona Expires: August 11, 2014 Institute IMDEA Networks Adam Simpson Alcatel-Lucent Jeffrey Haas Juniper Networks February 7, 2014 ADD-PATH for Route Servers draft-francois-idr-rs-addpaths-00 Abstract BGP speakers in Internet Exchange Points exchange routes with a large number of peers. To reduce the burden of maintaining many sessions, IXPs implement and administrate BGP route servers. Route servers announce to their clients the paths of multiple peers by using a single eBGP session. Route servers, however, are restricted to propagating a single path per NLRI per eBGP session. This constraint affects the path diversity received by clients, which could use paths that they would not have chosen, had they known all possible paths. To overcome this limitation, we propose in this draft the extension of ADD-PATH to eBGP peers in the context of route servers. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 11, 2014. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. Pierre Francois, et al. Expires August 11, 2014 [Page 1] Internet-Draft ADD-PATH for Route Servers February 2014 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation of eBGP ADD-PATH capability for IXP route Server . . 4 3.1. Operation of eBGP ADD-PATH in route servers with the limited paths capability . . . . . . . . . . . . . . . . . 4 4. Error conditions . . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Pierre Francois, et al. Expires August 11, 2014 [Page 2] Internet-Draft ADD-PATH for Route Servers February 2014 1. Introduction IXP route servers were designed to help network operators reduce the difficulties associated with maintaining a large number of sessions [IXPRouteServer]. Every route server client can receive paths from multiple ASes using the same eBGP session with the route server. In some cases, usually when there are many members in the IXP, multiple clients might announce a path to the same NLRI. Path diversity is an advantage for IXPs, as members can choose the path that better suits their policy. However, as a normal eBGP speaker, route servers can only advertize a single path to its clients. This limitation causes the route server to potentially hide paths that would be useful for their clients. ADD-PATH [AddPath] is a capability that allows BGP speakers to announce more than one path to their peers. Works related to ADD- PATH have focused on applications for iBGP deployments. We propose the use of ADD-PATH over eBGP sessions to overcome the problems associated to the limit in the number of paths that route servers can announce. In this document, we define the operation and error conditions of ADD-PATH for these scenarios and describe additional benefits for the route servers that implement it. 2. Motivation By collecting paths from all their clients, route servers potentially accumulate various paths for some destination prefix. Multiple of these paths may be compliant with the policy of some client of the route server. However, route servers typically maintain a single session with their clients, and hence advertise at most a single path towards each of them. As a result, a route server client will typically know only one of these paths. We believe that this aspect of route serving is an unfortunate limitation, as it artificially hides paths from clients that may have wanted to use them. First, it prevents the member from performing a policy based decision that is finer than the one advertised to the route server platform. That is, the arbitrary best path picked among the policy-compliant ones by the route server may be actually different from the one that the client would have picked, had it known about all of them. Second, it prevents the member from doing temporary preference tweaking among the set of available paths in order to perform traffic engineering. That is, a member may only receive a path for a destination through a peer that is saturated, while alternate paths Pierre Francois, et al. Expires August 11, 2014 [Page 3] Internet-Draft ADD-PATH for Route Servers February 2014 through non saturated nexthops are available and would have been used if the router (and the operator) were aware of their existence. ADD-PATH was designed to advertise more than one path towards a given NLRI. Multiple paths installed in the forwarding planes, as well as alternate paths, can be advertised among speakers supporting ADD- PATH. ADD-PATH can be used by a route server to announce all paths available for the same NLRI that still fulfill the policy of the route server client. 3. Operation of eBGP ADD-PATH capability for IXP route Server A route server that supports the advertisement of multiple paths toward the same NLRI SHOULD announce the ADD-PATH capability to its clients. Likewise, a client supporting the reception of multiple paths SHOULD announce the ADD-PATH capability to the route server. In an IXP context, only the route server should propagate multiple paths to the route server clients. The advertisement of multiple paths in the other direction is currently out of the specification of this document. Therefore, a route Server client should set the Send/ Receive field for the Add-Path capability with a value of 1. The route Server should set the same field in the capability with a 2. A route server supporting ADD-PATH can announce to its clients all paths that comply with their policy. This operational mode is similar to the ADD-PATH ALL mode described in [AddPathGuidelines]. A route server could also support other type of ADD-PATH modes that restrict the paths announced to the client. In an Add-N mode, for instance, the route server would announce at most N paths to their clients. 3.1. Operation of eBGP ADD-PATH in route servers with the limited paths capability The limited paths capability provides ADD-PATH speakers with a method to communicate the maximum number of paths towards the same NLRI that BGP speakers are willing to receive. The use of this capability in IXP environments is recommended, as it provides the clients with the ability to control the resources used in their devices by limiting the total amount of paths received from the route Server. 4. Error conditions In the specific context of route servers, third party nexthops are Pierre Francois, et al. Expires August 11, 2014 [Page 4] Internet-Draft ADD-PATH for Route Servers February 2014 being used so as to have the client actually be able to select the appropriate nexthop. This is achieved by letting the route server leave the nexthop field of the propagated paths unchanged. Similarly, the propagation of multiple paths by the route server to one of its clients must be made in a way that allows the receiver to actually select one among those paths. As a result, a route server advertising two different paths for the same destination, with equal nexthops, is out of specification. If this situation occurs, the client SHOULD log the event and let the normal decision process decide the best path. A typical route server client will have only one usable path towards a given destination announced to the other clients of the route server. As a result, a route server client advertising more than one path towards a given destination, to its route server, is out of specification. If this situation occurs, the client SHOULD log the event and let the normal decision process decide the best path. 5. IANA considerations None 6. Security Considerations The use of eBGP ADD-PATH in the route server environment does not increase the number of destinations for which paths are being advertised. However, the potential number of paths per destination is now larger than one, potentially increasing the memory load of the Adj-Rib-In. Systems risking to be short on memory due to this increase should be configured to constrain the amount of paths being advertised to them by a value which ensures proper operations. 7. References [AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder, "Advertisement of Multiple Paths in BGP", draft-ietf-idr-add-paths-06.txt (work in progress). [AddPathGuidelines] J. Uttaro, P. Francois, R. Fragassi, A. Simpson, and K. Patel, "Best Practices for Advertisement of Multiple Paths in IBGP", draft-ietf-idr-add-paths-guidelines-05.txt (work in progress). Pierre Francois, et al. Expires August 11, 2014 [Page 5] Internet-Draft ADD-PATH for Route Servers February 2014 [IXPRouteServer] E. Jasinska, N. Hilliard, R. Raszuk, and N. Bakker, "Best Practices for Advertisement of Multiple Paths in IBGP", draft-ietf-idr-ix-bgp-route-server-03 (work in progress). Authors' Addresses Pierre Francois Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes 28918 ES Email: pierre.francois@imdea.org Camilo Cardona Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganes 28918 ES Email: juancamilo.cardona@imdea.org Adam Simpson Alcatel-Lucent 600 March Road Ontario K2K 2E6 CA Email: adam.simpson@alcatel-lucent.com Jeffrey Haas Juniper Networks 1194 N. Mathilda Ave Sunnyvale 94089 USA Email: jhaas@juniper.net Pierre Francois, et al. Expires August 11, 2014 [Page 6]