idnits 2.17.1 draft-decraene-bgp-graceful-shutdown-requirements-01.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 14) being 65 lines 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (March 5, 2009) is 5493 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'BGP RR' is defined on line 616, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Decraene 3 Internet-Draft France Telecom 4 Intended status: Informational P. Francois 5 Expires: September 6, 2009 UCL 6 C. Pelsser 7 NTT 8 Z. Ahmad 9 Orange Business Services 10 A. J. Elizondo Armengol 11 Telefonica I+D 12 March 5, 2009 14 Requirements for the graceful shutdown of BGP sessions 15 draft-decraene-bgp-graceful-shutdown-requirements-01.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. This document may contain material 21 from IETF Documents or IETF Contributions published or made publicly 22 available before November 10, 2008. The person(s) controlling the 23 copyright in some of this material may not have granted the IETF 24 Trust the right to allow modifications of such material outside the 25 IETF Standards Process. Without obtaining an adequate license from 26 the person(s) controlling the copyright in such materials, this 27 document may not be modified outside the IETF Standards Process, and 28 derivative works of it may not be created outside the IETF Standards 29 Process, except to format it for publication as an RFC or to 30 translate it into languages other than English. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 6, 2009. 50 Copyright Notice 51 Requirements for the graceful shutdown of BGP sessions 53 Copyright (c) 2009 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. 63 Abstract 65 The BGP protocol is heavily used in Service Provider networks both 66 for Internet and BGP/MPLS VPN services. For resiliency purposes, 67 redundant routers and BGP sessions can be deployed to reduce the 68 consequences of an AS Border Router or BGP session breakdown on 69 customers' or peers' traffic. However simply taking down or even up a 70 BGP session for maintenance purposes may still induce connectivity 71 losses during the BGP convergence. This is no more satisfactory for 72 new applications (e.g. voice over IP, on line gaming, VPN). 73 Therefore, a solution is required for the graceful shutdown of a (set 74 of) BGP session(s) in order to limit the amount of traffic loss 75 during a planned shutdown. This document expresses requirements for 76 such a solution. 78 Table of Contents 80 1. Conventions used in this document...........................2 81 2. Introduction................................................3 82 3. Problem statement...........................................3 83 3.1. Example of undesirable BGP routing behavior.................4 84 3.2. Causes of packet loss.......................................5 85 4. Terminology.................................................5 86 5. Goals and requirements......................................6 87 6. Reference Topologies........................................7 88 6.1. E-BGP topologies............................................7 89 6.2. I-BGP topologies............................................9 90 7. Security Considerations....................................12 91 8. IANA Considerations........................................12 92 9. References.................................................13 93 9.1. Normative References.......................................13 94 9.2. Informative References.....................................13 95 10. Acknowledgments............................................13 96 11. Author's Addresses.........................................14 98 1. Conventions used in this document 99 Requirements for the graceful shutdown of BGP sessions 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in RFC 2119. 105 2. Introduction 107 The BGP protocol is heavily used in Service Provider networks both 108 for Internet and BGP/MPLS VPN services. For resiliency purposes, 109 redundant routers and BGP sessions can be deployed to reduce the 110 consequences of an AS Border Router or BGP session breakdown on 111 customers' or peers' traffic. 113 We place ourselves in the context where a Service Provider needs to 114 shut down one or multiple BGP peering link(s) or a whole ASBR. If an 115 alternate path is available, the requirement is to avoid or reduce 116 customer or peer traffic loss during the BGP convergence. Indeed, as 117 an alternate path is available in the Autonomous System (AS), it 118 should be made possible to reroute the customer or peer traffic on 119 the backup path before the BGP session(s) is/are torn down and the 120 forwarding is interrupted on the nominal path. 122 The requirements also covers the subsequent re-establishment of the 123 BGP session as even this "UP" case can currently trigger route loss 124 and thus traffic loss at some routers. 126 Currently, the [BGP] and [MP-BGP] do not include any operation to 127 reduce or prevent traffic loss in case of planned maintenance 128 requiring the shutdown of a forwarding resource. When a BGP session 129 is taken down, BGP behaves as if it was a sudden link or router 130 failure. Besides, the introduction of Route Reflectors as per [BGP 131 RR] to solve scalability issues bound to iBGP full-meshes has 132 worsened the duration of routing convergence: some route reflectors 133 may hide the back up path and depending on RR topology more iBGP hops 134 may be involved in the iBGP convergence. On the other hand, some 135 protocols are already considering such graceful shutdown procedure 136 (e.g. [GMPLS G-Shut]). 138 Note that these planned maintenance operations cannot be addressed by 139 Graceful Restart extensions [BGP GR] as GR only applies when the 140 forwarding is preserved during the control plane restart. On the 141 contrary, Graceful Shutdown applies when the forwarding is 142 interrupted. 143 A successful approach of such mechanism should minimize the loss of 144 traffic in most foreseen maintenance situations. 146 3. Problem statement 148 As per [BGP], when one (or many) BGP session(s) are shut down to 149 perform a link or router maintenance operation, a BGP NOTIFICATION 150 message is sent to the peer and the session is then closed. A 151 protocol convergence is then triggered both by the local router and 153 Requirements for the graceful shutdown of BGP sessions 155 by the peer. Alternate paths to the destination are selected, if 156 known. If those alternates paths are not known prior to the BGP 157 session shutdown, additional BGP convergence steps are required in 158 each AS to search for an alternate path. 160 This behavior is not satisfactory in a maintenance situation because 161 the traffic that was directed towards the removed next-hops may be 162 lost until the end of the BGP convergence. As it is a planned 163 operation, a make before break solution should be made possible. 165 As maintenance operations are frequent in large networks 166 [Reliability], the global availability of the network is 167 significantly impaired by this BGP maintenance issue. 169 3.1. Example of undesirable BGP routing behavior 171 To illustrate these problems, let us consider the following example 172 where one customer router "CUST" is dual-attached to two SP routers 173 "ASBR1" and "ASBR2". 174 ASBR1 and ASBR2 are in the same AS and owned by the same service 175 provider. Both are iBGP client of the route reflector R1. 177 ' 178 AS1 ' AS2 179 ' 181 /-----------ASBR1--- 182 / \ 183 / \ 184 CUST R1 185 \ / 186 Z/z \ / 187 \-----------ASBR2--- 189 ' 190 AS1 ' AS2 191 ' 193 Before the maintenance, packets for destination Z/z use the CUST- 194 ASBR1 link because R1 selects ASBR1's route based on the IGP cost. 196 Let's assume the service provider wants to shutdown the ASBR1-CUST 197 link for maintenance purposes. Currently, when the shutdown is 198 performed on ASBR1, the following steps are performed: 199 1. ASBR1 sends a withdraw to its route reflector R1 for the prefix 200 Z/z. 201 2. R1 runs its decision process, selects the route from ASBR2 and 202 advertises the new path to ASBR1. 203 3. ASBR1 runs its decision process and recovers the reachability of 204 Z/z. 206 Requirements for the graceful shutdown of BGP sessions 208 Traffic is lost between step 1 when ASBR1 looses its route and step 3 209 when it discovers a new path. 211 Note that this is a simplified description for illustrative purpose. 212 In a bigger AS, multiple steps of BGP convergence may be required to 213 find and select the best alternate path (e.g. ASBR1 is chosen based 214 on a higher local pref, hierarchical route reflectors are used...). 215 When multiple BGP routers are involved and plenty of prefixes are 216 affected, the recovery process can take longer than applications 217 requirements. 219 3.2. Causes of packet loss 221 The loss of packets during the maintenance has two main causes: 222 - lack of an alternate path on some routers 223 - transient routing inconsistency. 225 Some routers may lack an alternate path because another router is 226 hiding the backup path. This router can be a route reflector only 227 propagating the best path. Or the backup ASBR does not advertise the 228 backup path because it prefers the nominal path. This lack of 229 knowledge of the alternate path is the first target of this 230 requirement draft. 232 Transient routing inconsistencies happen during iBGP convergence 233 because all routers are not updating their RIB at the same time. This 234 can lead to forwarding loops and then packet drops. This can be 235 avoided by performing only one IP lookup on BGP routes in each AS and 236 by using tunnels (e.g. MPLS LSP) to send packets between ASBRs. 238 4. Terminology 240 g-shut initiator: the router on which the session(s) shutdown is 241 (are) performed for the maintenance. 243 g-shut neighbor: a router that peers with the g-shut initiator 244 via (one of) the session(s) undergoing maintenance. 246 Affected prefixes: a prefix initially reached via the peering 247 link(s) undergoing maintenance. 249 Affected router: a router reaching an affected prefix via a 250 peering link undergoing maintenance. 252 Initiator AS: the autonomous system of the g-shut initiator 253 router. 255 Neighbor AS(es): the autonomous system(s) of the g-shut neighbor 256 router(s). 258 Requirements for the graceful shutdown of BGP sessions 260 5. Goals and requirements 262 When a BGP session of the router under maintenance is shut down, the 263 router removes the routes and then triggers the BGP convergence on 264 its BGP peers. The goal of BGP graceful shutdown is to initiate the 265 BGP convergence to find the alternate paths before the nominal paths 266 are removed. As a result, before the nominal BGP session is shut 267 down, all routers learn and use the alternate paths. Then the nominal 268 BGP session can be shut down. 270 As a result, provided an alternate path is available in the AS, the 271 packets are rerouted before the BGP session termination and fewer 272 packets (possibly none) are lost during the BGP convergence process 273 since at any time, all routers have a valid path. 275 Another goal is to minimize packet loss when the BGP session is re- 276 established following the maintenance. 278 From the above goals we can derive the following requirements: 280 a) A mechanism to advertise the maintenance action to all affected 281 routers is REQUIRED. Such mechanism may be either implicit or 282 explicit. Note that affected routers can be located both in the local 283 AS and in neighboring ASes. 285 b) An Internet wide convergence is OPTIONAL. However if the 286 initiator AS and the neighbor AS(es) have a backup path, they MUST be 287 able to gracefully converge before the nominal path is shut down. 289 c) The proposed solution SHOULD be applicable to any kind of BGP 290 sessions (e-BGP, i-BGP, i-BGP route reflector client, e-BGP 291 confederations, e-BGP multi hop, MultiProtocol BGP extension...) and 292 any address family. If a BGP implementation allows closing a sub-set 293 of AFIs carried in a MP-BGP session, this mechanism MAY be applicable 294 to this sub-set of AFIs. 296 Depending on the session type (eBGP, iBGP...), there may be some 297 variations in the proposed solution in order to fit the requirements. 299 The following cases should be handled in priority: 300 - The shutdown of an inter-AS link and therefore the shutdown of an 301 eBGP session. 302 - The shutdown of an AS Border Router and therefore the shutdown of 303 all its BGP sessions 304 - The shutdown of a customer access router and all of its BGP 305 sessions. In VPN as per [VPN], this router is called a CE and the use 306 of others protocols than BGP on the PE-CE access link should also be 307 considered (static routes, RIPv2, OSPF, IS-IS...). 309 d) The proposed solution SHOULD NOT change the BGP convergence 310 behavior for the ASes exterior to the maintenance process. An 312 Requirements for the graceful shutdown of BGP sessions 314 incremental deployment on a per AS or per BGP session basis SHOULD be 315 made possible. In case of partial deployment the proposed solution 316 SHOULD incrementally improve the maintenance process. The solution 317 SHOULD bring improvements even when one of the two ASes does not 318 support graceful shutdown. In particular, large Service Providers may 319 not be able to upgrade all of the deployed customer premises access 320 routers (CPE). 322 e) Redistribution or advertisement of (static) IP routes into BGP 323 SHOULD also be covered. 325 f) The proposed solution MAY be designed in order to avoid 326 transient forwarding loops. Indeed, forwarding loops increase packet 327 transit delay and may lead to link saturation. 329 g) The specific procedure SHOULD end when the BGP session is 330 closed. The procedure SHOULD be reverted, either automatically or 331 manually, when the session is re-established. During this reversion 332 procedure -when the session is brought up- the procedure SHOULD also 333 minimize packet loss when the nominal path is installed and used 334 again. In particular, it SHOULD be ensured that the backup path is 335 not removed from the routing tables of the effected nodes before it 336 learns the nominal path. In the end, once the planned maintenance is 337 finished and the shutdown resource becomes available again, the 338 nominal BGP routing MUST be reestablished. 340 The metrics to evaluate and compare the proposed solutions are, in 341 decreasing order of importance: 342 - The duration of the remaining loss of connectivity when the BGP 343 session is brought down or up 344 - The applicability to a wide range of BGP and network topologies, 345 especially those described in section 6; 346 - The duration of transient forwarding loops; 347 - The additional load introduced in BGP (eg BGP messages sent to peer 348 routers, peer ASes, the Internet). 350 6. Reference Topologies 352 In order to benchmark the proposed solutions, some typical BGP 353 topologies are detailed in this section. The solution drafts 354 should state its applicability for each of these possible 355 topologies. 357 However, solutions SHOULD be applicable to all possible BGP 358 topologies and not only to these below examples. 360 6.1. E-BGP topologies 362 6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2 363 Requirements for the graceful shutdown of BGP sessions 365 In this topology we have an asymmetric protection scheme between 366 AS1 and AS2: 367 - On AS2 side, two different routers are used to connect to AS1. 368 - On AS1 side, one single router with two BGP sessions is used. 370 ' 371 AS1 ' AS2 372 ' 373 /----------- ASBR2.1 374 / ' 375 / ' 376 ASBR1.1 ' 377 \ ' 378 \ ' 379 \----------- ASBR2.2 380 ' 381 ' 382 AS1 ' AS2 383 ' 385 The requirements of section 5 should be applicable to: 386 - Maintenance of one of the routers of AS2; 387 - Maintenance of one link between AS1 and AS2, performed either 388 on an AS1 or AS2 router. 390 Note that in case of maintenance of the whole router, all its BGP 391 session needs to be shutdown. 393 6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2 395 In this topology we have a symmetric protection scheme between 396 AS1 and AS2: on both sides, two different routers are used to 397 connect AS1 to AS2. 399 ' 400 AS1 ' AS2 401 ' 402 ASBR1.1----------- ASBR2.1 403 ' 404 ' 405 ' 406 ' 407 ' 408 ASBR1.2----------- ASBR2.2 409 ' 410 AS1 ' AS2 411 ' 413 The requirements of section 5 should be applicable to: 414 - Maintenance of any of the ASBR routers (in AS1 or AS2); 415 - Maintenance of one link between AS1 and AS2 performed either on 416 an AS1 or AS2 router. 418 Requirements for the graceful shutdown of BGP sessions 420 6.1.3. 2 ASBRs in AS2 each connected to two different ASes 422 In this topology at least three ASes are involved. Depending on 423 which routes are exchanged between these ASes, some protection 424 for some of the traffic may be possible. 426 ' 427 AS1 ' AS2 428 ' 429 ASBR1.1----------- ASBR2.1 430 | ' 431 | ' 432 '''''|'''''''''' 433 | ' 434 | ' 435 ASBR3.1----------- ASBR2.2 436 ' 437 AS3 ' AS2 439 The requirements of section 5 do not translate as easily as in 440 the two previous topologies because we do not require propagating 441 the maintenance advertisement outside of the two ASes involved in 442 an eBGP session. 443 For instance if ASBR2.2 requires a maintenance affecting ASBR3.1, 444 then ASBR3.1 will be notified. However we do not require for ASBR1.1 445 to be notified of the maintenance of the eBGP session between 446 ASBR3.1-ASBR2.2. 448 6.2. I-BGP topologies 450 We describe here some frequent i-BGP topologies that SHOULD be 451 supported. 452 Indeed maintenance of an e-BGP session needs to be propagated 453 within the AS so the solution may depend on the specific i-BGP 454 topology. 456 Requirements for the graceful shutdown of BGP sessions 458 6.2.1. iBGP Full-Mesh 460 In this topology we have a full mesh of iBGP sessions: 462 P1 ------ P2 463 | \ / | 464 | \ / | 465 | \ / | AS1 466 | / \ | 467 | / \ | 468 ASBR1.1---ASBR1.2 469 \ / 470 \ / 471 ''''''\''''/'''''''''''' 472 \ / AS2 473 ASBR2.1 475 When the session between ASBR1.1 and ASBR2.1 undergoes 476 maintenance, it is required that all i-BGP peers of ASBR1.1 477 reroute traffic to ASBR1.2 before the session between ASBR1.1 and 478 ASBR2.1 is shut down. 480 6.2.2. Route Reflector 482 In this topology, route reflectors are used to limit the number of 483 i-BGP sessions. 485 P1 RR----- P2 RR 486 | \ / | 487 | \ / | 488 | \ / | AS1 489 | \ / | 490 | / \ | 491 | / \ | 492 | / \ | 493 ASBR1.1 ASBR1.2 494 \ / 495 \ / 496 ''''''\''''''/'''''''''''' 497 \ / 498 \ / AS2 499 ASBR2.1 501 When the session between ASBR1.1 and ASBR2.1 undergoes 502 maintenance, it is required that all BGP routers of AS1 reroute 503 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 504 is shut down. 506 Requirements for the graceful shutdown of BGP sessions 508 6.2.3. hierarchical Route Reflector 510 In this topology, hierarchical route reflectors are used to limit 511 the number of i-BGP sessions. 513 P1/hRR -------- P2/hRR 514 | | 515 | | 516 | | AS1 517 | | 518 | | 520 P3/RR P4/RR 521 | | 522 | | 523 | | AS1 524 | | 525 | | 526 ASBR1.1 ASBR1.2 527 \ / 528 \ / 529 ''''''\'''''''''/'''''''''''' 530 \ / 531 \ / AS2 532 ASBR2.1 534 When the session between ASBR1.1 and ASBR2.1 undergoes 535 maintenance, it is required that all BGP routers of AS1 reroute 536 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 537 is shut down. 539 6.2.4. Confederations 541 In this topology, a confederation of ASs is used to limit the number 542 of i-BGP sessions. Moreover, RRs may be present in the member ASs of 543 the confederation. 544 Confederations may be run with different sub-options. Regarding the 545 IGP, each member AS can run its own IGP or they can all share the 546 same IGP. Regarding BGP, local_pref may or may not cross the member 547 AS boundaries. 548 A solution should support the shutdown of eBGP sessions between 549 member-ASs in the confederation in addition to the shutdown of eBGP 550 sessions between a member-AS and an AS outside of the confederation. 552 Requirements for the graceful shutdown of BGP sessions 554 ASBR1C.1 ---------- ASBR1C.2 555 | | 556 | | 557 | AS1C | 558 | | 559 | | 560 """|"""""""""""""""""""|""" 561 | " | 562 ASBR1A.2 " ASBR1B.2 563 | " | 564 | " | 565 | AS1A " AS1B | AS1 566 | " | 567 | " | 568 ASBR1A.1 " ASBR1B.1 569 \ " / 570 \ " / 571 ''''''\'''''''''''''/'''''''''''' 572 \ / 573 \ / AS2 574 ASBR2.1 576 In the above figure, member-AS AS1A, AS1B, AS1C belong to a 577 confederation of ASs in AS1. AS1A and AS1B are connected to AS2. 579 In normal operation, for the traffic toward AS2, 580 . AS1A sends the traffic directly to AS2 through ASBR1A.1 581 . AS1B sends the traffic directly to AS2 through ASBR1B.1 582 . AS1C load balances the traffic between AS1A and AS1B 584 When the session between ASBR1A.1 and ASBR2.1 undergoes 585 maintenance, it is required that all BGP routers of AS1 reroute 586 traffic to ASBR1B.1 before the session between ASBR1A.1 and 587 ASBR2.1 is shut down. 589 7. Security Considerations 591 Security considerations MUST be addressed by the proposed 592 solutions. 594 One AS SHOULD NOT be able to use the graceful shutdown procedure 595 to selectively influence routing decision in the peer AS (inbound 596 TE) outside the case of the planned maintenance. In the case the 597 proposed solution allows this, the peer AS SHOULD have means to 598 detect such behavior. 600 8. IANA Considerations 602 This document has no actions for IANA. 604 Requirements for the graceful shutdown of BGP sessions 606 9. References 608 9.1. Normative References 610 [BGP] Y. Rekhter, T. Li, 611 "A Border Gateway protocol 4 (BGP)", RFC 4271, January 2006. 613 [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter 614 "Multiprotocol Extensions for BGP-4", RFC 4760 January 2007. 616 [BGP RR] T. Bates, E. Chen, R. Chandra 617 "BGP Route Reflection: An Alternative to Full Mesh Internal BGP 618 (IBGP)", RFC 4456 April 2006. 620 [BGP GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter 621 "Graceful Restart Mechanism for BGP", RFC 4724 January 2007. 623 [VPN] E. Rosen, Y. Rekhter 624 "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364 625 February 2006. 627 9.2. Informative References 629 [GMPLS G-Shut] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton 630 "Graceful Shutdown in MPLS and Generalized MPLS Traffic 631 Engineering Networks" October 29, 2009, internet draft, draft-ietf- 632 ccamp-mpls-graceful-shutdown-08.txt, work in progress. 634 [Reliability] Network Strategy Partners, LLC. 635 "Reliable IP Nodes: A prerequisite to profitable IP services", 636 November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf 638 10. Acknowledgments 640 This draft is mostly an updated version of draft-dubois-bgp-pm- 641 reqs-02.txt. 643 Authors would like to thank Nicolas Dubois, Benoit Fondeviole, 644 Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier 645 Vinet, Tomonori Takeda, Vincent Gillet, Jean-Louis le Roux and 646 Pierre Alain Coste for the useful discussions on this subject, 647 their review and comments. 649 This draft has been partly sponsored by the European project IST 650 AGAVE. 652 Requirements for the graceful shutdown of BGP sessions 654 Authors' Addresses 656 Bruno Decraene 657 France Telecom 658 38-40 rue du General Leclerc 659 92794 Issy Moulineaux cedex 9 660 France 662 Email: bruno.decraene@orange-ftgroup.com 664 Pierre Francois 665 Universite catholique de Louvain 666 Place Ste Barbe, 2 667 Louvain-la-Neuve 1348 668 BE 670 Email: francois@info.ucl.ac.be 672 Cristel Pelsser 673 NTT Corporation 674 9-11, Midori-Cho 3 Chrome 675 Musashino-Shi, Tokyo 180-8585 676 Japan 678 Email: pelsser.cristel@lab.ntt.co.jp 680 Zubair Ahmad 681 Orange Business Services 682 13775 McLearen Road, Oak Hill VA 20171 683 USA 685 Email: zubair.ahmad@ orange-ftgroup.com 687 Antonio Jose Elizondo Armengol 688 Division de Analisis Tecnologicos 689 Technology Analysis Division 690 Telefonica I+D 691 C/ Emilio Vargas 6 692 28043, Madrid 694 E-mail: ajea@tid.es