idnits 2.17.1 draft-ietf-grow-bgp-graceful-shutdown-requirements-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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 22, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 GROW Working Group B. Decraene 3 Internet-Draft France Telecom 4 Intended status: Informational P. Francois 5 UCL 6 C. Pelsser 7 IIJ 8 Z. Ahmad 9 Orange Business Services 10 A. J. Elizondo Armengol 11 Telefonica I+D 12 T. Takeda 13 NTT 14 October 22, 2010 16 Requirements for the graceful shutdown of BGP sessions 17 draft-ietf-grow-bgp-graceful-shutdown-requirements-06.txt 19 Status of this Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may contain material 23 from IETF Documents or IETF Contributions published or made publicly 24 available before November 10, 2008. The person(s) controlling the 25 copyright in some of this material may not have granted the IETF 26 Trust the right to allow modifications of such material outside the 27 IETF Standards Process. Without obtaining an adequate license from 28 the person(s) controlling the copyright in such materials, this 29 document may not be modified outside the IETF Standards Process, and 30 derivative works of it may not be created outside the IETF Standards 31 Process, except to format it for publication as an RFC or to 32 translate it into languages other than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on April 20, 2011. 52 Internet-Draft Requirements for the graceful shutdown of BGP sessions 54 Copyright Notice 56 Copyright (c) 2010 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Abstract 71 The Border Gateway Protocol(BGP) is heavily used in Service Provider 72 networks both for Internet and BGP/MPLS VPN services. For resiliency 73 purposes, redundant routers and BGP sessions can be deployed to 74 reduce the consequences of an AS Border Router or BGP session 75 breakdown on customers' or peers' traffic. However simply taking down 76 or even bringing up a BGP session for maintenance purposes may still 77 induce connectivity losses during the BGP convergence. This is not 78 satisfactory any more for new applications (e.g. voice over IP, on 79 line gaming, VPN). Therefore, a solution is required for the graceful 80 shutdown of a (set of) BGP session(s) in order to limit the amount of 81 traffic loss during a planned shutdown. This document expresses 82 requirements for such a solution. 84 Table of Contents 86 1. Conventions used in this document...........................3 87 2. Introduction................................................3 88 3. Problem statement...........................................4 89 3.1. Example of undesirable BGP routing behavior.................4 90 3.2. Causes of packet loss.......................................5 91 4. Terminology.................................................6 92 5. Goals and requirements......................................7 93 6. Reference Topologies........................................9 94 6.1. E-BGP topologies............................................9 95 6.2. I-BGP topologies...........................................11 96 7. Security Considerations....................................15 97 8. IANA Considerations........................................16 98 9. References.................................................16 99 9.1. Normative References.......................................16 100 9.2. Informative References.....................................16 101 10. Acknowledgments............................................17 102 11. Author's Addresses.........................................17 104 Internet-Draft Requirements for the graceful shutdown of BGP sessions 106 1. Conventions used in this document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Introduction 114 The Border Gateway Protocol(BGP) [BGP-4] is heavily used in Service 115 Provider networks both for Internet and BGP/MPLS VPN services [VPN]. 116 For resiliency purposes, redundant routers and BGP sessions can be 117 deployed to reduce the consequences of an AS Border Router or BGP 118 session breakdown on customers' or peers' traffic. 120 We place ourselves in the context where a Service Provider performs a 121 maintenance operation and needs to shut down one or multiple BGP 122 peering link(s) or a whole ASBR. If an alternate path is available 123 within the AS, the requirement is to avoid or reduce customer or peer 124 traffic loss during the BGP convergence. Indeed, as an alternate path 125 is available in the Autonomous System (AS), it should be made 126 possible to reroute the customer or peer traffic on this backup path 127 before the BGP session(s) is/are torn down, the nominal path 128 withdrawn and the forwarding is interrupted on the nominal path. 130 The requirements also cover the subsequent re-establishment of the 131 BGP session as even this "UP" case can currently trigger route loss 132 and thus traffic loss at some routers. 134 Currently, BGP [BGP-4] and MP-BGP [MP-BGP] do not include any 135 operation to gracefully advertise or withdraw a prefix while traffic 136 toward that prefix could still be correctly forwarded using the old 137 path. When a BGP session is taken down, BGP behaves as if it was a 138 sudden link or router failure and withdraws the prefixes learnt over 139 that session, which may trigger traffic loss. There is no mechanism 140 to advertise to its BGP peers that the prefix will soon be 141 unreachable, while still being reachable. When applicable, such 142 mechanism would reduce or prevent traffic loss. It would typically be 143 applicable in case of a maintenance operation requiring the shutdown 144 of a forwarding resource. Typical examples would be a link or line 145 card maintenance, replacement or upgrade. It may also be applicable 146 for a software upgrade as it may involve a firmware reset on the line 147 cards and hence forwarding interruption. 148 The introduction of Route Reflectors as per [RR] to solve scalability 149 issues bound to IBGP full-meshes has worsened the duration of routing 150 convergence as some route reflectors may hide the back up path. Thus 151 depending on RR topology more IBGP hops may be involved in the IBGP 152 convergence. 154 Internet-Draft Requirements for the graceful shutdown of BGP sessions 156 Note that these planned maintenance operations cannot be addressed by 157 Graceful Restart extensions [GR] as GR only applies when the 158 forwarding is preserved during the control plane restart. On the 159 contrary, Graceful Shutdown applies when the forwarding is 160 interrupted. 161 Note also that some protocols are already considering such graceful 162 shutdown procedure (e.g. GMPLS in [RFC5817]). 164 A successful approach of such mechanism should minimize the loss of 165 traffic in most foreseen maintenance situations. 167 3. Problem statement 169 As per [BGP-4], when one (or many) BGP session(s) are shut down, a 170 BGP NOTIFICATION message is sent to the peer and the session is then 171 closed. A protocol convergence is then triggered both by the local 172 router and by the peer. Alternate paths to the destination are 173 selected, if known. If those alternates paths are not known prior to 174 the BGP session shutdown, additional BGP convergence steps are 175 required in each AS to search for an alternate path. 177 This behavior is not satisfactory in a maintenance situation because 178 the traffic that was directed towards the removed next-hops may be 179 lost until the end of the BGP convergence. As it is a planned 180 operation, a make before break solution should be made possible. 182 As maintenance operations are frequent in large networks 183 [Reliability], the global availability of the network is 184 significantly impaired by this BGP maintenance issue. 186 3.1. Example of undesirable BGP routing behavior 188 To illustrate these problems, let us consider the following simple 189 example where one customer router "CUST" is dual-attached to two SP 190 routers "ASBR1" and "ASBR2". 191 ASBR1 and ASBR2 are in the same AS and owned by the same service 192 provider. Both are IBGP client of the route reflector R1. 194 Internet-Draft Requirements for the graceful shutdown of BGP sessions 196 ' 197 AS1 ' AS2 198 ' 200 /-----------ASBR1--- 201 / \ 202 / \ 203 CUST R1 204 \ / 205 Z/z \ / 206 \-----------ASBR2--- 208 ' 209 AS1 ' AS2 210 ' 212 Figure 1. Dual attached customer 214 Before the maintenance, packets for destination Z/z use the ASBR1- 215 CUST link because R1 selects ASBR1's route based on the IGP cost. 217 Let's assume the service provider wants to shutdown the ASBR1-CUST 218 link for maintenance purposes. Currently, when the shutdown is 219 performed on ASBR1, the following steps are performed: 220 1. ASBR1 sends a withdraw to its route reflector R1 for the prefix 221 Z/z. 222 2. R1 runs its decision process, selects the route from ASBR2 and 223 advertises the new path to ASBR1. 224 3. ASBR1 runs its decision process and recovers the reachability of 225 Z/z. 227 Traffic is lost between step 1 when ASBR1 looses its route and step 3 228 when it discovers a new path. 230 Note that this is a simplified description for illustrative purpose. 231 In a bigger AS, multiple steps of BGP convergence may be required to 232 find and select the best alternate path (e.g. ASBR1 is chosen based 233 on a higher local pref, hierarchical route reflectors are used...). 234 When multiple BGP routers are involved and plenty of prefixes are 235 affected, the recovery process can take longer than applications 236 requirements. 238 3.2. Causes of packet loss 240 The loss of packets during the maintenance has two main causes: 241 - lack of an alternate path on some routers, 242 - transient routing inconsistency. 244 Internet-Draft Requirements for the graceful shutdown of BGP sessions 246 Some routers may lack an alternate path because another router is 247 hiding the backup path. This router can be: 248 - a route reflector only propagating its best path; 249 - the backup ASBR not advertising the backup path because it prefers 250 the nominal path. 251 This lack of knowledge of the alternate path is the first target of 252 this requirement draft. 254 Transient routing inconsistencies happen during IBGP convergence 255 because all routers are not updating their RIB and FIB at the same 256 time. This can lead to forwarding loops and then packet drops. The 257 duration of these transient micro-loops may depend on the IBGP 258 topology (e.g. number of Route Reflectors between ingress and egress 259 ASBR), implementation differences among router platforms (e.g. speed 260 to update the RIB and FIB, possibly the order in which prefixes are 261 modified), forwarding mode (hop by hop IP forwarding versus 262 tunneling). 263 Transient forwarding loops can be avoided by performing only one IP 264 lookup on BGP routes in each AS and by using tunnels (e.g. MPLS LSP) 265 to send packets between ASBRs. As such, BGP/MPLS VPNs should be 266 immune to such micro forwarding loops. 268 4. Terminology 270 g-shut: Graceful SHUTdown. A method for explicitly notifying the BGP 271 routers that a BGP session (and hence the prefixes learnt over that 272 session) is going to be disabled. 274 g-noshut: Graceful NO SHUTdown. A method for explicitly notifying 275 the BGP routers that a BGP session (and hence the prefixes learnt 276 over that session) is going to be enabled. 278 g-shut initiator: the router on which the session(s) shutdown is 279 (are) performed for the maintenance. 281 g-shut neighbor: a router that peers with the g-shut initiator 282 via (one of) the session(s) undergoing maintenance. 284 Affected prefixes: a prefix initially reached via the peering 285 link(s) undergoing maintenance. 287 Affected router: a router reaching an affected prefix via a 288 peering link undergoing maintenance. 290 Initiator AS: the autonomous system of the g-shut initiator 291 router. 293 Neighbor AS(es): the autonomous system(s) of the g-shut neighbor 294 router(s). 296 Internet-Draft Requirements for the graceful shutdown of BGP sessions 298 5. Goals and requirements 300 When a BGP session of the router under maintenance is shut down, the 301 router removes the routes and then triggers the BGP convergence on 302 its BGP peers. The goal of BGP graceful shutdown is to initiate the 303 BGP convergence to find the alternate paths before the nominal paths 304 are removed. As a result, before the nominal BGP session is shut 305 down, all routers learn and use the alternate paths. Then the nominal 306 BGP session can be shut down. 308 As a result, provided an alternate path with enough remaining 309 capacity is available in the AS, the packets are rerouted before the 310 BGP session termination and fewer packets (possibly none) are lost 311 during the BGP convergence process since at any time, all routers 312 have a valid path. 314 Another goal is to minimize packet loss when the BGP session is re- 315 established following the maintenance. 317 From the above goals we can derive the following requirements: 319 a) A mechanism to advertise the maintenance action to all affected 320 routers is REQUIRED. Such mechanism may be either implicit or 321 explicit. Note that affected routers can be located both in the local 322 AS and in neighboring ASes. Note also that the maintenance action can 323 either be the shutdown of a BGP session or the establishment of a BGP 324 session. 325 The mechanism SHOULD allow BGP routers to minimize packet loss when a 326 path is removed or advertised. In particular, it SHOULD be ensured 327 that the old path is not removed from the routing tables of the 328 affected routers before the new path is known. 329 The solution mechanism MUST reduce packet loss but MAY provide only a 330 reduction rather than full minimization, in order to trade off with 331 simplicity of implementation and operation as shown in some of the 332 following requirements. 334 b) An Internet wide convergence is OPTIONAL. However if the 335 initiator AS and the neighbor AS(es) have a backup path, they SHOULD 336 be able to gracefully converge before the nominal path is shut down. 338 c) The proposed solution SHOULD be applicable to any kind of BGP 339 sessions (EBGP, IBGP, IBGP route reflector client, EBGP 340 confederations, EBGP multi hop, MultiProtocol BGP extension...) and 341 any address family. If a BGP implementation allows closing or 342 enabling a sub-set of AFIs carried in a MP-BGP session, this 343 mechanism MAY be applicable to this sub-set of AFIs. 345 Depending on the kind of session, there may be some variations in the 346 proposed solution in order to fulfill the requirements. 348 The following cases should be handled in priority: 350 Internet-Draft Requirements for the graceful shutdown of BGP sessions 352 - The shutdown of an inter-AS link and therefore the shutdown of an 353 eBGP session; 354 - The shutdown of an AS Border Router and therefore the shutdown of 355 all its BGP sessions. 357 Service Providers and platforms implementing a graceful shutdown 358 solution should note that in BGP/MPLS VPN as per [VPN], the PE-CE 359 routing can be performed by other protocols than BGP (e.g. static 360 routes, RIPv2, OSPF, IS-IS). This is out of scope of this document. 362 d) The proposed solution SHOULD NOT change the BGP convergence 363 behavior for the ASes exterior to the maintenance process, namely 364 ASes other than the initiator AS and it(s) neighbor AS(es). 366 e) An incremental deployment on a per AS or per BGP session basis 367 MUST be made possible. In case of partial deployment the proposed 368 solution SHOULD incrementally improve the maintenance process. 369 It should be noted that in an inter domain relation, one AS may have 370 more incentive to use graceful shutdown than the other. Similarly, in 371 a BGP/MPLS VPN environment, it's much easier to upgrade the PE 372 routers than the CE mainly because there is at least an order of 373 magnitude more CE and CE locations than PE and PE locations. As a 374 consequence, when splitting the cost of the solution between the g- 375 shut initiator and the g-shut neighbour the solution SHOULD favour a 376 low cost solution on the neighbour AS side in order to reduce the 377 impact on the g-shut neighbour. Impact should be understood as a 378 generic term which includes first hardware, then software, then 379 configuration upgrade.. 381 f) Redistribution or advertisement of (static) IP routes into BGP 382 SHOULD also be covered. 384 g) The proposed solution MAY be designed in order to avoid 385 transient forwarding loops. Indeed, forwarding loops increase packet 386 transit delay and may lead to link saturation. 388 h) The specific procedure SHOULD end when the BGP session is closed 389 following the g-shut and once the BGP session is gracefully opened 390 following the g-noshut. In the end, once the planned maintenance is 391 finished the nominal BGP routing MUST be reestablished. 392 The duration of the g-shut procedure, and hence the time before the 393 BGP session is safely closed SHOULD be discussed by the solution 394 document. Examples of possible solutions are the use of a pre- 395 configured timer, of a message to signal the end of the BGP 396 convergence or monitoring the traffic on the g-shut interface... 398 i) The solution SHOULD be simple and simple to operate. Hence it 399 MAY only cover a subset of the cases. (As a consequence, most of the 400 above requirements are expressed as "SHOULD" rather than "MUST") 402 Internet-Draft Requirements for the graceful shutdown of BGP sessions 404 The metrics to evaluate and compare the proposed solutions are, in 405 decreasing order of importance: 406 - The duration of the remaining loss of connectivity when the BGP 407 session is brought down or up 408 - The applicability to a wide range of BGP and network topologies, 409 especially those described in section 6; 410 - The simplicity; 411 - The duration of transient forwarding loops; 412 - The additional load introduced in BGP (eg BGP messages sent to peer 413 routers, peer ASes, the Internet). 415 6. Reference Topologies 417 In order to benchmark the proposed solutions, some typical BGP 418 topologies are detailed in this section. The solution documents 419 should state the applicability of the solutions for each of these 420 possible topologies. 422 However, solutions SHOULD be applicable to all possible BGP 423 topologies and not only to these below examples. Note that this 424 is a "SHOULD" rather than a "MUST" as a partial lightweight 425 solution may be preferred to a full but more complex solution. 426 Especially since some ISP may not be concerned by some topologies 427 (e.g. confederations). 429 6.1. EBGP topologies 431 We describe here some frequent EBGP topologies that SHOULD be 432 supported by the solution. 434 6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2 436 In this topology we have an asymmetric protection scheme between 437 AS1 and AS2: 438 - On AS2 side, two different routers are used to connect to AS1. 439 - On AS1 side, one single router with two BGP sessions is used. 441 Internet-Draft Requirements for the graceful shutdown of BGP sessions 443 ' 444 AS1 ' AS2 445 ' 446 /----------- ASBR2.1 447 / ' 448 / ' 449 ASBR1.1 ' 450 \ ' 451 \ ' 452 \----------- ASBR2.2 453 ' 454 ' 455 AS1 ' AS2 456 ' 458 Figure 2. EBGP topology with redundant ASBR in one of the AS. 460 The requirements of section 5 should be applicable to: 461 - Maintenance of one of the routers of AS2; 462 - Maintenance of one link between AS1 and AS2, performed either 463 on an AS1 or AS2 router. 465 Note that in case of maintenance of the whole router, all its BGP 466 sessions need to be gracefully shutdown at the beginning of the 467 maintenance and gracefully brought up at the end of the 468 maintenance. 470 6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2 472 In this topology we have a symmetric protection scheme between 473 AS1 and AS2: on both sides, two different routers are used to 474 connect AS1 to AS2. 476 ' 477 AS1 ' AS2 478 ' 479 ASBR1.1----------- ASBR2.1 480 ' 481 ' 482 ' 483 ' 484 ' 485 ASBR1.2----------- ASBR2.2 486 ' 487 AS1 ' AS2 488 ' 490 Figure 3. EBGP topology with redundant ASBR in both ASes 492 The requirements of section 5 should be applicable to: 493 - Maintenance of any of the ASBR routers (in AS1 or AS2); 495 Internet-Draft Requirements for the graceful shutdown of BGP sessions 497 - Maintenance of one link between AS1 and AS2 performed either on 498 an AS1 or AS2 router. 500 6.1.3. 2 ASBRs in AS2 each connected to two different ASes 502 In this topology at least three ASes are involved. Depending on 503 which routes are exchanged between these ASes, some protection 504 for some of the traffic may be possible. 506 ' 507 AS1 ' AS2 508 ' 509 ASBR1.1----------- ASBR2.1 510 | ' 511 | ' 512 '''''|'''''''''' 513 | ' 514 | ' 515 ASBR3.1----------- ASBR2.2 516 ' 517 AS3 ' AS2 519 Figure 4. EBGP topology of a dual homed customer 521 The requirements of section 5 do not translate as easily as in 522 the two previous topologies because we do not require propagating 523 the maintenance advertisement outside of the two ASes involved in 524 an eBGP session. 525 For instance if ASBR2.2 requires a maintenance affecting ASBR3.1, 526 then ASBR3.1 will be notified. However we do not require for ASBR1.1 527 to be notified of the maintenance of the eBGP session between 528 ASBR3.1-ASBR2.2. 530 6.2. IBGP topologies 532 We describe here some frequent IBGP topologies that SHOULD be 533 supported by the solution. 535 Internet-Draft Requirements for the graceful shutdown of BGP sessions 537 6.2.1. IBGP Full-Mesh 539 In this topology we have a full mesh of iBGP sessions: 541 P1 ------ P2 542 | \ / | 543 | \ / | 544 | \ / | AS1 545 | / \ | 546 | / \ | 547 ASBR1.1---ASBR1.2 548 \ / 549 \ / 550 ''''''\''''/'''''''''''' 551 \ / AS2 552 ASBR2.1 554 Figure 5. IBGP full mesh 556 When the session between ASBR1.1 and ASBR2.1 is gracefully 557 shutdown, it is required that all routers of AS1 reroute traffic 558 to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 is shut 559 down. 560 Symmetrically, when the session between ASBR1.1 and ASBR2.1 is 561 gracefully brought up, it is required that all routers of AS1 562 preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before 563 the less preferred path trough ASBR1.2 is possibly withdrawn. 565 6.2.2. Route Reflector 567 In this topology, route reflectors are used to limit the number of 568 IBGP sessions. There is a single level of route reflectors and the 569 route reflectors are fully meshed. 571 Internet-Draft Requirements for the graceful shutdown of BGP sessions 573 P1 RR----- P2 RR 574 | \ / | 575 | \ / | 576 | \ / | AS1 577 | \ / | 578 | / \ | 579 | / \ | 580 | / \ | 581 ASBR1.1 ASBR1.2 582 \ / 583 \ / 584 ''''''\''''''/'''''''''''' 585 \ / 586 \ / AS2 587 ASBR2.1 589 Figure 6. Route Reflector 591 When the session between ASBR1.1 and ASBR2.1 is gracefully 592 shutdown, it is required that all BGP routers of AS1 reroute 593 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 594 is shut down. 595 Symmetrically, when the session between ASBR1.1 and ASBR2.1 is 596 gracefully brought up, it is required that all routers of AS1 597 preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before 598 the less preferred path trough ASBR1.2 is possibly withdrawn. 600 6.2.3. hierarchical Route Reflector 602 In this topology, hierarchical route reflectors are used to limit 603 the number of IBGP sessions. There could me more than levels of 604 route reflectors and the top level route reflectors are fully 605 meshed. 607 Internet-Draft Requirements for the graceful shutdown of BGP sessions 609 P1/hRR -------- P2/hRR 610 | | 611 | | 612 | | AS1 613 | | 614 | | 616 P3/RR P4/RR 617 | | 618 | | 619 | | AS1 620 | | 621 | | 622 ASBR1.1 ASBR1.2 623 \ / 624 \ / 625 ''''''\'''''''''/'''''''''''' 626 \ / 627 \ / AS2 628 ASBR2.1 630 Figure 7. Hierarchical Route Reflector 632 When the session between ASBR1.1 and ASBR2.1 is gracefully 633 shutdown, it is required that all BGP routers of AS1 reroute 634 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 635 is shut down. 636 Symmetrically, when the session between ASBR1.1 and ASBR2.1 is 637 gracefully brought up, it is required that all routers of AS1 638 preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before 639 the less preferred path trough ASBR1.2 is possibly withdrawn. 641 6.2.4. Confederations 643 In this topology, a confederation of ASs is used to limit the number 644 of IBGP sessions. Moreover, RRs may be present in the member ASs of 645 the confederation. 646 Confederations may be run with different sub-options. Regarding the 647 IGP, each member AS can run its own IGP or they can all share the 648 same IGP. Regarding BGP, local_pref may or may not cross the member 649 AS boundaries. 650 A solution should support the graceful shutdown and graceful bring up 651 of EBGP sessions between member-ASs in the confederation in addition 652 to the graceful shutdown and graceful bring up of EBGP sessions 653 between a member-AS and an AS outside of the confederation. 655 Internet-Draft Requirements for the graceful shutdown of BGP sessions 657 ASBR1C.1 ---------- ASBR1C.2 658 | | 659 | | 660 | AS1C | 661 | | 662 | | 663 """|"""""""""""""""""""|""" 664 | " | 665 ASBR1A.2 " ASBR1B.2 666 | " | 667 | " | 668 | AS1A " AS1B | AS1 669 | " | 670 | " | 671 ASBR1A.1 " ASBR1B.1 672 \ " / 673 \ " / 674 ''''''\'''''''''''''/'''''''''''' 675 \ / 676 \ / AS2 677 ASBR2.1 679 Figure 8. Confederation 681 In the above figure, member-AS AS1A, AS1B, AS1C belong to a 682 confederation of ASs in AS1. AS1A and AS1B are connected to AS2. 684 In normal operation, for the traffic toward AS2, 685 . AS1A sends the traffic directly to AS2 through ASBR1A.1 686 . AS1B sends the traffic directly to AS2 through ASBR1B.1 687 . AS1C load balances the traffic between AS1A and AS1B 689 When the session between ASBR1A.1 and ASBR2.1 is gracefully shutdown, 690 it is required that all BGP routers of AS1 reroute traffic to 691 ASBR1B.1 before the session between ASBR1A.1 and ASBR2.1 is shut 692 down. 693 Symmetrically, when the session between ASBR1A.1 and ASBR2.1 is 694 gracefully brought up, it is required that all routers of AS1 695 preferring ASBR1A.1 over ASBR1.2 reroute traffic to ASBR1A.1 before 696 the less preferred path trough ASBR1.2 is possibly withdrawn. 698 7. Security Considerations 700 At the requirements stage, this graceful shutdown mechanism is 701 expected to not affect the security of the BGP protocol, especially 702 if it can be kept simple. No new sessions are required and the 703 additional ability to signal the graceful shutdown is not expected to 704 bring additional attack vector as BGP neighbors already have the 705 ability to send incorrect or misleading information or even shut down 706 the session. 708 Internet-Draft Requirements for the graceful shutdown of BGP sessions 710 Security considerations MUST be addressed by the proposed 711 solutions. In particular they SHOULD address the issues of bogus 712 g-shut messages and how they would affect the network(s), as well 713 as the impact of hiding a g-shut message so that g-shut is not 714 performed. 716 The solution SHOULD NOT increase the ability for one AS to 717 selectively influence routing decision in the peer AS (inbound 718 Traffic Engineering) outside the case of the BGP session 719 shutdown. Otherwise, the peer AS SHOULD have means to detect such 720 behavior. 722 8. IANA Considerations 724 This document has no actions for IANA. 726 9. References 728 9.1. Normative References 730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 731 Requirement Levels", BCP 14, RFC 2119, March 1997. 733 [BGP-4] Y. Rekhter, T. Li, "A Border Gateway protocol 4 (BGP)", RFC 734 4271, January 2006. 736 [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol 737 Extensions for BGP-4", RFC 4760 January 2007. 739 [RR] T. Bates, E. Chen, R. Chandra 740 "BGP Route Reflection: An Alternative to Full Mesh Internal BGP 741 (IBGP)", RFC 4456 April 2006. 743 [VPN] E. Rosen, Y. Rekhter 744 "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364 745 February 2006. 747 9.2. Informative References 749 [RFC5817] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton 750 "Graceful Shutdown in MPLS and Generalized MPLS Traffic 751 Engineering Networks", RFC 5817 April 2010. 753 [GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter 754 "Graceful Restart Mechanism for BGP", RFC 4724 January 2007. 756 [Reliability] Network Strategy Partners, LLC. 757 "Reliable IP Nodes: A prerequisite to profitable IP services", 758 November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf 760 Internet-Draft Requirements for the graceful shutdown of BGP sessions 762 10. Acknowledgments 764 Authors would like to thank Nicolas Dubois, Benoit Fondeviole, 765 Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier 766 Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and 767 Ronald Bonica for the useful discussions on this subject, their 768 review and comments. 770 This draft has been partly sponsored by the European project IST 771 AGAVE. 773 Authors' Addresses 775 Bruno Decraene 776 France Telecom 777 38-40 rue du General Leclerc 778 92794 Issy Moulineaux cedex 9 779 France 781 Email: bruno.decraene@orange-ftgroup.com 783 Pierre Francois 784 Universite catholique de Louvain 785 Place Ste Barbe, 2 786 Louvain-la-Neuve 1348 787 BE 789 Email: francois@info.ucl.ac.be 791 Cristel Pelsser 792 Internet Initiative Japan 793 Jinbocho Mitsui Building 794 1-105 Kanda jinbo-cho 795 Chiyoda-ku, Tokyo 101-0051 796 Japan 798 Email: cristel@iij.ad.jp 800 Zubair Ahmad 801 Orange Business Services 802 13775 McLearen Road, Oak Hill VA 20171 803 USA 805 Email: zubair.ahmad@orange-ftgroup.com 807 Antonio Jose Elizondo Armengol 808 Division de Analisis Tecnologicos 810 Internet-Draft Requirements for the graceful shutdown of BGP sessions 812 Technology Analysis Division 813 Telefonica I+D 814 C/ Emilio Vargas 6 815 28043, Madrid 817 E-mail: ajea@tid.es 819 Tomonori Takeda 820 NTT Corporation 821 9-11, Midori-Cho 3 Chrome 822 Musashino-Shi, Tokyo 180-8585 823 Japan 825 Email: takeda.tomonori@lab.ntt.co.jp