idnits 2.17.1 draft-ietf-idr-ix-bgp-route-server-00.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 (March 26, 2012) is 4412 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) == Unused Reference: 'RFC1863' is defined on line 407, but no explicit reference was found in the text == Unused Reference: 'RFC4223' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'RFC4760' is defined on line 413, but no explicit reference was found in the text == Unused Reference: 'RFC5065' is defined on line 417, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 420, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-grow-diverse-bgp-path-dist-06 ** Downref: Normative reference to an Informational draft: draft-ietf-grow-diverse-bgp-path-dist (ref. 'I-D.ietf-grow-diverse-bgp-path-dist') == Outdated reference: A later version (-15) exists of draft-ietf-idr-add-paths-06 -- Obsolete informational reference (is this intentional?): RFC 1863 (Obsoleted by RFC 4223) -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IDR Working Group E. Jasinska 3 Internet-Draft Limelight Networks 4 Intended status: Standards Track N. Hilliard 5 Expires: September 27, 2012 INEX 6 R. Raszuk 7 NTT MCL Inc. 8 N. Bakker 9 AMS-IX B.V. 10 March 26, 2012 12 Internet Exchange Route Server 13 draft-ietf-idr-ix-bgp-route-server-00 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 September 27, 2012. 43 Copyright Notice 45 Copyright (c) 2012 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. Specification of Requirements . . . . . . . . . . . . . . 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. Implementing Per-Client Policy Control . . . . . . . . 7 73 2.3.2.1. Multiple Route Server RIBs . . . . . . . . . . . . 7 74 2.3.2.2. Advertising Multiple Paths . . . . . . . . . . . . 7 75 3. Security Considerations . . . . . . . . . . . . . . . . . . . 8 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 77 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 78 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 79 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 80 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 83 1. Introduction to Multilateral Interconnection 85 Internet exchange points (IXPs) provide IP data interconnection 86 facilities for their participants, typically using shared Layer-2 87 networking media such as Ethernet. The Border Gateway Protocol (BGP) 88 [RFC4271], an inter-Autonomous System routing protocol, is commonly 89 used to facilitate exchange of network reachability information over 90 such media. 92 While bilateral exterior BGP sessions between exchange participants 93 were previously the most common means of exchanging reachability 94 information, the overhead associated with dense interconnection has 95 caused substantial operational scaling problems for Internet exchange 96 point participants. 98 Multilateral interconnection is a method of interconnecting BGP 99 speaking routers using a third party brokering system, commonly 100 referred to as a route server and typically managed by the IXP 101 operator. Each of the multilateral interconnection participants 102 (usually referred to as route server clients) announces network 103 reachability information to the route server using exterior BGP, and 104 the route server in turn forwards this information to each other 105 route server client connected to it, according to its configuration. 106 Although a route server uses BGP to exchange reachability information 107 with each of its clients, it does not forward traffic itself and is 108 therefore not a router. 110 A route server can be viewed as similar in function to an [RFC4456] 111 route reflector, except that it operates using EBGP instead of iBGP. 112 Certain adaptions to [RFC4271] are required to enable an EBGP router 113 to operate as a route server, which are outlined in Section 2 of this 114 document. 116 The term "route server" is often in a different context used to 117 describe a BGP node whose purpose is to accept BGP feeds from 118 multiple clients for the purpose of operational analysis and 119 troubleshooting. A system of this form may alternatively be known as 120 a "route collector" or a "route-views server". This document uses 121 the term "route server" exclusively to describe multilateral peering 122 brokerage systems. 124 1.1. Specification of Requirements 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 128 "OPTIONAL" in this document are to be interpreted as described in 129 [RFC2119]. 131 2. Technical Considerations for Route Server Implementations 133 2.1. Client UPDATE Messages 135 A route server MUST accept all UPDATE messages received from each of 136 its clients for inclusion in its Adj-RIB-In. These UPDATE messages 137 MAY by omitted from the route server's Loc-RIB or Loc-RIBs, due to 138 filters configured for the purposes of implementing routing policy. 139 The route server SHOULD perform one or more BGP Decision Processes to 140 select routes for subsequent advertisement to its clients, taking 141 into account possible configuration to provide multiple NLRI paths to 142 a particular client as described in Section 2.3.2.2 or multiple Loc- 143 RIBs as described in Section 2.3.2.1. The route server SHOULD 144 forward UPDATE messages where appropriate from its Loc-RIB or Loc- 145 RIBs to its clients. 147 2.2. Attribute Transparency 149 As a route server primarily performs a brokering service, 150 modification of attributes could cause route server clients to alter 151 their BGP best path selection process for received prefix 152 reachability information, thereby changing the intended routing 153 policies of exchange participants. Therefore, contrary to what is 154 specified in section 5. of [RFC4271], route servers SHOULD NOT by 155 default (unless explicitly configured) update well-known BGP 156 attributes received from route server clients before redistributing 157 them to their other route server clients. Optional recognized and 158 unrecognized BGP attributes, whether transitive or non-transitive, 159 SHOULD NOT be updated by the route server (unless enforced by local 160 IX operator configuration) and SHOULD be passed on to other route 161 server clients. 163 2.2.1. NEXT_HOP Attribute 165 The NEXT_HOP, a well-known mandatory BGP attribute, defines the IP 166 address of the router used as the next hop to the destinations listed 167 in the Network Layer Reachability Information field of the UPDATE 168 message. As the route server does not participate in the actual 169 routing of traffic, the NEXT_HOP attribute MUST be passed unmodified 170 to the route server clients, similar to the "third party" next hop 171 feature described in section 5.1.3. of [RFC4271]. 173 2.2.2. AS_PATH Attribute 175 AS_PATH is a well-known mandatory attribute which identifies the 176 autonomous systems through which routing information carried in the 177 UPDATE message has passed. 179 As a route server does not participate in the process of forwarding 180 data between client routers, and because modification of the AS_PATH 181 attribute could affect route server client best path calculations, 182 the route server SHOULD NOT prepend its own AS number to the AS_PATH 183 segment nor modify the AS_PATH segment in any other way. 185 2.2.3. MULTI_EXIT_DISC Attribute 187 MULTI_EXIT_DISC is an optional non-transitive attribute intended to 188 be used on external (inter-AS) links to discriminate among multiple 189 exit or entry points to the same neighboring AS. If applied to an 190 NLRI UPDATE sent to a route server, the attribute (contrary to 191 section 5.1.4 of [RFC4271]) SHOULD be propagated to other route 192 server clients and the route server SHOULD NOT modify the value of 193 this attribute. 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 for ensuring 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", which is described in Section 2.3.1. 217 Route server implementations SHOULD implement one of the methods 218 described in Section 2.3.2, for the operator to be able to allow the 219 control of path distribution on a per-client basis without the 220 occurrence of "path hiding". 222 2.3.1. Path Hiding on a Route Server 224 ___ ___ 225 / \ / \ 226 ..| AS1 |..| AS2 |.. 227 : \___/ \___/ : 228 : \ / | : 229 : \ / | : 230 : IXP \/ | : 231 : /\ | : 232 : / \ | : 233 : ___/____\_|_ : 234 : / \ / \ : 235 ..| AS3 |..| AS4 |.. 236 \___/ \___/ 238 Figure 1: Per-Client Policy Controlled Interconnection at an IXP 240 Using the example in Figure 1, AS1 does not directly exchange prefix 241 information with either AS2 or AS3 at the IXP, but only interconnects 242 with AS4. 244 In the traditional bilateral interconnection model, per-client policy 245 control to a third party exchange participant is accomplished either 246 by not engaging in a bilateral interconnection with that participant 247 or else by implementing outbound filtering on the BGP session towards 248 that participant. However, in a multilateral interconnection 249 environment, only the route server can perform outbound filtering in 250 the direction of the route server client; route server clients depend 251 on the route server to perform their outbound filtering for them. 253 Assuming a traditional best path selection, when the same prefix is 254 advertised to a route server from multiple route server clients, the 255 route server will select a single best path for propagation to all 256 connected clients. If, however, the route server has been configured 257 to filter the calculated best path from reaching a particular route 258 server client, then that client will not receive a path for that 259 prefix, although alternate paths received by the route server might 260 have been policy compliant for that client. This phenomenon is 261 referred to as "path hiding". 263 For example, in Figure 1, if the same prefix were sent to the route 264 server via AS2 and AS4, and the route via AS2 was preferred according 265 to BGP's traditional best path selection, but AS1's policy prevents 266 AS2's path from being accepted, then AS1 would never receive a path 267 to this prefix, even though the route server had previously received 268 a valid alternative path via AS4. This happens because the best path 269 selection is performed only once on the route server for all clients. 271 Path hiding will only occur on route servers which employ per-client 272 policy control; if an IXP operator deploys a route server without the 273 possibility for policy control, then path hiding does not occur, as 274 all paths are considered equally valid from the point of view of the 275 route server. 277 2.3.2. Implementing Per-Client Policy Control 279 In this section, we describe the alternatives to provide per-client 280 policy control while preventing the occurrence of path hiding. 282 2.3.2.1. Multiple Route Server RIBs 284 The most portable means to allow for per-client policy control 285 without the occurrence of path hiding, is by using a route server BGP 286 implementation which performs the per-client best path calculation 287 for each set of paths to a prefix, which results after the route 288 server's client policies have been taken into consideration. This 289 can be implemented by using per-client Loc-RIBs, with path filtering 290 implemented between the Adj-RIB-In and the per-client Loc-RIB. 291 Implementations MAY optimize this by maintaining paths not subject to 292 filtering policies in a global Loc-RIB, with per-client Loc-RIBs 293 stored as deltas. 295 This implementation is highly portable, as it makes no assumptions 296 about the feature capabilities of the route server clients. 298 2.3.2.2. Advertising Multiple Paths 300 The path distribution model described above assumes standard BGP 301 session encoding where the route server sends a single path to its 302 client for any given prefix. This path is selected using the BGP 303 path selection decision process described in [RFC4271]. If, however, 304 it were possible for the route server to send more than a single path 305 to a route server client, then route server clients would no longer 306 depend on receiving a single best path to a particular prefix; 307 consequently, the path hiding problem described in Section 2.3.1 308 would disappear. 310 We present two methods which describe how such increased path 311 diversity could be implemented. 313 2.3.2.2.1. Diverse BGP Path Approach 315 The Diverse BGP Path proposal as defined in 316 [I-D.ietf-grow-diverse-bgp-path-dist] is a simple way to distribute 317 multiple prefix paths from a route server to a route server client by 318 using a separate BGP session from the route server to a client for 319 each different path. 321 The number of paths which may be distributed to a client is 322 constrained by the number of BGP sessions which the server and the 323 client are willing to establish with each other. The distributed 324 paths may be established from the global BGP Loc-RIB on the route 325 server in addition to any per-client Loc-RIB. As there may be more 326 potential paths to a given prefix than configured BGP sessions, this 327 method is not guaranteed to eliminate the path hiding problem in all 328 situations. Furthermore, this method may significantly increase the 329 number of BGP sessions handled by the route server, which may 330 negatively impact its performance. 332 2.3.2.2.2. BGP ADD-PATH Approach 334 The [I-D.ietf-idr-add-paths] Internet draft proposes a different 335 approach to multiple path propagation, by allowing a BGP speaker to 336 forward multiple paths for the same prefix on a single BGP session. 337 As [RFC4271] specifies that a BGP listener must implement an implicit 338 withdraw when it receives an UPDATE message for a prefix which 339 already exists in its Adj-RIB-In, this approach requires explicit 340 support for the feature both on the route server and on its clients. 342 If the ADD-PATH capability is negotiated bidirectionally between the 343 route server and a route server client, and the route server client 344 propagates multiple paths for the same prefix to the route server, 345 then this could potentially cause the propagation of inactive, 346 invalid or suboptimal paths to the route server, thereby causing loss 347 of reachability to other route server clients. For this reason, ADD- 348 PATH implementations on a route server SHOULD enforce send-only mode 349 with the route server clients, which would result in negotiating 350 receive-only mode from the client to the route server. 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. 358 4. IANA Considerations 360 The new set of mechanism for route servers does not require any new 361 allocations from IANA. 363 5. Acknowledgments 365 The authors would like to thank Ryan Bickhart, Steven Bakker, Chris 366 Hall, Bruno Decraene and Pierre Francois for their valuable input. 368 In addition, the authors would like to acknowledge the developers of 369 BIRD, OpenBGPD and Quagga, whose open source BGP implementations 370 include route server capabilities which are compliant with this 371 document. 373 6. References 375 6.1. Normative References 377 [I-D.ietf-grow-diverse-bgp-path-dist] 378 Raszuk, R., Fernando, R., Patel, K., McPherson, D., and K. 379 Kumaki, "Distribution of diverse BGP paths.", 380 draft-ietf-grow-diverse-bgp-path-dist-06 (work in 381 progress), November 2011. 383 [I-D.ietf-idr-add-paths] 384 Walton, D., Chen, E., Retana, A., and J. Scudder, 385 "Advertisement of Multiple Paths in BGP", 386 draft-ietf-idr-add-paths-06 (work in progress), 387 September 2011. 389 [RFC1997] Chandrasekeran, R., Traina, P., and T. Li, "BGP 390 Communities Attribute", RFC 1997, August 1996. 392 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 393 Requirement Levels", BCP 14, RFC 2119, March 1997. 395 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 396 Protocol 4 (BGP-4)", RFC 4271, January 2006. 398 [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 399 Communities Attribute", RFC 4360, February 2006. 401 [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route 402 Reflection: An Alternative to Full Mesh Internal BGP 403 (IBGP)", RFC 4456, April 2006. 405 6.2. Informative References 407 [RFC1863] Haskin, D., "A BGP/IDRP Route Server alternative to a full 408 mesh routing", RFC 1863, October 1995. 410 [RFC4223] Savola, P., "Reclassification of RFC 1863 to Historic", 411 RFC 4223, October 2005. 413 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 414 "Multiprotocol Extensions for BGP-4", RFC 4760, 415 January 2007. 417 [RFC5065] Traina, P., McPherson, D., and J. Scudder, "Autonomous 418 System Confederations for BGP", RFC 5065, August 2007. 420 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 421 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 422 May 2008. 424 Authors' Addresses 426 Elisa Jasinska 427 Limelight Networks 428 2220 W 14th St 429 Tempe, AZ 85281 430 US 432 Email: elisa@llnw.com 434 Nick Hilliard 435 INEX 436 4027 Kingswood Road 437 Dublin 24 438 IE 440 Email: nick@inex.ie 442 Robert Raszuk 443 NTT MCL Inc. 444 101 S Ellsworth Avenue Suite 350 445 San Mateo, CA 94401 446 US 448 Email: robert@raszuk.net 449 Niels Bakker 450 AMS-IX B.V. 451 Westeinde 12 452 Amsterdam, NH 1017 ZN 453 NL 455 Email: niels.bakker@ams-ix.net