--- 1/draft-ietf-grow-bgp-gshut-03.txt 2012-10-22 12:14:19.269841845 +0200 +++ 2/draft-ietf-grow-bgp-gshut-04.txt 2012-10-22 12:14:19.289841631 +0200 @@ -1,24 +1,24 @@ Network Working Group Pierre Francois Internet-Draft Institute IMDEA Networks Intended status: Informational Bruno Decraene -Expires: June 10, 2012 France Telecom +Expires: April 25, 2013 France Telecom Cristel Pelsser Internet Initiative Japan Keyur Patel Clarence Filsfils Cisco Systems - December 8, 2011 + October 22, 2012 Graceful BGP session shutdown - draft-ietf-grow-bgp-gshut-03 + draft-ietf-grow-bgp-gshut-04 Abstract This draft describes operational procedures aimed at reducing the amount of traffic lost during planned maintenances of routers or links, involving the shutdown of BGP peering sessions. Status of this Memo This Internet-Draft is submitted in full conformance with the @@ -27,25 +27,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on June 10, 2012. + This Internet-Draft will expire on April 25, 2013. Copyright Notice - Copyright (c) 2011 IETF Trust and the persons identified as the + Copyright (c) 2012 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -79,21 +79,21 @@ 6. Link Up cases . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Unreachability local to the ASBR . . . . . . . . . . . . . 8 6.2. iBGP convergence . . . . . . . . . . . . . . . . . . . . . 9 7. IANA assigned g-shut BGP community . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Appendix A. Alternative techniques with limited applicability . . 11 A.1. Multi Exit Discriminator tweaking . . . . . . . . . . . . 11 A.2. IGP distance Poisoning . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 1. Introduction Routing changes in BGP can be caused by planned, maintenance operations. This document discusses operational procedures to be applied in order to reduce or eliminate losses of packets during the maintenance. These losses come from the transient lack of reachability during the BGP convergence following the shutdown of an eBGP peering session between two Autonomous System Border Routers (ASBR). @@ -183,39 +183,39 @@ performing the maintenance. The part of the procedure aimed at avoiding LoC for incoming paths can thus be applied even if no LoC are expected for the outgoing paths. 4.2. Make before break convergence: g-shut This section describes configurations and actions to be performed to perform a graceful shutdown procedure for eBGP peering links. The goal of this procedure is to let the paths being shutdown - visible, but with a lower local preference, while alternate paths + visible, but with a lower LOCAL_PREF value, while alternate paths spread through the iBGP topology. Instead of withdrawing the path, routers of an AS will keep on using it until they become aware of alternate paths. 4.2.1. eBGP g-shut 4.2.1.1. Pre-configuration On each ASBR supporting the g-shut procedure, an outbound BGP route policy is applied on all iBGP sessions of the ASBR, that: o matches the g-shut community - o sets the local-pref of the paths tagged with the g-shut - community to a low value + o sets the LOCAL_PREF attribute of the paths tagged with the + g-shut community to a low value o removes the g-shut community from the paths. o optionally, adds an AS specific g-shut community on these paths to indicate that these are to be withdrawn soon. If some - ingress ASBRs reset the local preference attribute, this AS - specific g-shut community will be used to override other local + ingress ASBRs reset the LOCAL_PREF attribute, this AS specific + g-shut community will be used to override other LOCAL_PREF preference changes. Note that in the case where an AS is aggregating multiple routes under a covering prefix, it is recommended to filter out the g-shut community from the resulting aggregate BGP route. By doing so, the setting of the g-shut community on one of the aggregated routes will not let the entire aggregate inherit the community. Not doing so would let the entire aggregate undergo the g-shut behavior. 4.2.1.2. Operations at maintenance time @@ -234,31 +234,31 @@ o perform a BGP session shutdown. 4.2.1.3. BGP implementation support for G-Shut A BGP router implementation MAY provide features aimed at automating the application of the graceful shutdown procedures described above. Upon a session shutdown specified as graceful by the operator, a BGP implementation supporting a g-shut feature SHOULD: - 1. Update all the paths propagated over the corresponding eBGP - session, tagging the GSHUT community to them. Any subsequent - update sent to the session being gracefully shut down would be - tagged with the GSHUT community. - 2. Lower the local preference value of the paths received over the - eBGP session being shut down, upon their propagation over iBGP - sessions. Optionally, also tag these paths with an AS specific - g-shut community. Note that alternatively, the local preference - of the paths received over the eBGP session can be lowered on - the g-shut initiator itself, instead of only when propagating - over its iBGP sessions. + 1. On the eBGP side, update all the paths propagated over the + corresponding eBGP session, tagging the GSHUT community to them. + Any subsequent update sent to the session being gracefully shut + down would be tagged with the GSHUT community. + 2. On the iBGP side, lower the LOCAL_PREF value of the paths + received over the eBGP session being shut down, upon their + propagation over iBGP sessions. Optionally, also tag these + paths with an AS specific g-shut community. Note that + alternatively, the LOCAL_PREF of the paths received over the + eBGP session can be lowered on the g-shut initiator itself, + instead of only when propagating over its iBGP sessions. 3. Optionally shut down the session after a configured time. 4. Prevent the GSHUT community from being inherited by a path that would aggregate some paths tagged with the GSHUT community. This behavior avoids the GSHUT procedure to be applied to the aggregate upon the graceful shutdown of one of its covered prefixes. A BGP implementation supporting a g-shut feature SHOULD also automatically install the BGP policies that are supposed to be configured, as decribed in Section 4.2.1.1 for sessions over which @@ -268,24 +268,24 @@ If the iBGP topology is viable after the maintenance of the session, i.e, if all BGP speakers of the AS have an iBGP signaling path for all prefixes advertised on this g-shut iBGP session, then the shutdown of an iBGP session does not lead to transient unreachability. 4.2.3. Router g-shut In the case of a shutdown of a router, a reconfiguration of the - outbound BGP route policies of the g-shut initiator MAY be performed - to set a low local-pref value for the paths originated by the g-shut - initiator (e.g, BGP aggregates redistributed from other protocols, - including static routes). + outbound BGP route policies of the g-shut initiator SHOULD be + performed to set a low LOCAL_PREF value for the paths originated by + the g-shut initiator (e.g, BGP aggregates redistributed from other + protocols, including static routes). This behavior is equivalent to the recommended behavior for paths "redistributed" from eBGP sessions to iBGP sessions in the case of the shutdown of an ASBR. 5. Forwarding modes and transient forwarding loops during convergence The g-shut procedure or the solutions improving the availability of alternate paths, do not change the fact that BGP convergence and the subsequent FIB updates are runned independently on each router of the @@ -369,21 +369,21 @@ For Internet routes, a non transitive extended community will be reserved from the pool defined in [EXT_POOL]. Using such a community type allows for not leaking graceful signaling out of the AS boundaries, without the need to explicitly configure filters to strip the community off upon path propagation. 8. Security Considerations By providing the g-shut service to a neighboring AS, an ISP provides - means to this neighbor to lower the local-pref value assigned to the + means to this neighbor to lower the LOCAL_PREF value assigned to the paths received from this neighbor. The neighbor could abuse the technique and do inbound traffic engineering by declaring some prefixes as undergoing a maintenance so as to switch traffic to another peering link. If this behavior is not tolerated by the ISP, it SHOULD monitor the use of the g-shut community by this neighbor. ASes using the regular (transitive) g-shut community SHOULD remove @@ -394,44 +394,40 @@ transitive extended community do not need to do this as the community is non transitive and hence cannot be used by remote ASes. 9. Acknowledgments The authors wish to thank Olivier Bonaventure and Pradosh Mohapatra for their useful comments on this work. 10. References - [AddPath] D. Walton, A. Retana, and E. Chen, "Advertisement of - Multiple Paths in BGP", draft-walton-bgp-add-paths-06.txt - (work in progress). + [AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder, + "Advertisement of Multiple Paths in BGP", + draft-ietf-idr-add-paths-07.txt (work in progress). [BestExternal] - Marques, P., Fernando, R., Chen, E., and P. Mohapatra, - "Advertisement of the best-external route to IBGP", - draft-ietf-idr-best-external-00.txt, May 2009. + Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. + Gredler, "Advertisement of the best-external route to + IBGP", draft-ietf-idr-best-external-05.txt. [REQS] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., Armengol, A., and T. Takeda, "Requirements for the - graceful shutdown of BGP sessions", - draft-ietf-grow-bgp-graceful-shutdown-requirements- - - 06.txt, October 2010. + graceful shutdown of BGP sessions", RFC 6198. [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended Communities Attribute", RFC 4360, February 2006. [EXT_POOL] Decraene, B. and P. Francois, "Assigned BGP extended communities", - draft-ietf-idr-reserved-extended-communities-01, - May 2011. + draft-ietf-idr-reserved-extended-communities-03. [BGPWKC] "http://www.iana.org/assignments/ bgp-well-known-communities". [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Appendix A. Alternative techniques with limited applicability A few alternative techniques have been considered to provide g-shut @@ -468,33 +464,33 @@ Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganese 28918 ES Email: pierre.francois@imdea.org Bruno Decraene France Telecom 38-40 rue du General Leclerc - 92794 Issi Moulineaux cedex 9 + 92794 Issy Moulineaux cedex 9 FR Email: bruno.decraene@orange.com Cristel Pelsser Internet Initiative Japan Jinbocho Mitsui Bldg. 1-105 Kanda Jinbo-cho Tokyo 101-0051 JP - Email: pelsser.cristel@iij.ad.jp + Email: cristel@iij.ad.jp Keyur Patel Cisco Systems 170 West Tasman Dr San Jose, CA 95134 US Email: keyupate@cisco.com Clarence Filsfils