draft-ietf-grow-bgp-graceful-shutdown-requirements-01.txt   draft-ietf-grow-bgp-graceful-shutdown-requirements-02.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
October 23, 2009 April 30, 2010
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
draft-ietf-grow-bgp-graceful-shutdown-requirements-01.txt draft-ietf-grow-bgp-graceful-shutdown-requirements-02.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 April 22, 2010. This Internet-Draft will expire on October 27, 2010.
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. 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
described in the Simplified BSD License.
Abstract Abstract
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. However simply taking down or even up a customers' or peers' traffic. However simply taking down or even
BGP session for maintenance purposes may still induce connectivity bringing up a BGP session for maintenance purposes may still induce
losses during the BGP convergence. This is no more satisfactory for connectivity losses during the BGP convergence. This is no more
new applications (e.g. voice over IP, on line gaming, VPN). satisfactory for new applications (e.g. voice over IP, on line
Therefore, a solution is required for the graceful shutdown of a (set gaming, VPN). Therefore, a solution is required for the graceful
of) BGP session(s) in order to limit the amount of traffic loss shutdown of a (set of) BGP session(s) in order to limit the amount of
during a planned shutdown. This document expresses requirements for traffic loss during a planned shutdown. This document expresses
such a solution. requirements for such a solution.
Table of Contents Table of Contents
1. Conventions used in this document...........................3 1. Conventions used in this document...........................3
2. Introduction................................................3 2. Introduction................................................3
3. Problem statement...........................................3 3. Problem statement...........................................4
3.1. Example of undesirable BGP routing behavior.................4 3.1. Example of undesirable BGP routing behavior.................4
3.2. Causes of packet loss.......................................5 3.2. Causes of packet loss.......................................5
4. Terminology.................................................5 4. Terminology.................................................6
5. Goals and requirements......................................6 5. Goals and requirements......................................6
6. Reference Topologies........................................7 6. Reference Topologies........................................8
6.1. E-BGP topologies............................................8 6.1. E-BGP topologies............................................8
6.2. I-BGP topologies............................................9 6.2. I-BGP topologies...........................................10
7. Security Considerations....................................12 7. Security Considerations....................................13
8. IANA Considerations........................................12 8. IANA Considerations........................................13
9. References.................................................13 9. References.................................................14
9.1. Normative References.......................................13 9.1. Normative References.......................................14
9.2. Informative References.....................................13 9.2. Informative References.....................................14
10. Acknowledgments............................................13 10. Acknowledgments............................................14
11. Author's Addresses.........................................14 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.
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 needs to We place ourselves in the context where a Service Provider performs a
shut down one or multiple BGP peering link(s) or a whole ASBR. If an maintenance operation and needs to shut down one or multiple BGP
alternate path is available, the requirement is to avoid or reduce peering link(s) or a whole ASBR. If an alternate path is available
customer or peer traffic loss during the BGP convergence. Indeed, as within the AS, the requirement is to avoid or reduce customer or peer
an alternate path is available in the Autonomous System (AS), it traffic loss during the BGP convergence. Indeed, as an alternate path
should be made possible to reroute the customer or peer traffic on is available in the Autonomous System (AS), it should be made
the backup path before the BGP session(s) is/are torn down and the possible to reroute the customer or peer traffic on this backup path
forwarding is interrupted on 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.
The requirements also covers 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, the [BGP] and [MP-BGP] do not include any operation to Currently, [BGP] and [MP-BGP] do not include any operation to
reduce or prevent traffic loss in case of planned maintenance gracefully withdraw a prefix while traffic toward that prefix could
requiring the shutdown of a forwarding resource. When a BGP session still be correctly forwarded. When a BGP session is taken down, BGP
is taken down, BGP behaves as if it was a sudden link or router behaves as if it was a sudden link or router failure and withdraws
failure. Besides, the introduction of Route Reflectors as per [BGP the prefixes learnt over that session, which may trigger traffic
RR] to solve scalability issues bound to iBGP full-meshes has loss. There is no mechanism to advertise to its BGP peers that the
worsened the duration of routing convergence: some route reflectors prefix will soon be unreachable, while still being reachable. When
may hide the back up path and depending on RR topology more iBGP hops applicable, such mechanism would reduce or prevent traffic loss. It
may be involved in the iBGP convergence. On the other hand, some would typically be applicable in case of a maintenance operation
protocols are already considering such graceful shutdown procedure requiring the shutdown of a forwarding resource. Typical examples
(e.g. [GMPLS G-Shut]). would be a link or line card maintenance, replacement or upgrade. It
may also be applicable for a software upgrade as it may involve a
firmware reset on the line cards and hence forwarding interruption.
The introduction of Route Reflectors as per [BGP RR] to solve
scalability issues bound to iBGP full-meshes has worsened the
duration of routing convergence as some route reflectors may hide the
back up path. Thus depending on RR topology more iBGP hops may be
involved in the iBGP convergence.
Note that these planned maintenance operations cannot be addressed by Note that these planned maintenance operations cannot be addressed by
Graceful Restart extensions [BGP GR] as GR only applies when the Graceful Restart extensions [BGP GR] as GR only applies when the
Requirements for the graceful shutdown of BGP sessions
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
shutdown procedure (e.g. [GMPLS G-Shut]).
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 to As per [BGP], when one (or many) BGP session(s) are shut down, a BGP
perform a link or router maintenance operation, a BGP NOTIFICATION NOTIFICATION message is sent to the peer and the session is then
closed. A protocol convergence is then triggered both by the local
Requirements for the graceful shutdown of BGP sessions router and by the peer. Alternate paths to the destination are
selected, if known. If those alternates paths are not known prior to
message is sent to the peer and the session is then closed. A the BGP session shutdown, additional BGP convergence steps are
protocol convergence is then triggered both by the local router and required in each AS to search for an alternate path.
by the peer. Alternate paths to the destination are selected, if
known. If those alternates paths are not known prior to the BGP
session shutdown, additional BGP convergence steps are 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.
As maintenance operations are frequent in large networks As maintenance operations are frequent in large networks
[Reliability], the global availability of the network is [Reliability], the global availability of the network is
significantly impaired by this BGP maintenance issue. significantly impaired by this BGP maintenance issue.
3.1. Example of undesirable BGP routing behavior 3.1. Example of undesirable BGP routing behavior
To illustrate these problems, let us consider the following example To illustrate these problems, let us consider the following example
where one customer router "CUST" is dual-attached to two SP routers where one customer router "CUST" is dual-attached to two SP routers
"ASBR1" and "ASBR2". "ASBR1" and "ASBR2".
ASBR1 and ASBR2 are in the same AS and owned by the same service ASBR1 and ASBR2 are in the same AS and owned by the same service
provider. Both are iBGP client of the route reflector R1. provider. Both are iBGP client of the route reflector R1.
Requirements for the graceful shutdown of BGP sessions
' '
AS1 ' AS2 AS1 ' AS2
' '
/-----------ASBR1--- /-----------ASBR1---
/ \ / \
/ \ / \
CUST R1 CUST R1
\ / \ /
Z/z \ / Z/z \ /
skipping to change at page 5, line 4 skipping to change at page 5, line 33
Before the maintenance, packets for destination Z/z use the CUST- Before the maintenance, packets for destination Z/z use the CUST-
ASBR1 link because R1 selects ASBR1's route based on the IGP cost. ASBR1 link because R1 selects ASBR1's route based on the IGP cost.
Let's assume the service provider wants to shutdown the ASBR1-CUST Let's assume the service provider wants to shutdown the ASBR1-CUST
link for maintenance purposes. Currently, when the shutdown is link for maintenance purposes. Currently, when the shutdown is
performed on ASBR1, the following steps are performed: performed on ASBR1, the following steps are performed:
1. ASBR1 sends a withdraw to its route reflector R1 for the prefix 1. ASBR1 sends a withdraw to its route reflector R1 for the prefix
Z/z. Z/z.
2. R1 runs its decision process, selects the route from ASBR2 and 2. R1 runs its decision process, selects the route from ASBR2 and
advertises the new path to ASBR1. advertises the new path to ASBR1.
Requirements for the graceful shutdown of BGP sessions
3. ASBR1 runs its decision process and recovers the reachability of 3. ASBR1 runs its decision process and recovers the reachability of
Z/z. Z/z.
Traffic is lost between step 1 when ASBR1 looses its route and step 3 Traffic is lost between step 1 when ASBR1 looses its route and step 3
when it discovers a new path. when it discovers a new path.
Note that this is a simplified description for illustrative purpose. Note that this is a simplified description for illustrative purpose.
In a bigger AS, multiple steps of BGP convergence may be required to In a bigger AS, multiple steps of BGP convergence may be required to
find and select the best alternate path (e.g. ASBR1 is chosen based find and select the best alternate path (e.g. ASBR1 is chosen based
on a higher local pref, hierarchical route reflectors are used...). on a higher local pref, hierarchical route reflectors are used...).
skipping to change at page 5, line 31 skipping to change at page 6, line 4
3.2. Causes of packet loss 3.2. Causes of packet loss
The loss of packets during the maintenance has two main causes: The loss of packets during the maintenance has two main causes:
- lack of an alternate path on some routers - lack of an alternate path on some routers
- transient routing inconsistency. - transient routing inconsistency.
Some routers may lack an alternate path because another router is Some routers may lack an alternate path because another router is
hiding the backup path. This router can be a route reflector only hiding the backup path. This router can be a route reflector only
propagating the best path. Or the backup ASBR does not advertise the propagating the best path. Or the backup ASBR does not advertise the
backup path because it prefers the nominal path. This lack of backup path because it prefers the nominal path. This lack of
Requirements for the graceful shutdown of BGP sessions
knowledge of the alternate path is the first target of this knowledge of the alternate path is the first target of this
requirement draft. requirement draft.
Transient routing inconsistencies happen during iBGP convergence Transient routing inconsistencies happen during iBGP convergence
because all routers are not updating their RIB at the same time. This because all routers are not updating their RIB at the same time. This
can lead to forwarding loops and then packet drops. This can be can lead to forwarding loops and then packet drops. This can be
avoided by performing only one IP lookup on BGP routes in each AS and avoided by performing only one IP lookup on BGP routes in each AS and
by using tunnels (e.g. MPLS LSP) to send packets between ASBRs. by using tunnels (e.g. MPLS LSP) to send packets between ASBRs.
4. Terminology 4. Terminology
skipping to change at page 6, line 5 skipping to change at page 6, line 33
Affected prefixes: a prefix initially reached via the peering Affected prefixes: a prefix initially reached via the peering
link(s) undergoing maintenance. link(s) undergoing maintenance.
Affected router: a router reaching an affected prefix via a Affected router: a router reaching an affected prefix via a
peering link undergoing maintenance. peering link undergoing maintenance.
Initiator AS: the autonomous system of the g-shut initiator Initiator AS: the autonomous system of the g-shut initiator
router. router.
Requirements for the graceful shutdown of BGP sessions
Neighbor AS(es): the autonomous system(s) of the g-shut neighbor Neighbor AS(es): the autonomous system(s) of the g-shut neighbor
router(s). router(s).
5. Goals and requirements 5. Goals and requirements
When a BGP session of the router under maintenance is shut down, the When a BGP session of the router under maintenance is shut down, the
router removes the routes and then triggers the BGP convergence on router removes the routes and then triggers the BGP convergence on
its BGP peers. The goal of BGP graceful shutdown is to initiate the its BGP peers. The goal of BGP graceful shutdown is to initiate the
BGP convergence to find the alternate paths before the nominal paths BGP convergence to find the alternate paths before the nominal paths
are removed. As a result, before the nominal BGP session is shut are removed. As a result, before the nominal BGP session is shut
skipping to change at page 6, line 32 skipping to change at page 7, line 4
packets (possibly none) are lost during the BGP convergence process packets (possibly none) are lost during the BGP convergence process
since at any time, all routers have a valid path. since at any time, all routers have a valid path.
Another goal is to minimize packet loss when the BGP session is re- Another goal is to minimize packet loss when the BGP session is re-
established following the maintenance. established following the maintenance.
From the above goals we can derive the following requirements: From the above goals we can derive the following requirements:
a) A mechanism to advertise the maintenance action to all affected a) A mechanism to advertise the maintenance action to all affected
routers is REQUIRED. Such mechanism may be either implicit or routers is REQUIRED. Such mechanism may be either implicit or
Requirements for the graceful shutdown of BGP sessions
explicit. Note that affected routers can be located both in the local explicit. Note that affected routers can be located both in the local
AS and in neighboring ASes. AS and in neighboring ASes.
b) An Internet wide convergence is OPTIONAL. However if the b) An Internet wide convergence is OPTIONAL. However if the
initiator AS and the neighbor AS(es) have a backup path, they MUST be initiator AS and the neighbor AS(es) have a backup path, they MUST be
able to gracefully converge before the nominal path is shut down. able to gracefully converge before the nominal path is shut down.
c) The proposed solution SHOULD be applicable to any kind of BGP c) The proposed solution SHOULD be applicable to any kind of BGP
sessions (e-BGP, i-BGP, i-BGP route reflector client, e-BGP sessions (e-BGP, i-BGP, i-BGP route reflector client, e-BGP
confederations, e-BGP multi hop, MultiProtocol BGP extension...) and confederations, e-BGP multi hop, MultiProtocol BGP extension...) and
skipping to change at page 7, line 5 skipping to change at page 7, line 34
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 VPN as per [VPN], this router is called a CE and the use
of others protocols than BGP on the PE-CE access link should also be of others protocols than BGP on the PE-CE access link should also be
considered (static routes, RIPv2, OSPF, IS-IS...). considered (static routes, RIPv2, OSPF, IS-IS...).
Requirements for the graceful shutdown of BGP sessions
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. An behavior for the ASes exterior to the maintenance process.
incremental deployment on a per AS or per BGP session basis SHOULD be
made possible. In case of partial deployment the proposed solution
SHOULD incrementally improve the maintenance process. The solution
SHOULD bring improvements even when one of the two ASes does not
support graceful shutdown. In particular, large Service Providers may
not be able to upgrade all of the deployed customer premises access
routers (CPE).
e) Redistribution or advertisement of (static) IP routes into BGP e) An incremental deployment on a per AS or per BGP session basis
SHOULD be made possible. In case of partial deployment the proposed
solution SHOULD incrementally improve the maintenance process. The
solution SHOULD bring improvements even when one of the two ASes does
not support graceful shutdown. In particular, large Service Providers
may not be able to upgrade all of the deployed customer premises
access routers (CPE).
f) Redistribution or advertisement of (static) IP routes into BGP
SHOULD also be covered. SHOULD also be covered.
f) 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.
g) 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 again. In particular, it SHOULD be ensured that the backup path is
Requirements for the graceful shutdown of BGP sessions
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
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 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
routers, peer ASes, the Internet). routers, peer ASes, the Internet).
6. Reference Topologies 6. Reference Topologies
In order to benchmark the proposed solutions, some typical BGP In order to benchmark the proposed solutions, some typical BGP
topologies are detailed in this section. The solution drafts topologies are detailed in this section. The solution drafts
should state its applicability for each of these possible should state its applicability for each of these possible
topologies. topologies.
However, solutions SHOULD be applicable to all possible BGP However, solutions SHOULD be applicable to all possible BGP
topologies and not only to these below examples. topologies and not only to these below examples. Note that this
is a "SHOULD" rather than a "MUST" as a partial lightweight
Requirements for the graceful shutdown of BGP sessions solution may be preferred to a full but more complex solution.
Especially since some ISP may not be concerned by some topologies
(e.g. confederations).
6.1. E-BGP topologies 6.1. E-BGP topologies
We describe here some frequent eBGP topologies that SHOULD be
supported by the solution.
6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2 6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2
In this topology we have an asymmetric protection scheme between In this topology we have an asymmetric protection scheme between
AS1 and AS2: AS1 and AS2:
- On AS2 side, two different routers are used to connect to AS1. - On AS2 side, two different routers are used to connect to AS1.
- On AS1 side, one single router with two BGP sessions is used. - On AS1 side, one single router with two BGP sessions is used.
Requirements for the graceful shutdown of BGP sessions
' '
AS1 ' AS2 AS1 ' AS2
' '
/----------- ASBR2.1 /----------- ASBR2.1
/ ' / '
/ ' / '
ASBR1.1 ' ASBR1.1 '
\ ' \ '
\ ' \ '
\----------- ASBR2.2 \----------- ASBR2.2
skipping to change at page 9, line 5 skipping to change at page 9, line 50
' '
' '
' '
' '
' '
ASBR1.2----------- ASBR2.2 ASBR1.2----------- ASBR2.2
' '
AS1 ' AS2 AS1 ' AS2
' '
Requirements for the graceful shutdown of BGP sessions
The requirements of section 5 should be applicable to: The requirements of section 5 should be applicable to:
- Maintenance of any of the ASBR routers (in AS1 or AS2); - Maintenance of any of the ASBR routers (in AS1 or AS2);
- Maintenance of one link between AS1 and AS2 performed either on - Maintenance of one link between AS1 and AS2 performed either on
an AS1 or AS2 router. an AS1 or AS2 router.
Requirements for the graceful shutdown of BGP sessions
6.1.3. 2 ASBRs in AS2 each connected to two different ASes 6.1.3. 2 ASBRs in AS2 each connected to two different ASes
In this topology at least three ASes are involved. Depending on In this topology at least three ASes are involved. Depending on
which routes are exchanged between these ASes, some protection which routes are exchanged between these ASes, some protection
for some of the traffic may be possible. for some of the traffic may be possible.
' '
AS1 ' AS2 AS1 ' AS2
' '
ASBR1.1----------- ASBR2.1 ASBR1.1----------- ASBR2.1
skipping to change at page 9, line 42 skipping to change at page 10, line 37
the two previous topologies because we do not require propagating the two previous topologies because we do not require propagating
the maintenance advertisement outside of the two ASes involved in the maintenance advertisement outside of the two ASes involved in
an eBGP session. an eBGP session.
For instance if ASBR2.2 requires a maintenance affecting ASBR3.1, For instance if ASBR2.2 requires a maintenance affecting ASBR3.1,
then ASBR3.1 will be notified. However we do not require for ASBR1.1 then ASBR3.1 will be notified. However we do not require for ASBR1.1
to be notified of the maintenance of the eBGP session between to be notified of the maintenance of the eBGP session between
ASBR3.1-ASBR2.2. ASBR3.1-ASBR2.2.
6.2. I-BGP topologies 6.2. I-BGP topologies
We describe here some frequent i-BGP topologies that SHOULD be We describe here some frequent iBGP topologies that SHOULD be
supported. supported by the solution.
Indeed maintenance of an e-BGP session needs to be propagated
within the AS so the solution may depend on the specific i-BGP
topology.
Requirements for the graceful shutdown of BGP sessions
6.2.1. iBGP Full-Mesh 6.2.1. iBGP Full-Mesh
In this topology we have a full mesh of iBGP sessions: In this topology we have a full mesh of iBGP sessions:
P1 ------ P2 P1 ------ P2
| \ / | | \ / |
| \ / | | \ / |
| \ / | AS1 | \ / | AS1
| / \ | | / \ |
| / \ | | / \ |
ASBR1.1---ASBR1.2 ASBR1.1---ASBR1.2
\ / \ /
\ / \ /
''''''\''''/'''''''''''' ''''''\''''/''''''''''''
\ / AS2 \ / AS2
ASBR2.1 ASBR2.1
Requirements for the graceful shutdown of BGP sessions
When the session between ASBR1.1 and ASBR2.1 undergoes When the session between ASBR1.1 and ASBR2.1 undergoes
maintenance, it is required that all i-BGP peers of ASBR1.1 maintenance, it is required that all i-BGP peers of ASBR1.1
reroute traffic to ASBR1.2 before the session between ASBR1.1 and reroute traffic to ASBR1.2 before the session between ASBR1.1 and
ASBR2.1 is shut down. ASBR2.1 is shut down.
6.2.2. Route Reflector 6.2.2. Route Reflector
In this topology, route reflectors are used to limit the number of In this topology, route reflectors are used to limit the number of
i-BGP sessions. i-BGP sessions.
skipping to change at page 11, line 5 skipping to change at page 11, line 38
''''''\''''''/'''''''''''' ''''''\''''''/''''''''''''
\ / \ /
\ / AS2 \ / AS2
ASBR2.1 ASBR2.1
When the session between ASBR1.1 and ASBR2.1 undergoes When the session between ASBR1.1 and ASBR2.1 undergoes
maintenance, it is required that all BGP routers of AS1 reroute maintenance, it is required that all BGP routers of AS1 reroute
traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1
is shut down. is shut down.
Requirements for the graceful shutdown of BGP sessions
6.2.3. hierarchical Route Reflector 6.2.3. hierarchical Route Reflector
In this topology, hierarchical route reflectors are used to limit In this topology, hierarchical route reflectors are used to limit
the number of i-BGP sessions. the number of i-BGP sessions.
Requirements for the graceful shutdown of BGP sessions
P1/hRR -------- P2/hRR P1/hRR -------- P2/hRR
| | | |
| | | |
| | AS1 | | AS1
| | | |
| | | |
P3/RR P4/RR P3/RR P4/RR
| | | |
| | | |
skipping to change at page 12, line 47 skipping to change at page 13, line 47
When the session between ASBR1A.1 and ASBR2.1 undergoes When the session between ASBR1A.1 and ASBR2.1 undergoes
maintenance, it is required that all BGP routers of AS1 reroute maintenance, it is required that all BGP routers of AS1 reroute
traffic to ASBR1B.1 before the session between ASBR1A.1 and traffic to ASBR1B.1 before the session between ASBR1A.1 and
ASBR2.1 is shut down. ASBR2.1 is shut down.
7. Security Considerations 7. Security Considerations
Security considerations MUST be addressed by the proposed Security considerations MUST be addressed by the proposed
solutions. solutions.
One AS SHOULD NOT be able to use the graceful shutdown procedure The solution SHOULD NOT increase the ability for one AS to
to selectively influence routing decision in the peer AS (inbound selectively influence routing decision in the peer AS (inbound
TE) outside the case of the planned maintenance. In the case the TE) outside the case of the BGP session shutdown. Otherwise, the
proposed solution allows this, the peer AS SHOULD have means to peer AS SHOULD have means to detect such behavior.
detect such behavior.
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
skipping to change at page 13, line 32 skipping to change at page 14, line 32
"Graceful Restart Mechanism for BGP", RFC 4724 January 2007. "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 [GMPLS G-Shut] 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" September 15, 2009, internet draft, draft-ietf- Engineering Networks", RFC 5817 April 2010.
ccamp-mpls-graceful-shutdown-12.txt, work in progress.
[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.
skipping to change at page 14, line 14 skipping to change at page 15, line 14
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
Authors' Addresses Authors' Addresses
Bruno Decraene Bruno Decraene
France Telecom France Telecom
38-40 rue du General Leclerc 38-40 rue du General Leclerc
92794 Issy Moulineaux cedex 9 92794 Issy Moulineaux cedex 9
France France
Email: bruno.decraene@orange-ftgroup.com Email: bruno.decraene@orange-ftgroup.com
Pierre Francois Pierre Francois
Universite catholique de Louvain Universite catholique de Louvain
Place Ste Barbe, 2 Place Ste Barbe, 2
Louvain-la-Neuve 1348 Louvain-la-Neuve 1348
BE BE
Email: francois@info.ucl.ac.be Email: francois@info.ucl.ac.be
Cristel Pelsser Cristel Pelsser
Internet Initiative Japan Internet Initiative Japan
Jinbocho Mitsui Building Jinbocho Mitsui Building
1-105 Kanda jinbo-cho 1-105 Kanda jinbo-cho
Chiyoda-ku, Tokyo 101-0051 Chiyoda-ku, Tokyo 101-0051
Japan Japan
Email: cristel@iij.ad.jp Email: cristel@iij.ad.jp
Zubair Ahmad Zubair Ahmad
Orange Business Services Orange Business Services
13775 McLearen Road, Oak Hill VA 20171 13775 McLearen Road, Oak Hill VA 20171
USA USA
Email: zubair.ahmad@ orange-ftgroup.com Email: zubair.ahmad@ orange-ftgroup.com
Antonio Jose Elizondo Armengol Antonio Jose Elizondo Armengol
Division de Analisis Tecnologicos Division de Analisis Tecnologicos
Technology Analysis Division Technology Analysis Division
Telefonica I+D Telefonica I+D
C/ Emilio Vargas 6 C/ Emilio Vargas 6
28043, Madrid 28043, Madrid
E-mail: ajea@tid.es E-mail: ajea@tid.es
Tomonori Takeda Tomonori Takeda
NTT Corporation NTT Corporation
9-11, Midori-Cho 3 Chrome 9-11, Midori-Cho 3 Chrome
Requirements for the graceful shutdown of BGP sessions
Musashino-Shi, Tokyo 180-8585 Musashino-Shi, Tokyo 180-8585
Japan Japan
Email: takeda.tomonori@lab.ntt.co.jp Email: takeda.tomonori@lab.ntt.co.jp
 End of changes. 47 change blocks. 
97 lines changed or deleted 131 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/