Multicast VPN State Damping
updates
- rfc-6514 — BGP Encodings and Procedures for Multicast in MPLS/BGP IP VPNs
Extracted elements (26)
Damping is achieved by delaying withdrawal (keeping routes advertised) rather than suppressing advertisement, because multicast traffic must continue flowing to active receivers; this is the opposite of BGP unicast damping where a route is withdrawn/suppressed. The term 'suppressed' from RFC 2439 is intentionally avoided.
Existing BGP route damping (RFC 2439) suppresses a damped route, but for multicast the desired behavior is to keep advertising a damped route (hold the state active) rather than withdraw it. This inversion makes standard BGP damping inapplicable directly, so new procedures adapted from its exponential-decay parameters are defined instead.
Rate-limiting PIM messages (RFC 4609) and exploiting existing PIM prune-override or IGMP/MLD timers were rejected as damping mechanisms because they impact service on the PE-CE link, require disabling explicit tracking, may be incompatible with fast-leave implementations, lack sufficient configurability, and cannot discriminate flows by dynamicity.
The exponential-decay parameter set from RFC 2439 and RFC 7196 is reused for multicast damping to help operators deploy the feature based on consistent configuration parameters and obtain predictable results without the drawbacks of rate-limiting or repurposing PIM/IGMP timers.
For P-tunnels implemented with P2MP RSVP-TE or ingress replication (root-initiated tunnels), no specific P-tunnel membership damping action is required as long as the Leaf A-D route activity itself is damped.
No figure-of-merit or damping state is created when PIM Prune or IGMP/MLD messages are received for non-existing (S,G) state; damping state is only created in conjunction with actual multicast routing state.
The procedures in Section 5.1 do not impact PIM refresh/expiration (Prune messages from S,G keep-alive timer expiry are not suppressed), the PIM Assert mechanism, Prune messages sent when the RPF neighbor changes, or Prune messages sent during RPT-to-SPT switching. These corner cases are explicitly exempted from damping.
A PE implementing MVPN damping procedures MUST damp Leaf A-D routes in the same manner as C-multicast routes, and MUST damp activity related to removing itself from a P-tunnel, to protect the provider network from excessive P-tunnel state changes.
A router implementing these procedures MUST apply RFC 7761 PIM procedures unchanged for downstream interface traffic forwarding, update the figure-of-merit following the exponential decay algorithm, increase the figure-of-merit by the increment-factor, and update the damping state accordingly on reception of updated multicast membership or routing information that changes the PIM downstream state machine.
An implementation MUST keep an explicit (S,G) state as long as damping is active on that (S,G); once the state expires and damping becomes inactive, the associated figure-of-merit and damping state are removed.
An implementation of RFC 6513 that uses PIM to carry C-multicast routing information MUST support the VRF PIM-SM damping technique (suppressing Prune(S,G) by not withdrawing the C-multicast BGP route) to be compliant with this specification.
An implementation of RFC 7117 (multicast in VPLS) MUST follow the P-tunnel state damping procedures described in Section 6.1 to be compliant with this specification.
At least one of the two damping approaches (PIM-based per Section 5.1 or BGP C-multicast route damping per Section 5.2) MUST be implemented; implementing the BGP approach is recommended so that damping can also be applied on Route Reflectors and ASBRs.
Complementing existing multicast state monitoring interfaces (e.g., MRIB) with information about active damping on corresponding states is RECOMMENDED, to enable operators to observe and troubleshoot damping activity.
In deployments where RRs and ASBRs cannot distinguish the cause of a C-multicast route withdrawal, it is RECOMMENDED not to enable multicast VPN route damping on RRs and ASBRs, as these devices cannot differentiate whether a withdrawal was due to a multicast hop change or ordinary state churn.
The implementation is REQUIRED to allow the operator to configure the *decay-half-life* in seconds rather than minutes, to accommodate the much faster timescales of multicast membership changes compared to unicast routing.
When damping becomes active and the received message has caused the upstream state machine to transition to NotJoined state, the upstream state machine for (S,G) MUST NOT be updated; instead it is held in Joined state and events that would cause a state update SHOULD be ignored until the reuse-threshold is reached, preventing PIM Prune messages from being sent.
When not all routers can drop traffic from the wrong PE, the withdrawal of a C-multicast route due to a change in the Upstream Multicast Hop or Upstream Multicast PE SHOULD NOT be damped. An implementation MUST either not damp these withdrawals by default and/or provide a configuration knob to disable damping of such withdrawals.
A *figure-of-merit* is associated with each (S,G) upstream state machine; it tracks recent activity via an exponential decay function and is initialized to zero at state creation. Damping becomes active when the figure-of-merit exceeds the *cutoff-threshold* and becomes inactive when it decays below the *reuse-threshold*.
Four configurable damping parameters are defined: *decay-half-life* (half-life of exponential decay), *cutoff-threshold* (figure-of-merit value above which damping activates), *reuse-threshold* (value below which damping deactivates), and *increment-factor* (amount added to figure-of-merit on each multicast state update event).
Proposed maximum configurable values are: decay-half-life=60s and cutoff-threshold=50000. More aggressive DoS protection can be achieved by increasing the increment-factor or decay-half-life, or by reducing the cutoff-threshold and/or reuse-threshold.
Recommended default parameter values are: increment-factor=1000, cutoff-threshold=3000, decay-half-life=10s, reuse-threshold=1500, and a maximum figure-of-merit cap of 20×increment-factor (20000). With these values, a state changing less than once per 6 seconds will never be damped; a state changing at maximum pace will remain damped for approximately 37 seconds after activity stops.
The damping procedures reduce control-plane load for routing state updates sent upstream but do not reduce load from downstream interfaces; protection against downstream churn (from customer-facing interfaces or adjacent-AS routers) requires enabling damping on those downstream neighbors or at network edges, and is complemented by per-router multicast state limits.
These procedures address averaged control-plane load but not instantaneous peaks; a burst of simultaneous Join/Prune events on many states can still cause a peak load before damping activates. Damping must be complemented by configuration limiting the number of multicast states createable via protocol interactions with receivers, neighboring ASes, or multicast CEs.
When damping is triggered and a Prune has been requested for a state, that state may remain active for some time, potentially preventing an otherwise acceptable new state from being created if the router's multicast state table is near its limit; operators should account for this interaction between damping and state limits.
The damping state for an (S,G) transitions from inactive to active when the recomputed figure-of-merit strictly exceeds the cutoff-threshold. When active, the upstream state machine is held in Joined state. The damping state transitions back to inactive when the figure-of-merit decays strictly below the reuse-threshold, at which point the upstream state machine is recomputed from downstream state machines.