draft-ietf-idr-rfd-usable-01.txt   draft-ietf-idr-rfd-usable-02.txt 
Network Working Group C. Pelsser Network Working Group C.P. Pelsser
Internet-Draft R. Bush Internet-Draft R.B. Bush
Intended status: Standards Track Internet Initiative Japan Intended status: Standards Track Internet Initiative Japan
Expires: June 20, 2013 K. Patel Expires: September 12, 2013 K.P. Patel
P. Mohapatra P.M. Mohapatra
Cisco Systems Cisco Systems
O. Maennel O.M. Maennel
Loughborough University Loughborough University
December 17, 2012 March 11, 2013
Making Route Flap Damping Usable Making Route Flap Damping Usable
draft-ietf-idr-rfd-usable-01 draft-ietf-idr-rfd-usable-02
Abstract Abstract
Route Flap Damping (RFD) was first proposed to reduce BGP churn in Route Flap Damping (RFD) was first proposed to reduce BGP churn in
routers. Unfortunately, RFD was found to severely penalize sites for routers. Unfortunately, RFD was found to severely penalize sites for
being well-connected because topological richness amplifies the being well-connected because topological richness amplifies the
number of update messages exchanged. Many operators have turned RFD number of update messages exchanged. Many operators have turned RFD
off. Based on experimental measurement, this document recommends off. Based on experimental measurement, this document recommends
adjusting a few RFD algorithmic constants and limits, to reduce the adjusting a few RFD algorithmic constants and limits, to reduce the
high risks with RFD, with the result being damping a non-trivial high risks with RFD, with the result being damping a non-trivial
amount of long term churn without penalizing well-behaved prefixes' amount of long term churn without penalizing well-behaved prefixes'
normal convergence process. normal convergence process.
Requirements Language Requirements Language
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" are to "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to
be interpreted as described in RFC 2119 [RFC2119] only when they be interpreted as described in RFC 2119 [RFC2119] only when they
appear in all upper case. They may also appear in lower or mixed appear in all upper case. They may also appear in lower or mixed
case as English words, without any normative meaning. case as English words, without normative meaning.
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 June 20, 2013. This Internet-Draft will expire on September 12, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2013 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.
Table of Contents Table of Contents
1. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . . 4 1. Suggested Reading . . . . . . . . . . . . . . . . . . . . . . 2
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
3. RFD Parameters . . . . . . . . . . . . . . . . . . . . . . . . 4 3. RFD Parameters . . . . . . . . . . . . . . . . . . . . . . . 3
4. Suppress Threshold Versus Churn . . . . . . . . . . . . . . . . 5 4. Suppress Threshold Versus Churn . . . . . . . . . . . . . . . 3
5. Maximum Penalty . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Maximum Penalty . . . . . . . . . . . . . . . . . . . . . . . 4
6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . . 6 6. Recommendations . . . . . . . . . . . . . . . . . . . . . . . 4
7. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
10.1. Normative References . . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 5
10.2. Informative References . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Suggested Reading 1. Suggested Reading
It is assumed that the reader understands BGP, [RFC4271] and Route It is assumed that the reader understands BGP, [RFC4271] and Route
Flap Damping, [RFC2439]. This work is based on the measurements in Flap Damping, [RFC2439]. This work is based on the measurements in
the paper [pelsser2011]. A survey of Japanese operators' use of RFD the paper [pelsser2011]. A survey of Japanese operators' use of RFD
and their desires is reported in and their desires is reported in
[I-D.shishio-grow-isp-rfd-implement-survey]. [I-D.shishio-grow-isp-rfd-implement-survey].
2. Introduction 2. Introduction
Route Flap Damping (RFD) was first proposed (see [ripe178] and Route Flap Damping (RFD) was first proposed (see [ripe178] and
[RFC2439]) and subsequently implemented to reduce BGP churn in [RFC2439]) and subsequently implemented to reduce BGP churn in
routers. Unfortunately, RFD was found to severely penalize sites for routers. Unfortunately, RFD was found to severely penalize sites for
being well-connected because topological richness amplifies the being well-connected because topological richness amplifies the
number of update messages exchanged, see [mao2002]. Subsequently, number of update messages exchanged, see [mao2002]. Subsequently,
many operators turned RFD off, see [ripe378]. Based on experimental many operators turned RFD off, see [ripe378]. Based on the
measurements of [pelsser2011], [ripe580] now recommends that RFD is
usable with some changes to the parameters. Based on the same
measurements, this document recommends adjusting a few RFD measurements, this document recommends adjusting a few RFD
algorithmic constants and limits, with the result being damping of a algorithmic constants and limits, with the result being damping of a
non-trivial amount of long term churn without penalizing well-behaved non-trivial amount of long term churn without penalizing well-behaved
prefixes' normal convergence process. prefixes' normal convergence process.
Very few prefixes are responsible for a large amount of the BGP Very few prefixes are responsible for a large amount of the BGP
messages received by a router, see [huston2006] and [pelsser2011]. messages received by a router, see [huston2006] and [pelsser2011].
For example, the measurements in [pelsser2011] showed that only 3% of For example, the measurements in [pelsser2011] showed that only 3% of
the prefixes were responsible for 36% percent of the BGP messages at the prefixes were responsible for 36% percent of the BGP messages at
a router with real feeds from a Tier-1 and an Internet Exchange Point a router with real feeds from a Tier-1 and an Internet Exchange Point
skipping to change at page 5, line 30 skipping to change at page 4, line 8
4. Suppress Threshold Versus Churn 4. Suppress Threshold Versus Churn
By turning RFD back on with the values recommended in Section 6 churn By turning RFD back on with the values recommended in Section 6 churn
is reduced. Moreover, with these values, prefixes going through is reduced. Moreover, with these values, prefixes going through
normal convergence are generally not damped. normal convergence are generally not damped.
[pelsser2011] estimates that, with a suppress threshold of 6,000, the [pelsser2011] estimates that, with a suppress threshold of 6,000, the
BGP update rate is reduced by 19% compared to a situation without RFD BGP update rate is reduced by 19% compared to a situation without RFD
enabled. With this 6,000 suppress threshold, 90% fewer prefixes are enabled. With this 6,000 suppress threshold, 90% fewer prefixes are
damped compared to use of a 2,000 threshold. I.e. far fewer well- damped compared to use of a 2,000 threshold. I.e. far fewer well-
behaved prefixes are damped. behaved prefixes are damped.
Setting the suppress threshold to 12,000 leads to very few damped Setting the suppress threshold to 12,000 leads to very few damped
prefixes (1.7% of the prefixes damped with a threshold of 2,000, in prefixes (1.7% of the prefixes damped with a threshold of 2,000, in
the experiments in [pelsser2011] yielding an average hourly update the experiments in [pelsser2011] yielding an average hourly update
reduction of 11% compared to not using RFD. reduction of 11% compared to not using RFD.
+---------------+--------------+-------------+----------------------+ +-----------------+-----------------+-------------+-----------------+
| Suppress | Damped | % of Table | Update Rate (one | | Suppress | Damped | % of Table | Update Rate |
| Threshold | Instances | Damped | hour bins) | | Threshold | Instances | Damped | (one hour bins) |
+---------------+--------------+-------------+----------------------+ +-----------------+-----------------+-------------+-----------------+
| 2,000 | 43342 | 13.16% | 53.11% | | 2,000 | 43342 | 13.16% | 53.11% |
| 4,000 | 11253 | 3.42% | 74.16% | | 4,000 | 11253 | 3.42% | 74.16% |
| 6,000 | 4352 | 1.32% | 81.03% | | 6,000 | 4352 | 1.32% | 81.03% |
| 8,000 | 2104 | 0.64% | 84.85% | | 8,000 | 2104 | 0.64% | 84.85% |
| 10,000 | 1286 | 0.39% | 87.12% | | 10,000 | 1286 | 0.39% | 87.12% |
| 12,000 | 720 | 0.22% | 88.74% | | 12,000 | 720 | 0.22% | 88.74% |
| 14,000 | 504 | 0.15% | 89.97% | | 14,000 | 504 | 0.15% | 89.97% |
| 16,000 | 353 | 0.11% | 91.01% | | 16,000 | 353 | 0.11% | 91.01% |
| 18,000 | 311 | 0.09% | 91.88% | | 18,000 | 311 | 0.09% | 91.88% |
| 20,000 | 261 | 0.08% | 92.69% | | 20,000 | 261 | 0.08% | 92.69% |
+---------------+--------------+-------------+----------------------+ +-----------------+-----------------+-------------+-----------------+
Damped Prefixes vs. Churn, from [pelsser2011]
Note overly-aggressive current default Suppress Threshold Damped Prefixes vs. Churn, from [pelsser2011]. Note overly-
aggressive current default Suppress Threshold
Table 2 Table 2
5. Maximum Penalty 5. Maximum Penalty
It is important to understand that the parameters shown in Table 1, It is important to understand that the parameters shown in Table 1,
and the implementation's sampling rate, impose an upper bound on the and the implementation's sampling rate, impose an upper bound on the
penalty value, which we can call the 'computed maximum penalty'. penalty value, which we can call the 'computed maximum penalty'.
In addition, BGP implementations have an internal constant which we In addition, BGP implementations have an internal constant which we
skipping to change at page 8, line 5 skipping to change at page 6, line 5
[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, March 1997.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998. Flap Damping", RFC 2439, November 1998.
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway
Protocol 4 (BGP-4)", RFC 4271, January 2006. Protocol 4 (BGP-4)", RFC 4271, January 2006.
[mao2002] Mao, Z. M., Govidan, R., Varghese, G., and Katz, R., [mao2002] Mao, Z. M., Govidan, R., Varghese, G., Katz, R., "Route
"Route Flap Damping Excacerbates Internet Routing Flap Damping Excacerbates Internet Routing Convergence",
Convergence", In Proceedings of SIGCOMM , August 2002, <ht In Proceedings of SIGCOMM , August 2002, <http://
tp://www.acm.org/sigcomm/sigcomm2002/papers/ www.acm.org/sigcomm/sigcomm2002/papers/
routedampening.pdf>. routedampening.pdf>.
[pelsser2011] [pelsser2011]
Pelsser, C., Maennel, O., Mohapatra, P., Bush, R., and Pelsser, C., Maennel, O., Mohapatra, P., Bush, R., Patel,
Patel, K., "Route Flap Damping Made Usable", Passive and K., "Route Flap Damping Made Usable", Passive and Active
Active Measurement (PAM), March 2011, Measurement (PAM), March 2011,
<http://pam2011.gatech.edu/papers/pam2011--Pelsser.pdf>. <http://pam2011.gatech.edu/papers/pam2011--Pelsser.pdf>.
[ripe378] Panigl, P. and Smith, P., "RIPE Routing Working Group [ripe378] Panigl, P. Smith, P., "RIPE Routing Working Group
Recommendations On Route-flap Damping", 2006, Recommendations On Route-flap Damping", 2006,
<http://www.ripe.net/ripe/docs/ripe-378>. <http://www.ripe.net/ripe/docs/ripe-378>.
10.2. Informative References 10.2. Informative References
[I-D.shishio-grow-isp-rfd-implement-survey] [I-D.shishio-grow-isp-rfd-implement-survey]
Tsuchiya, S., Kawamura, S., Bush, R., and C. Pelsser, Tsuchiya, S., Kawamura, S., Bush, R., and C. Pelsser,
"Route Flap Damping Deployment Status Survey", "Route Flap Damping Deployment Status Survey", draft-
draft-shishio-grow-isp-rfd-implement-survey-05 (work in shishio-grow-isp-rfd-implement-survey-05 (work in
progress), June 2012. progress), June 2012.
[huston2006] [huston2006]
Huston, G., "BGP Extreme Routing Noise", RIPE 52 , 2006, < Huston, G., "BGP Extreme Routing Noise", RIPE 52 , 2006,
http://meetings.ripe.net/ripe-52/presentations/ <http://meetings.ripe.net/ripe-52/presentations/ripe52
ripe52-plenary-bgp-review.pdf>. -plenary-bgp-review.pdf>.
[ripe178] Barber, T., Doran, S., Karrenberg, D., Panigl, C., and [ripe178] Barber, T., Doran, S., Karrenberg, D., Panigl, C.,
Schmitz, J., "RIPE Routing-WG Recommendation for Schmitz, J., "RIPE Routing-WG Recommendation for
Coordinated Route-flap Damping Parameters", 2001, Coordinated Route-flap Damping Parameters", 2001,
<http://www.ripe.net/ripe/docs/ripe-178>. <http://www.ripe.net/ripe/docs/ripe-178>.
Authors' Addresses [ripe580] Pelsser, C., Bush, R., Maennel, O., Patel, K., Mohapatra,
P., Kuhne, M., Evans, R., "RIPE Routing-WG Recommendation
for Route-flap Damping", 2013,
<http://www.ripe.net/ripe/docs/ripe-580>.
Authors' Addresses
Cristel Pelsser Cristel Pelsser
Internet Initiative Japan Internet Initiative Japan
Jinbocho Mitsui Buiding, 1-105 Jinbocho Mitsui Buiding, 1-105
Kanda-Jinbocho, Chiyoda-ku, Tokyo 101-0051 Kanda-Jinbocho, Chiyoda-ku, Tokyo 101-0051
JP JP
Phone: +81 3 5205 6464 Phone: +81 3 5205 6464
Email: cristel@iij.ad.jp Email: cristel@iij.ad.jp
Randy Bush Randy Bush
Internet Initiative Japan Internet Initiative Japan
5147 Crystal Springs 5147 Crystal Springs
Bainbridge Island, Washington 98110 Bainbridge Island, Washington 98110
US US
Phone: +1 206 780 0431 x1
Email: randy@psg.com Email: randy@psg.com
Keyur Patel Keyur Patel
Cisco Systems Cisco Systems
170 W. Tasman Drive 170 W. Tasman Drive
San Jose, CA 95134 San Jose, CA 95134
US US
Email: keyupate@cisco.com Email: keyupate@cisco.com
 End of changes. 24 change blocks. 
60 lines changed or deleted 65 lines changed or added

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