Network Working Group N. Dubois B. Decraene B. Fondeviole Internet Draft France Telecom R&D Document: draft-dubois-bgp-pm-reqs-01.txt February 2005 Expiration Date: August 2005 Requirements for planned maintenance of BGP sessions draft-dubois-bgp-pm-reqs-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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. Abstract To ease the maintenance of BGP-4 [BGP-4] sessions and limit the amount of traffic that is lost during planned maintenance operations on routers, a solution is required in order to gracefully shutdown a router or a session. 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 [1]. Dubois Expires September 2004 [Page 1] Internet Draft BGP planned maintenance requirements February 2005 Table of Contents 1. Introduction.........................................2 2. Problem statement....................................2 3. Goal and requirements................................3 4. Scope................................................4 5. Example..............................................4 6. Reference topologies.................................5 6. Security Considerations..............................8 7. Intellectual Property Statement......................9 8. Security Considerations..............................9 9. Acknowledgments......................................10 10.References...........................................11 11.Authors' Addresses:..................................11 1. Introduction The BGP-4 protocol is heavily used in service provider networks. For resiliency purposes, most of the IP network operators deploy redundant routers and BGP sessions to minimize the risk of BGP session breakdown toward their customers or peers. In a context where a Service Provider wants to upgrade or remove a particular router that maintains one or several BGP sessions, our requirement is to avoid customer or peer traffic loss as much as possible. It should be made possible to reroute the customer or peer traffic before the maintenance operation. Currently, the BGP-4 specification does not include any operation to prevent traffic loss in case of planned maintenance. A successful approach of such mechanism should indeed minimize the loss of traffic in most foreseen maintenance contexts and be easily deployable, if possible backward compatible. 2. Problem statement Currently, when one or more BGP session needs to be shut down, a BGP NOTIFICATION message is sent to the peer and the session is then closed. A protocol convergence is then triggered both in the local router and in the peer and if possible an alternate route to the destination is selected. This behavior is not satisfactory in a maintenance situation because customer traffic that was directed toward the removed next-hops is Dubois Expires September 2004 [Page 2] Internet Draft BGP planned maintenance requirements February 2005 lost until the end of BGP convergence. As it is a planned operation, a make before break solution should be possible. As maintenance operations are frequent in large networks, the global availability of the network is significantly impaired by the BGP maintenance issues. 3. Goal and Requirements When some or all BGP sessions of a router needs to be administratively shut down, instead of sending a BGP NOTIFICATION message and/or tearing the TCP session down, our goal is to have the following two-step behavior: Step 1: A mechanism is implemented in order to gracefully reroute traffic toward and from the next-hop that is going to be maintained. By doing so, customers' flows are rerouted before the maintenance and no traffic is lost for all the destination prefixes for which an alternate route is available. If possible, the proposed solution should be designed in order to avoid transient routing loops. Step 2: Once customer traffic is correctly rerouted BGP-4 sessions are shutdown. Step 3: Once maintenance is terminated, if possible a mechanism should be implemented to gracefully restore to the original state avoiding transient routing loops. As a result, if another router provides an alternate path towards a set of destination prefixes, the IP flows are re-routed before the session termination and no traffic is lost during rerouting, since both the forwarding and the Loc-RIB tables are maintained while the peers are re-computing their forwarding tables. From the above goal we can derivate the following requirements: a/ A mechanism to advertise the maintenance action to all relevant routers in both ASes is required. Are considered as relevant routers all the routers that are sending traffic to any BGP-NLRI whose next hops are the router undergoing maintenance. If possible, the proposed solution should be designed in order to avoid transient routing loops. Dubois Expires September 2004 [Page 3] Internet Draft BGP planned maintenance requirements February 2005 b/ It is required that the router implements a mechanism to maintain the forwarding for the NLRI undergoing maintenance until all reroutable traffic has been rerouted. c/ A mechanism may be needed to indicate the end of the graceful maintenance operation. If possible, the proposed solution should be designed in order to avoid transient routing loops. d/ An Internet wide convergence is not required. However the local AS and its direct peers must be able to gracefully converge before the service interruption. e/ The proposed solution should be applicable to all kinds of BGP-4 sessions (e-BGP, i-BGP and i-BGP client) and any address family. If the BGP-4 implementation allows closing a sub-set of AFIs carried in a MP-BGP-4 session, this mechanism is applicable to this sub-set of AFI identifiers. However we see the two following particular case as a priority: -Case of the reload of one AS border router; -Case of the maintenance of one particular e-BGP sessions; -Case of PE <-> CE links in a MPLS-VPN environment. f/The proposed solution should not change the BGP convergence behaviour for the ASes exterior to the maintenance process. An incremental deployment on a per AS basis must be possible. 4. Scope Purpose of this requirement is neither to solve all the convergence issues that may arise within the Internet nor to modify the convergence properties of the BGP protocol. The example section illustrates one typical and important case where this requirement should be applicable and tries to make it more understandable. In addition a topologies section presents some BGP topologies (both i-BGP and e-BGP) and confronts them to the requirement. These topologies should be used to test the proper behavior of any proposed solution. 5. Example Purpose of this section is to give one typical example and help the reader understand how graceful maintenance will enhance the availability of the inter provider BGP connections. Let us consider the following example (Figure 1 below) where one customer router (denoted as "CUST" in the figure) is dual-homed to Dubois Expires September 2004 [Page 4] Internet Draft BGP planned maintenance requirements February 2005 two SP routers, denoted as "ASBR1" and "ASBR2", ASBR1 and ASBR2 are in the same AS and owned by the same service provider. ' ' ' AS1 ' AS2 ' /-----------ASBR1-----P1---- / | / | CUST | \ | X.Y/16 \ | \-----------ASBR2-----P2---- ' ' AS1 ' AS2 ' Figure 1: Redundant peering example. Let's say traffic is normally conveyed by the CUST-ASBR1 link. and the SP wants to shutdown ASBR1 for maintenance purposes. The standard behavior is: 1. ASBR1 tears all its BGP-4 sessions down. 2. As a result, it removes all its BGP-4 routes from its RIB and FIB tables. 3. Its BGP-4 peers remove all the routes that were announced by the shutting down peer. During its peers convergence : - CUST continues to send traffic to ASBR1. ASBR1 drops this traffic because it has no route to destination. Dubois Expires September 2004 [Page 5] Internet Draft BGP planned maintenance requirements February 2005 - P1 continues to send traffic to ASBR1. ASBR1 drops this traffic because it has no route to X.Y/16. From the customer's point of view, the traffic is lost during BGP-4 convergence time. With the new required behavior defined in this document: - On all its BGP-4 sessions, ASBR 1 signals a maintenance according to the requirement defined in a/ - During this time it keeps forwarding customer traffic in both directions. - Once all reroutable traffic has been rerouted, ASBR1 closes its BGP-4 sessions with its peers. No trafic is lost. 6. Reference topologies In order to qualify each proposed solutions, some typical BGP topologies are detailed. Proposed solutions should be applicable to all these BGP topologies. 6.1. E-BGP topologies: E-BGP topology "2PE <-> 1CE" ' AS1 ' AS2 ' /-----------Router / ' / ' Router ' \ ' \ ' \-----------Router ' ' AS1 ' AS2 ' In this topology we have an asymmetric protection scheme between AS 1 and AS 2: - On AS 2 side, two different routers have been used to connect to AS 1. - On AS 1 side, one single router with two BGP sessions is used. The requirement of section 4 should be applicable to: - Maintenance of one of the router of AS2 - Maintenance of one of the two sessions between AS1 and AS2 Dubois Expires September 2004 [Page 6] Internet Draft BGP planned maintenance requirements February 2005 E-BGP topology "2PE <-> 2CE" ' AS1 ' AS2 ' Router1,1-----------Router2,1 ' ' ' ' ' Router1,2-----------Router2,2 ' AS1 ' AS2 ' In this topology we have a symmetric protection scheme between AS 1 and AS 2: - On both sides, two different routers have been used to connect AS 1 to AS 2. The requirement of section 4 should be applicable to: - Maintenance of any of the routers (in AS 1 or 2); - Maintenance of one of the two sessions between AS1 and AS2; E-BGP topology "2ISP <-> 2CE" ' AS1 ' AS2 ' Router1-----------Router2,1 | ' | ' '''''|'''''''''' | ' | ' Router3-----------Router2,2 ' AS3 ' AS2 In this topology the protection scheme between AS 1 and AS 2 is not as straitforward as in the two previous topologies: - Depending on which routes are exchanged between the 3 ASes, some protection for some of the traffic may be possible. The requirement of section 4 does not translate as easily as in the two previous topologies, as we do not require to propagate the maintenance advertisement in the internet. For instance if router2,2 requires a maintenance impacting router 3, router3 will be notified, however we do not require for Router1 to be notified. Dubois Expires September 2004 [Page 7] Internet Draft BGP planned maintenance requirements February 2005 6.2. I-BGP topologies: We describe here some frequent i-BGP topologies, as the solution efficiency may vary depending on the i-BGP deployment choices. One can remark that having a maintenance advertisement for maintenance of the i-BGP session is not necessary: the administrator of one AS can use a lot of various means to gracefully reroute traffic. However maintenance of an e-BGP session needs to be propagated within the AS, so a solution to the requirement should work in any of the below topologies. "i-BGP topology Full-Mesh" It is a full-mesh topology as represented below. P1 -------- P2 |\ /| | \ / | | \ / | AS 1 | / \ | | / \ | ASBR1------ASBR2 \ / \ / ''''''\''''''/'''''''''''' \ / \ / AS 2 CE We consider there is a full-mesh of i-BGP sessions between all routers. In case the session between CE and ASBR1 undergoes maintenance, it is required that all iBGP peers of ASBR1 reroute traffic to ASBR2 before the session between ASBR1 and ASBR2 is shut down. "i-BGP topology RR" P1 RR----- P2 RR |\ /| | \ / | | \ / | AS 1 | / \ | | / \ | ASBR1 ASBR2 \ / \ / ''''''\''''''/'''''''''''' \ / \ / AS 2 CE Dubois Expires September 2004 [Page 8] Internet Draft BGP planned maintenance requirements February 2005 It is the case where some route reflectors are used to limit the number of i-BGP sessions. "i-BGP topology hierarchical RR" It is the case where some hierarchical route reflectors are used to limit the number of i-BGP sessions. P1/hRR -------- P2/hRR | | | | | | AS 1 | | | | P1/RR -------- P2/RR | | | | | | AS 1 | | | | ASBR1 ASBR2 \ / \ / ''''''\'''''''''/'''''''''''' \ / \ / AS 2 CE 7. Security Considerations Eventual security issues will be addressed in future versions of this draft. 8. Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to Dubois Expires September 2004 [Page 9] Internet Draft BGP planned maintenance requirements February 2005 pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. 8.1. IPR Disclosure Acknowledgement By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 9. Acknowledgments The author would like to thank Christian Jacquenet, Olivier Bonaventure, Xavier Vinet, Vincent Gillet and Jean-Louis le Roux for the useful discussions on this subject, their review and comments. 10. References [BGP-4] Rekhter, Y. and T. Li (editors), "A Border Gateway protocol 4 (BGP-4)", Internet Draft draft-ietf-idr-bgp4-23.txt. Dubois Expires September 2004 [Page 10] Internet Draft BGP planned maintenance requirements February 2005 11. Author's Addresses Nicolas Dubois France Telecom R&D 38-40 rue de general Leclerc 92794 Issy Moulineaux cedex 9 France Email: nicolas.dubois@francetelecom.com Bruno Decraene France Telecom R&D 38-40 rue de general Leclerc 92794 Issy Moulineaux cedex 9 France Email: bruno.decraene@francetelecom.com Benoit Fondeviole France Telecom R&D 38-40 rue de general Leclerc 92794 Issy Moulineaux cedex 9 France Email: benoit.fondeviole@francetelecom.com Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Dubois Expires September 2004 [Page 11]