idnits 2.17.1 draft-francois-idr-rs-addpaths-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 143: '...rd the same NLRI SHOULD announce the A...' RFC 2119 keyword, line 145: '... paths SHOULD announce the ADD-PATH ...' RFC 2119 keyword, line 198: '... client SHOULD log the event and let...' RFC 2119 keyword, line 202: '... IXP environment SHOULD only be perfor...' RFC 2119 keyword, line 203: '... A route server SHOULD log any case i...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 12, 2014) is 3542 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-09 == Outdated reference: A later version (-08) exists of draft-ietf-idr-add-paths-guidelines-06 == Outdated reference: A later version (-12) exists of draft-ietf-idr-ix-bgp-route-server-05 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Pierre Francois 3 Internet-Draft Institute IMDEA Networks 4 Intended status: Informational Camilo Cardona 5 Expires: February 13, 2015 Institute IMDEA Networks / UC3M 6 Adam Simpson 7 Alcatel-Lucent 8 Jeffrey Haas 9 Juniper Networks 10 August 12, 2014 12 ADD-PATH for Route Servers 13 draft-francois-idr-rs-addpaths-01 15 Abstract 17 BGP speakers at Internet Exchange Points typically exchange routes 18 with a large number of peers. To reduce the burden of maintaining 19 many sessions, IXPs implement and administrate BGP route servers. 20 Route servers announce to their clients the paths of multiple peers 21 by using a single eBGP session. Route servers, however, are 22 restricted to propagating a single path per NLRI per eBGP session. 23 This constraint affects the diversity of paths received by clients. 24 To overcome this limitation, we propose the extension of ADD-PATH to 25 eBGP peers. ADD-PATH allows a BGP speaker to send multiple paths for 26 the same NLRI, typically through different nexthops, over a single 27 session with a peer. By supporting ADD-PATH, a route server hence 28 allows a client to potentially select among all the available paths 29 for that NLRI, instead of the one arbitrarily chosen by the Route 30 Server. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 13, 2015. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 67 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Operation of eBGP ADD-PATH capability for IXP route Server . 3 69 3.1. Capability . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Path Selection . . . . . . . . . . . . . . . . . . . . . 4 71 3.2.1. ADD-PATH ALL Policy compliant . . . . . . . . . . . . 4 72 3.2.2. ADD-PATH N Policy compliant . . . . . . . . . . . . . 4 73 4. Error conditions . . . . . . . . . . . . . . . . . . . . . . 5 74 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 5 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 76 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 79 1. Introduction 81 IXP route servers were designed to help network operators reduce the 82 difficulties associated with maintaining a large number of sessions 83 [IXPRouteServer]. Every route server client can receive paths from 84 multiple ASes using the same eBGP session with the route server. In 85 some cases, usually when there are many members in the IXP, multiple 86 clients might announce a path to the same NLRI. Path diversity is an 87 advantage for IXPs, as members can choose the path that better suits 88 their policy. However, as a normal eBGP speaker, route servers can 89 only advertise a single path per NLRI to each client. This 90 limitation causes the route server to potentially hide paths that 91 would be useful for their clients. 93 ADD-PATH [AddPath] is a capability that allows BGP speakers to 94 announce more than one path to their peers. Works related to ADD- 95 PATH have focused on applications for iBGP deployments. We propose 96 the use of ADD-PATH over eBGP sessions to overcome the problems 97 associated with the limit on the number of paths that route servers 98 can announce. In this document, we define the operation and error 99 conditions of ADD-PATH for these scenarios and describe additional 100 benefits for the route servers that implement it. 102 2. Motivation 104 By collecting paths from all their clients, route servers potentially 105 accumulate various paths for some destination prefix. Multiple of 106 these paths may be compliant with the policy of some clients of the 107 route server. However, route servers typically maintain a single 108 session with their clients, and hence advertise at most a single path 109 towards each of them. As a result, a route server client will 110 typically know only one of these paths. In some cases, depending on 111 the implementation of the IXP route server, the route server client 112 would not even receive a path for the NLRI. Refer to 113 [IXPRouteServer] for an explanation of this problem. 115 We believe that this aspect of route serving is an unfortunate 116 limitation, as it artificially hides paths from clients that may have 117 wanted to use them. 119 First, it prevents the member from performing a policy based decision 120 that is finer than the one advertised to the route server platform. 121 That is, the arbitrary best path picked among the policy-compliant 122 ones by the route server may be actually different from the one that 123 the client would have picked, had it known about all of them. 125 Second, it prevents the member from doing temporary preference 126 tweaking among the set of available paths in order to perform traffic 127 engineering. That is, a member may only receive a path for a 128 destination through a peer that is saturated, while alternate paths 129 through non-saturated nexthops are available and would have been used 130 if the router (and the operator) were aware of their existence. 132 ADD-PATH was designed to advertise more than one path towards a given 133 NLRI. Multiple paths installed in the forwarding planes, as well as 134 alternate paths, can be advertised among speakers supporting ADD- 135 PATH. ADD-PATH can be used by a route server to announce all paths 136 available for the same NLRI that still fulfill the policy of the 137 route server client. 139 3. Operation of eBGP ADD-PATH capability for IXP route Server 140 3.1. Capability 142 A route server that supports the advertisement of multiple paths 143 toward the same NLRI SHOULD announce the ADD-PATH capability to its 144 clients. Likewise, a client supporting the reception of multiple 145 paths SHOULD announce the ADD-PATH capability to the route server. 147 In an IXP context, only the route server should propagate multiple 148 paths to the route server clients. The advertisement of multiple 149 paths in the other direction is currently out of the specification of 150 this document. Therefore, a route Server client should set the Send/ 151 Receive field for the Add-Path capability with a value of 1. The 152 route Server should set the same field in the capability with a 2. 154 3.2. Path Selection 156 We describe here two path selection modes that can be implemented by 157 the route server. 159 3.2.1. ADD-PATH ALL Policy compliant 161 A route server supporting ADD-PATH can announce to its clients all 162 paths that comply with their policy. This selection mode is 163 denominated as "ADD-PATH ALL Policy compliant". 165 3.2.2. ADD-PATH N Policy compliant 167 A route server may also support another type of ADD-PATH mode that 168 restricts the number of paths per NLRI announced to each client. For 169 instance, the route server would announce at most N paths to their 170 clients that comply with their policies. This mode would help reduce 171 the resources needed in the client, in case the number of available 172 paths is large. Note that once the number of policy-compliant paths 173 that can be advertised is restricted, a client might not receive the 174 best possible path with respect to its own policies. 176 The configuration of the number of paths sent to each route server 177 client could be done manually or set by the route server client via a 178 communication channel. 180 The selection of paths is free to the implementation of the route 181 server. Similarly to the ADD-PATH N mode [AddPathGuidelines], the 182 route server COULD choose a set of paths equivalent to the one 183 obtained after running the BGP best algorithm N times, excluding the 184 selected path after each interaction. 186 4. Error conditions 188 In the specific context of route servers, third party nexthops are 189 being used to have the client actually be able to select the 190 appropriate nexthop. This is achieved by letting the route server 191 leave the nexthop field of the propagated paths unchanged. 193 Similarly, the propagation of multiple paths by the route server to 194 one of its clients must be made in a way that allows the receiver to 195 actually select one among those paths. As a result, a route server 196 advertising two different paths for the same destination, with equal 197 nexthops, is out of specification. If this situation occurs, the 198 client SHOULD log the event and let the normal decision process 199 decide the best path. 201 As described in Section 3.1, the advertisement of multiple paths in 202 an IXP environment SHOULD only be performed from the route server to 203 its clients. A route server SHOULD log any case in which a route 204 server client signals, through the ADD-PATH capability, its 205 willingness to announce more than one path. The route server SHOULD 206 continue to operate under these events, considering all paths 207 received from its clients. 209 5. IANA considerations 211 None 213 6. Security Considerations 215 The use of eBGP ADD-PATH in the route server environment does not 216 increase the number of destinations for which paths are being 217 advertised. However, the potential number of paths per destination 218 is now larger than one, potentially increasing the memory load of the 219 Adj-Rib-In. Systems risking to be short on memory due to this 220 increase should be configured to constrain the amount of paths being 221 advertised to them by a value which ensures proper operations. 223 7. References 225 [AddPath] Walton, D., Chen, E., Retana, A., and J. Scudder, 226 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 227 add-paths-09.txt (work in progress), October 2013. 229 [AddPathGuidelines] 230 Uttaro, J., Francois, P., Fragassi, R., Simpson, A., 231 Patel, K., and P. Mohapatra, "Best Practices for 232 Advertisement of Multiple Paths in IBGP", draft-ietf-idr- 233 add-paths-guidelines-06.txt (work in progress), January 234 2014. 236 [IXPRouteServer] 237 Jasinska, E., Hilliard, N., Raszuk, R., and N. Bakker, 238 "Internet Exchange Route Server", draft-ietf-idr-ix-bgp- 239 route-server-05 (work in progress), June 2014. 241 Authors' Addresses 243 Pierre Francois 244 Institute IMDEA Networks 245 Avda. del Mar Mediterraneo, 22 246 Leganes 28918 247 ES 249 Email: pierre.francois@imdea.org 251 Camilo Cardona 252 Institute IMDEA Networks / UC3M 253 Avda. del Mar Mediterraneo, 22 254 Leganes 28918 255 ES 257 Email: juancamilo.cardona@imdea.org 259 Adam Simpson 260 Alcatel-Lucent 261 600 March Road 262 Ontario K2K 2E6 263 CA 265 Email: adam.simpson@alcatel-lucent.com 267 Jeffrey Haas 268 Juniper Networks 269 1194 N. Mathilda Ave 270 Sunnyvale 94089 271 USA 273 Email: jhaas@juniper.net