Network Working Group Pierre Francois Internet-Draft Institute IMDEA Networks Intended status: Informational Camilo Cardona Expires: February 13, 2015 Institute IMDEA Networks / UC3M Adam Simpson Alcatel-Lucent Jeffrey Haas Juniper Networks August 12, 2014 ADD-PATH for Route Servers draft-francois-idr-rs-addpaths-01 Abstract BGP speakers at Internet Exchange Points typically 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 diversity of paths received by clients. To overcome this limitation, we propose the extension of ADD-PATH to eBGP peers. ADD-PATH allows a BGP speaker to send multiple paths for the same NLRI, typically through different nexthops, over a single session with a peer. By supporting ADD-PATH, a route server hence allows a client to potentially select among all the available paths for that NLRI, instead of the one arbitrarily chosen by the Route Server. 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 February 13, 2015. Pierre Francois, et al. Expires February 13, 2015 [Page 1] Internet-Draft ADD-PATH for Route Servers August 2014 Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Operation of eBGP ADD-PATH capability for IXP route Server . 3 3.1. Capability . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 4 3.2.1. ADD-PATH ALL Policy compliant . . . . . . . . . . . . 4 3.2.2. ADD-PATH N Policy compliant . . . . . . . . . . . . . 4 4. Error conditions . . . . . . . . . . . . . . . . . . . . . . 5 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 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 advertise a single path per NLRI to each client. 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 Pierre Francois, et al. Expires February 13, 2015 [Page 2] Internet-Draft ADD-PATH for Route Servers August 2014 associated with the limit on 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 clients 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. In some cases, depending on the implementation of the IXP route server, the route server client would not even receive a path for the NLRI. Refer to [IXPRouteServer] for an explanation of this problem. 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 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 Pierre Francois, et al. Expires February 13, 2015 [Page 3] Internet-Draft ADD-PATH for Route Servers August 2014 3.1. Capability 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. 3.2. Path Selection We describe here two path selection modes that can be implemented by the route server. 3.2.1. ADD-PATH ALL Policy compliant A route server supporting ADD-PATH can announce to its clients all paths that comply with their policy. This selection mode is denominated as "ADD-PATH ALL Policy compliant". 3.2.2. ADD-PATH N Policy compliant A route server may also support another type of ADD-PATH mode that restricts the number of paths per NLRI announced to each client. For instance, the route server would announce at most N paths to their clients that comply with their policies. This mode would help reduce the resources needed in the client, in case the number of available paths is large. Note that once the number of policy-compliant paths that can be advertised is restricted, a client might not receive the best possible path with respect to its own policies. The configuration of the number of paths sent to each route server client could be done manually or set by the route server client via a communication channel. The selection of paths is free to the implementation of the route server. Similarly to the ADD-PATH N mode [AddPathGuidelines], the route server COULD choose a set of paths equivalent to the one obtained after running the BGP best algorithm N times, excluding the selected path after each interaction. Pierre Francois, et al. Expires February 13, 2015 [Page 4] Internet-Draft ADD-PATH for Route Servers August 2014 4. Error conditions In the specific context of route servers, third party nexthops are being used 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. As described in Section 3.1, the advertisement of multiple paths in an IXP environment SHOULD only be performed from the route server to its clients. A route server SHOULD log any case in which a route server client signals, through the ADD-PATH capability, its willingness to announce more than one path. The route server SHOULD continue to operate under these events, considering all paths received from its clients. 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] Walton, D., Chen, E., Retana, A., and J. Scudder, "Advertisement of Multiple Paths in BGP", draft-ietf-idr- add-paths-09.txt (work in progress), October 2013. Pierre Francois, et al. Expires February 13, 2015 [Page 5] Internet-Draft ADD-PATH for Route Servers August 2014 [AddPathGuidelines] Uttaro, J., Francois, P., Fragassi, R., Simpson, A., Patel, K., and P. Mohapatra, "Best Practices for Advertisement of Multiple Paths in IBGP", draft-ietf-idr- add-paths-guidelines-06.txt (work in progress), January 2014. [IXPRouteServer] Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, "Internet Exchange Route Server", draft-ietf-idr-ix-bgp- route-server-05 (work in progress), June 2014. 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 / UC3M 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 February 13, 2015 [Page 6]