draft-ietf-grow-bgp-gshut-06.txt   draft-ietf-grow-bgp-gshut-07.txt 
Network Working Group Pierre Francois Network Working Group Pierre Francois
Internet-Draft Institute IMDEA Networks Internet-Draft Individual Contributor
Intended status: Informational Bruno Decraene Intended status: Informational B. Decraene
Expires: February 15, 2015 Orange Expires: December 23, 2017 Orange
Cristel Pelsser C. Pelsser
Internet Initiative Japan Strasbourg University
Keyur Patel K. Patel
Clarence Filsfils Arrcus, Inc.
C. Filsfils
Cisco Systems Cisco Systems
August 14, 2014 June 21, 2017
Graceful BGP session shutdown Graceful BGP session shutdown
draft-ietf-grow-bgp-gshut-06 draft-ietf-grow-bgp-gshut-07
Abstract Abstract
This draft describes operational procedures aimed at reducing the This draft describes operational procedures aimed at reducing the
amount of traffic lost during planned maintenances of routers or amount of traffic lost during planned maintenances of routers or
links, involving the shutdown of BGP peering sessions. links, involving the shutdown of BGP peering sessions.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 15, 2015. This Internet-Draft will expire on December 23, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2017 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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Packet loss upon manual eBGP session shutdown . . . . . . . . 5 3. Packet loss upon manual eBGP session shutdown . . . . . . . . 3
4. Practices to avoid packet losses . . . . . . . . . . . . . . . 5 4. Practices to avoid packet losses . . . . . . . . . . . . . . 4
4.1. Improving availability of alternate paths . . . . . . . . 5 4.1. Improving availability of alternate paths . . . . . . . . 4
4.2. Make before break convergence: g-shut . . . . . . . . . . 6 4.2. Make before break convergence: g-shut . . . . . . . . . . 4
4.2.1. eBGP g-shut . . . . . . . . . . . . . . . . . . . . . 6
4.2.2. iBGP g-shut . . . . . . . . . . . . . . . . . . . . . 7
4.2.3. Router g-shut . . . . . . . . . . . . . . . . . . . . 7
5. Forwarding modes and transient forwarding loops during 5. Forwarding modes and transient forwarding loops during
convergence . . . . . . . . . . . . . . . . . . . . . . . . . 8 convergence . . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Link Up cases . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Link Up cases . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Unreachability local to the ASBR . . . . . . . . . . . . . 8 6.1. Unreachability local to the ASBR . . . . . . . . . . . . 7
6.2. iBGP convergence . . . . . . . . . . . . . . . . . . . . . 9 6.2. iBGP convergence . . . . . . . . . . . . . . . . . . . . 7
7. IANA assigned g-shut BGP community . . . . . . . . . . . . . . 9 7. IANA assigned g-shut BGP community . . . . . . . . . . . . . 8
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . . 11 11.1. Normative References . . . . . . . . . . . . . . . . . . 9
Appendix A. Alternative techniques with limited applicability . . 11 11.2. Informative References . . . . . . . . . . . . . . . . . 9
A.1. Multi Exit Discriminator tweaking . . . . . . . . . . . . 11 Appendix A. Alternative techniques with limited applicability . 10
A.2. IGP distance Poisoning . . . . . . . . . . . . . . . . . . 11 A.1. Multi Exit Discriminator tweaking . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 A.2. IGP distance Poisoning . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Routing changes in BGP can be caused by planned, maintenance Routing changes in BGP can be caused by planned, maintenance
operations. This document discusses operational procedures to be operations. This document discusses operational procedures to be
applied in order to reduce or eliminate losses of packets during the applied in order to reduce or eliminate losses of packets during the
maintenance. These losses come from the transient lack of maintenance. These losses come from the transient lack of
reachability during the BGP convergence following the shutdown of an reachability during the BGP convergence following the shutdown of an
eBGP peering session between two Autonomous System Border Routers eBGP peering session between two Autonomous System Border Routers
(ASBR). (ASBR).
skipping to change at page 4, line 29 skipping to change at page 3, line 11
The procedures described in this document can be applied to reduce or The procedures described in this document can be applied to reduce or
avoid packet loss for outbound and inbound traffic flows initially avoid packet loss for outbound and inbound traffic flows initially
forwarded along the peering link to be shut down. These procedures forwarded along the peering link to be shut down. These procedures
trigger, in both involved ASes, rerouting to the alternate path, trigger, in both involved ASes, rerouting to the alternate path,
while allowing routers to keep using old paths until alternate ones while allowing routers to keep using old paths until alternate ones
are learned, installed in the RIB and in the FIB. This ensures that are learned, installed in the RIB and in the FIB. This ensures that
routers always have a valid route available during the convergence routers always have a valid route available during the convergence
process. process.
The goal of the document is to meet the requirements described in The goal of the document is to meet the requirements described in
[REQS] at best, without changing the BGP protocol. [RFC6198] at best, without changing the BGP protocol.
Still, it explains why reserving a community value for the purpose of Still, it explains why reserving a community value for the purpose of
BGP session graceful shutdown would reduce the management overhead BGP session graceful shutdown would reduce the management overhead
bound with the solution. It would also allow vendors to provide an bound with the solution. It would also allow vendors to provide an
automatic graceful shutdown mechanism that does not require any automatic graceful shutdown mechanism that does not require any
router reconfiguration at maintenance time. router reconfiguration at maintenance time.
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].
skipping to change at page 5, line 37 skipping to change at page 4, line 21
4. Practices to avoid packet losses 4. Practices to avoid packet losses
This section describes means for an ISP to reduce the transient loss This section describes means for an ISP to reduce the transient loss
of packets upon a manual shutdown of a BGP session. of packets upon a manual shutdown of a BGP session.
4.1. Improving availability of alternate paths 4.1. Improving availability of alternate paths
All solutions that increase the availability of alternate BGP paths All solutions that increase the availability of alternate BGP paths
at routers performing packet lookups in BGP tables such as at routers performing packet lookups in BGP tables such as
[BestExternal] and [AddPath] help in reducing the LoC bound with [I-D.ietf-idr-best-external] and [RFC7911] help in reducing the LoC
manual shutdown of eBGP sessions. bound with manual shutdown of eBGP sessions.
One of such solutions increasing diversity in such a way that, at any One of such solutions increasing diversity in such a way that, at any
single step of the convergence process following the eBGP session single step of the convergence process following the eBGP session
shutdown, a BGP router does not receive a message withdrawing the shutdown, a BGP router does not receive a message withdrawing the
only path it currently knows for a given NLRI, allows for a only path it currently knows for a given NLRI, allows for a
simplified g-shut procedure. simplified g-shut procedure.
Note that the LoC for the inbound traffic of the maintained router, Note that the LoC for the inbound traffic of the maintained router,
induced by a lack of alternate path propagation within the iBGP induced by a lack of alternate path propagation within the iBGP
topology of a neighboring AS is not under the control of the operator topology of a neighboring AS is not under the control of the operator
performing the maintenance. The part of the procedure aimed at performing the maintenance. The part of the procedure aimed at
avoiding LoC for incoming paths can thus be applied even if no LoC avoiding LoC for incoming paths can thus be applied even if no LoC
are expected for the outgoing paths. are expected for the outgoing paths.
4.2. Make before break convergence: g-shut 4.2. Make before break convergence: g-shut
This section describes configurations and actions to be performed for This section describes configurations and actions to be performed for
the graceful shutdown of eBGP peering links. the graceful shutdown of eBGP sessions, iBGP sessions or a whole BGP
speaker.
The goal of this procedure is to let the paths being shutdown The goal of this procedure is to let, in both ASes, the paths being
visible, but with a lower LOCAL_PREF value, while alternate paths shutdown visible, but with a lower LOCAL_PREF value, while alternate
spread through the iBGP topology. Instead of withdrawing the path, paths spread through the iBGP topology. Instead of withdrawing the
routers of an AS will keep on using it until they become aware of path, routers of an AS will keep on using it until they become aware
alternate paths. of alternate paths.
4.2.1. eBGP g-shut 4.2.1. eBGP g-shut
This section describes configurations and actions to be performed for
the graceful shutdown of eBGP peering links.
4.2.1.1. Pre-configuration 4.2.1.1. Pre-configuration
On each ASBR supporting the g-shut procedure, an outbound BGP route On each ASBR supporting the g-shut procedure, an outbound BGP route
policy is applied on all iBGP sessions of the ASBR, that: policy is applied on all iBGP sessions of the ASBR, that:
o matches the g-shut community
o sets the LOCAL_PREF attribute of the paths tagged with the o matches the g-shut community
g-shut community to a low value
o removes the g-shut community from the paths. o sets the LOCAL_PREF attribute of the paths tagged with the g-shut
o optionally, adds an AS specific g-shut community on these paths community to a low value
to indicate that these are to be withdrawn soon. If some
ingress ASBRs reset the LOCAL_PREF attribute, this AS specific o removes the g-shut community from the paths.
g-shut community will be used to override other LOCAL_PREF
preference changes. o optionally, adds an AS specific g-shut community on these paths to
indicate that these are to be withdrawn soon. If some ingress
ASBRs reset the LOCAL_PREF attribute, this AS specific g-shut
community will be used to override other LOCAL_PREF preference
changes.
Note that in the case where an AS is aggregating multiple routes Note that in the case where an AS is aggregating multiple routes
under a covering prefix, it is recommended to filter out the g-shut under a covering prefix, it is recommended to filter out the g-shut
community from the resulting aggregate BGP route. By doing so, the community from the resulting aggregate BGP route. By doing so, the
setting of the g-shut community on one of the aggregated routes will setting of the g-shut community on one of the aggregated routes will
not let the entire aggregate inherit the community. Not doing so not let the entire aggregate inherit the community. Not doing so
would let the entire aggregate undergo the g-shut behavior. would let the entire aggregate undergo the g-shut behavior.
4.2.1.2. Operations at maintenance time 4.2.1.2. Operations at maintenance time
skipping to change at page 6, line 43 skipping to change at page 5, line 38
Note that in the case where an AS is aggregating multiple routes Note that in the case where an AS is aggregating multiple routes
under a covering prefix, it is recommended to filter out the g-shut under a covering prefix, it is recommended to filter out the g-shut
community from the resulting aggregate BGP route. By doing so, the community from the resulting aggregate BGP route. By doing so, the
setting of the g-shut community on one of the aggregated routes will setting of the g-shut community on one of the aggregated routes will
not let the entire aggregate inherit the community. Not doing so not let the entire aggregate inherit the community. Not doing so
would let the entire aggregate undergo the g-shut behavior. would let the entire aggregate undergo the g-shut behavior.
4.2.1.2. Operations at maintenance time 4.2.1.2. Operations at maintenance time
On the g-shut initiator, upon maintenance time, it is required to: On the g-shut initiator, upon maintenance time, it is required to:
o apply an outbound BGP route policy on the maintained eBGP session o apply an outbound BGP route policy on the maintained eBGP session
to tag the paths propagated over the session with the g-shut to tag the paths propagated over the session with the g-shut
community. This will trigger the BGP implementation to re- community. This will trigger the BGP implementation to re-
advertise all active routes previously advertised, and tag them advertise all active routes previously advertised, and tag them
with the g-shut community. with the g-shut community.
o apply an inbound BGP route policy on the maintained eBGP session o apply an inbound BGP route policy on the maintained eBGP session
to tag the paths received over the session with the g-shut to tag the paths received over the session with the g-shut
community. community.
o wait for convergence to happen. o wait for convergence to happen.
o perform a BGP session shutdown. o perform a BGP session shutdown.
4.2.1.3. BGP implementation support for G-Shut 4.2.1.3. BGP implementation support for g-Shut
A BGP router implementation MAY provide features aimed at automating A BGP router implementation MAY provide features aimed at automating
the application of the graceful shutdown procedures described above. the application of the graceful shutdown procedures described above.
Upon a session shutdown specified as graceful by the operator, a BGP Upon a session shutdown specified as graceful by the operator, a BGP
implementation supporting a g-shut feature SHOULD: implementation supporting a g-shut feature SHOULD:
1. On the eBGP side, update all the paths propagated over the 1. On the eBGP side, update all the paths propagated over the
corresponding eBGP session, tagging the GSHUT community to them. corresponding eBGP session, tagging the g-shut community to them.
Any subsequent update sent to the session being gracefully shut Any subsequent update sent to the session being gracefully shut
down would be tagged with the GSHUT community. down would be tagged with the g-shut community.
2. On the iBGP side, lower the LOCAL_PREF value of the paths
received over the eBGP session being shut down, upon their 2. On the iBGP side, lower the LOCAL_PREF value of the paths
propagation over iBGP sessions. Optionally, also tag these received over the eBGP session being shut down, upon their
paths with an AS specific g-shut community. Note that propagation over iBGP sessions. Optionally, also tag these paths
alternatively, the LOCAL_PREF of the paths received over the with an AS specific g-shut community.
eBGP session can be lowered on the g-shut initiator itself,
instead of only when propagating over its iBGP sessions. 3. Optionally shut down the session after a configured time.
3. Optionally shut down the session after a configured time.
4. Prevent the GSHUT community from being inherited by a path that 4. Prevent the g-shut community from being inherited by a path that
would aggregate some paths tagged with the GSHUT community. would aggregate some paths tagged with the GSHUT community. This
This behavior avoids the GSHUT procedure to be applied to the behavior avoids the GSHUT procedure to be applied to the
aggregate upon the graceful shutdown of one of its covered aggregate upon the graceful shutdown of one of its covered
prefixes. prefixes.
A BGP implementation supporting a g-shut feature SHOULD also A BGP implementation supporting a g-shut feature SHOULD also
automatically install the BGP policies that are supposed to be automatically install the BGP policies that are supposed to be
configured, as decribed in Section 4.2.1.1 for sessions over which configured, as described in Section 4.2.1.1 for sessions over which
g-shut is to be supported. g-shut is to be supported.
4.2.2. iBGP g-shut 4.2.2. iBGP g-shut
If the iBGP topology is viable after the maintenance of the session, For the shutdown of an iBGP session, provided the iBGP topology is
i.e, if all BGP speakers of the AS have an iBGP signaling path for viable after the maintenance of the session, i.e, if all BGP speakers
all prefixes advertised on this g-shut iBGP session, then the of the AS have an iBGP signaling path for all prefixes advertised on
shutdown of an iBGP session does not lead to transient this g-shut iBGP session, then the shutdown of an iBGP session does
unreachability. not lead to transient unreachability. As a consequence, no specific
g-shut action is required.
4.2.3. Router g-shut 4.2.3. Router g-shut
In the case of a shutdown of a router, a reconfiguration of the In the case of a shutdown of a router, a reconfiguration of the
outbound BGP route policies of the g-shut initiator SHOULD be outbound BGP route policies of the g-shut initiator SHOULD be
performed to set a low LOCAL_PREF value for the paths originated by performed to set a low LOCAL_PREF value for the paths originated by
the g-shut initiator (e.g, BGP aggregates redistributed from other the g-shut initiator (e.g, BGP aggregates redistributed from other
protocols, including static routes). protocols, including static routes).
This behavior is equivalent to the recommended behavior for paths This behavior is equivalent to the recommended behavior for paths
skipping to change at page 9, line 15 skipping to change at page 8, line 8
6.2. iBGP convergence 6.2. iBGP convergence
Corner cases leading to LoC can occur during an eBGP link up event. Corner cases leading to LoC can occur during an eBGP link up event.
A typical example for such transient unreachability for a given A typical example for such transient unreachability for a given
prefix is the following: prefix is the following:
Let's consider 3 route reflectors RR1, RR2, RR3. There is a full Let's consider 3 route reflectors RR1, RR2, RR3. There is a full
mesh of iBGP session between them. mesh of iBGP session between them.
1. RR1 is initially advertising the current best path to the 1. RR1 is initially advertising the current best path to the
members of its iBGP RR full-mesh. It propagated that path members of its iBGP RR full-mesh. It propagated that path within
within its RR full-mesh. RR2 knows only that path towards the its RR full-mesh. RR2 knows only that path toward the prefix.
prefix.
2. RR3 receives a new best path originated by the "g-no-shut"
initiator, being one of its RR clients. RR3 selects it as best,
and propagates an UPDATE within its RR full-mesh, i.e., to RR1
and RR2.
3. RR1 receives that path, reruns its decision process, and
picks this new path as best. As a result, RR1 withdraws its
previously announced best-path on the iBGP sessions of its RR
full-mesh.
4. If, for any reason, RR3 processes the withdraw generated in
step 3, before processing the update generated in step 2, RR3
transiently suffers from unreachability for the affected prefix.
The use of [BestExternal] among the RR of the iBGP full-mesh can 2. RR3 receives a new best path originated by the "g-no-shut"
solve these corner cases by ensuring that within an AS, the initiator, being one of its RR clients. RR3 selects it as best,
advertisement of a new route is not translated into the withdraw of a and propagates an UPDATE within its RR full-mesh, i.e., to RR1 and
former route. RR2.
3. RR1 receives that path, reruns its decision process, and picks
this new path as best. As a result, RR1 withdraws its previously
announced best-path on the iBGP sessions of its RR full-mesh.
4. If, for any reason, RR3 processes the withdraw generated in
step 3, before processing the update generated in step 2, RR3
transiently suffers from unreachability for the affected prefix.
The use of [I-D.ietf-idr-best-external] among the RR of the iBGP
full-mesh can solve these corner cases by ensuring that within an AS,
the advertisement of a new route is not translated into the withdraw
of a former route.
Indeed, "best-external" ensures that an ASBR does not withdraw a Indeed, "best-external" ensures that an ASBR does not withdraw a
previously advertised (eBGP) path when it receives an additional, previously advertised (eBGP) path when it receives an additional,
preferred path over an iBGP session. Also, "best-intra-cluster" preferred path over an iBGP session. Also, "best-intra-cluster"
ensures that a RR does not withdraw a previously advertised (iBGP) ensures that a RR does not withdraw a previously advertised (iBGP)
path to its non clients (e.g. other RRs in a mesh of RR) when it path to its non clients (e.g. other RRs in a mesh of RR) when it
receives a new, preferred path over an iBGP session. receives a new, preferred path over an iBGP session.
7. IANA assigned g-shut BGP community 7. IANA assigned g-shut BGP community
Applying the g-shut procedure is rendered much easier with the use of Applying the g-shut procedure is rendered much easier with the use of
a single g-shut community value which could be used on all eBGP a single g-shut BGP community value [RFC1997] which could be used on
sessions, for both inbound and outbound signaling. The community all eBGP sessions, for both inbound and outbound signaling. The
value 0xFFFF0000 has been assigned by IANA for this purpose. community value 0xFFFF0000 has been assigned by IANA for this
purpose.
For Internet routes, a non transitive extended community will be 8. IANA Considerations
reserved from the pool defined in [EXT_POOL]. Using such a community
type allows for not leaking graceful signaling out of the AS
boundaries, without the need to explicitly configure filters to strip
the community off upon path propagation.
8. Security Considerations This document has no actions for IANA.
9. Security Considerations
By providing the g-shut service to a neighboring AS, an ISP provides By providing the g-shut service to a neighboring AS, an ISP provides
means to this neighbor to lower the LOCAL_PREF value assigned to the means to this neighbor and possibly its downstream ASes to lower the
paths received from this neighbor. LOCAL_PREF value assigned to the paths received from this neighbor.
The neighbor could abuse the technique and do inbound traffic The neighbor could abuse the technique and do inbound traffic
engineering by declaring some prefixes as undergoing a maintenance so engineering by declaring some prefixes as undergoing a maintenance so
as to switch traffic to another peering link. as to switch traffic to another peering link.
If this behavior is not tolerated by the ISP, it SHOULD monitor the If this behavior is not tolerated by the ISP, it SHOULD monitor the
use of the g-shut community by this neighbor. use of the g-shut community by this neighbor.
ASes using the regular (transitive) g-shut community SHOULD remove 10. Acknowledgments
the community from neighboring ASes that do not support the g-shut
procedure. Doing so prevents malignant remote ASes from using the
community through intermediate ASes that do not support the feature,
in order to perform inbound traffic engineering. ASes using the non-
transitive extended community do not need to do this as the community
is non transitive and hence cannot be used by remote ASes.
9. Acknowledgments
The authors wish to thank Olivier Bonaventure and Pradosh Mohapatra
for their useful comments on this work.
10. References
10.1. Normative References
[REQS] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z., The authors wish to thank Olivier Bonaventure, Pradosh Mohapatra and
Armengol, A., and T. Takeda, "Requirements for the Job Snijders for their useful comments on this work.
graceful shutdown of BGP sessions", RFC 6198.
[EXT_POOL] 11. References
Decraene, B. and P. Francois, "Assigned BGP extended
communities",
draft-ietf-idr-reserved-extended-communities-06.
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended 11.1. Normative References
Communities Attribute", RFC 4360, February 2006.
[BGPWKC] "http://www.iana.org/assignments/ [RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
bgp-well-known-communities". Attribute", RFC 1997, DOI 10.17487/RFC1997, August 1996,
<http://www.rfc-editor.org/info/rfc1997>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
10.2. Informative References [RFC6198] Decraene, B., Francois, P., Pelsser, C., Ahmad, Z.,
Elizondo Armengol, A., and T. Takeda, "Requirements for
the Graceful Shutdown of BGP Sessions", RFC 6198,
DOI 10.17487/RFC6198, April 2011,
<http://www.rfc-editor.org/info/rfc6198>.
[AddPath] D. Walton, E. Chen, A. Retana, and J. Scudder, 11.2. Informative References
"Advertisement of Multiple Paths in BGP",
draft-ietf-idr-add-paths-09.txt (work in progress).
[BestExternal] [I-D.ietf-idr-best-external]
Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H. Marques, P., Fernando, R., Chen, E., Mohapatra, P., and H.
Gredler, "Advertisement of the best-external route to Gredler, "Advertisement of the best external route in
IBGP", draft-ietf-idr-best-external-05.txt. BGP", draft-ietf-idr-best-external-05 (work in progress),
January 2012.
[RFC7911] Walton, D., Retana, A., Chen, E., and J. Scudder,
"Advertisement of Multiple Paths in BGP", RFC 7911,
DOI 10.17487/RFC7911, July 2016,
<http://www.rfc-editor.org/info/rfc7911>.
Appendix A. Alternative techniques with limited applicability Appendix A. Alternative techniques with limited applicability
A few alternative techniques have been considered to provide g-shut A few alternative techniques have been considered to provide g-shut
capabilities but have been rejected due to their limited capabilities but have been rejected due to their limited
applicability. This section describe them for possible reference. applicability. This section describe them for possible reference.
A.1. Multi Exit Discriminator tweaking A.1. Multi Exit Discriminator tweaking
The MED attribute of the paths to be avoided can be increased so as The MED attribute of the paths to be avoided can be increased so as
skipping to change at page 12, line 8 skipping to change at page 10, line 43
alternates are as good as the old paths with respect to their Local- alternates are as good as the old paths with respect to their Local-
Pref value, their AS Path length, and their MED value. Pref value, their AS Path length, and their MED value.
Also, this poisoning cannot be applied when nexthop self is used as Also, this poisoning cannot be applied when nexthop self is used as
there is no nexthop specific to the maintained session to poison in there is no nexthop specific to the maintained session to poison in
the IGP. the IGP.
Authors' Addresses Authors' Addresses
Pierre Francois Pierre Francois
Institute IMDEA Networks Individual Contributor
Avda. del Mar Mediterraneo, 22
Leganese 28918
ES
Email: pierre.francois@imdea.org Email: pfrpfr@gmail.com
Bruno Decraene Bruno Decraene
Orange Orange
38-40 rue du General Leclerc
92794 Issy Moulineaux cedex 9
FR
Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com
Cristel Pelsser Cristel Pelsser
Internet Initiative Japan Strasbourg University
Jinbocho Mitsui Bldg.
1-105 Kanda Jinbo-cho
Tokyo 101-0051
JP
Email: cristel@iij.ad.jp Email: pelsser@unistra.fr
Keyur Patel Keyur Patel
Cisco Systems Arrcus, Inc.
170 West Tasman Dr
San Jose, CA 95134
US
Email: keyupate@cisco.com Email: keyur@arrcus.com
Clarence Filsfils Clarence Filsfils
Cisco Systems Cisco Systems
De kleetlaan 6a
Diegem 1831
BE
Email: cfilsfil@cisco.com Email: cfilsfil@cisco.com
 End of changes. 47 change blocks. 
177 lines changed or deleted 150 lines changed or added

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