draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt   draft-ietf-grow-bgp-graceful-shutdown-requirements-03.txt 
skipping to change at page 1, line 15 skipping to change at page 1, line 15
Intended status: Informational P. Francois Intended status: Informational P. Francois
UCL UCL
C. Pelsser C. Pelsser
IIJ IIJ
Z. Ahmad Z. Ahmad
Orange Business Services Orange Business Services
A. J. Elizondo Armengol A. J. Elizondo Armengol
Telefonica I+D Telefonica I+D
T. Takeda T. Takeda
NTT NTT
April 30, 2010 June 11, 2010
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
draft-ietf-grow-bgp-graceful-shutdown-requirements-02.txt draft-ietf-grow-bgp-graceful-shutdown-requirements-03.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 51 skipping to change at page 1, line 51
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 27, 2010. This Internet-Draft will expire on December 08, 2010.
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 3, line 11 skipping to change at page 3, line 11
9.2. Informative References.....................................14 9.2. Informative References.....................................14
10. Acknowledgments............................................14 10. Acknowledgments............................................14
11. Author's Addresses.........................................15 11. Author's Addresses.........................................15
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
1. Conventions used in this document 1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
The BGP protocol is heavily used in Service Provider networks both The BGP protocol is heavily used in Service Provider networks both
for Internet and BGP/MPLS VPN services. For resiliency purposes, for Internet and BGP/MPLS VPN services. For resiliency purposes,
redundant routers and BGP sessions can be deployed to reduce the redundant routers and BGP sessions can be deployed to reduce the
consequences of an AS Border Router or BGP session breakdown on consequences of an AS Border Router or BGP session breakdown on
customers' or peers' traffic. customers' or peers' traffic.
We place ourselves in the context where a Service Provider performs a We place ourselves in the context where a Service Provider performs a
skipping to change at page 3, line 35 skipping to change at page 3, line 35
traffic loss during the BGP convergence. Indeed, as an alternate path traffic loss during the BGP convergence. Indeed, as an alternate path
is available in the Autonomous System (AS), it should be made is available in the Autonomous System (AS), it should be made
possible to reroute the customer or peer traffic on this backup path possible to reroute the customer or peer traffic on this backup path
before the BGP session(s) is/are torn down, the nominal path before the BGP session(s) is/are torn down, the nominal path
withdrawn and the forwarding is interrupted on the nominal path. withdrawn and the forwarding is interrupted on the nominal path.
The requirements also cover the subsequent re-establishment of the The requirements also cover the subsequent re-establishment of the
BGP session as even this "UP" case can currently trigger route loss BGP session as even this "UP" case can currently trigger route loss
and thus traffic loss at some routers. and thus traffic loss at some routers.
Currently, [BGP] and [MP-BGP] do not include any operation to Currently, BGP [BGP-4] and MP-BGP [MP-BGP] do not include any
gracefully withdraw a prefix while traffic toward that prefix could operation to gracefully withdraw a prefix while traffic toward that
still be correctly forwarded. When a BGP session is taken down, BGP prefix could still be correctly forwarded. When a BGP session is
behaves as if it was a sudden link or router failure and withdraws taken down, BGP behaves as if it was a sudden link or router failure
the prefixes learnt over that session, which may trigger traffic and withdraws the prefixes learnt over that session, which may
loss. There is no mechanism to advertise to its BGP peers that the trigger traffic loss. There is no mechanism to advertise to its BGP
prefix will soon be unreachable, while still being reachable. When peers that the prefix will soon be unreachable, while still being
applicable, such mechanism would reduce or prevent traffic loss. It reachable. When applicable, such mechanism would reduce or prevent
would typically be applicable in case of a maintenance operation traffic loss. It would typically be applicable in case of a
requiring the shutdown of a forwarding resource. Typical examples maintenance operation requiring the shutdown of a forwarding
would be a link or line card maintenance, replacement or upgrade. It resource. Typical examples would be a link or line card maintenance,
may also be applicable for a software upgrade as it may involve a replacement or upgrade. It may also be applicable for a software
firmware reset on the line cards and hence forwarding interruption. upgrade as it may involve a firmware reset on the line cards and
The introduction of Route Reflectors as per [BGP RR] to solve hence forwarding interruption.
scalability issues bound to iBGP full-meshes has worsened the The introduction of Route Reflectors as per [RR] to solve scalability
duration of routing convergence as some route reflectors may hide the issues bound to iBGP full-meshes has worsened the duration of routing
back up path. Thus depending on RR topology more iBGP hops may be convergence as some route reflectors may hide the back up path. Thus
involved in the iBGP convergence. depending on RR topology more iBGP hops may be involved in the iBGP
convergence.
Note that these planned maintenance operations cannot be addressed by
Graceful Restart extensions [BGP GR] as GR only applies when the
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
Note that these planned maintenance operations cannot be addressed by
Graceful Restart extensions [GR] as GR only applies when the
forwarding is preserved during the control plane restart. On the forwarding is preserved during the control plane restart. On the
contrary, Graceful Shutdown applies when the forwarding is contrary, Graceful Shutdown applies when the forwarding is
interrupted. interrupted.
Note also that some protocols are already considering such graceful Note also that some protocols are already considering such graceful
shutdown procedure (e.g. [GMPLS G-Shut]). shutdown procedure (e.g. GMPLS in [RFC5817]).
A successful approach of such mechanism should minimize the loss of A successful approach of such mechanism should minimize the loss of
traffic in most foreseen maintenance situations. traffic in most foreseen maintenance situations.
3. Problem statement 3. Problem statement
As per [BGP], when one (or many) BGP session(s) are shut down, a BGP As per [BGP-4], when one (or many) BGP session(s) are shut down, a
NOTIFICATION message is sent to the peer and the session is then BGP NOTIFICATION message is sent to the peer and the session is then
closed. A protocol convergence is then triggered both by the local closed. A protocol convergence is then triggered both by the local
router and by the peer. Alternate paths to the destination are router and by the peer. Alternate paths to the destination are
selected, if known. If those alternates paths are not known prior to selected, if known. If those alternates paths are not known prior to
the BGP session shutdown, additional BGP convergence steps are the BGP session shutdown, additional BGP convergence steps are
required in each AS to search for an alternate path. required in each AS to search for an alternate path.
This behavior is not satisfactory in a maintenance situation because This behavior is not satisfactory in a maintenance situation because
the traffic that was directed towards the removed next-hops may be the traffic that was directed towards the removed next-hops may be
lost until the end of the BGP convergence. As it is a planned lost until the end of the BGP convergence. As it is a planned
operation, a make before break solution should be made possible. operation, a make before break solution should be made possible.
skipping to change at page 7, line 30 skipping to change at page 7, line 30
Depending on the session type (eBGP, iBGP...), there may be some Depending on the session type (eBGP, iBGP...), there may be some
variations in the proposed solution in order to fit the requirements. variations in the proposed solution in order to fit the requirements.
The following cases should be handled in priority: The following cases should be handled in priority:
- The shutdown of an inter-AS link and therefore the shutdown of an - The shutdown of an inter-AS link and therefore the shutdown of an
eBGP session. eBGP session.
- The shutdown of an AS Border Router and therefore the shutdown of - The shutdown of an AS Border Router and therefore the shutdown of
all its BGP sessions all its BGP sessions
- The shutdown of a customer access router and all of its BGP - The shutdown of a customer access router and all of its BGP
sessions. In VPN as per [VPN], this router is called a CE and the use sessions. In BGP/MPLS VPN as per [VPN], this router is called a CE
of others protocols than BGP on the PE-CE access link should also be and the use of others protocols than BGP on the PE-CE access link
considered (static routes, RIPv2, OSPF, IS-IS...). should also be considered (static routes, RIPv2, OSPF, IS-IS...).
d) The proposed solution SHOULD NOT change the BGP convergence d) The proposed solution SHOULD NOT change the BGP convergence
behavior for the ASes exterior to the maintenance process. behavior for the ASes exterior to the maintenance process, namely
ASes other than the initiator AS and it(s) neighbor AS(es).
e) An incremental deployment on a per AS or per BGP session basis e) An incremental deployment on a per AS or per BGP session basis
SHOULD be made possible. In case of partial deployment the proposed SHOULD be made possible. In case of partial deployment the proposed
solution SHOULD incrementally improve the maintenance process. The solution SHOULD incrementally improve the maintenance process. The
solution SHOULD bring improvements even when one of the two ASes does solution SHOULD bring improvements even when one of the two ASes does
not support graceful shutdown. In particular, large Service Providers not support graceful shutdown. In particular, large Service Providers
may not be able to upgrade all of the deployed customer premises may not be able to upgrade all of the deployed customer premises
access routers (CPE). access routers (CPE).
f) Redistribution or advertisement of (static) IP routes into BGP f) Redistribution or advertisement of (static) IP routes into BGP
skipping to change at page 7, line 57 skipping to change at page 8, line 4
g) The proposed solution MAY be designed in order to avoid g) The proposed solution MAY be designed in order to avoid
transient forwarding loops. Indeed, forwarding loops increase packet transient forwarding loops. Indeed, forwarding loops increase packet
transit delay and may lead to link saturation. transit delay and may lead to link saturation.
h) The specific procedure SHOULD end when the BGP session is h) The specific procedure SHOULD end when the BGP session is
closed. The procedure SHOULD be reverted, either automatically or closed. The procedure SHOULD be reverted, either automatically or
manually, when the session is re-established. During this reversion manually, when the session is re-established. During this reversion
procedure -when the session is brought up- the procedure SHOULD also procedure -when the session is brought up- the procedure SHOULD also
minimize packet loss when the nominal path is installed and used minimize packet loss when the nominal path is installed and used
again. In particular, it SHOULD be ensured that the backup path is
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
again. In particular, it SHOULD be ensured that the backup path is
not removed from the routing tables of the effected nodes before it not removed from the routing tables of the effected nodes before it
learns the nominal path. In the end, once the planned maintenance is learns the nominal path. In the end, once the planned maintenance is
finished and the shutdown resource becomes available again, the finished and the shutdown resource becomes available again, the
nominal BGP routing MUST be reestablished. nominal BGP routing MUST be reestablished.
i) The solution SHOULD be simple and hence MAY only cover a subset i) The solution SHOULD be simple and simple to operate. Hence it
of the cases. MAY only cover a subset of the cases.
The metrics to evaluate and compare the proposed solutions are, in The metrics to evaluate and compare the proposed solutions are, in
decreasing order of importance: decreasing order of importance:
- The duration of the remaining loss of connectivity when the BGP - The duration of the remaining loss of connectivity when the BGP
session is brought down or up session is brought down or up
- The applicability to a wide range of BGP and network topologies, - The applicability to a wide range of BGP and network topologies,
especially those described in section 6; especially those described in section 6;
- The simplicity; - The simplicity;
- The duration of transient forwarding loops; - The duration of transient forwarding loops;
- The additional load introduced in BGP (eg BGP messages sent to peer - The additional load introduced in BGP (eg BGP messages sent to peer
skipping to change at page 14, line 11 skipping to change at page 14, line 11
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
9. References 9. References
9.1. Normative References 9.1. Normative References
[BGP] Y. Rekhter, T. Li, [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"A Border Gateway protocol 4 (BGP)", RFC 4271, January 2006. Requirement Levels", BCP 14, RFC 2119, March 1997.
[MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter [BGP-4] Y. Rekhter, T. Li, "A Border Gateway protocol 4 (BGP)", RFC
"Multiprotocol Extensions for BGP-4", RFC 4760 January 2007. 4271, January 2006.
[BGP RR] T. Bates, E. Chen, R. Chandra [MP-BGP] T. Bates, R. Chandra, D. Katz, Y. Rekhter, "Multiprotocol
Extensions for BGP-4", RFC 4760 January 2007.
[RR] T. Bates, E. Chen, R. Chandra
"BGP Route Reflection: An Alternative to Full Mesh Internal BGP "BGP Route Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456 April 2006. (IBGP)", RFC 4456 April 2006.
[BGP GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter
"Graceful Restart Mechanism for BGP", RFC 4724 January 2007.
[VPN] E. Rosen, Y. Rekhter [VPN] E. Rosen, Y. Rekhter
"BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364 "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364
February 2006. February 2006.
9.2. Informative References 9.2. Informative References
[GMPLS G-Shut] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton [RFC5817] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton
"Graceful Shutdown in MPLS and Generalized MPLS Traffic "Graceful Shutdown in MPLS and Generalized MPLS Traffic
Engineering Networks", RFC 5817 April 2010. Engineering Networks", RFC 5817 April 2010.
[GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter
"Graceful Restart Mechanism for BGP", RFC 4724 January 2007.
[Reliability] Network Strategy Partners, LLC. [Reliability] Network Strategy Partners, LLC.
"Reliable IP Nodes: A prerequisite to profitable IP services", "Reliable IP Nodes: A prerequisite to profitable IP services",
November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf
10. Acknowledgments 10. Acknowledgments
This draft is mostly an updated version of draft-dubois-bgp-pm- This draft is mostly an updated version of draft-dubois-bgp-pm-
reqs-02.txt. reqs-02.txt.
Authors would like to thank Nicolas Dubois, Benoit Fondeviole, Authors would like to thank Nicolas Dubois, Benoit Fondeviole,
 End of changes. 19 change blocks. 
44 lines changed or deleted 48 lines changed or added

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