idnits 2.17.1 draft-ietf-grow-bgp-graceful-shutdown-requirements-03.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 (June 11, 2010) is 5061 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 June 11, 2010 16 Requirements for the graceful shutdown of BGP sessions 17 draft-ietf-grow-bgp-graceful-shutdown-requirements-03.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 December 08, 2010. 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 BGP protocol is heavily used in Service Provider networks both 72 for Internet and BGP/MPLS VPN services. For resiliency purposes, 73 redundant routers and BGP sessions can be deployed to reduce the 74 consequences of an AS Border Router or BGP session breakdown on 75 customers' or peers' traffic. However simply taking down or even 76 bringing up a BGP session for maintenance purposes may still induce 77 connectivity losses during the BGP convergence. This is no more 78 satisfactory for new applications (e.g. voice over IP, on line 79 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............................................8 95 6.2. I-BGP topologies...........................................10 96 7. Security Considerations....................................13 97 8. IANA Considerations........................................13 98 9. References.................................................14 99 9.1. Normative References.......................................14 100 9.2. Informative References.....................................14 101 10. Acknowledgments............................................14 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 BGP protocol is heavily used in Service Provider networks both 115 for Internet and BGP/MPLS VPN services. For resiliency purposes, 116 redundant routers and BGP sessions can be deployed to reduce the 117 consequences of an AS Border Router or BGP session breakdown on 118 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 Before the maintenance, packets for destination Z/z use the CUST- 213 ASBR1 link because R1 selects ASBR1's route based on the IGP cost. 215 Let's assume the service provider wants to shutdown the ASBR1-CUST 216 link for maintenance purposes. Currently, when the shutdown is 217 performed on ASBR1, the following steps are performed: 218 1. ASBR1 sends a withdraw to its route reflector R1 for the prefix 219 Z/z. 220 2. R1 runs its decision process, selects the route from ASBR2 and 221 advertises the new path to ASBR1. 222 3. ASBR1 runs its decision process and recovers the reachability of 223 Z/z. 225 Traffic is lost between step 1 when ASBR1 looses its route and step 3 226 when it discovers a new path. 228 Note that this is a simplified description for illustrative purpose. 229 In a bigger AS, multiple steps of BGP convergence may be required to 230 find and select the best alternate path (e.g. ASBR1 is chosen based 231 on a higher local pref, hierarchical route reflectors are used...). 232 When multiple BGP routers are involved and plenty of prefixes are 233 affected, the recovery process can take longer than applications 234 requirements. 236 3.2. Causes of packet loss 238 The loss of packets during the maintenance has two main causes: 239 - lack of an alternate path on some routers 240 - transient routing inconsistency. 242 Some routers may lack an alternate path because another router is 243 hiding the backup path. This router can be a route reflector only 244 propagating the best path. Or the backup ASBR does not advertise the 245 backup path because it prefers the nominal path. This lack of 247 Requirements for the graceful shutdown of BGP sessions 249 knowledge of the alternate path is the first target of this 250 requirement draft. 252 Transient routing inconsistencies happen during iBGP convergence 253 because all routers are not updating their RIB at the same time. This 254 can lead to forwarding loops and then packet drops. This can be 255 avoided by performing only one IP lookup on BGP routes in each AS and 256 by using tunnels (e.g. MPLS LSP) to send packets between ASBRs. 258 4. Terminology 260 g-shut initiator: the router on which the session(s) shutdown is 261 (are) performed for the maintenance. 263 g-shut neighbor: a router that peers with the g-shut initiator 264 via (one of) the session(s) undergoing maintenance. 266 Affected prefixes: a prefix initially reached via the peering 267 link(s) undergoing maintenance. 269 Affected router: a router reaching an affected prefix via a 270 peering link undergoing maintenance. 272 Initiator AS: the autonomous system of the g-shut initiator 273 router. 275 Neighbor AS(es): the autonomous system(s) of the g-shut neighbor 276 router(s). 278 5. Goals and requirements 280 When a BGP session of the router under maintenance is shut down, the 281 router removes the routes and then triggers the BGP convergence on 282 its BGP peers. The goal of BGP graceful shutdown is to initiate the 283 BGP convergence to find the alternate paths before the nominal paths 284 are removed. As a result, before the nominal BGP session is shut 285 down, all routers learn and use the alternate paths. Then the nominal 286 BGP session can be shut down. 288 As a result, provided an alternate path is available in the AS, the 289 packets are rerouted before the BGP session termination and fewer 290 packets (possibly none) are lost during the BGP convergence process 291 since at any time, all routers have a valid path. 293 Another goal is to minimize packet loss when the BGP session is re- 294 established following the maintenance. 296 From the above goals we can derive the following requirements: 298 a) A mechanism to advertise the maintenance action to all affected 299 routers is REQUIRED. Such mechanism may be either implicit or 301 Requirements for the graceful shutdown of BGP sessions 303 explicit. Note that affected routers can be located both in the local 304 AS and in neighboring ASes. 306 b) An Internet wide convergence is OPTIONAL. However if the 307 initiator AS and the neighbor AS(es) have a backup path, they MUST be 308 able to gracefully converge before the nominal path is shut down. 310 c) The proposed solution SHOULD be applicable to any kind of BGP 311 sessions (e-BGP, i-BGP, i-BGP route reflector client, e-BGP 312 confederations, e-BGP multi hop, MultiProtocol BGP extension...) and 313 any address family. If a BGP implementation allows closing a sub-set 314 of AFIs carried in a MP-BGP session, this mechanism MAY be applicable 315 to this sub-set of AFIs. 317 Depending on the session type (eBGP, iBGP...), there may be some 318 variations in the proposed solution in order to fit the requirements. 320 The following cases should be handled in priority: 321 - The shutdown of an inter-AS link and therefore the shutdown of an 322 eBGP session. 323 - The shutdown of an AS Border Router and therefore the shutdown of 324 all its BGP sessions 325 - The shutdown of a customer access router and all of its BGP 326 sessions. In BGP/MPLS VPN as per [VPN], this router is called a CE 327 and the use of others protocols than BGP on the PE-CE access link 328 should also be considered (static routes, RIPv2, OSPF, IS-IS...). 330 d) The proposed solution SHOULD NOT change the BGP convergence 331 behavior for the ASes exterior to the maintenance process, namely 332 ASes other than the initiator AS and it(s) neighbor AS(es). 334 e) An incremental deployment on a per AS or per BGP session basis 335 SHOULD be made possible. In case of partial deployment the proposed 336 solution SHOULD incrementally improve the maintenance process. The 337 solution SHOULD bring improvements even when one of the two ASes does 338 not support graceful shutdown. In particular, large Service Providers 339 may not be able to upgrade all of the deployed customer premises 340 access routers (CPE). 342 f) Redistribution or advertisement of (static) IP routes into BGP 343 SHOULD also be covered. 345 g) The proposed solution MAY be designed in order to avoid 346 transient forwarding loops. Indeed, forwarding loops increase packet 347 transit delay and may lead to link saturation. 349 h) The specific procedure SHOULD end when the BGP session is 350 closed. The procedure SHOULD be reverted, either automatically or 351 manually, when the session is re-established. During this reversion 352 procedure -when the session is brought up- the procedure SHOULD also 353 minimize packet loss when the nominal path is installed and used 355 Requirements for the graceful shutdown of BGP sessions 357 again. In particular, it SHOULD be ensured that the backup path is 358 not removed from the routing tables of the effected nodes before it 359 learns the nominal path. In the end, once the planned maintenance is 360 finished and the shutdown resource becomes available again, the 361 nominal BGP routing MUST be reestablished. 363 i) The solution SHOULD be simple and simple to operate. Hence it 364 MAY only cover a subset of the cases. 366 The metrics to evaluate and compare the proposed solutions are, in 367 decreasing order of importance: 368 - The duration of the remaining loss of connectivity when the BGP 369 session is brought down or up 370 - The applicability to a wide range of BGP and network topologies, 371 especially those described in section 6; 372 - The simplicity; 373 - The duration of transient forwarding loops; 374 - The additional load introduced in BGP (eg BGP messages sent to peer 375 routers, peer ASes, the Internet). 377 6. Reference Topologies 379 In order to benchmark the proposed solutions, some typical BGP 380 topologies are detailed in this section. The solution drafts 381 should state its applicability for each of these possible 382 topologies. 384 However, solutions SHOULD be applicable to all possible BGP 385 topologies and not only to these below examples. Note that this 386 is a "SHOULD" rather than a "MUST" as a partial lightweight 387 solution may be preferred to a full but more complex solution. 388 Especially since some ISP may not be concerned by some topologies 389 (e.g. confederations). 391 6.1. E-BGP topologies 393 We describe here some frequent eBGP topologies that SHOULD be 394 supported by the solution. 396 6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2 398 In this topology we have an asymmetric protection scheme between 399 AS1 and AS2: 400 - On AS2 side, two different routers are used to connect to AS1. 401 - On AS1 side, one single router with two BGP sessions is used. 403 Requirements for the graceful shutdown of BGP sessions 405 ' 406 AS1 ' AS2 407 ' 408 /----------- ASBR2.1 409 / ' 410 / ' 411 ASBR1.1 ' 412 \ ' 413 \ ' 414 \----------- ASBR2.2 415 ' 416 ' 417 AS1 ' AS2 418 ' 420 The requirements of section 5 should be applicable to: 421 - Maintenance of one of the routers of AS2; 422 - Maintenance of one link between AS1 and AS2, performed either 423 on an AS1 or AS2 router. 425 Note that in case of maintenance of the whole router, all its BGP 426 session needs to be shutdown. 428 6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2 430 In this topology we have a symmetric protection scheme between 431 AS1 and AS2: on both sides, two different routers are used to 432 connect AS1 to AS2. 434 ' 435 AS1 ' AS2 436 ' 437 ASBR1.1----------- ASBR2.1 438 ' 439 ' 440 ' 441 ' 442 ' 443 ASBR1.2----------- ASBR2.2 444 ' 445 AS1 ' AS2 446 ' 448 The requirements of section 5 should be applicable to: 449 - Maintenance of any of the ASBR routers (in AS1 or AS2); 450 - Maintenance of one link between AS1 and AS2 performed either on 451 an AS1 or AS2 router. 453 Requirements for the graceful shutdown of BGP sessions 455 6.1.3. 2 ASBRs in AS2 each connected to two different ASes 457 In this topology at least three ASes are involved. Depending on 458 which routes are exchanged between these ASes, some protection 459 for some of the traffic may be possible. 461 ' 462 AS1 ' AS2 463 ' 464 ASBR1.1----------- ASBR2.1 465 | ' 466 | ' 467 '''''|'''''''''' 468 | ' 469 | ' 470 ASBR3.1----------- ASBR2.2 471 ' 472 AS3 ' AS2 474 The requirements of section 5 do not translate as easily as in 475 the two previous topologies because we do not require propagating 476 the maintenance advertisement outside of the two ASes involved in 477 an eBGP session. 478 For instance if ASBR2.2 requires a maintenance affecting ASBR3.1, 479 then ASBR3.1 will be notified. However we do not require for ASBR1.1 480 to be notified of the maintenance of the eBGP session between 481 ASBR3.1-ASBR2.2. 483 6.2. I-BGP topologies 485 We describe here some frequent iBGP topologies that SHOULD be 486 supported by the solution. 488 6.2.1. iBGP Full-Mesh 490 In this topology we have a full mesh of iBGP sessions: 492 P1 ------ P2 493 | \ / | 494 | \ / | 495 | \ / | AS1 496 | / \ | 497 | / \ | 498 ASBR1.1---ASBR1.2 499 \ / 500 \ / 501 ''''''\''''/'''''''''''' 502 \ / AS2 503 ASBR2.1 505 Requirements for the graceful shutdown of BGP sessions 507 When the session between ASBR1.1 and ASBR2.1 undergoes 508 maintenance, it is required that all i-BGP peers of ASBR1.1 509 reroute traffic to ASBR1.2 before the session between ASBR1.1 and 510 ASBR2.1 is shut down. 512 6.2.2. Route Reflector 514 In this topology, route reflectors are used to limit the number of 515 i-BGP sessions. 517 P1 RR----- P2 RR 518 | \ / | 519 | \ / | 520 | \ / | AS1 521 | \ / | 522 | / \ | 523 | / \ | 524 | / \ | 525 ASBR1.1 ASBR1.2 526 \ / 527 \ / 528 ''''''\''''''/'''''''''''' 529 \ / 530 \ / AS2 531 ASBR2.1 533 When the session between ASBR1.1 and ASBR2.1 undergoes 534 maintenance, it is required that all BGP routers of AS1 reroute 535 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 536 is shut down. 538 6.2.3. hierarchical Route Reflector 540 In this topology, hierarchical route reflectors are used to limit 541 the number of i-BGP sessions. 543 Requirements for the graceful shutdown of BGP sessions 545 P1/hRR -------- P2/hRR 546 | | 547 | | 548 | | AS1 549 | | 550 | | 552 P3/RR P4/RR 553 | | 554 | | 555 | | AS1 556 | | 557 | | 558 ASBR1.1 ASBR1.2 559 \ / 560 \ / 561 ''''''\'''''''''/'''''''''''' 562 \ / 563 \ / AS2 564 ASBR2.1 566 When the session between ASBR1.1 and ASBR2.1 undergoes 567 maintenance, it is required that all BGP routers of AS1 reroute 568 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 569 is shut down. 571 6.2.4. Confederations 573 In this topology, a confederation of ASs is used to limit the number 574 of i-BGP sessions. Moreover, RRs may be present in the member ASs of 575 the confederation. 576 Confederations may be run with different sub-options. Regarding the 577 IGP, each member AS can run its own IGP or they can all share the 578 same IGP. Regarding BGP, local_pref may or may not cross the member 579 AS boundaries. 580 A solution should support the shutdown of eBGP sessions between 581 member-ASs in the confederation in addition to the shutdown of eBGP 582 sessions between a member-AS and an AS outside of the confederation. 584 Requirements for the graceful shutdown of BGP sessions 586 ASBR1C.1 ---------- ASBR1C.2 587 | | 588 | | 589 | AS1C | 590 | | 591 | | 592 """|"""""""""""""""""""|""" 593 | " | 594 ASBR1A.2 " ASBR1B.2 595 | " | 596 | " | 597 | AS1A " AS1B | AS1 598 | " | 599 | " | 600 ASBR1A.1 " ASBR1B.1 601 \ " / 602 \ " / 603 ''''''\'''''''''''''/'''''''''''' 604 \ / 605 \ / AS2 606 ASBR2.1 608 In the above figure, member-AS AS1A, AS1B, AS1C belong to a 609 confederation of ASs in AS1. AS1A and AS1B are connected to AS2. 611 In normal operation, for the traffic toward AS2, 612 . AS1A sends the traffic directly to AS2 through ASBR1A.1 613 . AS1B sends the traffic directly to AS2 through ASBR1B.1 614 . AS1C load balances the traffic between AS1A and AS1B 616 When the session between ASBR1A.1 and ASBR2.1 undergoes 617 maintenance, it is required that all BGP routers of AS1 reroute 618 traffic to ASBR1B.1 before the session between ASBR1A.1 and 619 ASBR2.1 is shut down. 621 7. Security Considerations 623 Security considerations MUST be addressed by the proposed 624 solutions. 626 The solution SHOULD NOT increase the ability for one AS to 627 selectively influence routing decision in the peer AS (inbound 628 TE) outside the case of the BGP session shutdown. Otherwise, the 629 peer AS SHOULD have means to detect such behavior. 631 8. IANA Considerations 633 This document has no actions for IANA. 635 Requirements for the graceful shutdown of BGP sessions 637 9. References 639 9.1. Normative References 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [BGP-4] Y. Rekhter, T. Li, "A Border Gateway protocol 4 (BGP)", RFC 645 4271, January 2006. 647 [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol 648 Extensions for BGP-4", RFC 4760 January 2007. 650 [RR] T. Bates, E. Chen, R. Chandra 651 "BGP Route Reflection: An Alternative to Full Mesh Internal BGP 652 (IBGP)", RFC 4456 April 2006. 654 [VPN] E. Rosen, Y. Rekhter 655 "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364 656 February 2006. 658 9.2. Informative References 660 [RFC5817] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton 661 "Graceful Shutdown in MPLS and Generalized MPLS Traffic 662 Engineering Networks", RFC 5817 April 2010. 664 [GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter 665 "Graceful Restart Mechanism for BGP", RFC 4724 January 2007. 667 [Reliability] Network Strategy Partners, LLC. 668 "Reliable IP Nodes: A prerequisite to profitable IP services", 669 November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf 671 10. Acknowledgments 673 This draft is mostly an updated version of draft-dubois-bgp-pm- 674 reqs-02.txt. 676 Authors would like to thank Nicolas Dubois, Benoit Fondeviole, 677 Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier 678 Vinet, Vincent Gillet, Jean-Louis le Roux and Pierre Alain Coste 679 for the useful discussions on this subject, their review and 680 comments. 682 This draft has been partly sponsored by the European project IST 683 AGAVE. 685 Requirements for the graceful shutdown of BGP sessions 687 Authors' Addresses 689 Bruno Decraene 690 France Telecom 691 38-40 rue du General Leclerc 692 92794 Issy Moulineaux cedex 9 693 France 695 Email: bruno.decraene@orange-ftgroup.com 697 Pierre Francois 698 Universite catholique de Louvain 699 Place Ste Barbe, 2 700 Louvain-la-Neuve 1348 701 BE 703 Email: francois@info.ucl.ac.be 705 Cristel Pelsser 706 Internet Initiative Japan 707 Jinbocho Mitsui Building 708 1-105 Kanda jinbo-cho 709 Chiyoda-ku, Tokyo 101-0051 710 Japan 712 Email: cristel@iij.ad.jp 714 Zubair Ahmad 715 Orange Business Services 716 13775 McLearen Road, Oak Hill VA 20171 717 USA 719 Email: zubair.ahmad@ orange-ftgroup.com 721 Antonio Jose Elizondo Armengol 722 Division de Analisis Tecnologicos 723 Technology Analysis Division 724 Telefonica I+D 725 C/ Emilio Vargas 6 726 28043, Madrid 728 E-mail: ajea@tid.es 730 Tomonori Takeda 731 NTT Corporation 732 9-11, Midori-Cho 3 Chrome 734 Requirements for the graceful shutdown of BGP sessions 736 Musashino-Shi, Tokyo 180-8585 737 Japan 739 Email: takeda.tomonori@lab.ntt.co.jp