RFC 7196

Making Route Flap Damping Usable

📅 published May 2014, from ietf

RFC 7196: Making Route Flap Damping Usable 💖

Okay bestie, let's get into this one 🦋. It's RFC 7196, titled Making Route Flap Damping Usable, published in May 2014 as a Standards Track document. The authors are C. Pelsser, R. Bush (Internet Initiative Japan), K. Patel (Cisco Systems), P. Mohapatra (Sproute Networks), and O. Maennel (Loughborough University). It's part of the IETF stream, with ISSN 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🌸

Abstract

Route Flap Damping (RFD) was first proposed to reduce BGP churn in routers. Unfortunately, it turned out RFD was severely penalizing sites for being well connected, because topological richness amplifies the number of update messages exchanged 😭. Lots of operators just switched RFD off. Based on experimental measurements, this document suggests tweaking a few RFD algorithmic constants and limits to cut down the high risks with RFD ✨. The result is damping a non-trivial amount of long-term churn without punishing well-behaved prefixes during their normal convergence process 💅

Status of This Memo

This is an Internet Standards Track document 🎀

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). For more info on Internet Standards, check Section 2 of RFC 5741 📚

For the current status of this document, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc7196 🌈

Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. 🔒

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please read these carefully, bestie, because they spell out your rights and restrictions for this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Simplified BSD License 🫶

Table of Contents

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  1.1.  Suggested Reading . . . . . . . . . . . . . . . . . . . .   3
2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
3.  RFD Parameters  . . . . . . . . . . . . . . . . . . . . . . .   3
4.  Suppress Threshold versus Churn . . . . . . . . . . . . . . .   4
5.  Maximum Penalty . . . . . . . . . . . . . . . . . . . . . . .   4
6.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   5
7.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   5
9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
  9.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
  9.2.  Informative References  . . . . . . . . . . . . . . . . .   6

1. Introduction ✨

Route Flap Damping (RFD) was first proposed (see [RIPE178] and [RFC2439]) and then implemented to reduce BGP churn in routers. Unfortunately, RFD was found to severely penalize sites for being well connected, because topological richness amplifies the number of update messages exchanged, see [MAO2002]. Many operators then turned RFD off, see [RIPE378]. Based on the measurements in [PELSSER2011], [RIPE580] now says RFD is usable with some changes to the parameters 🍓. Based on those same measurements, this document recommends adjusting a few RFD algorithmic constants and limits. The result is damping a non-trivial amount of long-term churn without penalizing well-behaved prefixes' normal convergence process 💜

Very few prefixes are responsible for a huge chunk of the BGP messages a router receives, see [HUSTON2006] and [PELSSER2011]. For example, the measurements in [PELSSER2011] showed that only 3% of the prefixes caused 36% of the BGP messages at a router with real feeds from a Tier-1 provider and an Internet Exchange Point during a one-week experiment 👀. Only these very frequently flapping prefixes should be damped. The values recommended in Section 6 achieve this. So RFD can be enabled, and some churn gets reduced 🧚

The goal is to, with absolutely minimal change, ease the danger of current RFD implementations and use. It is not a panacea, and it's not a deep and thorough approach to flap reduction 🙈

1.1. Suggested Reading

It's assumed the reader understands BGP [RFC4271] and Route Flap Damping [RFC2439] 📖. This work is based on the measurements in the paper [PELSSER2011]. A survey of Japanese operators' use of RFD and their desires is reported in [RFD-SURVEY] 🎀

2. Requirements Language 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [RFC2119], but only when they appear in all upper case. They can also show up in lower or mixed case as regular English words, with no normative meaning ✨

3. RFD Parameters 🌸

The following RFD parameters are common to all implementations. Some can be tuned by the operator, and some can't. There is currently no consensus on a single set of default values 🤷‍♀️

+--------------------------+----------+-------+---------+
| Parameter                | Tunable? | Cisco | Juniper |
+--------------------------+----------+-------+---------+
| Withdrawal               | No       | 1,000 |   1,000 |
| Re-Advertisement         | No       |     0 |   1,000 |
| Attribute Change         | No       |   500 |     500 |
| Suppress Threshold       | Yes      | 2,000 |   3,000 |
| Half-Life (min.)         | Yes      |    15 |      15 |
| Reuse Threshold          | Yes      |   750 |     750 |
| Max Suppress Time (min.) | Yes      |    60 |      60 |
+--------------------------+----------+-------+---------+

Note: Values without units specified are dimensionless constants.

      Table 1: Default RFD Parameters of Juniper and Cisco

4. Suppress Threshold versus Churn 🔥

If you turn RFD back on with the values recommended in Section 6, churn goes down. Plus, with those values, prefixes going through normal convergence are generally not damped 🫶

[PELSSER2011] estimates that, with a suppress threshold of 6,000, the BGP update rate drops by 19% compared to running without RFD enabled. [PELSSER2011] also looks at how many prefixes got damped over a week, between September 29, 2010 and October 6, 2010. With this 6,000 suppress threshold, 90% fewer prefixes are damped compared to a 2,000 threshold. Translation: far fewer well-behaved prefixes get damped 🥹

Setting the suppress threshold to 12,000 leads to very few damped prefixes. In the experiments in [PELSSER2011], 0.22% of prefixes were damped with a threshold of 12,000, giving an average hourly update reduction of 11% compared to not using RFD 🌈

+---------------+-------------+--------------+----------------------+
|      Suppress |      Damped |   % of Table |    Update Rate (one- |
|     Threshold |    Prefixes |       Damped |           hour bins) |
+---------------+-------------+--------------+----------------------+
|         2,000 |      43,342 |       13.16% |               53.11% |
|         4,000 |      11,253 |        3.42% |               74.16% |
|         6,000 |       4,352 |        1.32% |               81.03% |
|         8,000 |       2,104 |        0.64% |               84.85% |
|        10,000 |       1,286 |        0.39% |               87.12% |
|        12,000 |         720 |        0.22% |               88.74% |
|        14,000 |         504 |        0.15% |               89.97% |
|        16,000 |         353 |        0.11% |               91.01% |
|        18,000 |         311 |        0.09% |               91.88% |
|        20,000 |         261 |        0.08% |               92.69% |
+---------------+-------------+--------------+----------------------+

Note: the current default Suppress Threshold (2,000) is overly agressive.

      Table 2: Damped Prefixes vs. Churn, from [PELSSER2011]

5. Maximum Penalty 🧮

It's important to get this one: the parameters in Table 1 and the implementation's sampling rate put an upper bound on the penalty value. We can call that the 'computed maximum penalty' 💭

On top of that, BGP implementations have an internal constant, which we'll call the 'maximum penalty'. The current computed penalty may not exceed it 🙅‍♀️

6. Recommendations 👑

Use of the following values is recommended:

  • Router Maximum Penalty: The internal constant for the maximum penalty value MUST be raised to at least 50,000.
  • Default Configurable Parameters: So existing operational configurations don't break, existing BGP implementations, including the examples in Table 1, SHOULD NOT change their default values.
  • Minimum Suppress Threshold: Operators who want damping that's much less destructive than the current damping, but still somewhat aggressive, SHOULD configure the Suppress Threshold to no less than 6,000.
  • Conservative Suppress Threshold: Conservative operators SHOULD configure the Suppress Threshold to no less than 12,000.
  • Calculate But Do Not Damp: Implementations MAY have a test mode where the operator can see the results of a particular configuration without actually damping any prefixes. This lets you fine-tune parameters without losing reachability 🧁

7. Security Considerations 🚨

It is well known that an attacker can generate false flapping to cause a victim's prefix(es) to be damped. This is a real threat, bestie, so take it seriously 😱

The recommendations only change parameters to more conservative values, so there should be no increase in risk. In fact, moving to more conservative values should slightly mitigate the false-flap attack 🛡️

8. Acknowledgments 🫶

Nate Kushman initiated this work some years ago. Ron Bonica, Seiichi Kawamura, and Erik Muller contributed useful suggestions 💜

9. References ✨

9.1. Normative References 📚

okay bestie, these are the must-reads 💅 the spec leans on them, so you need them to make sense of anything here 🎀

9.2. Informative References 🌈

these ones are extra reading, not required, but they're iconic for the backstory and the real-world receipts ✨

  • [HUSTON2006] Huston, G., "2005 - A BGP Year in Review", RIPE 52, 2006, http://meetings.ripe.net/ripe-52/presentations/ripe52-plenary-bgp-review.pdf. 💜
  • [RFD-SURVEY] Tsuchiya, S., Kawamura, S., Bush, R., and C. Pelsser, "Route Flap Damping Deployment Status Survey", Work in Progress, June 2012. 🔥
  • [RIPE178] Barber, T., Doran, S., Karrenberg, D., Panigl, C., and J. Schmitz, "RIPE Routing-WG Recommendation for Coordinated Route-flap Damping Parameters", RIPE 178, February 1998, http://www.ripe.net/ripe/docs/ripe-178. 🌸
  • [RIPE580] Bush, R., Pelsser, C., Kuhne, M., Maennel, O., Mohapatra, P., Patel, K., and R. Evans, "RIPE Routing Working Group Recommendation for Route Flap Damping", RIPE 580, January 2013, http://www.ripe.net/ripe/docs/ripe-580. 🦋

Authors' Addresses 🫶

the squad behind this one, with all their contact info exactly as written 💖

Cristel Pelsser
Internet Initiative Japan
Jinbocho Mitsui Buiding, 1-105
Kanda-Jinbocho, Chiyoda-ku, Tokyo  101-0051
JP

Phone: +81 3 5205 6464
EMail: cristel@iij.ad.jp
Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, Washington  98110
US

EMail: randy@psg.com
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134
US

EMail: keyupate@cisco.com
Pradosh Mohapatra
Sproute Networks
41529 Higgins Way
Fremont, CA  94539
US

EMail: mpradosh@yahoo.com
Olaf Maennel
Loughborough University
Department of Computer Science - N.2.03
Loughborough
UK

Phone: +44 115 714 0042
EMail: o@maennel.net
📦 where this page comes from