draft-ietf-grow-bgp-graceful-shutdown-requirements-04.txt   draft-ietf-grow-bgp-graceful-shutdown-requirements-05.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
September 06, 2010 October 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-04.txt draft-ietf-grow-bgp-graceful-shutdown-requirements-05.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 March 05, 2011. This Internet-Draft will expire on April 09, 2011.
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 2, line 45 skipping to change at page 2, line 45
requirements for 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...........................................4 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.................................................6 4. Terminology.................................................6
5. Goals and requirements......................................6 5. Goals and requirements......................................7
6. Reference Topologies........................................8 6. Reference Topologies........................................9
6.1. E-BGP topologies............................................9 6.1. E-BGP topologies............................................9
6.2. I-BGP topologies...........................................11 6.2. I-BGP topologies...........................................11
7. Security Considerations....................................14 7. Security Considerations....................................14
8. IANA Considerations........................................14 8. IANA Considerations........................................15
9. References.................................................14 9. References.................................................15
9.1. Normative References.......................................14 9.1. Normative References.......................................15
9.2. Informative References.....................................14 9.2. Informative References.....................................15
10. Acknowledgments............................................15 10. Acknowledgments............................................15
11. Author's Addresses.........................................15 11. Author's Addresses.........................................16
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 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Introduction 2. Introduction
The Border Gateway Protocol(BGP) is heavily used in Service Provider The Border Gateway Protocol(BGP) [BGP-4] is heavily used in Service
networks both for Internet and BGP/MPLS VPN services. For resiliency Provider networks both for Internet and BGP/MPLS VPN services [VPN].
purposes, redundant routers and BGP sessions can be deployed to For resiliency purposes, redundant routers and BGP sessions can be
reduce the consequences of an AS Border Router or BGP session deployed to reduce the consequences of an AS Border Router or BGP
breakdown on customers' or peers' traffic. session breakdown on 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
maintenance operation and needs to shut down one or multiple BGP maintenance operation and needs to shut down one or multiple BGP
peering link(s) or a whole ASBR. If an alternate path is available peering link(s) or a whole ASBR. If an alternate path is available
within the AS, the requirement is to avoid or reduce customer or peer within the AS, the requirement is to avoid or reduce customer or peer
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.
skipping to change at page 5, line 55 skipping to change at page 6, line 5
When multiple BGP routers are involved and plenty of prefixes are When multiple BGP routers are involved and plenty of prefixes are
affected, the recovery process can take longer than applications affected, the recovery process can take longer than applications
requirements. requirements.
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.
Requirements for the graceful shutdown of BGP sessions
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: hiding the backup path. This router can be:
- a route reflector only propagating its best path; - a route reflector only propagating its best path;
Requirements for the graceful shutdown of BGP sessions
- the backup ASBR not advertising the backup path because it prefers - the backup ASBR not advertising the backup path because it prefers
the nominal path. the nominal path.
This lack of knowledge of the alternate path is the first target of This lack of knowledge of the alternate path is the first target of
this requirement draft. this 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. The duration of can lead to forwarding loops and then packet drops. The duration of
these transient micro-loops may depend on the IBGP topology (e.g. these transient micro-loops may depend on the IBGP topology (e.g.
number of Route Reflectors between ingress and egress ASBR), number of Route Reflectors between ingress and egress ASBR),
skipping to change at page 6, line 28 skipping to change at page 6, line 31
update the RIB and FIB, possibly the order in which prefixes are update the RIB and FIB, possibly the order in which prefixes are
modified), forwarding mode (hop by hop IP forwarding versus modified), forwarding mode (hop by hop IP forwarding versus
tunneling). tunneling).
Transient forwarding loops can be avoided by performing only one IP Transient forwarding loops can be avoided by performing only one IP
lookup on BGP routes in each AS and by using tunnels (e.g. MPLS LSP) lookup on BGP routes in each AS and by using tunnels (e.g. MPLS LSP)
to send packets between ASBRs. As such, BGP/MPLS VPNs should be to send packets between ASBRs. As such, BGP/MPLS VPNs should be
immune to such micro forwarding loops. immune to such micro forwarding loops.
4. Terminology 4. Terminology
g-shut: Graceful SHUTdown. A method for explicitly notifying the BGP
routers that a BGP session (and hence the prefixes learnt over that
session) is going to be disabled.
g-noshut: Graceful NO SHUTdown. A method for explicitly notifying
the BGP routers that a BGP session (and hence the prefixes learnt
over that session) is going to be enabled.
g-shut initiator: the router on which the session(s) shutdown is g-shut initiator: the router on which the session(s) shutdown is
(are) performed for the maintenance. (are) performed for the maintenance.
g-shut neighbor: a router that peers with the g-shut initiator g-shut neighbor: a router that peers with the g-shut initiator
via (one of) the session(s) undergoing maintenance. via (one of) the session(s) undergoing maintenance.
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.
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).
Requirements for the graceful shutdown of BGP sessions
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
down, all routers learn and use the alternate paths. Then the nominal down, all routers learn and use the alternate paths. Then the nominal
BGP session can be shut down. BGP session can be shut down.
As a result, provided an alternate path is available in the AS, the As a result, provided an alternate path with enough remaining
packets are rerouted before the BGP session termination and fewer capacity is available in the AS, the packets are rerouted before the
BGP session termination and fewer packets (possibly none) are lost
Requirements for the graceful shutdown of BGP sessions during the BGP convergence process since at any time, all routers
have a valid path.
packets (possibly none) are lost during the BGP convergence process
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
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. Note also that the maintenance action can AS and in neighboring ASes. Note also that the maintenance action can
either be the shutdown of a BGP session or the establishment of a BGP either be the shutdown of a BGP session or the establishment of a BGP
session. session.
The mechanism SHOULD minimize packet loss when a path is removed or The mechanism SHOULD allow BGP routers to minimize packet loss when a
advertised. In particular, it SHOULD be ensured that the old path is path is removed or advertised. In particular, it SHOULD be ensured
not removed from the routing tables of the affected routers before that the old path is not removed from the routing tables of the
the new path is known. affected routers before the new path is known.
The solution mechanism MUST reduce packet loss but MAY provide only a
reduction rather than full minimization, in order to trade off with
simplicity of implementation and operation as shown in some of the
following requirements.
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 SHOULD initiator AS and the neighbor AS(es) have a backup path, they SHOULD
be able to gracefully converge before the nominal path is shut down. be 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 (EBGP, IBGP, IBGP route reflector client, EBGP sessions (EBGP, IBGP, IBGP route reflector client, EBGP
confederations, EBGP multi hop, MultiProtocol BGP extension...) and confederations, EBGP multi hop, MultiProtocol BGP extension...) and
any address family. If a BGP implementation allows closing a sub-set any address family. If a BGP implementation allows closing a sub-set
of AFIs carried in a MP-BGP session, this mechanism MAY be applicable of AFIs carried in a MP-BGP session, this mechanism MAY be applicable
to this sub-set of AFIs. to this sub-set of AFIs.
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 fulfill the variations in the proposed solution in order to fulfill the
requirements. requirements.
Requirements for the graceful shutdown of BGP sessions
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.
Service Providers and platforms implementing a graceful shutdown Service Providers and platforms implementing a graceful shutdown
solution should note that in BGP/MPLS VPN as per [VPN], the PE-CE solution should note that in BGP/MPLS VPN as per [VPN], the PE-CE
routing can be performed by other protocols than BGP (e.g. static routing can be performed by other protocols than BGP (e.g. static
routes, RIPv2, OSPF, IS-IS...). This is out of scope of this routes, RIPv2, OSPF, IS-IS...). This is out of scope of this
document, but comprehensive graceful shutdown procedures should take document.
this into account.
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, namely behavior for the ASes exterior to the maintenance process, namely
ASes other than the initiator AS and it(s) neighbor AS(es). ASes other than the initiator AS and it(s) neighbor AS(es).
Requirements for the graceful shutdown of BGP sessions
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
SHOULD also be covered. SHOULD also be covered.
skipping to change at page 8, line 33 skipping to change at page 8, line 49
following the g-shut and once the BGP session is gracefully opened following the g-shut and once the BGP session is gracefully opened
following the g-noshut. In the end, once the planned maintenance is following the g-noshut. In the end, once the planned maintenance is
finished the nominal BGP routing MUST be reestablished. finished the nominal BGP routing MUST be reestablished.
The duration of the g-shut procedure, and hence the time before the The duration of the g-shut procedure, and hence the time before the
BGP session is safely closed SHOULD be discussed by the solution BGP session is safely closed SHOULD be discussed by the solution
document. Examples of possible solutions are the use of a pre- document. Examples of possible solutions are the use of a pre-
configured timer, of a message to signal the end of the BGP configured timer, of a message to signal the end of the BGP
convergence or monitoring the traffic on the g-shut interface... convergence or monitoring the traffic on the g-shut interface...
i) The solution SHOULD be simple and simple to operate. Hence it i) The solution SHOULD be simple and simple to operate. Hence it
MAY only cover a subset of the cases. MAY only cover a subset of the cases. (As a consequence, most of the
above requirements are expressed as "SHOULD" rather than "MUST")
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
Requirements for the graceful shutdown of BGP sessions
- 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
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 documents
should state its applicability for each of these possible should state the applicability of the solutions for each of these
topologies. possible 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. Note that this topologies and not only to these below examples. Note that this
is a "SHOULD" rather than a "MUST" as a partial lightweight is a "SHOULD" rather than a "MUST" as a partial lightweight
solution may be preferred to a full but more complex solution. solution may be preferred to a full but more complex solution.
Requirements for the graceful shutdown of BGP sessions
Especially since some ISP may not be concerned by some topologies Especially since some ISP may not be concerned by some topologies
(e.g. confederations). (e.g. confederations).
6.1. EBGP topologies 6.1. EBGP topologies
We describe here some frequent EBGP topologies that SHOULD be We describe here some frequent EBGP topologies that SHOULD be
supported by the solution. 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
skipping to change at page 9, line 40 skipping to change at page 10, line 4
\ ' \ '
\----------- ASBR2.2 \----------- ASBR2.2
' '
' '
AS1 ' AS2 AS1 ' AS2
' '
Figure 2. EBGP topology with redundant ASBR in one of the AS. Figure 2. EBGP topology with redundant ASBR in one of the AS.
The requirements of section 5 should be applicable to: The requirements of section 5 should be applicable to:
Requirements for the graceful shutdown of BGP sessions
- Maintenance of one of the routers of AS2; - Maintenance of one of the routers of AS2;
- Maintenance of one link between AS1 and AS2, performed either - Maintenance of one link between AS1 and AS2, performed either
on an AS1 or AS2 router. on an AS1 or AS2 router.
Note that in case of maintenance of the whole router, all its BGP Note that in case of maintenance of the whole router, all its BGP
session needs to be shutdown. session needs to be shutdown.
6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2 6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2
In this topology we have a symmetric protection scheme between In this topology we have a symmetric protection scheme between
AS1 and AS2: on both sides, two different routers are used to AS1 and AS2: on both sides, two different routers are used to
connect AS1 to AS2. connect AS1 to AS2.
Requirements for the graceful shutdown of BGP sessions
' '
AS1 ' AS2 AS1 ' AS2
' '
ASBR1.1----------- ASBR2.1 ASBR1.1----------- ASBR2.1
' '
' '
' '
' '
' '
ASBR1.2----------- ASBR2.2 ASBR1.2----------- ASBR2.2
skipping to change at page 10, line 34 skipping to change at page 11, line 5
- 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.
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.
Requirements for the graceful shutdown of BGP sessions
' '
AS1 ' AS2 AS1 ' AS2
' '
ASBR1.1----------- ASBR2.1 ASBR1.1----------- ASBR2.1
| ' | '
| ' | '
'''''|'''''''''' '''''|''''''''''
| ' | '
| ' | '
ASBR3.1----------- ASBR2.2 ASBR3.1----------- ASBR2.2
skipping to change at page 11, line 5 skipping to change at page 11, line 31
The requirements of section 5 do not translate as easily as in The requirements of section 5 do not translate as easily as in
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.
Requirements for the graceful shutdown of BGP sessions
6.2. IBGP topologies 6.2. IBGP topologies
We describe here some frequent IBGP topologies that SHOULD be We describe here some frequent IBGP topologies that SHOULD be
supported by the solution. supported by the solution.
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
skipping to change at page 11, line 33 skipping to change at page 12, line 4
\ / \ /
\ / \ /
''''''\''''/'''''''''''' ''''''\''''/''''''''''''
\ / AS2 \ / AS2
ASBR2.1 ASBR2.1
Figure 5. IBGP full mesh Figure 5. IBGP full mesh
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 IBGP peers of ASBR1.1 reroute maintenance, it is required that all IBGP peers of ASBR1.1 reroute
Requirements for the graceful shutdown of BGP sessions
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.
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
IBGP sessions. IBGP sessions.
Requirements for the graceful shutdown of BGP sessions
P1 RR----- P2 RR P1 RR----- P2 RR
| \ / | | \ / |
| \ / | | \ / |
| \ / | AS1 | \ / | AS1
| \ / | | \ / |
| / \ | | / \ |
| / \ | | / \ |
| / \ | | / \ |
ASBR1.1 ASBR1.2 ASBR1.1 ASBR1.2
\ / \ /
skipping to change at page 12, line 35 skipping to change at page 13, line 5
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.
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 IBGP sessions. the number of IBGP 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 13, line 5 skipping to change at page 13, line 30
ASBR1.1 ASBR1.2 ASBR1.1 ASBR1.2
\ / \ /
\ / \ /
''''''\'''''''''/'''''''''''' ''''''\'''''''''/''''''''''''
\ / \ /
\ / AS2 \ / AS2
ASBR2.1 ASBR2.1
Figure 7. Hierarchical Route Reflector Figure 7. Hierarchical Route Reflector
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 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.
6.2.4. Confederations 6.2.4. Confederations
In this topology, a confederation of ASs is used to limit the number In this topology, a confederation of ASs is used to limit the number
of IBGP sessions. Moreover, RRs may be present in the member ASs of of IBGP sessions. Moreover, RRs may be present in the member ASs of
the confederation. the confederation.
Confederations may be run with different sub-options. Regarding the Confederations may be run with different sub-options. Regarding the
IGP, each member AS can run its own IGP or they can all share the IGP, each member AS can run its own IGP or they can all share the
same IGP. Regarding BGP, local_pref may or may not cross the member same IGP. Regarding BGP, local_pref may or may not cross the member
AS boundaries. AS boundaries.
A solution should support the shutdown of EBGP sessions between A solution should support the shutdown of EBGP sessions between
member-ASs in the confederation in addition to the shutdown of EBGP member-ASs in the confederation in addition to the shutdown of EBGP
sessions between a member-AS and an AS outside of the confederation. sessions between a member-AS and an AS outside of the confederation.
Requirements for the graceful shutdown of BGP sessions
ASBR1C.1 ---------- ASBR1C.2 ASBR1C.1 ---------- ASBR1C.2
| | | |
| | | |
| AS1C | | AS1C |
| | | |
| | | |
"""|"""""""""""""""""""|""" """|"""""""""""""""""""|"""
| " | | " |
ASBR1A.2 " ASBR1B.2 ASBR1A.2 " ASBR1B.2
| " | | " |
skipping to change at page 14, line 5 skipping to change at page 14, line 39
Figure 8. Confederation Figure 8. Confederation
In the above figure, member-AS AS1A, AS1B, AS1C belong to a In the above figure, member-AS AS1A, AS1B, AS1C belong to a
confederation of ASs in AS1. AS1A and AS1B are connected to AS2. confederation of ASs in AS1. AS1A and AS1B are connected to AS2.
In normal operation, for the traffic toward AS2, In normal operation, for the traffic toward AS2,
. AS1A sends the traffic directly to AS2 through ASBR1A.1 . AS1A sends the traffic directly to AS2 through ASBR1A.1
. AS1B sends the traffic directly to AS2 through ASBR1B.1 . AS1B sends the traffic directly to AS2 through ASBR1B.1
. AS1C load balances the traffic between AS1A and AS1B . AS1C load balances the traffic between AS1A and AS1B
Requirements for the graceful shutdown of BGP sessions
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
At the requirements stage, this graceful shutdown mechanism is
expected to not affect the security of the BGP protocol, especially
if it can be kept simple. No new sessions are required and the
additional ability to signal the graceful shutdown is not expected to
bring additional attack vector as BGP neighbors already have the
ability to send incorrect or misleading information or even shut down
the session.
Security considerations MUST be addressed by the proposed Security considerations MUST be addressed by the proposed
solutions. solutions. In particular they SHOULD address the issues of bogus
g-shut messages and how they would affect the network(s), as well
Requirements for the graceful shutdown of BGP sessions
as the impact of hiding a g-shut message so that g-shut is not
performed.
The solution SHOULD NOT increase the ability for one AS to The solution SHOULD NOT increase the ability for one AS to
selectively influence routing decision in the peer AS (inbound selectively influence routing decision in the peer AS (inbound
Traffic Engineering) outside the case of the BGP session Traffic Engineering) outside the case of the BGP session
shutdown. Otherwise, the peer AS SHOULD have means to detect such shutdown. Otherwise, the peer AS SHOULD have means to detect such
behavior. behavior.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
skipping to change at page 15, line 4 skipping to change at page 15, line 51
9.2. Informative References 9.2. Informative References
[RFC5817] 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 [GR] S. Sangli, E. Chen, R. Fernando, J. Scudder, Y. Rekhter
"Graceful Restart Mechanism for BGP", RFC 4724 January 2007. "Graceful Restart Mechanism for BGP", RFC 4724 January 2007.
[Reliability] Network Strategy Partners, LLC. [Reliability] Network Strategy Partners, LLC.
Requirements for the graceful shutdown of BGP sessions
"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
Authors would like to thank Nicolas Dubois, Benoit Fondeviole, Authors would like to thank Nicolas Dubois, Benoit Fondeviole,
Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier
Requirements for the graceful shutdown of BGP sessions
Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and
Ronald Bonica for the useful discussions on this subject, their Ronald Bonica for the useful discussions on this subject, their
review and comments. review and comments.
This draft has been partly sponsored by the European project IST This draft has been partly sponsored by the European project IST
AGAVE. AGAVE.
Authors' Addresses Authors' Addresses
Bruno Decraene Bruno Decraene
skipping to change at page 16, line 5 skipping to change at page 16, line 48
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
Requirements for the graceful shutdown of BGP sessions
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
Requirements for the graceful shutdown of BGP sessions
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
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. 36 change blocks. 
56 lines changed or deleted 83 lines changed or added

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