draft-ietf-grow-bgp-graceful-shutdown-requirements-06.txt   draft-ietf-grow-bgp-graceful-shutdown-requirements-07.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 22, 2010 January 28, 2011
Requirements for the graceful shutdown of BGP sessions Requirements for the graceful shutdown of BGP sessions
draft-ietf-grow-bgp-graceful-shutdown-requirements-06.txt draft-ietf-grow-bgp-graceful-shutdown-requirements-07.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 20, 2011. This Internet-Draft will expire on July 27, 2011.
Internet-Draft Requirements for the graceful shutdown of BGP sessions Internet-Draft 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) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 46 skipping to change at page 2, line 46
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......................................7 5. Goals and requirements......................................7
6. Reference Topologies........................................9 6. Security Considerations.....................................9
6.1. E-BGP topologies............................................9 7. IANA Considerations........................................10
6.2. I-BGP topologies...........................................11 8. References.................................................10
7. Security Considerations....................................15 8.1. Normative References.......................................10
8. IANA Considerations........................................16 8.2. Informative References.....................................10
9. References.................................................16 9. Acknowledgments............................................10
9.1. Normative References.......................................16 10. Appendix: Reference BGP Topologies.........................12
9.2. Informative References.....................................16 10.1. EBGP topologies............................................12
10. Acknowledgments............................................17 10.2. IBGP topologies............................................14
11. Author's Addresses.........................................17 10.3. Routing decisions..........................................17
Internet-Draft Requirements for the graceful shutdown of BGP sessions Internet-Draft 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) [BGP-4] is heavily used in Service The Border Gateway Protocol(BGP) [RFC4271] is heavily used in Service
Provider networks both for Internet and BGP/MPLS VPN services [VPN]. Provider networks both for Internet and BGP/MPLS VPN services
For resiliency purposes, redundant routers and BGP sessions can be [RFC4364]. For resiliency purposes, redundant routers and BGP
deployed to reduce the consequences of an AS Border Router or BGP sessions can be deployed to reduce the consequences of an AS Border
session breakdown on customers' or peers' traffic. Router or BGP 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 is
withdrawn and the forwarding is interrupted on the nominal path. withdrawn and the forwarding is stopped.
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 [BGP-4] and MP-BGP [MP-BGP] do not include any BGP [RFC4271] and MP-BGP [RFC4760] do not currently have a mechanism
operation to gracefully advertise or withdraw a prefix while traffic to gracefully migrate traffic from one BGP next hop to another
toward that prefix could still be correctly forwarded using the old without interrupting the flow of traffic. When a BGP session is taken
path. When a BGP session is taken down, BGP behaves as if it was a down, BGP behaves as if it was a sudden link or router failure and
sudden link or router failure and withdraws the prefixes learnt over withdraws the prefixes learnt over that session, which may trigger
that session, which may trigger traffic loss. There is no mechanism traffic loss. There is no mechanism to advertise to its BGP peers
to advertise to its BGP peers that the prefix will soon be that the prefix will soon be unreachable, while still being
unreachable, while still being reachable. When applicable, such reachable. When applicable, such mechanism would reduce or prevent
mechanism would reduce or prevent traffic loss. It would typically be traffic loss. It would typically be applicable in case of a
applicable in case of a maintenance operation requiring the shutdown maintenance operation requiring the shutdown of a forwarding
of a forwarding resource. Typical examples would be a link or line resource. Typical examples would be a link or line card maintenance,
card maintenance, replacement or upgrade. It may also be applicable replacement or upgrade. It may also be applicable for a software
for a software upgrade as it may involve a firmware reset on the line upgrade as it may involve a firmware reset on the line cards and
cards and hence forwarding interruption. hence forwarding interruption.
The introduction of Route Reflectors as per [RR] to solve scalability The introduction of Route Reflectors as per [RFC4456] to solve
issues bound to IBGP full-meshes has worsened the duration of routing scalability issues bound to IBGP full-meshes has worsened the
convergence as some route reflectors may hide the back up path. Thus duration of routing convergence as some route reflectors may hide the
depending on RR topology more IBGP hops may be involved in the IBGP back up path. Thus depending on RR topology more IBGP hops may be
convergence. involved in the IBGP convergence.
Internet-Draft Requirements for the graceful shutdown of BGP sessions Internet-Draft Requirements for the graceful shutdown of BGP sessions
Note that these planned maintenance operations cannot be addressed by Note that these planned maintenance operations cannot be addressed by
Graceful Restart extensions [GR] as GR only applies when the Graceful Restart extensions [RFC4724] 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 in [RFC5817]). shutdown procedure (e.g. GMPLS in [RFC5817]).
A successful approach of such mechanism should minimize the loss of A metric of success is the degree to which such a mechanism
traffic in most foreseen maintenance situations. eliminates traffic loss during maintenance operations.
3. Problem statement 3. Problem statement
As per [BGP-4], when one (or many) BGP session(s) are shut down, a As per [RFC4271], when one (or many) BGP session(s) are shut down, a
BGP 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.
As maintenance operations are frequent in large networks As maintenance operations are frequent in large networks [Reliable],
[Reliability], the global availability of the network is the global availability of the network is significantly impaired by
significantly impaired by this BGP maintenance issue. 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 simple To illustrate these problems, let us consider the following simple
example where one customer router "CUST" is dual-attached to two SP example where one customer router "CUST" is dual-attached to two SP
routers "ASBR1" and "ASBR2". routers "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.
Internet-Draft Requirements for the graceful shutdown of BGP sessions Internet-Draft Requirements for the graceful shutdown of BGP sessions
skipping to change at page 5, line 31 skipping to change at page 5, line 31
' '
Figure 1. Dual attached customer Figure 1. Dual attached customer
Before the maintenance, packets for destination Z/z use the ASBR1- Before the maintenance, packets for destination Z/z use the ASBR1-
CUST link because R1 selects ASBR1's route based on the IGP cost. CUST 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 withdraw its prefix Z/z to its route reflector R1.
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.
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
skipping to change at page 6, line 16 skipping to change at page 6, line 16
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;
- 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 and FIB at the same because routers do not simultaneously update their RIBs and hence do
time. This can lead to forwarding loops and then packet drops. The not simultaneously update their FIBs entries. This can lead to
duration of these transient micro-loops may depend on the IBGP forwarding loops which result in both link congestion and packet
topology (e.g. number of Route Reflectors between ingress and egress drops. The duration of these transient micro-loops is dependent on
ASBR), implementation differences among router platforms (e.g. speed the IBGP topology (e.g. number of Route Reflectors between ingress
to update the RIB and FIB, possibly the order in which prefixes are and egress ASBR), implementation differences among router platforms
modified), forwarding mode (hop by hop IP forwarding versus which result in differences in the time taken to update specific
prefix in the FIB, forwarding mode (hop by hop IP forwarding versus
tunneling). tunneling).
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) Note that when an IP lookup is only performed on entry to the AS, for
to send packets between ASBRs. As such, BGP/MPLS VPNs should be example prior to entry into a tunnel across the AS, micro-loops will
immune to such micro forwarding loops. not occur. An example of this is when BGP is being used to as the
routing protocol for MPLS VPN as defined in [RFC4364].
Note that [RFC5715] defines a framework for loop-free convergence. It
has been written in the context of IP Fast ReRoute for link state IGP
[RFC5714] but some concepts are also of interest for BGP convergence.
4. Terminology 4. Terminology
g-shut: Graceful SHUTdown. A method for explicitly notifying the BGP g-shut: Graceful SHUTdown. A method for explicitly notifying the BGP
routers that a BGP session (and hence the prefixes learnt over that routers that a BGP session (and hence the prefixes learnt over that
session) is going to be disabled. session) is going to be disabled.
g-noshut: Graceful NO SHUTdown. A method for explicitly notifying g-noshut: Graceful NO SHUTdown. A method for explicitly notifying
the BGP routers that a BGP session (and hence the prefixes learnt the BGP routers that a BGP session (and hence the prefixes learnt
over that session) is going to be enabled. over that session) is going to be enabled.
skipping to change at page 6, line 54 skipping to change at page 7, line 5
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.
Internet-Draft 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).
Internet-Draft 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 Currently, when a BGP session of the router under maintenance is shut
router removes the routes and then triggers the BGP convergence on down, the router removes the routes and then triggers the BGP
its BGP peers. The goal of BGP graceful shutdown is to initiate the convergence on its BGP peers by withdrawing its route.
BGP convergence to find the alternate paths before the nominal paths The goal of BGP graceful shutdown of a (set of) BGP session(s) is to
are removed. As a result, before the nominal BGP session is shut minimize traffic loss during a planned shutdown. Ideally a solution
down, all routers learn and use the alternate paths. Then the nominal should reduce this traffic loss to zero.
BGP session can be shut down. Another goal is to minimize and preferably to eliminate packet loss
when the BGP session is re-established following the maintenance.
As a result, provided an alternate path with enough remaining As the event is known in advance, a make before break solution can be
capacity is available in the AS, the packets are rerouted before the used in order to initiate the BGP convergence, find and install the
BGP session termination and fewer packets (possibly none) are lost alternate paths before the nominal paths are removed. As a result,
during the BGP convergence process since at any time, all routers before the nominal BGP session is shut down, all affected routers
have a valid path. learn and use the alternate paths. Those alternate paths are computed
by BGP taking into account the known status of the network which
includes known failures that the network is processing concurrently
with the BGP session graceful shutdown and possibly known other
graceful shutdown under way. Therefore multiple BGP graceful
shutdowns overlapping within a short timeframe are gracefully
handled. Indeed a given graceful shutdown takes into account all
previous ones and previous graceful shutdown are given some time to
adapt to this new one. Then the nominal BGP session can be shut down.
Another goal is to minimize packet loss when the BGP session is re- As a result, provided an alternate path with enough remaining
established following the maintenance. capacity is available, the packets are rerouted before the BGP
session termination and fewer packets (possibly none) are lost during
the BGP convergence process since at any time, all routers have a
valid path.
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 allow BGP routers to minimize packet loss when a The mechanism SHOULD allow BGP routers to minimize and preferably to
path is removed or advertised. In particular, it SHOULD be ensured eliminate packet loss when a path is removed or advertised. In
that the old path is not removed from the routing tables of the particular, it SHOULD be ensured that the old path is not removed
affected routers before the new path is known. from the routing tables of the affected routers before the new path
The solution mechanism MUST reduce packet loss but MAY provide only a is known.
reduction rather than full minimization, in order to trade off with The solution mechanism MUST significantly reduce and ideally
simplicity of implementation and operation as shown in some of the
following requirements. Internet-Draft Requirements for the graceful shutdown of BGP sessions
eliminate packet loss. A trade off may be made between the degree of
packet loss and the simplicity of the solution.
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 or any address family. If a BGP implementation allows closing or
enabling a sub-set of AFIs carried in a MP-BGP session, this enabling a sub-set of AFIs carried in a MP-BGP session, this
mechanism MAY be applicable to this sub-set of AFIs. mechanism MAY be applicable to this sub-set of AFIs.
Depending on the kind of session, there may be some variations in the Depending on the kind of session, there may be some variations in the
proposed solution in order to fulfill the requirements. proposed solution in order to fulfill the requirements.
The following cases should be handled in priority: The following cases should be handled in priority:
Internet-Draft Requirements for the graceful shutdown of BGP sessions
- 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 [RFC4364], 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 document. routes, RIPv2, OSPF, IS-IS). This is out of scope of this document.
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).
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
MUST be made possible. In case of partial deployment the proposed MUST be made possible. In case of partial deployment the proposed
solution SHOULD incrementally improve the maintenance process. solution SHOULD incrementally improve the maintenance process.
It should be noted that in an inter domain relation, one AS may have It should be noted that in an inter domain relation, one AS may have
more incentive to use graceful shutdown than the other. Similarly, in more incentive to use graceful shutdown than the other. Similarly, in
a BGP/MPLS VPN environment, it's much easier to upgrade the PE a BGP/MPLS VPN environment, it's much easier to upgrade the PE
routers than the CE mainly because there is at least an order of routers than the CE mainly because there is at least an order of
magnitude more CE and CE locations than PE and PE locations. As a magnitude more CE and CE locations than PE and PE locations. As a
consequence, when splitting the cost of the solution between the g- consequence, when splitting the cost of the solution between the g-
shut initiator and the g-shut neighbour the solution SHOULD favour a shut initiator and the g-shut neighbour the solution SHOULD favour a
low cost solution on the neighbour AS side in order to reduce the low cost solution on the neighbour AS side in order to reduce the
impact on the g-shut neighbour. Impact should be understood as a impact on the g-shut neighbour. Impact should be understood as a
generic term which includes first hardware, then software, then generic term which includes first hardware, then software, then
configuration upgrade.. configuration upgrade.
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.
Internet-Draft Requirements for the graceful shutdown of BGP sessions
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 closed h) The specific procedure SHOULD end when the BGP session is closed
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. (As a consequence, most of the MAY only cover a subset of the cases. As a consequence, most of the
above requirements are expressed as "SHOULD" rather than "MUST") above requirements are expressed as "SHOULD" rather than "MUST".
Internet-Draft Requirements for the graceful shutdown of BGP sessions
The metrics to evaluate and compare the proposed solutions are, in The metrics to evaluate and compare the proposed solutions are:
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;
- 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 (e.g. BGP messages sent to
routers, peer ASes, the Internet). peer routers, peer ASes, the Internet).
6. Reference Topologies 6. Security Considerations
In order to benchmark the proposed solutions, some typical BGP At the requirements stage, this graceful shutdown mechanism is
topologies are detailed in this section. The solution documents expected to not affect the security of the BGP protocol, especially
should state the applicability of the solutions for each of these if it can be kept simple. No new sessions are required and the
possible topologies. 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.
However, solutions SHOULD be applicable to all possible BGP Security considerations MUST be addressed by the proposed
topologies and not only to these below examples. Note that this solutions. In particular they SHOULD address the issues of bogus
is a "SHOULD" rather than a "MUST" as a partial lightweight g-shut messages and how they would affect the network(s), as well
solution may be preferred to a full but more complex solution. as the impact of hiding a g-shut message so that g-shut is not
Especially since some ISP may not be concerned by some topologies performed.
(e.g. confederations).
6.1. EBGP topologies The solution SHOULD NOT increase the ability for one AS to
selectively influence routing decision in the peer AS (inbound
Traffic Engineering) outside the case of the BGP session
shutdown. Otherwise, the peer AS SHOULD have means to detect such
behavior.
We describe here some frequent EBGP topologies that SHOULD be Internet-Draft Requirements for the graceful shutdown of BGP sessions
supported by the solution.
6.1.1. 1 ASBR in AS1 connected to two ASBRs in the neighboring AS2 7. IANA Considerations
This document has no actions for IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4271] Rekhter, Y. and T. Li, "A Border Gateway protocol 4
(BGP)", RFC 4271, January 2006.
[RFC4760] Bates, T., Chandra, R., Katz, D. and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760 January
2007.
[RFC4456] Bates, T., Chen E. and R. Chandra "BGP Route Reflection:
An Alternative to Full Mesh Internal BGP (IBGP)", RFC
4456 April 2006.
[RFC4364] Rosen, E. and Y. Rekhter "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364 February 2006.
8.2. Informative References
[RFC5817] Ali, Z., Vasseur, J.P., Zamfir, A. and J. Newton,
"Graceful Shutdown in MPLS and Generalized MPLS Traffic
Engineering Networks", RFC 5817, April 2010.
[RFC5715] Shand, M. and S. Bryant, "A Framework for Loop-Free
Convergence", RFC 5715, January 2010.
[RFC5714] Shand, M. and S. Bryant, "IP Fast Reroute Framework", RFC
5714, January 2010.
[RFC4724] Sangli, S., Chen, E., Fernando, R., Scudder, J. and Y.
Rekhter, "Graceful Restart Mechanism for BGP", RFC
4724, January 2007.
[Reliable] Network Strategy Partners, LLC. "Reliable IP Nodes: A
prerequisite to profitable IP services", November 2002.
http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf
9. Acknowledgments
Authors would like to thank Nicolas Dubois, Benoit Fondeviole,
Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier
Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and
Internet-Draft Requirements for the graceful shutdown of BGP sessions
Ronald Bonica for the useful discussions on this subject, their
review and comments.
This draft has been partly sponsored by the European project IST
AGAVE.
Internet-Draft Requirements for the graceful shutdown of BGP sessions
10. Appendix: Reference BGP Topologies
This section describes some frequent BGP topologies used both within
the AS (IBGP) and between ASes (EBGP). Solutions should be applicable
to the following topologies and their combinations.
10.1. EBGP topologies
This section describes some frequent BGP topologies used between
ASes. In each figure, a line represents a BGP session.
10.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.
Internet-Draft Requirements for the graceful shutdown of BGP sessions '
AS1 ' AS2
' '
AS1 ' AS2 /----------- ASBR2.1
' / '
/----------- ASBR2.1 / '
/ ' ASBR1.1 '
/ ' \ '
ASBR1.1 ' \ '
\ ' \----------- 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: BGP graceful shutdown is expected to be applicable for the
- Maintenance of one of the routers of AS2; maintenance of:
- Maintenance of one link between AS1 and AS2, performed either - one of the routers of AS2;
on an AS1 or AS2 router. - one link between AS1 and AS2, performed either 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
sessions need to be gracefully shutdown at the beginning of the sessions need to be gracefully shutdown at the beginning of the
maintenance and gracefully brought up at the end of the maintenance and gracefully brought up at the end of the
maintenance. maintenance.
6.1.2. 2 ASBRs in AS1 connected to 2 ASBRs in AS2 Internet-Draft Requirements for the graceful shutdown of BGP sessions
10.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.
' '
AS1 ' AS2 AS1 ' AS2
' '
ASBR1.1----------- ASBR2.1 ASBR1.1----------- ASBR2.1
' '
' '
' '
' '
' '
ASBR1.2----------- ASBR2.2 ASBR1.2----------- ASBR2.2
' '
AS1 ' AS2 AS1 ' AS2
' '
Figure 3. EBGP topology with redundant ASBR in both ASes
The requirements of section 5 should be applicable to:
- Maintenance of any of the ASBR routers (in AS1 or AS2);
Internet-Draft Requirements for the graceful shutdown of BGP sessions Figure 3. EBGP topology with redundant ASBRs in both ASes
- Maintenance of one link between AS1 and AS2 performed either on BGP graceful shutdown is expected to be applicable for the
an AS1 or AS2 router. maintenance of:
- any of the ASBR routers (in AS1 or AS2);
- one link between AS1 and AS2 performed either on an AS1 or AS2
router.
6.1.3. 2 ASBRs in AS2 each connected to two different ASes 10.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.
which routes are exchanged between these ASes, some protection
for some of the traffic may be possible.
' '
AS1 ' AS2 AS1 ' AS2
' '
ASBR1.1----------- ASBR2.1 ASBR1.1----------- ASBR2.1
| ' | '
| ' | '
'''''|'''''''''' '''''|''''''''''
| ' | '
| ' | '
ASBR3.1----------- ASBR2.2 ASBR3.1----------- ASBR2.2
' '
AS3 ' AS2 AS3 ' AS2
Figure 4. EBGP topology of a dual homed customer Figure 4. EBGP topology of a dual homed customer
The requirements of section 5 do not translate as easily as in Internet-Draft Requirements for the graceful shutdown of BGP sessions
the two previous topologies because we do not require propagating
the maintenance advertisement outside of the two ASes involved in
an eBGP session.
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
to be notified of the maintenance of the eBGP session between
ASBR3.1-ASBR2.2.
6.2. IBGP topologies As the requirements expressed in section 5 is to advertise the
maintenance only within the initiator and neighbor ASes, but not
Internet wide, BGP graceful shutdown solutions may not be
applicable to this topology. Depending on which routes are
exchanged between these ASes, some protection for some of the
traffic may be possible.
We describe here some frequent IBGP topologies that SHOULD be For instance if ASBR2.2 performs a maintenance affecting ASBR3.1 then
supported by the solution. ASBR3.1 will be notified. However ASBR1.1 may not be notified of the
maintenance of the eBGP session between ASBR3.1 and ASBR2.2.
Internet-Draft Requirements for the graceful shutdown of BGP sessions 10.2. IBGP topologies
6.2.1. IBGP Full-Mesh This section describes some frequent BGP topologies used within an
AS. In each figure, a line represents a BGP session.
In this topology we have a full mesh of iBGP sessions: 10.2.1. IBGP Full-Mesh
P1 ------ P2 In this topology we have a full mesh of IBGP sessions:
| \ / |
| \ / | P1 ----- P2
| \ / | AS1 | \ / |
| / \ | | \ / |
| / \ | | \/ | AS1
ASBR1.1---ASBR1.2 | /\ |
\ / | / \ |
\ / | / \ |
''''''\''''/'''''''''''' ASBR1.1--ASBR1.2
\ / AS2 \ /
ASBR2.1 \ /
''''''\'''/''''''''''''
\ / AS2
ASBR2.1
Figure 5. IBGP full mesh Figure 5. IBGP full mesh
When the session between ASBR1.1 and ASBR2.1 is gracefully When the session between ASBR1.1 and ASBR2.1 is gracefully
shutdown, it is required that all routers of AS1 reroute traffic shutdown, it is required that all affected routers of AS1 reroute
to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 is shut traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1
down. is shut down.
Symmetrically, when the session between ASBR1.1 and ASBR2.1 is Similarly, when the session between ASBR1.1 and ASBR2.1 is
gracefully brought up, it is required that all routers of AS1 gracefully brought up, all affected routers of AS1 preferring
preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before ASBR1.1 over ASBR1.2 need to reroute traffic to ASBR1.1 before the
the less preferred path trough ASBR1.2 is possibly withdrawn. less preferred path through ASBR1.2 is possibly withdrawn.
6.2.2. Route Reflector 10.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. There is a single level of route reflectors and the IBGP sessions. There is a single level of route reflectors and the
route reflectors are fully meshed. route reflectors are fully meshed.
Internet-Draft Requirements for the graceful shutdown of BGP sessions Internet-Draft 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
\ / \ /
''''''\''''''/'''''''''''' \ /
\ / ''''''\''''''/''''''''''''
\ / AS2 \ /
ASBR2.1 \ / AS2
ASBR2.1
Figure 6. Route Reflector Figure 6. Route Reflector
When the session between ASBR1.1 and ASBR2.1 is gracefully When the session between ASBR1.1 and ASBR2.1 is gracefully
shutdown, it is required that all BGP routers of AS1 reroute shutdown, all BGP routers of AS1 need to reroute traffic to
traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 ASBR1.2 before the session between ASBR1.1 and ASBR2.1 is shut
is shut down. down.
Symmetrically, when the session between ASBR1.1 and ASBR2.1 is Similarly, when the session between ASBR1.1 and ASBR2.1 is
gracefully brought up, it is required that all routers of AS1 gracefully brought up, all affected routers of AS1 preferring
preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before ASBR1.1 over ASBR1.2 need to reroute traffic to ASBR1.1 before the
the less preferred path trough ASBR1.2 is possibly withdrawn. less preferred path through ASBR1.2 is possibly withdrawn.
6.2.3. hierarchical Route Reflector 10.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. There could me more than levels of the number of IBGP sessions. There could me more than two levels
route reflectors and the top level route reflectors are fully of route reflectors and the top level route reflectors are fully
meshed. meshed.
Internet-Draft Requirements for the graceful shutdown of BGP sessions Internet-Draft Requirements for the graceful shutdown of BGP sessions
P1/hRR -------- P2/hRR P1 (RR) -------- P2 (RR)
| | | |
| | | |
| | AS1 | | AS1
| | | |
| | | |
P3/RR P4/RR P3 (RR) P4 (RR)
| | | |
| | | |
| | AS1 | | AS1
| | | |
| | | |
ASBR1.1 ASBR1.2 ASBR1.1 ASBR1.2
\ / \ /
\ / \ /
''''''\'''''''''/'''''''''''' ''''''\'''''''''/''''''''''''
\ / \ /
\ / AS2 \ / AS2
ASBR2.1 ASBR2.1
Figure 7. Hierarchical Route Reflector Figure 7. Hierarchical Route Reflector
When the session between ASBR1.1 and ASBR2.1 is gracefully When the session between ASBR1.1 and ASBR2.1 is gracefully
shutdown, it is required that all BGP routers of AS1 reroute shutdown, all BGP routers of AS1 need to reroute traffic to
traffic to ASBR1.2 before the session between ASBR1.1 and ASBR2.1 ASBR1.2 before the session between ASBR1.1 and ASBR2.1 is shut
is shut down. down.
Symmetrically, when the session between ASBR1.1 and ASBR2.1 is Similarly, when the session between ASBR1.1 and ASBR2.1 is
gracefully brought up, it is required that all routers of AS1 gracefully brought up, all affected routers of AS1 preferring
preferring ASBR1.1 over ASBR1.2 reroute traffic to ASBR1.1 before ASBR1.1 over ASBR1.2 need to reroute traffic to ASBR1.1 before the
the less preferred path trough ASBR1.2 is possibly withdrawn. less preferred path through ASBR1.2 is possibly withdrawn.
6.2.4. Confederations 10.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 graceful shutdown and graceful bring up A solution should support the graceful shutdown and graceful bring up
of EBGP sessions between member-ASs in the confederation in addition of EBGP sessions between member-ASs in the confederation in addition
to the graceful shutdown and graceful bring up of EBGP sessions to the graceful shutdown and graceful bring up of EBGP sessions
between a member-AS and an AS outside of the confederation. between a member-AS and an AS outside of the confederation.
Internet-Draft Requirements for the graceful shutdown of BGP sessions Internet-Draft 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
| " | | " |
| " | | " |
| AS1A " AS1B | AS1 | AS1A " AS1B | AS1
| " | | " |
| " | | " |
ASBR1A.1 " ASBR1B.1 ASBR1A.1 " ASBR1B.1
\ " / \ " /
\ " / \ " /
''''''\'''''''''''''/'''''''''''' ''''''\'''''''''''''/''''''''''''
\ / \ /
\ / AS2 \ / AS2
ASBR2.1 ASBR2.1
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 ASes 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
When the session between ASBR1A.1 and ASBR2.1 is gracefully shutdown, When the session between ASBR1A.1 and ASBR2.1 is gracefully shutdown,
it is required that all BGP routers of AS1 reroute traffic to all BGP routers of AS1 need to reroute traffic to ASBR1B.1 before the
ASBR1B.1 before the session between ASBR1A.1 and ASBR2.1 is shut session between ASBR1A.1 and ASBR2.1 is shut down.
down. Similarly, when the session between ASBR1A.1 and ASBR2.1 is
Symmetrically, when the session between ASBR1A.1 and ASBR2.1 is gracefully brought up, all affected routers of AS1 preferring
gracefully brought up, it is required that all routers of AS1 ASBR1A.1 over ASBR1.2 need to reroute traffic to ASBR1A.1 before the
preferring ASBR1A.1 over ASBR1.2 reroute traffic to ASBR1A.1 before less preferred path through ASBR1.2 is possibly withdrawn.
the less preferred path trough ASBR1.2 is possibly withdrawn.
7. Security Considerations 10.3. Routing decisions
At the requirements stage, this graceful shutdown mechanism is We describe here some routing engineering choices that are
expected to not affect the security of the BGP protocol, especially frequently used in ASes and that should be supported by the
if it can be kept simple. No new sessions are required and the solution.
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.
Internet-Draft Requirements for the graceful shutdown of BGP sessions Internet-Draft Requirements for the graceful shutdown of BGP sessions
Security considerations MUST be addressed by the proposed 10.3.1. Hot potato (IGP cost)
solutions. In particular they SHOULD address the issues of bogus
g-shut messages and how they would affect the network(s), as well
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
selectively influence routing decision in the peer AS (inbound
Traffic Engineering) outside the case of the BGP session
shutdown. Otherwise, the peer AS SHOULD have means to detect such
behavior.
8. IANA Considerations
This document has no actions for IANA.
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BGP-4] Y. Rekhter, T. Li, "A Border Gateway protocol 4 (BGP)", RFC
4271, January 2006.
[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
(IBGP)", RFC 4456 April 2006.
[VPN] E. Rosen, Y. Rekhter
"BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364
February 2006.
9.2. Informative References
[RFC5817] Z. Ali, J.P. Vasseur, A. Zamfir and J. Newton
"Graceful Shutdown in MPLS and Generalized MPLS Traffic
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. Ingress router selects the nominal egress ASBR (AS exit point)
"Reliable IP Nodes: A prerequisite to profitable IP services", based on the IGP cost to reach the BGP next-hop.
November 2002. http://www.nspllc.com/NewPages/Reliable_IP_Nodes.pdf
Internet-Draft Requirements for the graceful shutdown of BGP sessions 10.3.2. Cold potato (BGP local preference)
10. Acknowledgments Ingress router selects the nominal egress ASBR based on the BGP
local LOCAL_PREF value set and advertised by the exit point.
Authors would like to thank Nicolas Dubois, Benoit Fondeviole, 10.3.3. Cold potato (BGP preference set on ingress)
Christian Jacquenet, Olivier Bonaventure, Steve Uhlig, Xavier
Vinet, Vincent Gillet, Jean-Louis le Roux, Pierre Alain Coste and
Ronald Bonica for the useful discussions on this subject, their
review and comments.
This draft has been partly sponsored by the European project IST Ingress router selects the nominal egress ASBR based on
AGAVE. preconfigured policy information. (Typically by locally setting
the BGP local pref based on the BGP communities attached on the
routes).
As per [RFC4271], note that if tunnels are not used to forward
packets between ingress and egress ASBR, this can lead to
persistent forwarding loops.
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
skipping to change at page 17, line 45 skipping to change at page 19, line 5
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
Internet-Draft Requirements for the graceful shutdown of BGP sessions
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
Internet-Draft Requirements for the graceful shutdown of BGP sessions
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
 End of changes. 75 change blocks. 
357 lines changed or deleted 400 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/