--- 1/draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt 2010-06-14 20:13:27.000000000 +0200 +++ 2/draft-ietf-grow-bgp-graceful-shutdown-requirements-03.txt 2010-06-14 20:13:27.000000000 +0200 @@ -4,24 +4,24 @@ Intended status: Informational P. Francois UCL C. Pelsser IIJ Z. Ahmad Orange Business Services A. J. Elizondo Armengol Telefonica I+D T. Takeda NTT - April 30, 2010 + June 11, 2010 Requirements for the graceful shutdown of BGP sessions - draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt + draft-ietf-grow-bgp-graceful-shutdown-requirements-03.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from @@ -40,21 +40,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on October 27, 2010. + This Internet-Draft will expire on December 08, 2010. Requirements for the graceful shutdown of BGP sessions Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents @@ -100,21 +100,21 @@ 9.2. Informative References.....................................14 10. Acknowledgments............................................14 11. Author's Addresses.........................................15 Requirements for the graceful shutdown of BGP sessions 1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119. + document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Introduction The BGP protocol is heavily used in Service Provider networks both for Internet and BGP/MPLS VPN services. For resiliency purposes, redundant routers and BGP sessions can be deployed to reduce the consequences of an AS Border Router or BGP session breakdown on customers' or peers' traffic. We place ourselves in the context where a Service Provider performs a @@ -124,57 +124,57 @@ traffic loss during the BGP convergence. Indeed, as an alternate path is available in the Autonomous System (AS), it should be made possible to reroute the customer or peer traffic on this backup path before the BGP session(s) is/are torn down, the nominal path withdrawn and the forwarding is interrupted on the nominal path. The requirements also cover the subsequent re-establishment of the BGP session as even this "UP" case can currently trigger route loss and thus traffic loss at some routers. - Currently, [BGP] and [MP-BGP] do not include any operation to - gracefully withdraw a prefix while traffic toward that prefix could - still be correctly forwarded. When a BGP session is taken down, BGP - behaves as if it was a sudden link or router failure and withdraws - the prefixes learnt over that session, which may trigger traffic - loss. There is no mechanism to advertise to its BGP peers that the - prefix will soon be unreachable, while still being reachable. When - applicable, such mechanism would reduce or prevent traffic loss. It - would typically be applicable in case of a maintenance operation - requiring the shutdown of a forwarding resource. Typical examples - would be a link or line card maintenance, replacement or upgrade. It - may also be applicable for a software upgrade as it may involve a - firmware reset on the line cards and hence forwarding interruption. - The introduction of Route Reflectors as per [BGP RR] to solve - scalability issues bound to iBGP full-meshes has worsened the - duration of routing convergence as some route reflectors may hide the - back up path. Thus depending on RR topology more iBGP hops may be - involved in the iBGP convergence. - - Note that these planned maintenance operations cannot be addressed by - Graceful Restart extensions [BGP GR] as GR only applies when the + Currently, BGP [BGP-4] and MP-BGP [MP-BGP] do not include any + operation to gracefully withdraw a prefix while traffic toward that + prefix could still be correctly forwarded. When a BGP session is + taken down, BGP behaves as if it was a sudden link or router failure + and withdraws the prefixes learnt over that session, which may + trigger traffic loss. There is no mechanism to advertise to its BGP + peers that the prefix will soon be unreachable, while still being + reachable. When applicable, such mechanism would reduce or prevent + traffic loss. It would typically be applicable in case of a + maintenance operation requiring the shutdown of a forwarding + resource. Typical examples would be a link or line card maintenance, + replacement or upgrade. It may also be applicable for a software + upgrade as it may involve a firmware reset on the line cards and + hence forwarding interruption. + The introduction of Route Reflectors as per [RR] to solve scalability + issues bound to iBGP full-meshes has worsened the duration of routing + convergence as some route reflectors may hide the back up path. Thus + depending on RR topology more iBGP hops may be involved in the iBGP + convergence. Requirements for the graceful shutdown of BGP sessions + Note that these planned maintenance operations cannot be addressed by + Graceful Restart extensions [GR] as GR only applies when the forwarding is preserved during the control plane restart. On the contrary, Graceful Shutdown applies when the forwarding is interrupted. Note also that some protocols are already considering such graceful - shutdown procedure (e.g. [GMPLS G-Shut]). + shutdown procedure (e.g. GMPLS in [RFC5817]). A successful approach of such mechanism should minimize the loss of traffic in most foreseen maintenance situations. 3. Problem statement - As per [BGP], when one (or many) BGP session(s) are shut down, a BGP - NOTIFICATION message is sent to the peer and the session is then + As per [BGP-4], when one (or many) BGP session(s) are shut down, a + BGP NOTIFICATION message is sent to the peer and the session is then closed. A protocol convergence is then triggered both by the local router and by the peer. Alternate paths to the destination are selected, if known. If those alternates paths are not known prior to the BGP session shutdown, additional BGP convergence steps are required in each AS to search for an alternate path. This behavior is not satisfactory in a maintenance situation because the traffic that was directed towards the removed next-hops may be lost until the end of the BGP convergence. As it is a planned operation, a make before break solution should be made possible. @@ -316,26 +316,27 @@ Depending on the session type (eBGP, iBGP...), there may be some variations in the proposed solution in order to fit the requirements. The following cases should be handled in priority: - The shutdown of an inter-AS link and therefore the shutdown of an eBGP session. - The shutdown of an AS Border Router and therefore the shutdown of all its BGP sessions - The shutdown of a customer access router and all of its BGP - sessions. In VPN as per [VPN], this router is called a CE and the use - of others protocols than BGP on the PE-CE access link should also be - considered (static routes, RIPv2, OSPF, IS-IS...). + sessions. In BGP/MPLS VPN as per [VPN], this router is called a CE + and the use of others protocols than BGP on the PE-CE access link + should also be considered (static routes, RIPv2, OSPF, IS-IS...). d) The proposed solution SHOULD NOT change the BGP convergence - behavior for the ASes exterior to the maintenance process. + behavior for the ASes exterior to the maintenance process, namely + ASes other than the initiator AS and it(s) neighbor AS(es). e) An incremental deployment on a per AS or per BGP session basis SHOULD be made possible. In case of partial deployment the proposed solution SHOULD incrementally improve the maintenance process. The solution SHOULD bring improvements even when one of the two ASes does not support graceful shutdown. In particular, large Service Providers may not be able to upgrade all of the deployed customer premises access routers (CPE). f) Redistribution or advertisement of (static) IP routes into BGP @@ -343,31 +344,31 @@ g) The proposed solution MAY be designed in order to avoid transient forwarding loops. Indeed, forwarding loops increase packet transit delay and may lead to link saturation. h) The specific procedure SHOULD end when the BGP session is closed. The procedure SHOULD be reverted, either automatically or manually, when the session is re-established. During this reversion procedure -when the session is brought up- the procedure SHOULD also minimize packet loss when the nominal path is installed and used - again. In particular, it SHOULD be ensured that the backup path is Requirements for the graceful shutdown of BGP sessions + again. In particular, it SHOULD be ensured that the backup path is not removed from the routing tables of the effected nodes before it learns the nominal path. In the end, once the planned maintenance is finished and the shutdown resource becomes available again, the nominal BGP routing MUST be reestablished. - i) The solution SHOULD be simple and hence MAY only cover a subset - of the cases. + i) The solution SHOULD be simple and simple to operate. Hence it + MAY only cover a subset of the cases. The metrics to evaluate and compare the proposed solutions are, in decreasing order of importance: - The duration of the remaining loss of connectivity when the BGP session is brought down or up - The applicability to a wide range of BGP and network topologies, especially those described in section 6; - The simplicity; - The duration of transient forwarding loops; - The additional load introduced in BGP (eg BGP messages sent to peer @@ -630,43 +631,46 @@ 8. IANA Considerations This document has no actions for IANA. Requirements for the graceful shutdown of BGP sessions 9. References 9.1. Normative References - [BGP] Y. Rekhter, T. Li, - "A Border Gateway protocol 4 (BGP)", RFC 4271, January 2006. + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. - [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter - "Multiprotocol Extensions for BGP-4", RFC 4760 January 2007. + [BGP-4] Y. Rekhter, T. Li, "A Border Gateway protocol 4 (BGP)", RFC + 4271, January 2006. - [BGP RR] T. Bates, E. Chen, R. Chandra + [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol + Extensions for BGP-4", RFC 4760 January 2007. + + [RR] T. Bates, E. Chen, R. Chandra "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456 April 2006. - [BGP GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter - "Graceful Restart Mechanism for BGP", RFC 4724 January 2007. - [VPN] E. Rosen, Y. Rekhter "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364 February 2006. 9.2. Informative References - [GMPLS G-Shut] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton + [RFC5817] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton "Graceful Shutdown in MPLS and Generalized MPLS Traffic Engineering Networks", RFC 5817 April 2010. + [GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter + "Graceful Restart Mechanism for BGP", RFC 4724 January 2007. + [Reliability] Network Strategy Partners, LLC. "Reliable IP Nodes: A prerequisite to profitable IP services", November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf 10. Acknowledgments This draft is mostly an updated version of draft-dubois-bgp-pm- reqs-02.txt. Authors would like to thank Nicolas Dubois, Benoit Fondeviole,