idnits 2.17.1 draft-ietf-grow-bgp-graceful-shutdown-requirements-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 23, 2009) is 5291 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'BGP RR' is defined on line 620, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 3 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 23, 2009 16 Requirements for the graceful shutdown of BGP sessions 17 draft-ietf-grow-bgp-graceful-shutdown-requirements-01.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 22, 2010. 52 Requirements for the graceful shutdown of BGP sessions 54 Copyright Notice 56 Copyright (c) 2009 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 in effect on the date of 61 publication of this document (http://trustee.ietf.org/license-info). 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. 65 Abstract 67 The BGP protocol is heavily used in Service Provider networks both 68 for Internet and BGP/MPLS VPN services. For resiliency purposes, 69 redundant routers and BGP sessions can be deployed to reduce the 70 consequences of an AS Border Router or BGP session breakdown on 71 customers' or peers' traffic. However simply taking down or even up a 72 BGP session for maintenance purposes may still induce connectivity 73 losses during the BGP convergence. This is no more satisfactory for 74 new applications (e.g. voice over IP, on line gaming, VPN). 75 Therefore, a solution is required for the graceful shutdown of a (set 76 of) BGP session(s) in order to limit the amount of traffic loss 77 during a planned shutdown. This document expresses requirements for 78 such a solution. 80 Table of Contents 82 1. Conventions used in this document...........................3 83 2. Introduction................................................3 84 3. Problem statement...........................................3 85 3.1. Example of undesirable BGP routing behavior.................4 86 3.2. Causes of packet loss.......................................5 87 4. Terminology.................................................5 88 5. Goals and requirements......................................6 89 6. Reference Topologies........................................7 90 6.1. E-BGP topologies............................................8 91 6.2. I-BGP topologies............................................9 92 7. Security Considerations....................................12 93 8. IANA Considerations........................................12 94 9. References.................................................13 95 9.1. Normative References.......................................13 96 9.2. Informative References.....................................13 97 10. Acknowledgments............................................13 98 11. Author's Addresses.........................................14 100 Requirements for the graceful shutdown of BGP sessions 102 1. Conventions used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119. 108 2. Introduction 110 The BGP protocol is heavily used in Service Provider networks both 111 for Internet and BGP/MPLS VPN services. For resiliency purposes, 112 redundant routers and BGP sessions can be deployed to reduce the 113 consequences of an AS Border Router or BGP session breakdown on 114 customers' or peers' traffic. 116 We place ourselves in the context where a Service Provider needs to 117 shut down one or multiple BGP peering link(s) or a whole ASBR. If an 118 alternate path is available, the requirement is to avoid or reduce 119 customer or peer traffic loss during the BGP convergence. Indeed, as 120 an alternate path is available in the Autonomous System (AS), it 121 should be made possible to reroute the customer or peer traffic on 122 the backup path before the BGP session(s) is/are torn down and the 123 forwarding is interrupted on the nominal path. 125 The requirements also covers the subsequent re-establishment of the 126 BGP session as even this "UP" case can currently trigger route loss 127 and thus traffic loss at some routers. 129 Currently, the [BGP] and [MP-BGP] do not include any operation to 130 reduce or prevent traffic loss in case of planned maintenance 131 requiring the shutdown of a forwarding resource. When a BGP session 132 is taken down, BGP behaves as if it was a sudden link or router 133 failure. Besides, the introduction of Route Reflectors as per [BGP 134 RR] to solve scalability issues bound to iBGP full-meshes has 135 worsened the duration of routing convergence: some route reflectors 136 may hide the back up path and depending on RR topology more iBGP hops 137 may be involved in the iBGP convergence. On the other hand, some 138 protocols are already considering such graceful shutdown procedure 139 (e.g. [GMPLS G-Shut]). 141 Note that these planned maintenance operations cannot be addressed by 142 Graceful Restart extensions [BGP GR] as GR only applies when the 143 forwarding is preserved during the control plane restart. On the 144 contrary, Graceful Shutdown applies when the forwarding is 145 interrupted. 146 A successful approach of such mechanism should minimize the loss of 147 traffic in most foreseen maintenance situations. 149 3. Problem statement 151 As per [BGP], when one (or many) BGP session(s) are shut down to 152 perform a link or router maintenance operation, a BGP NOTIFICATION 154 Requirements for the graceful shutdown of BGP sessions 156 message is sent to the peer and the session is then closed. A 157 protocol convergence is then triggered both by the local router and 158 by the peer. Alternate paths to the destination are selected, if 159 known. If those alternates paths are not known prior to the BGP 160 session shutdown, additional BGP convergence steps are required in 161 each AS to search for an alternate path. 163 This behavior is not satisfactory in a maintenance situation because 164 the traffic that was directed towards the removed next-hops may be 165 lost until the end of the BGP convergence. As it is a planned 166 operation, a make before break solution should be made possible. 168 As maintenance operations are frequent in large networks 169 [Reliability], the global availability of the network is 170 significantly impaired by this BGP maintenance issue. 172 3.1. Example of undesirable BGP routing behavior 174 To illustrate these problems, let us consider the following example 175 where one customer router "CUST" is dual-attached to two SP routers 176 "ASBR1" and "ASBR2". 177 ASBR1 and ASBR2 are in the same AS and owned by the same service 178 provider. Both are iBGP client of the route reflector R1. 180 ' 181 AS1 ' AS2 182 ' 184 /-----------ASBR1--- 185 / \ 186 / \ 187 CUST R1 188 \ / 189 Z/z \ / 190 \-----------ASBR2--- 192 ' 193 AS1 ' AS2 194 ' 196 Before the maintenance, packets for destination Z/z use the CUST- 197 ASBR1 link because R1 selects ASBR1's route based on the IGP cost. 199 Let's assume the service provider wants to shutdown the ASBR1-CUST 200 link for maintenance purposes. Currently, when the shutdown is 201 performed on ASBR1, the following steps are performed: 202 1. ASBR1 sends a withdraw to its route reflector R1 for the prefix 203 Z/z. 204 2. R1 runs its decision process, selects the route from ASBR2 and 205 advertises the new path to ASBR1. 207 Requirements for the graceful shutdown of BGP sessions 209 3. ASBR1 runs its decision process and recovers the reachability of 210 Z/z. 212 Traffic is lost between step 1 when ASBR1 looses its route and step 3 213 when it discovers a new path. 215 Note that this is a simplified description for illustrative purpose. 216 In a bigger AS, multiple steps of BGP convergence may be required to 217 find and select the best alternate path (e.g. ASBR1 is chosen based 218 on a higher local pref, hierarchical route reflectors are used...). 219 When multiple BGP routers are involved and plenty of prefixes are 220 affected, the recovery process can take longer than applications 221 requirements. 223 3.2. Causes of packet loss 225 The loss of packets during the maintenance has two main causes: 226 - lack of an alternate path on some routers 227 - transient routing inconsistency. 229 Some routers may lack an alternate path because another router is 230 hiding the backup path. This router can be a route reflector only 231 propagating the best path. Or the backup ASBR does not advertise the 232 backup path because it prefers the nominal path. This lack of 233 knowledge of the alternate path is the first target of this 234 requirement draft. 236 Transient routing inconsistencies happen during iBGP convergence 237 because all routers are not updating their RIB at the same time. This 238 can lead to forwarding loops and then packet drops. This can be 239 avoided by performing only one IP lookup on BGP routes in each AS and 240 by using tunnels (e.g. MPLS LSP) to send packets between ASBRs. 242 4. Terminology 244 g-shut initiator: the router on which the session(s) shutdown is 245 (are) performed for the maintenance. 247 g-shut neighbor: a router that peers with the g-shut initiator 248 via (one of) the session(s) undergoing maintenance. 250 Affected prefixes: a prefix initially reached via the peering 251 link(s) undergoing maintenance. 253 Affected router: a router reaching an affected prefix via a 254 peering link undergoing maintenance. 256 Initiator AS: the autonomous system of the g-shut initiator 257 router. 259 Requirements for the graceful shutdown of BGP sessions 261 Neighbor AS(es): the autonomous system(s) of the g-shut neighbor 262 router(s). 264 5. Goals and requirements 266 When a BGP session of the router under maintenance is shut down, the 267 router removes the routes and then triggers the BGP convergence on 268 its BGP peers. The goal of BGP graceful shutdown is to initiate the 269 BGP convergence to find the alternate paths before the nominal paths 270 are removed. As a result, before the nominal BGP session is shut 271 down, all routers learn and use the alternate paths. Then the nominal 272 BGP session can be shut down. 274 As a result, provided an alternate path is available in the AS, the 275 packets are rerouted before the BGP session termination and fewer 276 packets (possibly none) are lost during the BGP convergence process 277 since at any time, all routers have a valid path. 279 Another goal is to minimize packet loss when the BGP session is re- 280 established following the maintenance. 282 From the above goals we can derive the following requirements: 284 a) A mechanism to advertise the maintenance action to all affected 285 routers is REQUIRED. Such mechanism may be either implicit or 286 explicit. Note that affected routers can be located both in the local 287 AS and in neighboring ASes. 289 b) An Internet wide convergence is OPTIONAL. However if the 290 initiator AS and the neighbor AS(es) have a backup path, they MUST be 291 able to gracefully converge before the nominal path is shut down. 293 c) The proposed solution SHOULD be applicable to any kind of BGP 294 sessions (e-BGP, i-BGP, i-BGP route reflector client, e-BGP 295 confederations, e-BGP multi hop, MultiProtocol BGP extension...) and 296 any address family. If a BGP implementation allows closing a sub-set 297 of AFIs carried in a MP-BGP session, this mechanism MAY be applicable 298 to this sub-set of AFIs. 300 Depending on the session type (eBGP, iBGP...), there may be some 301 variations in the proposed solution in order to fit the requirements. 303 The following cases should be handled in priority: 304 - The shutdown of an inter-AS link and therefore the shutdown of an 305 eBGP session. 306 - The shutdown of an AS Border Router and therefore the shutdown of 307 all its BGP sessions 308 - The shutdown of a customer access router and all of its BGP 309 sessions. In VPN as per [VPN], this router is called a CE and the use 310 of others protocols than BGP on the PE-CE access link should also be 311 considered (static routes, RIPv2, OSPF, IS-IS...). 313 Requirements for the graceful shutdown of BGP sessions 315 d) The proposed solution SHOULD NOT change the BGP convergence 316 behavior for the ASes exterior to the maintenance process. An 317 incremental deployment on a per AS or per BGP session basis SHOULD be 318 made possible. In case of partial deployment the proposed solution 319 SHOULD incrementally improve the maintenance process. The solution 320 SHOULD bring improvements even when one of the two ASes does not 321 support graceful shutdown. In particular, large Service Providers may 322 not be able to upgrade all of the deployed customer premises access 323 routers (CPE). 325 e) Redistribution or advertisement of (static) IP routes into BGP 326 SHOULD also be covered. 328 f) The proposed solution MAY be designed in order to avoid 329 transient forwarding loops. Indeed, forwarding loops increase packet 330 transit delay and may lead to link saturation. 332 g) The specific procedure SHOULD end when the BGP session is 333 closed. The procedure SHOULD be reverted, either automatically or 334 manually, when the session is re-established. During this reversion 335 procedure -when the session is brought up- the procedure SHOULD also 336 minimize packet loss when the nominal path is installed and used 337 again. In particular, it SHOULD be ensured that the backup path is 338 not removed from the routing tables of the effected nodes before it 339 learns the nominal path. In the end, once the planned maintenance is 340 finished and the shutdown resource becomes available again, the 341 nominal BGP routing MUST be reestablished. 343 The metrics to evaluate and compare the proposed solutions are, in 344 decreasing order of importance: 345 - The duration of the remaining loss of connectivity when the BGP 346 session is brought down or up 347 - The applicability to a wide range of BGP and network topologies, 348 especially those described in section 6; 349 - The duration of transient forwarding loops; 350 - The additional load introduced in BGP (eg BGP messages sent to peer 351 routers, peer ASes, the Internet). 353 6. Reference Topologies 355 In order to benchmark the proposed solutions, some typical BGP 356 topologies are detailed in this section. The solution drafts 357 should state its applicability for each of these possible 358 topologies. 360 However, solutions SHOULD be applicable to all possible BGP 361 topologies and not only to these below examples. 363 Requirements for the graceful shutdown of BGP sessions 365 6.1. E-BGP topologies 367 6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2 369 In this topology we have an asymmetric protection scheme between 370 AS1 and AS2: 371 - On AS2 side, two different routers are used to connect to AS1. 372 - On AS1 side, one single router with two BGP sessions is used. 374 ' 375 AS1 ' AS2 376 ' 377 /----------- ASBR2.1 378 / ' 379 / ' 380 ASBR1.1 ' 381 \ ' 382 \ ' 383 \----------- ASBR2.2 384 ' 385 ' 386 AS1 ' AS2 387 ' 389 The requirements of section 5 should be applicable to: 390 - Maintenance of one of the routers of AS2; 391 - Maintenance of one link between AS1 and AS2, performed either 392 on an AS1 or AS2 router. 394 Note that in case of maintenance of the whole router, all its BGP 395 session needs to be shutdown. 397 6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2 399 In this topology we have a symmetric protection scheme between 400 AS1 and AS2: on both sides, two different routers are used to 401 connect AS1 to AS2. 403 ' 404 AS1 ' AS2 405 ' 406 ASBR1.1----------- ASBR2.1 407 ' 408 ' 409 ' 410 ' 411 ' 412 ASBR1.2----------- ASBR2.2 413 ' 414 AS1 ' AS2 415 ' 417 Requirements for the graceful shutdown of BGP sessions 419 The requirements of section 5 should be applicable to: 420 - Maintenance of any of the ASBR routers (in AS1 or AS2); 421 - Maintenance of one link between AS1 and AS2 performed either on 422 an AS1 or AS2 router. 424 6.1.3. 2 ASBRs in AS2 each connected to two different ASes 426 In this topology at least three ASes are involved. Depending on 427 which routes are exchanged between these ASes, some protection 428 for some of the traffic may be possible. 430 ' 431 AS1 ' AS2 432 ' 433 ASBR1.1----------- ASBR2.1 434 | ' 435 | ' 436 '''''|'''''''''' 437 | ' 438 | ' 439 ASBR3.1----------- ASBR2.2 440 ' 441 AS3 ' AS2 443 The requirements of section 5 do not translate as easily as in 444 the two previous topologies because we do not require propagating 445 the maintenance advertisement outside of the two ASes involved in 446 an eBGP session. 447 For instance if ASBR2.2 requires a maintenance affecting ASBR3.1, 448 then ASBR3.1 will be notified. However we do not require for ASBR1.1 449 to be notified of the maintenance of the eBGP session between 450 ASBR3.1-ASBR2.2. 452 6.2. I-BGP topologies 454 We describe here some frequent i-BGP topologies that SHOULD be 455 supported. 456 Indeed maintenance of an e-BGP session needs to be propagated 457 within the AS so the solution may depend on the specific i-BGP 458 topology. 460 Requirements for the graceful shutdown of BGP sessions 462 6.2.1. iBGP Full-Mesh 464 In this topology we have a full mesh of iBGP sessions: 466 P1 ------ P2 467 | \ / | 468 | \ / | 469 | \ / | AS1 470 | / \ | 471 | / \ | 472 ASBR1.1---ASBR1.2 473 \ / 474 \ / 475 ''''''\''''/'''''''''''' 476 \ / AS2 477 ASBR2.1 479 When the session between ASBR1.1 and ASBR2.1 undergoes 480 maintenance, it is required that all i-BGP peers of ASBR1.1 481 reroute traffic to ASBR1.2 before the session between ASBR1.1 and 482 ASBR2.1 is shut down. 484 6.2.2. Route Reflector 486 In this topology, route reflectors are used to limit the number of 487 i-BGP sessions. 489 P1 RR----- P2 RR 490 | \ / | 491 | \ / | 492 | \ / | AS1 493 | \ / | 494 | / \ | 495 | / \ | 496 | / \ | 497 ASBR1.1 ASBR1.2 498 \ / 499 \ / 500 ''''''\''''''/'''''''''''' 501 \ / 502 \ / AS2 503 ASBR2.1 505 When the session between ASBR1.1 and ASBR2.1 undergoes 506 maintenance, it is required that all BGP routers of AS1 reroute 507 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 508 is shut down. 510 Requirements for the graceful shutdown of BGP sessions 512 6.2.3. hierarchical Route Reflector 514 In this topology, hierarchical route reflectors are used to limit 515 the number of i-BGP sessions. 517 P1/hRR -------- P2/hRR 518 | | 519 | | 520 | | AS1 521 | | 522 | | 524 P3/RR P4/RR 525 | | 526 | | 527 | | AS1 528 | | 529 | | 530 ASBR1.1 ASBR1.2 531 \ / 532 \ / 533 ''''''\'''''''''/'''''''''''' 534 \ / 535 \ / AS2 536 ASBR2.1 538 When the session between ASBR1.1 and ASBR2.1 undergoes 539 maintenance, it is required that all BGP routers of AS1 reroute 540 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 541 is shut down. 543 6.2.4. Confederations 545 In this topology, a confederation of ASs is used to limit the number 546 of i-BGP sessions. Moreover, RRs may be present in the member ASs of 547 the confederation. 548 Confederations may be run with different sub-options. Regarding the 549 IGP, each member AS can run its own IGP or they can all share the 550 same IGP. Regarding BGP, local_pref may or may not cross the member 551 AS boundaries. 552 A solution should support the shutdown of eBGP sessions between 553 member-ASs in the confederation in addition to the shutdown of eBGP 554 sessions between a member-AS and an AS outside of the confederation. 556 Requirements for the graceful shutdown of BGP sessions 558 ASBR1C.1 ---------- ASBR1C.2 559 | | 560 | | 561 | AS1C | 562 | | 563 | | 564 """|"""""""""""""""""""|""" 565 | " | 566 ASBR1A.2 " ASBR1B.2 567 | " | 568 | " | 569 | AS1A " AS1B | AS1 570 | " | 571 | " | 572 ASBR1A.1 " ASBR1B.1 573 \ " / 574 \ " / 575 ''''''\'''''''''''''/'''''''''''' 576 \ / 577 \ / AS2 578 ASBR2.1 580 In the above figure, member-AS AS1A, AS1B, AS1C belong to a 581 confederation of ASs in AS1. AS1A and AS1B are connected to AS2. 583 In normal operation, for the traffic toward AS2, 584 . AS1A sends the traffic directly to AS2 through ASBR1A.1 585 . AS1B sends the traffic directly to AS2 through ASBR1B.1 586 . AS1C load balances the traffic between AS1A and AS1B 588 When the session between ASBR1A.1 and ASBR2.1 undergoes 589 maintenance, it is required that all BGP routers of AS1 reroute 590 traffic to ASBR1B.1 before the session between ASBR1A.1 and 591 ASBR2.1 is shut down. 593 7. Security Considerations 595 Security considerations MUST be addressed by the proposed 596 solutions. 598 One AS SHOULD NOT be able to use the graceful shutdown procedure 599 to selectively influence routing decision in the peer AS (inbound 600 TE) outside the case of the planned maintenance. In the case the 601 proposed solution allows this, the peer AS SHOULD have means to 602 detect such behavior. 604 8. IANA Considerations 606 This document has no actions for IANA. 608 Requirements for the graceful shutdown of BGP sessions 610 9. References 612 9.1. Normative References 614 [BGP] Y. Rekhter, T. Li, 615 "A Border Gateway protocol 4 (BGP)", RFC 4271, January 2006. 617 [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter 618 "Multiprotocol Extensions for BGP-4", RFC 4760 January 2007. 620 [BGP RR] T. Bates, E. Chen, R. Chandra 621 "BGP Route Reflection: An Alternative to Full Mesh Internal BGP 622 (IBGP)", RFC 4456 April 2006. 624 [BGP GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter 625 "Graceful Restart Mechanism for BGP", RFC 4724 January 2007. 627 [VPN] E. Rosen, Y. Rekhter 628 "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364 629 February 2006. 631 9.2. Informative References 633 [GMPLS G-Shut] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton 634 "Graceful Shutdown in MPLS and Generalized MPLS Traffic 635 Engineering Networks" September 15, 2009, internet draft, draft-ietf- 636 ccamp-mpls-graceful-shutdown-12.txt, work in progress. 638 [Reliability] Network Strategy Partners, LLC. 639 "Reliable IP Nodes: A prerequisite to profitable IP services", 640 November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf 642 10. Acknowledgments 644 This draft is mostly an updated version of draft-dubois-bgp-pm- 645 reqs-02.txt. 647 Authors would like to thank Nicolas Dubois, Benoit Fondeviole, 648 Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier 649 Vinet, Vincent Gillet, Jean-Louis le Roux and Pierre Alain Coste 650 for the useful discussions on this subject, their review and 651 comments. 653 This draft has been partly sponsored by the European project IST 654 AGAVE. 656 Requirements for the graceful shutdown of BGP sessions 658 Authors' Addresses 660 Bruno Decraene 661 France Telecom 662 38-40 rue du General Leclerc 663 92794 Issy Moulineaux cedex 9 664 France 665 Email: bruno.decraene@orange-ftgroup.com 667 Pierre Francois 668 Universite catholique de Louvain 669 Place Ste Barbe, 2 670 Louvain-la-Neuve 1348 671 BE 672 Email: francois@info.ucl.ac.be 674 Cristel Pelsser 675 Internet Initiative Japan 676 Jinbocho Mitsui Building 677 1-105 Kanda jinbo-cho 678 Chiyoda-ku, Tokyo 101-0051 679 Japan 680 Email: cristel@iij.ad.jp 682 Zubair Ahmad 683 Orange Business Services 684 13775 McLearen Road, Oak Hill VA 20171 685 USA 686 Email: zubair.ahmad@ orange-ftgroup.com 688 Antonio Jose Elizondo Armengol 689 Division de Analisis Tecnologicos 690 Technology Analysis Division 691 Telefonica I+D 692 C/ Emilio Vargas 6 693 28043, Madrid 694 E-mail: ajea@tid.es 696 Tomonori Takeda 697 NTT Corporation 698 9-11, Midori-Cho 3 Chrome 699 Musashino-Shi, Tokyo 180-8585 700 Japan 701 Email: takeda.tomonori@lab.ntt.co.jp