draft-ietf-grow-bgp-gshut-03.txt   draft-ietf-grow-bgp-gshut-04.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: June 10, 2012 France Telecom Expires: April 25, 2013 France Telecom
Cristel Pelsser Cristel Pelsser
Internet Initiative Japan Internet Initiative Japan
Keyur Patel Keyur Patel
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
December 8, 2011 October 22, 2012
Graceful BGP session shutdown Graceful BGP session shutdown
draft-ietf-grow-bgp-gshut-03 draft-ietf-grow-bgp-gshut-04
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 June 10, 2012. This Internet-Draft will expire on April 25, 2013.
Copyright Notice 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. 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 3, line 28 skipping to change at page 3, line 28
6. Link Up cases . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Link Up cases . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Unreachability local to the ASBR . . . . . . . . . . . . . 8 6.1. Unreachability local to the ASBR . . . . . . . . . . . . . 8
6.2. iBGP convergence . . . . . . . . . . . . . . . . . . . . . 9 6.2. iBGP convergence . . . . . . . . . . . . . . . . . . . . . 9
7. IANA assigned g-shut BGP community . . . . . . . . . . . . . . 9 7. IANA assigned g-shut BGP community . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Appendix A. Alternative techniques with limited applicability . . 11 Appendix A. Alternative techniques with limited applicability . . 11
A.1. Multi Exit Discriminator tweaking . . . . . . . . . . . . 11 A.1. Multi Exit Discriminator tweaking . . . . . . . . . . . . 11
A.2. IGP distance Poisoning . . . . . . . . . . . . . . . . . . 11 A.2. IGP distance Poisoning . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction 1. Introduction
Routing changes in BGP can be caused by planned, maintenance Routing changes in BGP can be caused by planned, maintenance
operations. This document discusses operational procedures to be operations. This document discusses operational procedures to be
applied in order to reduce or eliminate losses of packets during the applied in order to reduce or eliminate losses of packets during the
maintenance. These losses come from the transient lack of maintenance. These losses come from the transient lack of
reachability during the BGP convergence following the shutdown of an reachability during the BGP convergence following the shutdown of an
eBGP peering session between two Autonomous System Border Routers eBGP peering session between two Autonomous System Border Routers
(ASBR). (ASBR).
skipping to change at page 6, line 12 skipping to change at page 6, line 12
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 to
perform a graceful shutdown procedure for eBGP peering links. perform a graceful shutdown procedure for 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 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, 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
On each ASBR supporting the g-shut procedure, an outbound BGP route On each ASBR supporting the g-shut procedure, an outbound BGP route
policy is applied on all iBGP sessions of the ASBR, that: policy is applied on all iBGP sessions of the ASBR, that:
o matches the g-shut community o matches the g-shut community
o sets the local-pref of the paths tagged with the g-shut o sets the LOCAL_PREF attribute of the paths tagged with the
community to a low value g-shut community to a low value
o removes the g-shut community from the paths. o removes the g-shut community from the paths.
o optionally, adds an AS specific g-shut community on these paths o optionally, adds an AS specific g-shut community on these paths
to indicate that these are to be withdrawn soon. If some to indicate that these are to be withdrawn soon. If some
ingress ASBRs reset the local preference attribute, this AS ingress ASBRs reset the LOCAL_PREF attribute, this AS specific
specific g-shut community will be used to override other local g-shut community will be used to override other LOCAL_PREF
preference changes. preference changes.
Note that in the case where an AS is aggregating multiple routes 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 under a covering prefix, it is recommended to filter out the g-shut
community from the resulting aggregate BGP route. By doing so, the community from the resulting aggregate BGP route. By doing so, the
setting of the g-shut community on one of the aggregated routes will setting of the g-shut community on one of the aggregated routes will
not let the entire aggregate inherit the community. Not doing so not let the entire aggregate inherit the community. Not doing so
would let the entire aggregate undergo the g-shut behavior. would let the entire aggregate undergo the g-shut behavior.
4.2.1.2. Operations at maintenance time 4.2.1.2. Operations at maintenance time
skipping to change at page 7, line 16 skipping to change at page 7, line 16
o perform a BGP session shutdown. o perform a BGP session shutdown.
4.2.1.3. BGP implementation support for G-Shut 4.2.1.3. BGP implementation support for G-Shut
A BGP router implementation MAY provide features aimed at automating A BGP router implementation MAY provide features aimed at automating
the application of the graceful shutdown procedures described above. the application of the graceful shutdown procedures described above.
Upon a session shutdown specified as graceful by the operator, a BGP Upon a session shutdown specified as graceful by the operator, a BGP
implementation supporting a g-shut feature SHOULD: implementation supporting a g-shut feature SHOULD:
1. Update all the paths propagated over the corresponding eBGP 1. On the eBGP side, update all the paths propagated over the
session, tagging the GSHUT community to them. Any subsequent corresponding eBGP session, tagging the GSHUT community to them.
update sent to the session being gracefully shut down would be Any subsequent update sent to the session being gracefully shut
tagged with the GSHUT community. down would be tagged with the GSHUT community.
2. Lower the local preference value of the paths received over the 2. On the iBGP side, lower the LOCAL_PREF value of the paths
eBGP session being shut down, upon their propagation over iBGP received over the eBGP session being shut down, upon their
sessions. Optionally, also tag these paths with an AS specific propagation over iBGP sessions. Optionally, also tag these
g-shut community. Note that alternatively, the local preference paths with an AS specific g-shut community. Note that
of the paths received over the eBGP session can be lowered on alternatively, the LOCAL_PREF of the paths received over the
the g-shut initiator itself, instead of only when propagating eBGP session can be lowered on the g-shut initiator itself,
over its iBGP sessions. instead of only when propagating over its iBGP sessions.
3. Optionally shut down the session after a configured time. 3. Optionally shut down the session after a configured time.
4. Prevent the GSHUT community from being inherited by a path that 4. Prevent the GSHUT community from being inherited by a path that
would aggregate some paths tagged with the GSHUT community. would aggregate some paths tagged with the GSHUT community.
This behavior avoids the GSHUT procedure to be applied to the This behavior avoids the GSHUT procedure to be applied to the
aggregate upon the graceful shutdown of one of its covered aggregate upon the graceful shutdown of one of its covered
prefixes. prefixes.
A BGP implementation supporting a g-shut feature SHOULD also A BGP implementation supporting a g-shut feature SHOULD also
automatically install the BGP policies that are supposed to be automatically install the BGP policies that are supposed to be
configured, as decribed in Section 4.2.1.1 for sessions over which configured, as decribed in Section 4.2.1.1 for sessions over which
skipping to change at page 7, line 50 skipping to change at page 7, line 50
If the iBGP topology is viable after the maintenance of the session, 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 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 all prefixes advertised on this g-shut iBGP session, then the
shutdown of an iBGP session does not lead to transient shutdown of an iBGP session does not lead to transient
unreachability. unreachability.
4.2.3. Router g-shut 4.2.3. Router g-shut
In the case of a shutdown of a router, a reconfiguration of the 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 outbound BGP route policies of the g-shut initiator SHOULD be
to set a low local-pref value for the paths originated by the g-shut performed to set a low LOCAL_PREF value for the paths originated by
initiator (e.g, BGP aggregates redistributed from other protocols, the g-shut initiator (e.g, BGP aggregates redistributed from other
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 runned independently on each router of the
skipping to change at page 10, line 11 skipping to change at page 10, line 11
For Internet routes, a non transitive extended community will be For Internet routes, a non transitive extended community will be
reserved from the pool defined in [EXT_POOL]. Using such a community reserved from the pool defined in [EXT_POOL]. Using such a community
type allows for not leaking graceful signaling out of the AS type allows for not leaking graceful signaling out of the AS
boundaries, without the need to explicitly configure filters to strip boundaries, without the need to explicitly configure filters to strip
the community off upon path propagation. the community off upon path propagation.
8. Security Considerations 8. Security Considerations
By providing the g-shut service to a neighboring AS, an ISP provides 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. paths received from this neighbor.
The neighbor could abuse the technique and do inbound traffic The neighbor could abuse the technique and do inbound traffic
engineering by declaring some prefixes as undergoing a maintenance so engineering by declaring some prefixes as undergoing a maintenance so
as to switch traffic to another peering link. as to switch traffic to another peering link.
If this behavior is not tolerated by the ISP, it SHOULD monitor the If this behavior is not tolerated by the ISP, it SHOULD monitor the
use of the g-shut community by this neighbor. use of the g-shut community by this neighbor.
ASes using the regular (transitive) g-shut community SHOULD remove ASes using the regular (transitive) g-shut community SHOULD remove
skipping to change at page 10, line 36 skipping to change at page 10, line 36
transitive extended community do not need to do this as the community transitive extended community do not need to do this as the community
is non transitive and hence cannot be used by remote ASes. is non transitive and hence cannot be used by remote ASes.
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, A. Retana, and E. Chen, "Advertisement of [AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder,
Multiple Paths in BGP", draft-walton-bgp-add-paths-06.txt "Advertisement of Multiple Paths in BGP",
(work in progress). draft-ietf-idr-add-paths-07.txt (work in progress).
[BestExternal] [BestExternal]
Marques, P., Fernando, R., Chen, E., and P. Mohapatra, Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H.
"Advertisement of the best-external route to IBGP", Gredler, "Advertisement of the best-external route to
draft-ietf-idr-best-external-00.txt, May 2009. 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", graceful shutdown of BGP sessions", RFC 6198.
draft-ietf-grow-bgp-graceful-shutdown-requirements-
06.txt, October 2010.
[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-01, draft-ietf-idr-reserved-extended-communities-03.
May 2011.
[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 18 skipping to change at page 12, line 18
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 France Telecom
38-40 rue du General Leclerc 38-40 rue du General Leclerc
92794 Issi 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
Tokyo 101-0051 Tokyo 101-0051
JP JP
Email: pelsser.cristel@iij.ad.jp Email: cristel@iij.ad.jp
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 West Tasman Dr 170 West Tasman Dr
San Jose, CA 95134 San Jose, CA 95134
US US
Email: keyupate@cisco.com Email: keyupate@cisco.com
Clarence Filsfils Clarence Filsfils
 End of changes. 18 change blocks. 
41 lines changed or deleted 37 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/