RFC 7899

Multicast VPN State Damping

📅 published June 2016, from ietf

RFC 7899: Multicast VPN State Damping 🦋

Okay bestie, here's the title block tea ☕💖 This one came from the IETF (Internet Engineering Task Force), and T. Morin, Ed. is the editor. The other authors are S. Litkowski (Orange), K. Patel (Cisco Systems), Z. Zhang, R. Kebler, and J. Haas (Juniper Networks). It's dated June 2016, it's on the Standards Track 📋, its ISSN is 2070-1721, and it updates RFC 6514 (Updates: 6514) 🔥. That update matters, because this doc is basically adding detail to something 6514 already asked for. ✨

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). If you want more info on Internet Standards, check out Section 2 of RFC 7841 🌸

For the current status, any errata, and how to give feedback on this doc, go to http://www.rfc-editor.org/info/rfc7899. 💅

Copyright (c) 2016 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) as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜 Code Components pulled out of this document have to include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, just like the Simplified BSD License says 🫶

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Existing Mechanisms . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Rate-Limiting Multicast Control Traffic . . . . . . . . .   5
     4.2.  Existing PIM, IGMP, and MLD Timers  . . . . . . . . . . .   6
     4.3.  BGP Route Damping . . . . . . . . . . . . . . . . . . . .   6
   5.  Procedures for Multicast State Damping  . . . . . . . . . . .   7
     5.1.  PIM Procedures  . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Procedures for Multicast VPN State Damping  . . . . . . .  10
   6.  Procedures for P-Tunnel State Damping . . . . . . . . . . . .  12
     6.1.  Damping MVPN P-Tunnel Change Events . . . . . . . . . . .  12
     6.2.  Procedures for Ethernet VPNs  . . . . . . . . . . . . . .  13
   7.  Operational Considerations  . . . . . . . . . . . . . . . . .  13
     7.1.  Enabling Multicast Damping  . . . . . . . . . . . . . . .  13
     7.2.  Troubleshooting and Monitoring  . . . . . . . . . . . . .  13
     7.3.  Default and Maximum Values  . . . . . . . . . . . . . . .  13
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  15
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  16
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  16
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  17
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  18

Abstract

Okay so the abstract is the TL;DR 🧚 This doc explains how to damp Multicast VPN (MVPN) routing state changes, so the churn from multicast dynamicity at customer sites doesn't wreck things 💀 The goal is to stop control-plane load in the core routing infrastructure from climbing out of control. It's built for BGP-based multicast VPN, and the ideas are inspired by BGP unicast route damping, just adapted for multicast. It's giving careful engineering 💜

1. Introduction ✨

Let's set the scene 🎬 In a multicast VPN [RFC6513] running BGP-based procedures [RFC6514], receivers in VPN sites join and leave multicast groups or channels using membership control protocols: Internet Group Management Protocol (IGMP) [RFC3376] and Multicast Listener Discovery (MLD) [RFC3810]. The multicast routing protocols then adjust their routing states and P-multicast tree states so traffic gets forwarded to those receivers or pruned away from them 🌊 Similar challenges show up in the multicast specification for Virtual Private LAN Service (VPLS) [RFC7117], so this isn't a one-off situation 🫶

In VPN land, keeping customers isolated from each other on a shared infrastructure is a core requirement. That means the expectations around denial-of-service attack risk are seriously strict 🔒

Here's the thing about multicast: memberships change based on what multicast apps are doing on end hosts 📱 So membership changes can legitimately happen way more often than the usual churn you see in unicast routing state. Lowkey wild 😭

That's why there need to be mechanisms that keep the load on the BGP control plane, and on the P-tunnel setup control plane, under control. It doesn't matter how often end hosts make multicast membership changes, the load has to stay managed 🎀

This document describes procedures inspired by existing BGP route damping [RFC2439]. They give you a way to set an upper bound on how much processing the MVPN control-plane protocols do. Specifically, that's the BGP control plane in [RFC6514], the P-tunnel control-plane protocol in the context of [RFC6514], and the multicast specification for VPLS [RFC7117]. The goal of that upper bound runs alongside the goal of keeping the service intact (delivering the multicast stream as Customer Edge devices request it). The tradeoff is a minimal increase in average bandwidth use in the provider network 📈 The upper bound on control-plane load from processing a given multicast state is controlled indirectly, through configurable parameters ⚙️

Section 16 of [RFC6514] specifically calls out the need to damp the activity of C-multicast and Leaf Auto-discovery routes. It also outlines how to do that, by "delaying the advertisement of withdrawals of C-multicast routes". This specification gives more detail on how to implement that approach and how the operator gets control over it. That's why it updates [RFC6514] 💅

The base principle of this spec is in Section 3. Existing mechanisms that could be leaned on are covered in Section 4. Section 5 details the procedures this spec introduces 🦋

Section 6 gets into the specifics of damping MVPN P-tunnel state 🍓

Finally, Section 7 talks about operational considerations for the proposed mechanism 🌸

2. Terminology 📚

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Those are the official rules words, so read them carefully 🙈

This document reuses terminology from [RFC7761] and [RFC6514] 💜

Here's the vocab for this spec: damping of a multicast state is described as either "active" or "inactive" ✨ In [RFC2439], a unicast route that gets dampened is called "suppressed". This spec avoids that word, because the proposed solution is about holding a damped multicast state active instead 🧠

3. Overview 🌈

This is the big picture bestie 🖼️ The procedures here let the network operator configure multicast VPN PEs (Provider Edge routers) so they can delay the propagation of multicast state prune messages between PEs. That kicks in when the rate of multicast state dynamicity goes above a configurable threshold 📉 Assuming a receiver can only create a bounded number of multicast states, delaying prune propagation puts an upper bound on how often the router sends state updates to an upstream router. Very clean, very iconic 👑

From a downstream router's point of view, like a CE (Customer Edge router), nothing really changes 🫠 The multicast routing state changes it asks its PE for still get honored with no extra delay. Joins aren't affected by these procedures at all, and having the upstream router delay prune propagation toward its own upstream router doesn't change what traffic goes to the downstream router. So the bandwidth on the PE-CE link downstream of a PE that's using this damping isn't increased ✨

On the flip side, this approach raises average bandwidth utilization on a link upstream of a PE using the technique, like a PE-PE link. A given multicast flow stays forwarded for longer than it would with no damping at all 🌊 Even so, the technique is expected to protect the multicast routing infrastructure control plane without a big average bandwidth increase. For example, damping events happening more often than one event per X seconds can be handled without extending the time a multicast flow is present on a link by more than X seconds 🎯

Simulations of the exponential decay algorithm show that multicast state churn can be drastically reduced without significantly lengthening the time multicast traffic is forwarded 📊 So this technique protects the multicast routing infrastructure control plane efficiently, with no significant average bandwidth increase. The exception is a scenario with strict constraints on multicast bandwidth, where stretching out how long a multicast flow is forwarded would cause congestion 🚧

To be practical, a mechanism like this needs to be configurable. Specifically, there have to be ways to control when damping gets triggered, and to delay pruning a multicast state for a time that grows with that state's churn ⏳ That lets the operator pick their own tradeoff between minimizing dynamicity and reducing bandwidth consumption 💖

4. Existing Mechanisms 🔍

This section covers mechanisms that could address the issue but end up not being suitable or efficient enough 🙃

4.1. Rate-Limiting Multicast Control Traffic

The Protocol Independent Multicast - Sparse Mode (PIM-SM) specification [RFC7761] looks at multicast security threats, including the risk of denial-of-service attacks described in Section 1. A mechanism that rate-limits PIM messages is proposed in Section 5.3.3 of [RFC4609]. But it has two identified drawbacks: it impacts the service delivered, and it has side effects on legitimate users 😤

More in part 2, bestie! 🎀

4.2. Existing PIM, IGMP, and MLD Timers ✨

okay so in PIM multicast routing ([RFC7761]) there's a thing that can act like a kind of accidental de facto damping of multicast states, under some conditions 👀. When it's active, the prune override mechanism makes a PIM upstream router wait for a delay (the "prune override interval") before it acts on a PIM Prune message from a downstream neighbor 🦋.

This mechanism wasn't built for damping multicast state at all 🙈. It exists so PIM can work on multi-access networks (see Section 4.3.3 of [RFC7761]). Still, when it's active, a downstream router can't cause its upstream router to send its own upstream router multicast routing protocol messages for a given multicast state faster than 1/[JP_Override_Interval] (1/[JP_Override_Interval]). So yeah, it's a form of de facto damping 💅.

IGMP and MLD multicast membership control protocols can give a similar effect under the right conditions too 🌸.

Buuut these mechanisms aren't suitable for the goals in Section 1, and here's why 😭:

  • when they're enabled, they need extra bandwidth on the local link where the effect of a prune gets delayed (in our case, the PE-CE link);
  • when they're enabled, they require turning off explicit tracking (see Section 4.3.3 of [RFC7761]), even though that feature might be something you actually want 💀;
  • on certain implementations, they clash with behaviors that can't be turned off (for example, an implementation applying a fast-leave behavior on interfaces with only two neighbors);
  • they don't give you a suitable level of configurability; and
  • they don't have a way to tell multicast flows apart based on how dynamic they are.

4.3. BGP Route Damping 🌈

The procedures in [RFC2439] and [RFC7196] for BGP route flap damping are super useful for operators who want to control how much unicast route churn hits the routing infrastructure. They also give a standardized set of parameters for controlling damping 🧚.

BUT these procedures aren't directly relevant in a multicast context, for two reasons:

  • they aren't specified for multicast routing protocols in general, and
  • even where BGP routes carry multicast routing states (e.g., [RFC6514]), these procedures can't do what this document is going for 😤. The main reason is that a damped route gets suppressed, while the target behavior for multicast is to keep advertising when damping gets triggered on a multicast route.

Still, the standardized parameters that control the thresholds of the exponential decay mechanism can totally be reused ✨. That's the approach this document takes (Section 5). The reasons are to help operators deploy this feature with consistent configuration parameters, and to get predictable results without the drawbacks of relying on rate-limiting multicast control protocol exchanges (as explained in Section 4.1) or on existing PIM/IGMP timers (as explained in Section 4.2) 💖.

5. Procedures for Multicast State Damping 🔥

5.1. PIM Procedures 💜

This section lays out the procedures for multicast state damping that meet the goals in Section 1 🎀. It covers (S,G) states in the PIM-SM protocol ([RFC7761]). They apply unchanged to such states created from multicast group management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream interfaces. The same procedures also apply to (*,G) states for PIM-SM Any-Source Multicast (ASM) groups. Damping does not apply to (S,G,Rpt) Prune state, though 🙅‍♀️.

Some terms get borrowed from [RFC2439] here:

figure-of-merit: a number that estimates how active an (S,G) multicast routing state has been recently. It goes up on routing events related to this state and goes down between those events following an exponential decay function (see below). Whether damping turns on or off for the state depends on this number. It's associated with the upstream state machine for (S,G) and starts at zero when the state is created 📊.

exponential decay function: a mathematical function defined in Section 2.3 of [RFC2439], ignoring the first paragraph of that section since it doesn't apply here 🧮.

decay-half-life: how fast the exponential decay of the figure-of-merit happens. It's the amount of time it takes for the figure-of-merit to get cut in half when there's no routing event (this is a configurable parameter) ⏳.

cutoff-threshold: the figure-of-merit value above which damping gets applied (configurable parameter) 🚧.

reuse-threshold: the figure-of-merit value below which damping stops getting applied (configurable parameter) 🌷.

On top of those, there's a configurable increment-factor parameter that controls how much the figure-of-merit goes up on each multicast state update event 🍓.

Section 7.3 suggests default and maximum values for the configurable parameters 💅.

When a router gets updated multicast membership or routing information on a downstream interface I for a given (S,G) state, and that changes the state of the PIM downstream state machine (see Section 4.5.3 of [RFC7761]), a router implementing these procedures MUST:

  • apply the procedures of [RFC7761] unchanged for everything about what multicast traffic gets sent on downstream interfaces, including interface I
  • update the figure-of-merit following the exponential decay algorithm
  • increase the figure-of-merit for the (S,G) by the increment-factor
  • update the damping state for the (S,G) state: damping becomes active on the state if the recomputed figure-of-merit is strictly above the configured cutoff-threshold:
    • if damping stays inactive on the (S,G) state, update the upstream state machine as usual (per Section 4.5.7 of [RFC7761]).
    • if damping becomes active for the (S,G) state:
      • if the received message caused the upstream state machine to transition to Joined state, update the upstream state machine for (S,G) using the usual PIM procedures in Section 4.5.7 of [RFC7761], including sending a PIM Join to the upstream neighbor
      • if the received message caused the upstream state machine to transition to NotJoined state, do not update the upstream state machine for (S,G)
      • hold the upstream state machine in Joined state until the reuse threshold is reached. For updating this state machine, events that might change the state based on [RFC7761] SHOULD be ignored until the reuse-threshold is reached. So in the meantime, PIM Join messages can still be sent as refreshes to the upstream neighbor, but no PIM Prune message gets sent 🫶.
    • if damping was already active, do not update the upstream state machine for (S,G). It got frozen after processing the previous message 🧊.

Once the figure-of-merit for the (S,G) damping state decays to a value strictly below the configured reuse-threshold, the upstream state machine for (S,G) is recomputed from the states of the downstream state machines. That can end up with a PIM Join or Prune message going to the upstream neighbor 🦋.

Multicast apps are super specific, so it is REQUIRED for the implementation to let the operator configure the decay-half-life in seconds rather than in minutes ⏱️. Being able to do it in seconds is a must for these apps 😤.

This spec doesn't force one particular technique for updating the figure-of-merit during the exponential decay controlled by the configured decay-half-life 🧠. For example, you can use the same techniques described in [RFC2439]. The only real requirements are that the figure-of-merit gets updated before it gets increased, and that its decay below the reuse-threshold gets acted on in a timely way. Specifically, if the recomputation runs on a fixed time granularity, that granularity should be low enough that it doesn't noticeably delay turning damping off on a multicast state, beyond what the operator wanted. For example, with a decay-half-life of 10s, recomputing the figure-of-merit only once a minute would leave a multicast state damped way longer than configured 😭.

PIM implementations usually follow the suggestion in Section 4.1 of [RFC7761] 🧩:

implementations will only maintain state when it is relevant to forwarding operations - for example, the 'NoInfo' state might be assumed from the lack of other state information, rather than being held explicitly.

To implement the damping procedures properly, an implementation MUST keep an explicit (S,G) state for as long as damping is active on that (S,G) 🔒. Once an (S,G) state expires and damping becomes inactive on it, its associated figure-of-merit and damping state get removed too 🧹.

Also, these procedures:

  • don't affect PIM procedures for refreshing or expiring multicast routing states. PIM Prune messages triggered by the expiration of the (S,G) keep-alive timer aren't suppressed or delayed, and receiving Join messages that don't cause a state transition on the downstream interface doesn't increase the figure-of-merit 🌸;
  • don't affect the PIM Assert mechanism. In particular, PIM Prune messages triggered by a change of the PIM Assert winner on the upstream interface aren't suppressed or delayed 🙌;
  • don't affect PIM Prune messages sent when the RPF neighbor gets updated for a given multicast flow; and
  • don't affect PIM Prune messages sent when switching between a Rendezvous Point Tree and a Shortest Path Tree 🌳.

Finally, no action gets triggered by receiving PIM Prune messages (or corresponding IGMP/MLD messages) that relate to a non-existing (S,G) state. In particular, no figure-of-merit or damping state gets created in that case 🎀✨.

5.2. Procedures for Multicast VPN State Damping 🦋

okay so the stuff from Section 5.1 can be applied in the VRF PIM-SM implementation (the "C-PIM instance") 💅 and the matching move for suppressing a Prune(S,G) message is to not withdraw the C-multicast Source Tree Join (C-S,C-G) BGP route. bestie, an implementation of [RFC6513] that uses PIM to carry C-multicast routing info MUST support this technique to be compliant with this spec 📜

In the [RFC6514] world, where BGP carries the C-multicast routing info, there's an alternative to the Section 5.1 procedures. You apply damping in the BGP implementation using the existing BGP damping mechanisms on C-multicast Source Tree Join routes and Shared Tree Join routes (and on Leaf A-D routes too, see Section 6). You then tweak it to do the behavior from Section 3, following these guidelines:

  • not withdrawing (instead of not advertising) damped routes;
  • providing means to configure the decay-half-life in seconds if that option is not already available; and
  • using parameters for the exponential decay that are specific to multicast based on default values and multicast-specific configuration.

These would typically live on PE routers, but when BGP Route Reflectors (RRs) [RFC4456] are in the mix, it can be super useful to apply damping on RRs as well, for extra protection against activity created behind multiple PEs. ✨ For MVPN Inter-AS deployments, you might also need to protect one Autonomous System (AS) from the dynamicity of multicast VPN routing events coming from other ASes.

The choice between damping based on BGP routes and the procedures in Section 5.1 is up to the implementor, but at least one of the two MUST be implemented. If you want damping on RRs and Autonomous System Border Routers (ASBRs), going with the BGP approach is recommended. 🌸

When not all routers in a deployment can drop traffic coming from the wrong PE (as spelled out in Section 9.1.1 of [RFC6513]), the withdrawal of a C-multicast route caused by a change in the Upstream Multicast Hop or Upstream Multicast PE SHOULD NOT be damped. An implementation of this specification MUST do at least one of these two things:

  • not damp these withdrawals by default, and/or
  • provide a tuning knob to disable the damping of these withdrawals.

In that deployment context, it is RECOMMENDED not to enable any multicast VPN route damping on RRs and ASBRs, because these types of equipment cannot tell which event caused a C-multicast to be withdrawn. 🙈

Note well: it's out of scope for this section to consider these damping techniques on MVPN BGP routes other than C-multicast routes.

6. Procedures for P-Tunnel State Damping 🧚

6.1. Damping MVPN P-Tunnel Change Events

When selective P-tunnels are used (see Section 7 of [RFC6513]), updating the upstream state machine for a given (C-S,C-G) state on a PE connected to multicast receivers doesn't just generate activity to propagate C-multicast routing info to the source-connected PE. It can also possibly trigger changes related to the P-tunnels carrying (C-S,C-G) traffic. Protecting the provider network from an excessive amount of change in the state of P-tunnels is required, and this section details how to do it. 🔥

A PE implementing these procedures for MVPN MUST damp Leaf A-D routes in the same manner as it would for C-multicast routes (see Section 5.2).

A PE implementing these procedures for MVPN MUST damp the activity related to removing itself from a P-tunnel. The possible ways to do so depend on the type of P-tunnel, and local implementation details are left up to the implementor.

Here's an example of how the above can be achieved:

  • For P-tunnels implemented with the PIM protocol, apply the multicast state damping techniques described in Section 5.1 to the P-PIM instance, at least for (S,G) states corresponding to P-tunnels.
  • For P-tunnels implemented with multipoint LDP (mLDP), apply damping techniques completely similar to the one described in Section 5, but generalized to apply to mLDP states.
  • For root-initiated P-tunnels (P-tunnels implemented with the Point-to-Multipoint (P2MP) RSVP-TE, or relying on ingress replication), no particular action needs to be implemented to damp P-tunnels membership, if the activity of Leaf A-D route themselves is damped. 👑
  • Another possibility: base the decision to join or not join the P-tunnel to which a given (C-S,C-G) is bound, and to advertise or not advertise a Leaf A-D route related to (C-S,C-G), on whether a C-multicast Source Tree Join route is being advertised for (C-S,C-G), rather than on the state of the C-PIM Upstream state machine for (C-S,C-G). 🦋

6.2. Procedures for Ethernet VPNs

There are specifications that support or optimize multicast and broadcast in the context of Ethernet VPNs [RFC7117], relying on the use of Selective P-Multicast Service Interface (S-PMSI) and P-tunnels. For the same reasons as for IP multicast VPNs, an implementation of [RFC7117] MUST follow the procedures described in Section 6.1 to be compliant with this specification. 💖

7. Operational Considerations ⭐

7.1. Enabling Multicast Damping

In the context of multicast VPNs, these procedures would be enabled on PE routers. In the case of C-multicast routing based on BGP extensions ([RFC6514]), these procedures can also be enabled on ASBRs and RRs. 🌈

7.2. Troubleshooting and Monitoring

Implementing the damping mechanisms described in this document should be complemented by appropriate tools to observe and troubleshoot damping activity. 🛠️

Complementing the existing interface that provides info on multicast states with info on eventual damping of corresponding states (e.g., Multicast Routing Information Base (MRIB) states) is RECOMMENDED for C-multicast routing states and P-tunnel states. 🫶

7.3. Default and Maximum Values

Multicast streams get delivered unchanged to the end user no matter what values you pick for the configurable parameters, and the only trade-off is more bandwidth use. So the default and maximum values do not have to be perfectly tuned. 🙌

This section proposes default and maximum values that are conservative. That way they don't significantly impact network dimensioning, but they still stop multicast state churn from going beyond what counts as reasonably low churn for a multicast state. (See below for illustrations of the order of magnitude of the effect of these values.) 📊

The following values are RECOMMENDED to be adopted as default values:

  • increment-factor: 1000
  • cutoff-threshold: 3000
  • decay-half-life: 10s
  • reuse-threshold: 1500

For unicast damping, it's common to set an upper bound on how long a route is suppressed. In the case of multicast state damping, which relies on not withdrawing a damped route, it may be desirable to avoid a situation where a multicast flow keeps flowing in a portion of the network for a very long time when there are no receivers. 😭

The proposed default maximum value for the figure-of-merit is 20x increment-factor, i.e., 20000 with the proposed default increment-factor of 1000.

As illustrations, with these values:

  • a multicast state updated less frequently than once every 6 s will not be damped at all;
  • a multicast state changing once per second for 3 s, and then not changing, will not be damped;
  • a multicast state changing once per second for 4 s, and then not changing, will be damped after the fourth change for approximately 13 s;
  • a multicast state changing twice per second for 15 s, and then not changing, will be damped after the fourth change for approximately 50 s; and
  • a multicast state changing at a fast pace for a long time will reach the maximum of figure-of-merit; once the activity on this state stops, corresponding traffic may still flow in the network for approximately 37 s before dampening stops being active. 🍓

The following values are proposed as maximums:

  • decay-half-life: 60 s
  • cutoff-threshold: 50000

More aggressive protection against the risk of denial of service can be achieved by increasing the increment-factor or the decay-half-life, or by reducing the cutoff-threshold and/or reuse-threshold. 💜

8. Security Considerations 🔒

The procedures defined in this document do not introduce additional security issues beyond those already present in the contexts addressed. They actually aim at addressing some of the identified risks, without introducing as much denial-of-service risk as some of the mechanisms already defined. 🛡️

The protection provided relates to the control plane of the multicast routing protocols, including the components implementing the routing protocols and the components responsible for updating the multicast forwarding plane.

The procedures described are meant to provide some level of protection for the router on which they are enabled, by reducing the amount of routing state updates that it needs to send to its upstream neighbor or peers. They do not, however, provide any reduction of the control-plane load related to processing routing information from downstream neighbors. Protecting routers from an increase in control-plane load due to activity on downstream interfaces toward core routers (or, in the context of BGP-based MVPN C-multicast routing, BGP peers) relies on activating damping on the corresponding downstream neighbors (or BGP peers) and/or at the edge of the network. Protecting routers from an increase in control-plane load due to activity on customer-facing downstream interfaces, or on downstream interfaces to routers in another administrative domain, is out of the scope of this document and should use already defined mechanisms (see [RFC4609]). 😤

To be effective, the procedures described here must be complemented by configuration limiting the number of multicast states that can be created on a multicast router through protocol interactions with multicast receivers, neighbor routers in adjacent ASes, or, in multicast VPN contexts, with multicast CEs. Note well that the two mechanisms may interact: the state for which Prune has been requested may still remain taken into account for some time if damping has been triggered, and hence result in an otherwise acceptable new state from being successfully created. 💀

Additionally, it is worth noting that these procedures are not meant to protect against peaks of control-plane load. They only address averaged load. For instance, assuming a set of multicast states are submitted to the same Join/Prune events, damping can prevent more than a certain number of Join/Prune messages from being sent upstream in the period of time between the reception of the Join/Prune messages that trigger the activation of damping on these states and when damping becomes inactive after decay. ⏳

9. References 📚

9.1. Normative References

okay bestie, these are the docs the spec leans on the hardest 🧚 you need these to actually get it 💅

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route Flap Damping", RFC 2439, DOI 10.17487/RFC2439, November 1998, <http://www.rfc-editor.org/info/rfc2439>.

[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, DOI 10.17487/RFC3376, October 2002, <http://www.rfc-editor.org/info/rfc3376>.

[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.

[RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/BGP IP VPNs", RFC 6513, DOI 10.17487/RFC6513, February 2012, <http://www.rfc-editor.org/info/rfc6513>.

[RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012, <http://www.rfc-editor.org/info/rfc6514>.

[RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and C. Kodeboniya, "Multicast in Virtual Private LAN Service (VPLS)", RFC 7117, DOI 10.17487/RFC7117, February 2014, <http://www.rfc-editor.org/info/rfc7117>.

[RFC7196] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O. Maennel, "Making Route Flap Damping Usable", RFC 7196, DOI 10.17487/RFC7196, May 2014, <http://www.rfc-editor.org/info/rfc7196>.

[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 2016, <http://www.rfc-editor.org/info/rfc7761>.

9.2. Informative References

these ones are good background reading if you want the deeper lore 🦋

[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route Reflection: An Alternative to Full Mesh Internal BGP (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, <http://www.rfc-editor.org/info/rfc4456>.

[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol Independent Multicast - Sparse Mode (PIM-SM) Multicast Routing Security Issues and Enhancements", RFC 4609, DOI 10.17487/RFC4609, October 2006, <http://www.rfc-editor.org/info/rfc4609>.

Acknowledgements 🫶

big thank yous, obsessed with all of you 😭

okay so Bruno Decraene and Lenny Giuliano had discussions that really helped shape this proposal, so they get a huge shoutout 🌸 Yakov Rekhter and Eric Rosen reviewed it and left super helpful comments, iconic of them 👑 Wim Henderickx gave comments and backed this proposal, literally the best support 💜 and Martin Vigoureux, Gunter Van De Velde, and Alvaro Retana gave useful comments that helped finalize the document ✨

Authors' Addresses 💖

here's where you can find the authors, no cap 🎀

Thomas Morin (editor)
Orange
2, avenue Pierre Marzin
Lannion  22307
France

Email: thomas.morin@orange.com
Stephane Litkowski
Orange
France

Email: stephane.litkowski@orange.com
Keyur Patel
Cisco Systems
170 W. Tasman Drive
San Jose, CA  95134
United States of America

Email: keyupate@cisco.com
Zhaohui Zhang
Juniper Networks Inc.
10 Technology Park Drive
Westford, MA  01886
United States of America

Email: zzhang@juniper.net
Robert Kebler
Juniper Networks Inc.
10 Technology Park Drive
Westford, MA  01886
United States of America

Email: rkebler@juniper.net
Jeffrey Haas
Juniper Networks

Email: jhaas@juniper.net
📦 where this page comes from