draft-ietf-grow-bgp-gshut-04.txt   draft-ietf-grow-bgp-gshut-05.txt 
Network Working Group Pierre Francois Network Working Group Pierre Francois
Internet-Draft Institute IMDEA Networks Internet-Draft Institute IMDEA Networks
Intended status: Informational Bruno Decraene Intended status: Informational Bruno Decraene
Expires: April 25, 2013 France Telecom Expires: August 1, 2014 Orange
Cristel Pelsser Cristel Pelsser
Internet Initiative Japan Internet Initiative Japan
Keyur Patel Keyur Patel
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
October 22, 2012 January 28, 2014
Graceful BGP session shutdown Graceful BGP session shutdown
draft-ietf-grow-bgp-gshut-04 draft-ietf-grow-bgp-gshut-05
Abstract Abstract
This draft describes operational procedures aimed at reducing the This draft describes operational procedures aimed at reducing the
amount of traffic lost during planned maintenances of routers or amount of traffic lost during planned maintenances of routers or
links, involving the shutdown of BGP peering sessions. links, involving the shutdown of BGP peering sessions.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 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. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 6, line 8 skipping to change at page 6, line 8
Note that the LoC for the inbound traffic of the maintained router, Note that the LoC for the inbound traffic of the maintained router,
induced by a lack of alternate path propagation within the iBGP induced by a lack of alternate path propagation within the iBGP
topology of a neighboring AS is not under the control of the operator topology of a neighboring AS is not under the control of the operator
performing the maintenance. The part of the procedure aimed at performing the maintenance. The part of the procedure aimed at
avoiding LoC for incoming paths can thus be applied even if no LoC avoiding LoC for incoming paths can thus be applied even if no LoC
are expected for the outgoing paths. are expected for the outgoing paths.
4.2. Make before break convergence: g-shut 4.2. Make before break convergence: g-shut
This section describes configurations and actions to be performed to This section describes configurations and actions to be performed for
perform a graceful shutdown procedure for eBGP peering links. the graceful shutdown of eBGP peering links.
The goal of this procedure is to let the paths being shutdown The goal of this procedure is to let the paths being shutdown
visible, but with a lower LOCAL_PREF value, while alternate paths visible, but with a lower LOCAL_PREF value, while alternate paths
spread through the iBGP topology. Instead of withdrawing the path, spread through the iBGP topology. Instead of withdrawing the path,
routers of an AS will keep on using it until they become aware of routers of an AS will keep on using it until they become aware of
alternate paths. alternate paths.
4.2.1. eBGP g-shut 4.2.1. eBGP g-shut
4.2.1.1. Pre-configuration 4.2.1.1. Pre-configuration
skipping to change at page 8, line 14 skipping to change at page 8, line 14
protocols, including static routes). protocols, including static routes).
This behavior is equivalent to the recommended behavior for paths This behavior is equivalent to the recommended behavior for paths
"redistributed" from eBGP sessions to iBGP sessions in the case of "redistributed" from eBGP sessions to iBGP sessions in the case of
the shutdown of an ASBR. the shutdown of an ASBR.
5. Forwarding modes and transient forwarding loops during convergence 5. Forwarding modes and transient forwarding loops during convergence
The g-shut procedure or the solutions improving the availability of The g-shut procedure or the solutions improving the availability of
alternate paths, do not change the fact that BGP convergence and the 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 ASes. If the AS applying the solution does not rely on encapsulation
to forward packets from the Ingress Border Router to the Egress to forward packets from the Ingress Border Router to the Egress
Border Router, then transient forwarding loops and consequent packet Border Router, then transient forwarding loops and consequent packet
losses can occur during the convergence process. If zero LoC is losses can occur during the convergence process. If zero LoC is
required, encapsulation is required between ASBRs of the AS. required, encapsulation is required between ASBRs of the AS.
6. Link Up cases 6. Link Up cases
We identify two potential causes for transient packet losses upon an 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 eBGP link up event. The first one is local to the g-no-shut
skipping to change at page 9, line 19 skipping to change at page 9, line 19
A typical example for such transient unreachability for a given A typical example for such transient unreachability for a given
prefix is the following: prefix is the following:
Let's consider 3 route reflectors RR1, RR2, RR3. There is a full Let's consider 3 route reflectors RR1, RR2, RR3. There is a full
mesh of iBGP session between them. mesh of iBGP session between them.
1. RR1 is initially advertising the current best path to the 1. RR1 is initially advertising the current best path to the
members of its iBGP RR full-mesh. It propagated that path members of its iBGP RR full-mesh. It propagated that path
within its RR full-mesh. RR2 knows only that path towards the within its RR full-mesh. RR2 knows only that path towards the
prefix. 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, 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 propagates an UPDATE within its RR full-mesh, i.e., to RR1
and RR2. and RR2.
3. RR1 receives that path, reruns its decision process, and 3. RR1 receives that path, reruns its decision process, and
picks this new path as best. As a result, RR1 withdraws its picks this new path as best. As a result, RR1 withdraws its
previously announced best-path on the iBGP sessions of its RR previously announced best-path on the iBGP sessions of its RR
full-mesh. full-mesh.
4. If, for any reason, RR3 processes the withdraw generated in 4. If, for any reason, RR3 processes the withdraw generated in
step 3, before processing the update generated in step 2, RR3 step 3, before processing the update generated in step 2, RR3
transiently suffers from unreachability for the affected prefix. transiently suffers from unreachability for the affected prefix.
skipping to change at page 10, line 38 skipping to change at page 10, line 38
9. Acknowledgments 9. Acknowledgments
The authors wish to thank Olivier Bonaventure and Pradosh Mohapatra The authors wish to thank Olivier Bonaventure and Pradosh Mohapatra
for their useful comments on this work. for their useful comments on this work.
10. References 10. References
[AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder, [AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder,
"Advertisement of Multiple Paths in BGP", "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] [BestExternal]
Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H.
Gredler, "Advertisement of the best-external route to Gredler, "Advertisement of the best-external route to
IBGP", draft-ietf-idr-best-external-05.txt. IBGP", draft-ietf-idr-best-external-05.txt.
[REQS] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., [REQS] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z.,
Armengol, A., and T. Takeda, "Requirements for the Armengol, A., and T. Takeda, "Requirements for the
graceful shutdown of BGP sessions", RFC 6198. graceful shutdown of BGP sessions", RFC 6198.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended [RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, February 2006. Communities Attribute", RFC 4360, February 2006.
[EXT_POOL] [EXT_POOL]
Decraene, B. and P. Francois, "Assigned BGP extended Decraene, B. and P. Francois, "Assigned BGP extended
communities", communities",
draft-ietf-idr-reserved-extended-communities-03. draft-ietf-idr-reserved-extended-communities-06.
[BGPWKC] "http://www.iana.org/assignments/ [BGPWKC] "http://www.iana.org/assignments/
bgp-well-known-communities". bgp-well-known-communities".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
Appendix A. Alternative techniques with limited applicability Appendix A. Alternative techniques with limited applicability
A few alternative techniques have been considered to provide g-shut A few alternative techniques have been considered to provide g-shut
skipping to change at page 12, line 16 skipping to change at page 12, line 16
Pierre Francois Pierre Francois
Institute IMDEA Networks Institute IMDEA Networks
Avda. del Mar Mediterraneo, 22 Avda. del Mar Mediterraneo, 22
Leganese 28918 Leganese 28918
ES ES
Email: pierre.francois@imdea.org Email: pierre.francois@imdea.org
Bruno Decraene Bruno Decraene
France Telecom Orange
38-40 rue du General Leclerc 38-40 rue du General Leclerc
92794 Issy Moulineaux cedex 9 92794 Issy Moulineaux cedex 9
FR FR
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Cristel Pelsser Cristel Pelsser
Internet Initiative Japan Internet Initiative Japan
Jinbocho Mitsui Bldg. Jinbocho Mitsui Bldg.
1-105 Kanda Jinbo-cho 1-105 Kanda Jinbo-cho
 End of changes. 11 change blocks. 
12 lines changed or deleted 12 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/