idnits 2.17.1 draft-ietf-grow-bgp-graceful-shutdown-requirements-04.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 (September 06, 2010) is 4980 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 September 06, 2010 16 Requirements for the graceful shutdown of BGP sessions 17 draft-ietf-grow-bgp-graceful-shutdown-requirements-04.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 March 05, 2011. 52 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......................................6 93 6. Reference Topologies........................................8 94 6.1. E-BGP topologies............................................9 95 6.2. I-BGP topologies...........................................11 96 7. Security Considerations....................................14 97 8. IANA Considerations........................................14 98 9. References.................................................14 99 9.1. Normative References.......................................14 100 9.2. Informative References.....................................14 101 10. Acknowledgments............................................15 102 11. Author's Addresses.........................................15 104 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) is heavily used in Service Provider 115 networks both for Internet and BGP/MPLS VPN services. For resiliency 116 purposes, redundant routers and BGP sessions can be deployed to 117 reduce the consequences of an AS Border Router or BGP session 118 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 withdraw a prefix while traffic toward that 136 prefix could still be correctly forwarded. When a BGP session is 137 taken down, BGP behaves as if it was a sudden link or router failure 138 and withdraws the prefixes learnt over that session, which may 139 trigger traffic loss. There is no mechanism to advertise to its BGP 140 peers that the prefix will soon be unreachable, while still being 141 reachable. When applicable, such mechanism would reduce or prevent 142 traffic loss. It would typically be applicable in case of a 143 maintenance operation requiring the shutdown of a forwarding 144 resource. Typical examples would be a link or line card maintenance, 145 replacement or upgrade. It may also be applicable for a software 146 upgrade as it may involve a firmware reset on the line cards and 147 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 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 example 189 where one customer router "CUST" is dual-attached to two SP routers 190 "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 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 Some routers may lack an alternate path because another router is 245 hiding the backup path. This router can be: 246 - a route reflector only propagating its best path; 248 Requirements for the graceful shutdown of BGP sessions 250 - the backup ASBR not advertising the backup path because it prefers 251 the nominal path. 252 This lack of knowledge of the alternate path is the first target of 253 this requirement draft. 255 Transient routing inconsistencies happen during IBGP convergence 256 because all routers are not updating their RIB at the same time. This 257 can lead to forwarding loops and then packet drops. The duration of 258 these transient micro-loops may depend on the IBGP topology (e.g. 259 number of Route Reflectors between ingress and egress ASBR), 260 implementation differences among router platforms (e.g. speed to 261 update the RIB and FIB, possibly the order in which prefixes are 262 modified), forwarding mode (hop by hop IP forwarding versus 263 tunneling). 264 Transient forwarding loops can be avoided by performing only one IP 265 lookup on BGP routes in each AS and by using tunnels (e.g. MPLS LSP) 266 to send packets between ASBRs. As such, BGP/MPLS VPNs should be 267 immune to such micro forwarding loops. 269 4. Terminology 271 g-shut initiator: the router on which the session(s) shutdown is 272 (are) performed for the maintenance. 274 g-shut neighbor: a router that peers with the g-shut initiator 275 via (one of) the session(s) undergoing maintenance. 277 Affected prefixes: a prefix initially reached via the peering 278 link(s) undergoing maintenance. 280 Affected router: a router reaching an affected prefix via a 281 peering link undergoing maintenance. 283 Initiator AS: the autonomous system of the g-shut initiator 284 router. 286 Neighbor AS(es): the autonomous system(s) of the g-shut neighbor 287 router(s). 289 5. Goals and requirements 291 When a BGP session of the router under maintenance is shut down, the 292 router removes the routes and then triggers the BGP convergence on 293 its BGP peers. The goal of BGP graceful shutdown is to initiate the 294 BGP convergence to find the alternate paths before the nominal paths 295 are removed. As a result, before the nominal BGP session is shut 296 down, all routers learn and use the alternate paths. Then the nominal 297 BGP session can be shut down. 299 As a result, provided an alternate path is available in the AS, the 300 packets are rerouted before the BGP session termination and fewer 302 Requirements for the graceful shutdown of BGP sessions 304 packets (possibly none) are lost during the BGP convergence process 305 since at any time, all routers have a valid path. 307 Another goal is to minimize packet loss when the BGP session is re- 308 established following the maintenance. 310 From the above goals we can derive the following requirements: 312 a) A mechanism to advertise the maintenance action to all affected 313 routers is REQUIRED. Such mechanism may be either implicit or 314 explicit. Note that affected routers can be located both in the local 315 AS and in neighboring ASes. Note also that the maintenance action can 316 either be the shutdown of a BGP session or the establishment of a BGP 317 session. 318 The mechanism SHOULD minimize packet loss when a path is removed or 319 advertised. In particular, it SHOULD be ensured that the old path is 320 not removed from the routing tables of the affected routers before 321 the new path is known. 323 b) An Internet wide convergence is OPTIONAL. However if the 324 initiator AS and the neighbor AS(es) have a backup path, they SHOULD 325 be able to gracefully converge before the nominal path is shut down. 327 c) The proposed solution SHOULD be applicable to any kind of BGP 328 sessions (EBGP, IBGP, IBGP route reflector client, EBGP 329 confederations, EBGP multi hop, MultiProtocol BGP extension...) and 330 any address family. If a BGP implementation allows closing a sub-set 331 of AFIs carried in a MP-BGP session, this mechanism MAY be applicable 332 to this sub-set of AFIs. 334 Depending on the session type (EBGP, IBGP...), there may be some 335 variations in the proposed solution in order to fulfill the 336 requirements. 338 The following cases should be handled in priority: 339 - The shutdown of an inter-AS link and therefore the shutdown of an 340 eBGP session; 341 - The shutdown of an AS Border Router and therefore the shutdown of 342 all its BGP sessions. 344 Service Providers and platforms implementing a graceful shutdown 345 solution should note that in BGP/MPLS VPN as per [VPN], the PE-CE 346 routing can be performed by other protocols than BGP (e.g. static 347 routes, RIPv2, OSPF, IS-IS...). This is out of scope of this 348 document, but comprehensive graceful shutdown procedures should take 349 this into account. 351 d) The proposed solution SHOULD NOT change the BGP convergence 352 behavior for the ASes exterior to the maintenance process, namely 353 ASes other than the initiator AS and it(s) neighbor AS(es). 355 Requirements for the graceful shutdown of BGP sessions 357 e) An incremental deployment on a per AS or per BGP session basis 358 SHOULD be made possible. In case of partial deployment the proposed 359 solution SHOULD incrementally improve the maintenance process. The 360 solution SHOULD bring improvements even when one of the two ASes does 361 not support graceful shutdown. In particular, large Service Providers 362 may not be able to upgrade all of the deployed customer premises 363 access routers (CPE). 365 f) Redistribution or advertisement of (static) IP routes into BGP 366 SHOULD also be covered. 368 g) The proposed solution MAY be designed in order to avoid 369 transient forwarding loops. Indeed, forwarding loops increase packet 370 transit delay and may lead to link saturation. 372 h) The specific procedure SHOULD end when the BGP session is closed 373 following the g-shut and once the BGP session is gracefully opened 374 following the g-noshut. In the end, once the planned maintenance is 375 finished the nominal BGP routing MUST be reestablished. 376 The duration of the g-shut procedure, and hence the time before the 377 BGP session is safely closed SHOULD be discussed by the solution 378 document. Examples of possible solutions are the use of a pre- 379 configured timer, of a message to signal the end of the BGP 380 convergence or monitoring the traffic on the g-shut interface... 382 i) The solution SHOULD be simple and simple to operate. Hence it 383 MAY only cover a subset of the cases. 385 The metrics to evaluate and compare the proposed solutions are, in 386 decreasing order of importance: 387 - The duration of the remaining loss of connectivity when the BGP 388 session is brought down or up 389 - The applicability to a wide range of BGP and network topologies, 390 especially those described in section 6; 391 - The simplicity; 392 - The duration of transient forwarding loops; 393 - The additional load introduced in BGP (eg BGP messages sent to peer 394 routers, peer ASes, the Internet). 396 6. Reference Topologies 398 In order to benchmark the proposed solutions, some typical BGP 399 topologies are detailed in this section. The solution drafts 400 should state its applicability for each of these possible 401 topologies. 403 However, solutions SHOULD be applicable to all possible BGP 404 topologies and not only to these below examples. Note that this 405 is a "SHOULD" rather than a "MUST" as a partial lightweight 406 solution may be preferred to a full but more complex solution. 408 Requirements for the graceful shutdown of BGP sessions 410 Especially since some ISP may not be concerned by some topologies 411 (e.g. confederations). 413 6.1. EBGP topologies 415 We describe here some frequent EBGP topologies that SHOULD be 416 supported by the solution. 418 6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2 420 In this topology we have an asymmetric protection scheme between 421 AS1 and AS2: 422 - On AS2 side, two different routers are used to connect to AS1. 423 - On AS1 side, one single router with two BGP sessions is used. 425 ' 426 AS1 ' AS2 427 ' 428 /----------- ASBR2.1 429 / ' 430 / ' 431 ASBR1.1 ' 432 \ ' 433 \ ' 434 \----------- ASBR2.2 435 ' 436 ' 437 AS1 ' AS2 438 ' 440 Figure 2. EBGP topology with redundant ASBR in one of the AS. 442 The requirements of section 5 should be applicable to: 443 - Maintenance of one of the routers of AS2; 444 - Maintenance of one link between AS1 and AS2, performed either 445 on an AS1 or AS2 router. 447 Note that in case of maintenance of the whole router, all its BGP 448 session needs to be shutdown. 450 6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2 452 In this topology we have a symmetric protection scheme between 453 AS1 and AS2: on both sides, two different routers are used to 454 connect AS1 to AS2. 456 Requirements for the graceful shutdown of BGP sessions 458 ' 459 AS1 ' AS2 460 ' 461 ASBR1.1----------- ASBR2.1 462 ' 463 ' 464 ' 465 ' 466 ' 467 ASBR1.2----------- ASBR2.2 468 ' 469 AS1 ' AS2 470 ' 472 Figure 3. EBGP topology with redundant ASBR in both ASes 474 The requirements of section 5 should be applicable to: 475 - Maintenance of any of the ASBR routers (in AS1 or AS2); 476 - Maintenance of one link between AS1 and AS2 performed either on 477 an AS1 or AS2 router. 479 6.1.3. 2 ASBRs in AS2 each connected to two different ASes 481 In this topology at least three ASes are involved. Depending on 482 which routes are exchanged between these ASes, some protection 483 for some of the traffic may be possible. 485 ' 486 AS1 ' AS2 487 ' 488 ASBR1.1----------- ASBR2.1 489 | ' 490 | ' 491 '''''|'''''''''' 492 | ' 493 | ' 494 ASBR3.1----------- ASBR2.2 495 ' 496 AS3 ' AS2 498 Figure 4. EBGP topology of a dual homed customer 500 The requirements of section 5 do not translate as easily as in 501 the two previous topologies because we do not require propagating 502 the maintenance advertisement outside of the two ASes involved in 503 an eBGP session. 504 For instance if ASBR2.2 requires a maintenance affecting ASBR3.1, 505 then ASBR3.1 will be notified. However we do not require for ASBR1.1 506 to be notified of the maintenance of the eBGP session between 507 ASBR3.1-ASBR2.2. 509 Requirements for the graceful shutdown of BGP sessions 511 6.2. IBGP topologies 513 We describe here some frequent IBGP topologies that SHOULD be 514 supported by the solution. 516 6.2.1. IBGP Full-Mesh 518 In this topology we have a full mesh of iBGP sessions: 520 P1 ------ P2 521 | \ / | 522 | \ / | 523 | \ / | AS1 524 | / \ | 525 | / \ | 526 ASBR1.1---ASBR1.2 527 \ / 528 \ / 529 ''''''\''''/'''''''''''' 530 \ / AS2 531 ASBR2.1 533 Figure 5. IBGP full mesh 535 When the session between ASBR1.1 and ASBR2.1 undergoes 536 maintenance, it is required that all IBGP peers of ASBR1.1 reroute 537 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 538 is shut down. 540 6.2.2. Route Reflector 542 In this topology, route reflectors are used to limit the number of 543 IBGP sessions. 545 Requirements for the graceful shutdown of BGP sessions 547 P1 RR----- P2 RR 548 | \ / | 549 | \ / | 550 | \ / | AS1 551 | \ / | 552 | / \ | 553 | / \ | 554 | / \ | 555 ASBR1.1 ASBR1.2 556 \ / 557 \ / 558 ''''''\''''''/'''''''''''' 559 \ / 560 \ / AS2 561 ASBR2.1 563 Figure 6. Route Reflector 565 When the session between ASBR1.1 and ASBR2.1 undergoes 566 maintenance, it is required that all BGP routers of AS1 reroute 567 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 568 is shut down. 570 6.2.3. hierarchical Route Reflector 572 In this topology, hierarchical route reflectors are used to limit 573 the number of IBGP sessions. 575 P1/hRR -------- P2/hRR 576 | | 577 | | 578 | | AS1 579 | | 580 | | 582 P3/RR P4/RR 583 | | 584 | | 585 | | AS1 586 | | 587 | | 588 ASBR1.1 ASBR1.2 589 \ / 590 \ / 591 ''''''\'''''''''/'''''''''''' 592 \ / 593 \ / AS2 594 ASBR2.1 596 Figure 7. Hierarchical Route Reflector 598 Requirements for the graceful shutdown of BGP sessions 600 When the session between ASBR1.1 and ASBR2.1 undergoes 601 maintenance, it is required that all BGP routers of AS1 reroute 602 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 603 is shut down. 605 6.2.4. Confederations 607 In this topology, a confederation of ASs is used to limit the number 608 of IBGP sessions. Moreover, RRs may be present in the member ASs of 609 the confederation. 610 Confederations may be run with different sub-options. Regarding the 611 IGP, each member AS can run its own IGP or they can all share the 612 same IGP. Regarding BGP, local_pref may or may not cross the member 613 AS boundaries. 614 A solution should support the shutdown of EBGP sessions between 615 member-ASs in the confederation in addition to the shutdown of EBGP 616 sessions between a member-AS and an AS outside of the confederation. 618 ASBR1C.1 ---------- ASBR1C.2 619 | | 620 | | 621 | AS1C | 622 | | 623 | | 624 """|"""""""""""""""""""|""" 625 | " | 626 ASBR1A.2 " ASBR1B.2 627 | " | 628 | " | 629 | AS1A " AS1B | AS1 630 | " | 631 | " | 632 ASBR1A.1 " ASBR1B.1 633 \ " / 634 \ " / 635 ''''''\'''''''''''''/'''''''''''' 636 \ / 637 \ / AS2 638 ASBR2.1 640 Figure 8. Confederation 642 In the above figure, member-AS AS1A, AS1B, AS1C belong to a 643 confederation of ASs in AS1. AS1A and AS1B are connected to AS2. 645 In normal operation, for the traffic toward AS2, 646 . AS1A sends the traffic directly to AS2 through ASBR1A.1 647 . AS1B sends the traffic directly to AS2 through ASBR1B.1 648 . AS1C load balances the traffic between AS1A and AS1B 650 Requirements for the graceful shutdown of BGP sessions 652 When the session between ASBR1A.1 and ASBR2.1 undergoes 653 maintenance, it is required that all BGP routers of AS1 reroute 654 traffic to ASBR1B.1 before the session between ASBR1A.1 and 655 ASBR2.1 is shut down. 657 7. Security Considerations 659 Security considerations MUST be addressed by the proposed 660 solutions. 662 The solution SHOULD NOT increase the ability for one AS to 663 selectively influence routing decision in the peer AS (inbound 664 Traffic Engineering) outside the case of the BGP session 665 shutdown. Otherwise, the peer AS SHOULD have means to detect such 666 behavior. 668 8. IANA Considerations 670 This document has no actions for IANA. 672 9. References 674 9.1. Normative References 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, March 1997. 679 [BGP-4] Y. Rekhter, T. Li, "A Border Gateway protocol 4 (BGP)", RFC 680 4271, January 2006. 682 [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol 683 Extensions for BGP-4", RFC 4760 January 2007. 685 [RR] T. Bates, E. Chen, R. Chandra 686 "BGP Route Reflection: An Alternative to Full Mesh Internal BGP 687 (IBGP)", RFC 4456 April 2006. 689 [VPN] E. Rosen, Y. Rekhter 690 "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364 691 February 2006. 693 9.2. Informative References 695 [RFC5817] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton 696 "Graceful Shutdown in MPLS and Generalized MPLS Traffic 697 Engineering Networks", RFC 5817 April 2010. 699 [GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter 700 "Graceful Restart Mechanism for BGP", RFC 4724 January 2007. 702 [Reliability] Network Strategy Partners, LLC. 704 Requirements for the graceful shutdown of BGP sessions 706 "Reliable IP Nodes: A prerequisite to profitable IP services", 707 November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf 709 10. Acknowledgments 711 Authors would like to thank Nicolas Dubois, Benoit Fondeviole, 712 Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier 713 Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and 714 Ronald Bonica for the useful discussions on this subject, their 715 review and comments. 717 This draft has been partly sponsored by the European project IST 718 AGAVE. 720 Authors' Addresses 722 Bruno Decraene 723 France Telecom 724 38-40 rue du General Leclerc 725 92794 Issy Moulineaux cedex 9 726 France 728 Email: bruno.decraene@orange-ftgroup.com 730 Pierre Francois 731 Universite catholique de Louvain 732 Place Ste Barbe, 2 733 Louvain-la-Neuve 1348 734 BE 736 Email: francois@info.ucl.ac.be 738 Cristel Pelsser 739 Internet Initiative Japan 740 Jinbocho Mitsui Building 741 1-105 Kanda jinbo-cho 742 Chiyoda-ku, Tokyo 101-0051 743 Japan 745 Email: cristel@iij.ad.jp 747 Zubair Ahmad 748 Orange Business Services 749 13775 McLearen Road, Oak Hill VA 20171 750 USA 752 Email: zubair.ahmad@orange-ftgroup.com 754 Requirements for the graceful shutdown of BGP sessions 756 Antonio Jose Elizondo Armengol 757 Division de Analisis Tecnologicos 758 Technology Analysis Division 759 Telefonica I+D 760 C/ Emilio Vargas 6 761 28043, Madrid 763 E-mail: ajea@tid.es 765 Tomonori Takeda 766 NTT Corporation 767 9-11, Midori-Cho 3 Chrome 768 Musashino-Shi, Tokyo 180-8585 769 Japan 771 Email: takeda.tomonori@lab.ntt.co.jp