--- 1/draft-ietf-grow-bgp-gshut-04.txt 2014-01-28 05:14:33.971137645 -0800 +++ 2/draft-ietf-grow-bgp-gshut-05.txt 2014-01-28 05:14:33.995138244 -0800 @@ -1,24 +1,24 @@ Network Working Group Pierre Francois Internet-Draft Institute IMDEA Networks Intended status: Informational Bruno Decraene -Expires: April 25, 2013 France Telecom +Expires: August 1, 2014 Orange Cristel Pelsser Internet Initiative Japan Keyur Patel Clarence Filsfils Cisco Systems - October 22, 2012 + January 28, 2014 Graceful BGP session shutdown - draft-ietf-grow-bgp-gshut-04 + draft-ietf-grow-bgp-gshut-05 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 April 25, 2013. + This Internet-Draft will expire on August 1, 2014. Copyright Notice - Copyright (c) 2012 IETF Trust and the persons identified as the + Copyright (c) 2014 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 @@ -179,22 +179,22 @@ Note that the LoC for the inbound traffic of the maintained router, induced by a lack of alternate path propagation within the iBGP topology of a neighboring AS is not under the control of the operator 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. + This section describes configurations and actions to be performed for + the graceful shutdown of eBGP peering links. The goal of this procedure is to let the paths being shutdown 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 @@ -281,21 +281,21 @@ 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 + subsequent FIB updates are run independently on each router of the ASes. If the AS applying the solution does not rely on encapsulation to forward packets from the Ingress Border Router to the Egress Border Router, then transient forwarding loops and consequent packet losses can occur during the convergence process. If zero LoC is required, encapsulation is required between ASBRs of the AS. 6. Link Up cases We identify two potential causes for transient packet losses upon an eBGP link up event. The first one is local to the g-no-shut @@ -329,21 +329,21 @@ A typical example for such transient unreachability for a given prefix is the following: Let's consider 3 route reflectors RR1, RR2, RR3. There is a full mesh of iBGP session between them. 1. RR1 is initially advertising the current best path to the members of its iBGP RR full-mesh. It propagated that path within its RR full-mesh. RR2 knows only that path towards the prefix. - 2. RR3 receives a new best path orginated by the "g-no-shut" + 2. RR3 receives a new best path originated by the "g-no-shut" initiator, being one of its RR clients. RR3 selects it as best, and propagates an UPDATE within its RR full-mesh, i.e., to RR1 and RR2. 3. RR1 receives that path, reruns its decision process, and picks this new path as best. As a result, RR1 withdraws its previously announced best-path on the iBGP sessions of its RR full-mesh. 4. If, for any reason, RR3 processes the withdraw generated in step 3, before processing the update generated in step 2, RR3 transiently suffers from unreachability for the affected prefix. @@ -396,38 +396,38 @@ 9. Acknowledgments The authors wish to thank Olivier Bonaventure and Pradosh Mohapatra for their useful comments on this work. 10. References [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). + draft-ietf-idr-add-paths-09.txt (work in progress). [BestExternal] 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", 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-03. + draft-ietf-idr-reserved-extended-communities-06. [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 @@ -462,21 +462,21 @@ Pierre Francois Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 Leganese 28918 ES Email: pierre.francois@imdea.org Bruno Decraene - France Telecom + Orange 38-40 rue du General Leclerc 92794 Issy Moulineaux cedex 9 FR Email: bruno.decraene@orange.com Cristel Pelsser Internet Initiative Japan Jinbocho Mitsui Bldg. 1-105 Kanda Jinbo-cho