idnits 2.17.1 draft-gredler-idr-bgplu-epe-11.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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 06, 2017) is 2387 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3107 (Obsoleted by RFC 8277) == Outdated reference: A later version (-07) exists of draft-ietf-idr-link-bandwidth-06 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Inter-Domain Routing H. Gredler, Ed. 3 Internet-Draft RtBrick Inc. 4 Intended status: Informational K. Vairavakkalai 5 Expires: April 9, 2018 C. Ramachandran 6 B. Rajagopalan 7 E. Aries 8 Juniper Networks, Inc. 9 L. Fang 10 eBay 11 October 06, 2017 13 Egress Peer Engineering using BGP-LU 14 draft-gredler-idr-bgplu-epe-11 16 Abstract 18 The MPLS source routing paradigm provides path control for both 19 intra- and inter- Autonomous System (AS) traffic. RSVP-TE is 20 utilized for intra-AS path control. This documents outlines how MPLS 21 routers may use the BGP labeled unicast protocol (BGP-LU) for doing 22 traffic-engineering on inter-AS links. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 9, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Motivation, Rationale and Applicability . . . . . . . . . . . 3 66 3. Sample Topology . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Loopback IP addresses and Router-IDs . . . . . . . . . . 4 68 3.2. Link IP addresses . . . . . . . . . . . . . . . . . . . . 5 69 4. Service Route Advertisement . . . . . . . . . . . . . . . . . 5 70 5. Egress Next-hop Advertisement . . . . . . . . . . . . . . . . 5 71 5.1. iBGP meshing and BGP nexthop rewrite policy . . . . . . . 6 72 5.2. Single-hop eBGP . . . . . . . . . . . . . . . . . . . . . 7 73 5.3. Multi-hop eBGP . . . . . . . . . . . . . . . . . . . . . 8 74 5.4. Grouping of Peers . . . . . . . . . . . . . . . . . . . . 9 75 5.5. Supporting Summarization at ASBR . . . . . . . . . . . . 10 76 5.5.1. Locality forwarding bias . . . . . . . . . . . . . . 10 77 5.5.2. Label per group of peers sharing a locality . . . . . 10 78 6. Egress Link Protection . . . . . . . . . . . . . . . . . . . 10 79 6.1. FRR backup routes . . . . . . . . . . . . . . . . . . . . 10 80 6.1.1. Local links . . . . . . . . . . . . . . . . . . . . . 11 81 6.1.2. Remote BGP-LU labels . . . . . . . . . . . . . . . . 11 82 6.1.3. Local IP forwarding tables . . . . . . . . . . . . . 11 83 6.2. Avoiding micro-loops during FRR . . . . . . . . . . . . . 11 84 7. Dynamic link utilization . . . . . . . . . . . . . . . . . . 11 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 87 10. Security Considerations . . . . . . . . . . . . . . . . . . . 12 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 12 90 11.2. Informative References . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 93 1. Introduction 95 Today, BGP-LU [RFC3107] is used both as an intra-AS 96 [I-D.ietf-mpls-seamless-mpls] and inter-AS routing protocol. BGP-LU 97 may advertise a MPLS transport path between IGP regions and 98 Autonomous Systems. Those paths may span one or more router hops. 99 This document describes advertisement and use of one-hop MPLS label- 100 switched paths (LSPs) for traffic-engineering the links between 101 Autonomous Systems. 103 Consider Figure 1: an ASBR router (R2) advertises a labeled host 104 route for the remote-end IP address of its link (IP3). The BGP next- 105 hop gets set to R2s loopback IP address. For the advertised Label 106 a forwarding action of 'POP and forward' to next-hop (IP3) is 107 installed in R2's MPLS forwarding table. Now consider if R2 had 108 several links and R2 would advertise labels for all of its inter-AS 109 links. By pushing the corresponding MPLS label on the label- 110 stack an ingress router R1 may control the egress peer selection. 112 AS1 : AS2 113 : 114 +----+ iBGP +----+ : eBGP +----+ 115 | R1 |----------| R2 |-IP2----IP3-| R3 | 116 +----+ +----+ : +----+ 117 : 118 -----------traffic-flow----------> 119 <------------route-flow----------- 121 Figure 1: single-hop LSPs 123 Of course, since R1 and R2 may not be directly connected to each 124 other, if the interior routers within AS1 do not maintain routes to 125 external destinations, carrying traffic to such destinations would 126 require a tunnel from R1 to R2. Such tunnel could be realized as 127 either a MPLS Label Switched Path (LSP), or by GRE [RFC2784]. 129 2. Motivation, Rationale and Applicability 131 BGP-LU is often just seen as a 'stitching' protocol for connecting 132 Autonomous Systems. BGP-LU is often not viewed as a viable protocol 133 for solving the Inter-domain traffic-engineering problem. 135 With this document the authors want to clarify the use of BGP-LU for 136 Egress Peering traffic-engineering purposes and encourage both 137 implementers and network operators to use a widely deployed and 138 operationally well understood protocol, rather than inventing new 139 protocols or new extensions to the existing protocols. 141 3. Sample Topology 143 The following topology (Figure 2) and IP addresses shall be used 144 throughout the Egress Peering Engineering advertisement examples. 146 : : 147 AS 1 : AS 2 : AS 4 148 : : 149 : +-----+ : 150 /IP2--:-IP3--|ASBR3| : 151 +-----+ +-----+-IP4--:-IP5--+-----+-----------+-----+ 152 | R1 +-------------+ASBR1| : |ASBR6| 153 +--+--+ +--+--+-IP6--:-IP7--+-----+-----------+-----+ 154 | | \ : |ASBR4| : / 155 | | \ : +-----+ : / 156 | | IP8- --- 157 | | \ ................ / 158 | | IP9- --- 159 | | : \ / : 160 | | : \ / : 161 +--+--+ +--+--+ : +--+--+ : 162 | R2 +-------------+ASBR2|-IP10-:-IP11-|ASBR5| : 163 +-----+ +-----+ : +-----+ : 164 : : 165 : AS3 : 166 : : 168 Figure 2: Sample Topology 170 3.1. Loopback IP addresses and Router-IDs 172 o R1: 192.0.2.1/32 174 o R2: 192.0.2.2/32 176 o ASBR1: 192.0.2.11/32 178 o ASBR2: 192.0.2.12/32 180 o ASBR3: 192.0.2.13/32 182 o ASBR4: 192.0.2.14/32 184 o ASBR5: 192.0.2.15/32 186 o ASBR6: 192.0.2.16/32 188 3.2. Link IP addresses 190 o ASBR1 (203.0.113.2/31) to ASBR3 (203.0.113.3/31) link #1 192 o ASBR1 (203.0.113.4/31) to ASBR3 (203.0.113.5/31) link #2 194 o ASBR1 (203.0.113.6/31) to ASBR4 (203.0.113.7/31) 196 o ASBR1 (203.0.113.8/31) to ASBR5 (203.0.113.9/31) 198 o ASBR2 (203.0.113.10/31) to ASBR5 (203.0.113.11/31) 200 4. Service Route Advertisement 202 In Figure 3 a simple network layout is shown. There are two classes 203 of BGP speakers: 205 1. Ingress Routers 207 2. Controllers 209 Ingress routers receive BGP-LU routes from the ASBRs. Each BGP-LU 210 route corresponds to an egress link. Furthermore Ingress routers 211 receive their service routes using the BGP protocol. The BGP Add- 212 paths extension [I-D.ietf-idr-add-paths] ensures that multiple paths 213 to a given service route may get advertised. 215 As outlined in [I-D.filsfils-spring-segment-routing-central-epe], 216 Controllers receive BGP-LU routes from the ASBRs as well. However 217 the service routes may be received either using the BGP protocol plus 218 the BGP Add-paths extension [I-D.ietf-idr-add-paths] or alternatively 219 The BGP Monitoring protocol [I-D.ietf-grow-bmp] (BMP). BMP has 220 support for advertising the RIB-In of a BGP router. As such it might 221 be a suitable protocol for feeding all potential egress paths of a 222 service-route from a ASBR into a controller. 224 5. Egress Next-hop Advertisement 226 An ASBR assigns a distinct label for each of its next-hops facing an 227 eBGP peer and advertises it to its internal BGP mesh. The ASBR 228 programs a forwarding action 'POP and forward' into the MPLS 229 forwarding table. Note that the neighboring AS is not required to 230 support exchanging NLRIs with the local AS using BGP-LU. It is the 231 local ASBR (ASBR{1,2}) which generates the BGP-LU routes into its 232 iBGP mesh or controller facing session(s). The forwarding next-hop 233 for those routes points to the link-IP addresses of the remote ASBRs 234 (ASBR{3,4,5}). Note that the generated BGP-LU routes always match 235 the BGP next-hop that the remote ASBRs set their BGP service routes 236 to, such that the software component doing route-resolution 237 understands the association between the BGP service route and the 238 BGP-LU forwarding route. 240 5.1. iBGP meshing and BGP nexthop rewrite policy 242 Throughout this document we describe how the BGP next-hop of both BGP 243 Service Routes and BGP-LU routes shall be rewritten. This may clash 244 with existing network deployments and existing network configurations 245 guidelines which may mandate to rewrite the BGP next-hop when an BGP 246 update enters an AS. 248 The Egress peering use case assumes a central controller as shown 249 Figure 3. In order to support both existing BGP nexthop guidelines 250 and the suggestion described in this document, an implementation 251 SHOULD support several internal BGP peer-groups: 253 1. iBGP peer group for Ingress Routers 255 2. iBGP peer group for Controllers 257 The first peer group MAY be left unchanged and use any existing BGP 258 nexthop rewrite policy. The second peer group MUST use the BGP 259 rewrite policy described in this document for both service and BGP-LU 260 routes. 262 Of course a common iBGP peer group and a common rewrite policy may be 263 used if the proposed policy is compatible with existing routing 264 software implementations of BGP next-hop route resolution. 266 +-----------+ 267 | Ingress | 268 | Router | 269 +-----------+ 270 ^ 271 | 272 +-----------+ 273 | BGP | +------------+ 274 | Route |-------------->| Controller | 275 | Reflector | +------------+ 276 +-----------+ ^ 277 ^ ^ | 278 | | | 279 | +-------------------+ | 280 | | | 281 v v v 282 +-----------+ +-----------+ 283 | BGP | | BGP | 284 | ASBR1 | . . . | ASBR2 | 285 +-----------+ +-----------+ 287 Figure 3: Selective iBGP NH rewrite 289 5.2. Single-hop eBGP 291 In Figure 2 the ASBR{1,5} and ASBR{2,5} links are examples for 292 single-hop eBGP advertisements. 294 o ASBR5 advertises a BGP service (SAFI-1) route {172.16/12} to ASBR1 295 with a BGP next-hop of 203.0.113.9. When ASBR1 re-advertises this 296 BGP service route towards its iBGP mesh (R{1,2}) it does not 297 overwrite the BGP next-hop, but rather leaves it unchanged. 299 o ASBR1 advertises a BGP-LU route {203.0.113.9/32, label 100} with a 300 BGP next hop of 192.0.2.11. ASBR1 programs a MPLS forwarding 301 state of 'POP and forward' to 203.0.113.9 for the advertised label 302 100. 304 o ASBR5 advertises a BGP service (SAFI-1) route {172.16/12} to ASBR2 305 with a BGP next-hop of 203.0.113.11. When ASBR2 re-advertises 306 this BGP service route towards its iBGP mesh (R{1,2}) it does not 307 overwrite the BGP next-hop, but rather leaves it unchanged. 309 o ASBR2 advertises BGP-LU route {203.0.113.11/32, label 101} with a 310 BGP next hop of 192.0.2.12. ASBR2 programs a MPLS forwarding 311 state of 'POP and forward' to 203.0.113.11 for the advertised 312 label 101. 314 o Should the operator already be redistributing egress links into 315 the network for purposes of BGP next-hop resolution, the BGP-LU 316 route {203.0.113.9/32, label 100} will now take precedence due to 317 LPM over the previous redistributed prefix {203.0.113.8/31}. If 318 the BGP next-hop prefix {203.0.113.9/32} were to be redistributed 319 as-is, then standard protocol best-path and preference selection 320 mechanisms will be exhausted in order to select the best-path. 322 o In general, ASBR1 may receive advertisements for the route to 323 172.16/12 from ASBR3 and ASBR4, as well as from ASBR5. One of 324 these other advertisements may be chosen as the best path by the 325 BGP decision process. In order to allow ASBR1 to re-advertise the 326 route to 172.16/12 received from ASBR5 with next-hop 203.0.113.9, 327 independent of the other advertisements received, ASBR1 and R{1,2} 328 need to support the BGP add-paths extension. 329 [I-D.ietf-idr-add-paths]. 331 5.3. Multi-hop eBGP 333 Todays operational practice for load-sharing across parallel links is 334 to configure a single multi-hop eBGP session between a pair of 335 routers. The IP addresses for the Multi-hop eBGP session are 336 typically sourced from the loopback IP interfaces. Note that those 337 IP addresses do not share an IP subnet. Most often those loopback IP 338 addresses are most specific host routes. Since the BGP next-hops of 339 the received BGP service routes are typically rewritten to the remote 340 routers loopback IP address they cannot get immediatly resolved by 341 the receiving router. To overcome this, the operator configures a 342 static route with next-hops pointing to each of the remote-IP 343 addresses of the underlying links. 345 In Figure 2 both ASBR{1,3} links are examples of a multi-hop eBGP 346 advertisement. In order to advertise a distinct label for a common 347 FEC throughout the iBGP mesh, ASBR1 and all the receiving iBGP 348 routers need to support the BGP Add-paths extension. 349 [I-D.ietf-idr-add-paths]. 351 o ASBR3 advertises a BGP service (SAFI-1) route {172.16/12} over 352 multi-hop eBGP to ASBR1 with a BGP next-hop of 192.0.2.13. When 353 ASBR1 re-advertises this BGP service route towards its iBGP mesh 354 (R{1,2}) it does not overwrite the BGP next-hop, but rather leaves 355 it unchanged. Note that the iBGP routers SHOULD support the BGP 356 Add-paths extension [I-D.ietf-idr-add-paths] such that ASBR can 357 re-advertise all paths to the SAFI-1 route {172.16/12}. 359 o For link #1, ASBR1 advertises into its iBGP mesh a BGP-LU route 360 {192.0.2.13/32, label 102} with a BGP next hop of 192.0.2.11. To 361 differentiate this from the link #2 route-advertisement (which 362 contains the same FEC) it is setting the path-ID to 1. ASBR1 363 programs a MPLS forwarding state of 'POP and forward' to 364 203.0.113.3 for the advertised label 102. 366 o For link #2, ASBR1 advertises into its iBGP mesh a BGP-LU route 367 {192.0.2.13/32, label 103} with a BGP next hop of 192.0.2.11. To 368 differentiate this from the link #1 route-advertisement (which 369 contains the same FEC) it is setting the path-ID to 2. ASBR1 370 programs a MPLS forwarding state of 'POP and forward' to 371 203.0.113.5 for the advertised label 103. 373 o Should the operator already be redistributing static routes into 374 the network, the BGP next-hop {192.0.2.13} may already be 375 resolvable. It is then that standard protocol best-path and 376 preference selection mechanisms will be exhausted in order to 377 select the best-path. 379 5.4. Grouping of Peers 381 In addition to offering a distinct BGP-LU label for each egress link, 382 an ASBR MAY want to advertise a BGP-LU label which represents a load- 383 balancing forwarding action across a set of peers. The difference is 384 here that the ingress node gives up individual link control, but 385 rather delegates the load-balancing decision to a particular egress 386 router which has the freedom to send the traffic down to any link in 387 the Peer Set as identified by the BGP-LU label. 389 Assume that ASBR1 wants to advertise a label identifying the Peer Set 390 {ASBR3, ASBR4, ASBR5}. 392 o For the two ASBR{1,3} links in Figure 2, belonging to Peer Set 1, 393 ASBR1 advertises a single BGP-LU route {192.0.2.13/32, label 104} 394 with a BGP next hop of 192.0.2.11. To differentiate this from the 395 ASBR{1,3} single link route-advertisements (which contains the 396 same FEC) it is setting the path-ID to 3 and attaching a Peer-Set 397 Community 'Peer Set 1'. 399 o For the ASBR{1,4} link in Figure 2, ASBR1 advertises a BGP-LU 400 route {203.0.113.7/32, label 104} with a BGP next hop of 401 192.0.2.11. To differentiate this from the ASBR{1,4} single link 402 route-advertisements (which contains the same FEC) it is setting 403 the path-ID to 2 and attaching a Peer-Set Community 'Peer Set 1'. 405 o For the ASBR{1,5} link in Figure 2, ASBR1 advertises a BGP-LU 406 route {203.0.113.9/32, label 104} with a BGP next hop of 407 192.0.2.11. To differentiate this from the ASBR{1,5} single link 408 route-advertisements (which contains the same FEC) it is setting 409 the path-ID to 2 and attaching a Peer-Set Community 'Peer Set 1'. 411 Finally ASBR1 programs a MPLS forwarding state of 'POP and load- 412 balance' to {203.0.113.3, 203.0.113.5, 203.0.113.7, 203.0.113.9} for 413 the advertised label 104. 415 5.5. Supporting Summarization at ASBR 417 5.5.1. Locality forwarding bias 419 A router has one or more forwarding plane units. A forwarding plane 420 unit consists of one or more interfaces. Forwarding of packets to an 421 interface that is member of a forwarding plane unit is cheaper than 422 across units. 424 A route entry in the forwarding-table may contain multiple next-hops, 425 each pointing to a network-interface. When forwarding a packet, a 426 forwarding plane unit may optionally provide preference to a subset 427 of these next-hops, whose interfaces are its own members. This 428 behavior is called "Locality forwarding bias". 430 5.5.2. Label per group of peers sharing a locality 432 An ASBR MAY assign a distinct label for the set of eBGP-peers that 433 share a forwarding plane unit and advertise it to its internal BGP 434 mesh. The ASBR programs a forwarding action 'POP and IP-lookup' into 435 the MPLS forwarding table for these labels. While performing the IP- 436 lookup, the ASBR MUST perform "Locality-forwarding bias" to ensure it 437 only selects next-hops towards eBGP peers that are attached to the 438 current forwarding plane unit, where the IP-lookup is happening. 440 This provides the ingress-peers with ability to steer traffic towards 441 a "subset of eBGP-peers" attached to an ASBR, while preserving the 442 ability of the ASBR to aggregate the IP prefixes received from those 443 eBGP-peers, while re-advertising to the internal BGP mesh. 445 6. Egress Link Protection 447 It is desirable to provide a local-repair based protection scheme, in 448 case a redundant path is available to reach a peer AS. Protection 449 may be applied at multiple levels in the routing stack. Since the 450 ASBR has insight into both BGP-LU and BGP service advertisements, 451 protection can be provided at the BGP-LU, at the BGP service or both 452 levels. 454 6.1. FRR backup routes 456 Assume the network operator wants to provide a local-repair next-hop 457 for the 172.16/12 BGP service route at ASBR1. The active route 458 resolves over the parallel links towards ASBR3. In case the link #1 459 between ASBR{1,3} fails there are now several candidate backup paths 460 providing protection against link or node failure. 462 6.1.1. Local links 464 Assuming that the remaining link #2 between ASBR{1,3} has enough 465 capacity, and link-protection is sufficient, this link MAY serve as 466 temporary backup. 468 However if node-protection or additional capacity is desired, then 469 the local link between ASBR{1,4} or ASBR{1,5} MAY be used as 470 temporary backup. 472 6.1.2. Remote BGP-LU labels 474 ASBR1 is both originator and receiver of BGP routing information. 475 For this protection method it is required that the ASBRs support the 476 [I-D.ietf-idr-best-external] behavior. ASBR1 receives both the BGP- 477 LU and BGP service routes from ASBR2 and therefore can use the ASBR2 478 advertised label as a backup path given that ASBR1 has a tunnel 479 towards ASBR2. 481 6.1.3. Local IP forwarding tables 483 For protecting plain unicast (Internet) routing information a very 484 simple backup scheme could be to recurse to the relevant IP 485 forwarding table and do an IP lookup to further determine a new 486 egress link. 488 6.2. Avoiding micro-loops during FRR 490 Typically, Egress Link Protection mechanisms for Service-routes at 491 the ASBRs are susceptible to micro forwarding-loops if the IP-lookup 492 at backup-path ASBR points back to the primary-ASBR for some reason, 493 during local-repair period. 495 By using mechanisms described in this document, such forwarding-loops 496 can be avoided. Because the backup-ASBR will receive a MPLS-packet 497 with EPE label, it will not do an IP-lookup, and will forwarding 498 traffic based on MPLS-label lookup only. Thus the repaired traffic 499 is guaranteed to exit the network towards an Egress-peer at backup- 500 ASBR, and not turn back towards the IBGP core. 502 7. Dynamic link utilization 504 For a software component which controls the egress link selection it 505 may be desirable to know about a particular egress links current 506 utilization, such that it can adjust the traffic that gets sent to a 507 particular interface. 509 In [I-D.ietf-idr-link-bandwidth] a community for reporting link- 510 bandwidth is specified. Rather than reporting the static bandwidth 511 of the link, the ASBRs shall report the available bandwidth as seen 512 by the data-plane via the link-bandwidth community in their BGP-LU 513 update message. 515 It is crucial that ingress routers learn quickly about congestion of 516 an egress link and hence it is desired to get timely updates of the 517 advertised per-link BGP-LU routes carrying the available bandwidth 518 information when the available bandwidth crosses a certain 519 (preconfigured) threshold. 521 Controllers may also utilize the link-bandwidth community among other 522 common mechanisms to retrieve data-plane statistics (e.g. SNMP, 523 NETCONF) 525 8. Acknowledgements 527 Many thanks to Yakov Rekhter, Chris Bowers and Jeffrey (Zhaohui) 528 Zhang for their detailed review and insightful comments. 530 Special thanks to Richard Steenbergen and Tom Scholl who brought up 531 the original idea of using MPLS for BGP based egress load-balancing 532 at their inspiring talk at Nanog 48. 534 9. IANA Considerations 536 This documents does not request any action from IANA. 538 10. Security Considerations 540 This document does not introduce any change in terms of BGP security. 542 11. References 544 11.1. Normative References 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, 548 DOI 10.17487/RFC2119, March 1997, 549 . 551 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 552 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 553 DOI 10.17487/RFC2784, March 2000, 554 . 556 [RFC3107] Rekhter, Y. and E. Rosen, "Carrying Label Information in 557 BGP-4", RFC 3107, DOI 10.17487/RFC3107, May 2001, 558 . 560 11.2. Informative References 562 [I-D.filsfils-spring-segment-routing-central-epe] 563 Filsfils, C., Previdi, S., Patel, K., Shaw, S., Ginsburg, 564 D., and D. Afanasiev, "Segment Routing Centralized Egress 565 Peer Engineering", draft-filsfils-spring-segment-routing- 566 central-epe-05 (work in progress), August 2015. 568 [I-D.ietf-grow-bmp] 569 Scudder, J., Fernando, R., and S. Stuart, "BGP Monitoring 570 Protocol", draft-ietf-grow-bmp-17 (work in progress), 571 January 2016. 573 [I-D.ietf-idr-add-paths] 574 Walton, D., Retana, A., Chen, E., and J. Scudder, 575 "Advertisement of Multiple Paths in BGP", draft-ietf-idr- 576 add-paths-15 (work in progress), May 2016. 578 [I-D.ietf-idr-best-external] 579 Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. 580 Gredler, "Advertisement of the best external route in 581 BGP", draft-ietf-idr-best-external-05 (work in progress), 582 January 2012. 584 [I-D.ietf-idr-link-bandwidth] 585 Mohapatra, P. and R. Fernando, "BGP Link Bandwidth 586 Extended Community", draft-ietf-idr-link-bandwidth-06 587 (work in progress), January 2013. 589 [I-D.ietf-mpls-seamless-mpls] 590 Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz, 591 M., and D. Steinberg, "Seamless MPLS Architecture", draft- 592 ietf-mpls-seamless-mpls-07 (work in progress), June 2014. 594 Authors' Addresses 595 Hannes Gredler (editor) 596 RtBrick Inc. 598 Email: hannes@rtbrick.com 600 Kaliraj Vairavakkalai 601 Juniper Networks, Inc. 602 1194 N. Mathilda Ave. 603 Sunnyvale, CA 94089 604 US 606 Email: kaliraj@juniper.net 608 Chandra Ramachandran 609 Juniper Networks, Inc. 610 Electra, Exora Business Park Marathahalli - Sarjapur Outer Ring Road 611 Bangalore, KA 560103 612 India 614 Email: csekar@juniper.net 616 Balaji Rajagopalan 617 Juniper Networks, Inc. 618 Electra, Exora Business Park Marathahalli - Sarjapur Outer Ring Road 619 Bangalore, KA 560103 620 India 622 Email: balajir@juniper.net 624 Ebben Aries 625 Juniper Networks, Inc. 626 1194 N. Mathilda Ave. 627 Sunnyvale, CA 94089 628 US 630 Email: earies@juniper.net 631 Luyuan Fang 632 eBay 633 411 108th Ave NE 634 Bellevue, WA 98004 635 US 637 Email: lufang@ebay.com