idnits 2.17.1 draft-ietf-idr-ix-bgp-route-server-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 10, 2014) is 3417 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-10 -- Obsolete informational reference (is this intentional?): RFC 1863 (Obsoleted by RFC 4223) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group E. Jasinska 3 Internet-Draft Netflix, Inc 4 Intended status: Standards Track N. Hilliard 5 Expires: June 13, 2015 INEX 6 R. Raszuk 7 Mirantis Inc. 8 N. Bakker 9 Akamai Technologies B.V. 10 December 10, 2014 12 Internet Exchange Route Server 13 draft-ietf-idr-ix-bgp-route-server-06 15 Abstract 17 This document outlines a specification for multilateral 18 interconnections at Internet exchange points (IXPs). Multilateral 19 interconnection is a method of exchanging routing information between 20 three or more exterior BGP speakers using a single intermediate 21 broker system, referred to as a route server. Route servers are 22 typically used on shared access media networks, such as Internet 23 exchange points (IXPs), to facilitate simplified interconnection 24 between multiple Internet routers. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on June 13, 2015. 43 Copyright Notice 45 Copyright (c) 2014 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction to Multilateral Interconnection . . . . . . . . . 3 61 1.1. Notational Conventions . . . . . . . . . . . . . . . . . . 3 62 2. Technical Considerations for Route Server Implementations . . 4 63 2.1. Client UPDATE Messages . . . . . . . . . . . . . . . . . . 4 64 2.2. Attribute Transparency . . . . . . . . . . . . . . . . . . 4 65 2.2.1. NEXT_HOP Attribute . . . . . . . . . . . . . . . . . . 4 66 2.2.2. AS_PATH Attribute . . . . . . . . . . . . . . . . . . 4 67 2.2.3. MULTI_EXIT_DISC Attribute . . . . . . . . . . . . . . 5 68 2.2.4. Communities Attributes . . . . . . . . . . . . . . . . 5 69 2.3. Per-Client Policy Control in Multilateral 70 Interconnection . . . . . . . . . . . . . . . . . . . . . 5 71 2.3.1. Path Hiding on a Route Server . . . . . . . . . . . . 6 72 2.3.2. Mitigation of Path Hiding . . . . . . . . . . . . . . 7 73 2.3.2.1. Multiple Route Server RIBs . . . . . . . . . . . . 7 74 2.3.2.2. Advertising Multiple Paths . . . . . . . . . . . . 7 75 2.3.3. Implementation Recommendations . . . . . . . . . . . . 8 76 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 77 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 78 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 79 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 81 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 84 1. Introduction to Multilateral Interconnection 86 Internet exchange points (IXPs) provide IP data interconnection 87 facilities for their participants, typically using shared Layer-2 88 networking media such as Ethernet. The Border Gateway Protocol (BGP) 89 [RFC4271], an inter-Autonomous System routing protocol, is commonly 90 used to facilitate exchange of network reachability information over 91 such media. 93 While bilateral exterior BGP sessions between exchange participants 94 were previously the most common means of exchanging reachability 95 information, the overhead associated with dense interconnection has 96 caused substantial operational scaling problems for Internet exchange 97 point participants. 99 Multilateral interconnection is a method of interconnecting BGP 100 speaking routers using a third party brokering system, commonly 101 referred to as a route server and typically managed by the IXP 102 operator. Each of the multilateral interconnection participants 103 (usually referred to as route server clients) announces network 104 reachability information to the route server using exterior BGP, and 105 the route server in turn forwards this information to each other 106 route server client connected to it, according to its configuration. 107 Although a route server uses BGP to exchange reachability information 108 with each of its clients, it does not forward traffic itself and is 109 therefore not a router. 111 A route server can be viewed as similar in function to an [RFC4456] 112 route reflector, except that it operates using EBGP instead of iBGP. 113 Certain adaptions to [RFC4271] are required to enable an EBGP router 114 to operate as a route server; these are outlined in Section 2 of this 115 document. 117 The term "route server" is often in a different context used to 118 describe a BGP node whose purpose is to accept BGP feeds from 119 multiple clients for the purpose of operational analysis and 120 troubleshooting. A system of this form may alternatively be known as 121 a "route collector" or a "route-views server". This document uses 122 the term "route server" exclusively to describe multilateral peering 123 brokerage systems. 125 1.1. Notational Conventions 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 [RFC2119]. 132 2. Technical Considerations for Route Server Implementations 134 2.1. Client UPDATE Messages 136 A route server MUST accept all UPDATE messages received from each of 137 its clients for inclusion in its Adj-RIB-In. These UPDATE messages 138 MAY be omitted from the route server's Loc-RIB or Loc-RIBs, due to 139 filters configured for the purposes of implementing routing policy. 140 The route server SHOULD perform one or more BGP Decision Processes to 141 select routes for subsequent advertisement to its clients, taking 142 into account possible configuration to provide multiple NLRI paths to 143 a particular client as described in Section 2.3.2.2 or multiple Loc- 144 RIBs as described in Section 2.3.2.1. The route server SHOULD 145 forward UPDATE messages where appropriate from its Loc-RIB or Loc- 146 RIBs to its clients. 148 2.2. Attribute Transparency 150 As a route server primarily performs a brokering service, 151 modification of attributes could cause route server clients to alter 152 their BGP best path selection process for received prefix 153 reachability information, thereby changing the intended routing 154 policies of exchange participants. Therefore, contrary to what is 155 specified in section 5. of [RFC4271], route servers SHOULD NOT by 156 default (unless explicitly configured) update well-known BGP 157 attributes received from route server clients before redistributing 158 them to their other route server clients. Optional recognized and 159 unrecognized BGP attributes, whether transitive or non-transitive, 160 SHOULD NOT be updated by the route server (unless enforced by local 161 IX operator configuration) and SHOULD be passed on to other route 162 server clients. 164 2.2.1. NEXT_HOP Attribute 166 The NEXT_HOP is a well-known mandatory BGP attribute which defines 167 the IP address of the router used as the next hop to the destinations 168 listed in the Network Layer Reachability Information field of the 169 UPDATE message. As the route server does not participate in the 170 actual routing of traffic, the NEXT_HOP attribute MUST be passed 171 unmodified to the route server clients, similar to the "third party" 172 next hop feature described in section 5.1.3. of [RFC4271]. 174 2.2.2. AS_PATH Attribute 176 AS_PATH is a well-known mandatory attribute which identifies the 177 autonomous systems through which routing information carried in the 178 UPDATE message has passed. 180 As a route server does not participate in the process of forwarding 181 data between client routers, and because modification of the AS_PATH 182 attribute could affect route server client best path calculations, 183 the route server SHOULD NOT prepend its own AS number to the AS_PATH 184 segment nor modify the AS_PATH segment in any other way. 186 2.2.3. MULTI_EXIT_DISC Attribute 188 MULTI_EXIT_DISC is an optional non-transitive attribute intended to 189 be used on external (inter-AS) links to discriminate among multiple 190 exit or entry points to the same neighboring AS. Contrary to section 191 5.1.4 of [RFC4271], if applied to an NLRI UPDATE sent to a route 192 server, this attribute SHOULD be propagated to other route server 193 clients and the route server SHOULD NOT modify its value. 195 2.2.4. Communities Attributes 197 The BGP COMMUNITIES ([RFC1997]) and Extended Communities ([RFC4360]) 198 attributes are attributes intended for labeling information carried 199 in BGP UPDATE messages. Transitive as well as non-transitive 200 Communities attributes applied to an NLRI UPDATE sent to a route 201 server SHOULD NOT be modified, processed or removed. However, if 202 such an attribute is intended for processing by the route server 203 itself, it MAY be modified or removed. 205 2.3. Per-Client Policy Control in Multilateral Interconnection 207 While IXP participants often use route servers with the intention of 208 interconnecting with as many other route server participants as 209 possible, there are circumstances where control of path distribution 210 on a per-client basis is important to ensure that desired 211 interconnection policies are met. 213 The control of path distribution on a per-client basis can lead to a 214 path being hidden from the route server client. We refer to this as 215 "path hiding". 217 2.3.1. Path Hiding on a Route Server 219 ___ ___ 220 / \ / \ 221 ..| AS1 |..| AS2 |.. 222 : \___/ \___/ : 223 : \ / | : 224 : \ / | : 225 : IXP \/ | : 226 : /\ | : 227 : / \ | : 228 : ___/____\_|_ : 229 : / \ / \ : 230 ..| AS3 |..| AS4 |.. 231 \___/ \___/ 233 Figure 1: Per-Client Policy Controlled Interconnection at an IXP 235 Using the example in Figure 1, AS1 does not directly exchange prefix 236 information with either AS2 or AS3 at the IXP, but only interconnects 237 with AS4. 239 In the traditional bilateral interconnection model, per-client policy 240 control to a third party exchange participant is accomplished either 241 by not engaging in a bilateral interconnection with that participant 242 or else by implementing outbound filtering on the BGP session towards 243 that participant. However, in a multilateral interconnection 244 environment, only the route server can perform outbound filtering in 245 the direction of the route server client; route server clients depend 246 on the route server to perform their outbound filtering for them. 248 Assuming a traditional best path selection, when the same prefix is 249 advertised to a route server from multiple route server clients, the 250 route server will select a single best path for propagation to all 251 connected clients. If, however, the route server has been configured 252 to filter the calculated best path from reaching a particular route 253 server client, then that client will not receive a path for that 254 prefix, although alternate paths received by the route server might 255 have been policy compliant for that client. This phenomenon is 256 referred to as "path hiding". 258 For example, in Figure 1, if the same prefix were sent to the route 259 server via AS2 and AS4, and the route via AS2 was preferred according 260 to BGP's traditional best path selection, but AS1's policy prevents 261 AS2's path from being accepted, then AS1 would never receive a path 262 to this prefix, even though the route server had previously received 263 a valid alternative path via AS4. This happens because the best path 264 selection is performed only once on the route server for all clients. 266 Path hiding will only occur on route servers which employ per-client 267 policy control; if an IXP operator deploys a route server without 268 implementing a per-client routing policy control system, then path 269 hiding does not occur as all paths are considered equally valid from 270 the point of view of the route server. 272 2.3.2. Mitigation of Path Hiding 274 There are several approaches which can be taken to mitigate against 275 path hiding. 277 2.3.2.1. Multiple Route Server RIBs 279 The most portable method to allow for per-client policy control 280 without the occurrence of path hiding, is by using a route server BGP 281 implementation which performs the per-client best path calculation 282 for each set of paths to a prefix, which results after the route 283 server's client policies have been taken into consideration. This 284 can be implemented by using per-client Loc-RIBs, with path filtering 285 implemented between the Adj-RIB-In and the per-client Loc-RIB. 286 Implementations MAY optimize this by maintaining paths not subject to 287 filtering policies in a global Loc-RIB, with per-client Loc-RIBs 288 stored as deltas. 290 This implementation is highly portable, as it makes no assumptions 291 about the feature capabilities of the route server clients. 293 2.3.2.2. Advertising Multiple Paths 295 The path distribution model described above assumes standard BGP 296 session encoding where the route server sends a single path to its 297 client for any given prefix. This path is selected using the BGP 298 path selection decision process described in [RFC4271]. If, however, 299 it were possible for the route server to send more than a single path 300 to a route server client, then route server clients would no longer 301 depend on receiving a single best path to a particular prefix; 302 consequently, the path hiding problem described in Section 2.3.1 303 would disappear. 305 We present two methods which describe how such increased path 306 diversity could be implemented. 308 2.3.2.2.1. Diverse BGP Path Approach 310 The Diverse BGP Path proposal as defined in [RFC6774] is a simple way 311 to distribute multiple prefix paths from a route server to a route 312 server client by using a separate BGP session from the route server 313 to a client for each different path. 315 The number of paths which may be distributed to a client is 316 constrained by the number of BGP sessions which the server and the 317 client are willing to establish with each other. The distributed 318 paths may be established from the global BGP Loc-RIB on the route 319 server in addition to any per-client Loc-RIB. As there may be more 320 potential paths to a given prefix than configured BGP sessions, this 321 method is not guaranteed to eliminate the path hiding problem in all 322 situations. Furthermore, this method may significantly increase the 323 number of BGP sessions handled by the route server, which may 324 negatively impact its performance. 326 2.3.2.2.2. BGP ADD-PATH Approach 328 The [I-D.ietf-idr-add-paths] Internet draft proposes a different 329 approach to multiple path propagation, by allowing a BGP speaker to 330 forward multiple paths for the same prefix on a single BGP session. 331 As [RFC4271] specifies that a BGP listener must implement an implicit 332 withdraw when it receives an UPDATE message for a prefix which 333 already exists in its Adj-RIB-In, this approach requires explicit 334 support for the feature both on the route server and on its clients. 336 If the ADD-PATH capability is negotiated bidirectionally between the 337 route server and a route server client, and the route server client 338 propagates multiple paths for the same prefix to the route server, 339 then this could potentially cause the propagation of inactive, 340 invalid or suboptimal paths to the route server, thereby causing loss 341 of reachability to other route server clients. For this reason, ADD- 342 PATH implementations on a route server SHOULD enforce send-only mode 343 with the route server clients, which would result in negotiating 344 receive-only mode from the client to the route server. 346 2.3.3. Implementation Recommendations 348 A route server SHOULD implement one of the methods described in 349 Section 2.3.2 to allow per-client routing policy control without 350 "path hiding". 352 3. Security Considerations 354 The path hiding problem outlined in section Section 2.3.1 can be used 355 in certain circumstances to proactively block third party path 356 announcements from other route server clients. Route server 357 operators should be aware that security issues may arise unless steps 358 are taken to mitigate against path hiding. 360 4. IANA Considerations 362 The new set of mechanisms for route servers does not require any new 363 allocations from IANA. 365 5. Acknowledgments 367 The authors would like to thank Ryan Bickhart, Steven Bakker, Martin 368 Pels, Chris Hall, Aleksi Suhonen, Bruno Decraene, Pierre Francois and 369 Eduardo Ascenco Reis for their valuable input. 371 In addition, the authors would like to acknowledge the developers of 372 BIRD, OpenBGPD, Quagga and IOS whose BGP implementations include 373 route server capabilities which are compliant with this document. 375 Route server functionality was described in 1995 in [RFC1863] and 376 modern route server implementations are based on concepts developed 377 in the 1990s by the Routing Arbiter Project and the Route Server Next 378 Generation Project, managed by ISI and Merit. Although the original 379 RSNG code is no longer in use at any IXPs, the IXP community owes a 380 debt of gratitude to the many people who were involved in route 381 server development in the 1990s. 383 6. References 385 6.1. Normative References 387 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 388 Communities Attribute", RFC 1997, August 1996. 390 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 391 Requirement Levels", BCP 14, RFC 2119, March 1997. 393 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 394 Protocol 4 (BGP-4)", RFC 4271, January 2006. 396 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 397 Communities Attribute", RFC 4360, February 2006. 399 6.2. Informative References 401 [I-D.ietf-idr-add-paths] 402 Walton, D., Retana, A., Chen, E., and J. Scudder, 403 "Advertisement of Multiple Paths in BGP", 404 draft-ietf-idr-add-paths-10 (work in progress), 405 October 2014. 407 [RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full 408 mesh routing", RFC 1863, October 1995. 410 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 411 Reflection: An Alternative to Full Mesh Internal BGP 412 (IBGP)", RFC 4456, April 2006. 414 [RFC6774] Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K. 415 Kumaki, "Distribution of Diverse BGP Paths", RFC 6774, 416 November 2012. 418 Authors' Addresses 420 Elisa Jasinska 421 Netflix, Inc 422 100 Winchester Circle 423 Los Gatos, CA 95032 424 USA 426 Email: elisa@netflix.com 428 Nick Hilliard 429 INEX 430 4027 Kingswood Road 431 Dublin 24 432 IE 434 Email: nick@inex.ie 436 Robert Raszuk 437 Mirantis Inc. 438 615 National Ave. #100 439 Mt View, CA 94043 440 USA 442 Phone: 443 Fax: 444 Email: robert@raszuk.net 445 URI: 447 Niels Bakker 448 Akamai Technologies B.V. 449 Kingsfordweg 151 450 Amsterdam 1043 GR 451 NL 453 Email: nbakker@akamai.com