draft-ietf-bess-multicast-damping-06.txt   rfc7899.txt 
Network Working Group T. Morin, Ed. Internet Engineering Task Force (IETF) T. Morin, Ed.
Internet-Draft S. Litkowski Request for Comments: 7899 S. Litkowski
Updates: 6514 (if approved) Orange Updates: 6514 Orange
Intended status: Standards Track K. Patel Category: Standards Track K. Patel
Expires: November 10, 2016 Cisco Systems ISSN: 2070-1721 Cisco Systems
Z. Zhang Z. Zhang
R. Kebler R. Kebler
J. Haas J. Haas
Juniper Networks Juniper Networks
May 09, 2016 June 2016
Multicast VPN state damping Multicast VPN State Damping
draft-ietf-bess-multicast-damping-06
Abstract Abstract
This document describes procedures to damp multicast VPN routing This document describes procedures to damp Multicast VPN (MVPN)
state changes and control the effect of the churn due to the routing state changes and control the effect of the churn due to the
multicast dynamicity in customer sites. The procedures described in multicast dynamicity in customer sites. The procedures described in
this document are applicable to BGP-based multicast VPN and help this document are applicable to BGP-based multicast VPN and help
avoid uncontrolled control plane load increase in the core routing avoid uncontrolled control-plane load increase in the core routing
infrastructure. New procedures are proposed inspired from BGP infrastructure. The new procedures proposed were inspired by BGP
unicast route damping principles, but adapted to multicast. unicast route damping principles that have been adapted to multicast.
Requirements Language
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].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on November 10, 2016. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7899.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Existing mechanisms . . . . . . . . . . . . . . . . . . . . . 5 4. Existing Mechanisms . . . . . . . . . . . . . . . . . . . . . 5
4.1. Rate-limiting of multicast control traffic . . . . . . . 5 4.1. Rate-Limiting Multicast Control Traffic . . . . . . . . . 5
4.2. Existing PIM, IGMP and MLD timers . . . . . . . . . . . . 5 4.2. Existing PIM, IGMP, and MLD Timers . . . . . . . . . . . 6
4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 6 4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 6
5. Procedures for multicast state damping . . . . . . . . . . . 7 5. Procedures for Multicast State Damping . . . . . . . . . . . 7
5.1. PIM procedures . . . . . . . . . . . . . . . . . . . . . 7 5.1. PIM Procedures . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures for multicast VPN state damping . . . . . . . 10 5.2. Procedures for Multicast VPN State Damping . . . . . . . 10
6. Procedures for P-tunnel state damping . . . . . . . . . . . . 11 6. Procedures for P-Tunnel State Damping . . . . . . . . . . . . 12
6.1. Damping mVPN P-tunnel change events . . . . . . . . . . . 11 6.1. Damping MVPN P-Tunnel Change Events . . . . . . . . . . . 12
6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 12 6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 13
7. Operational considerations . . . . . . . . . . . . . . . . . 12 7. Operational Considerations . . . . . . . . . . . . . . . . . 13
7.1. Enabling multicast damping . . . . . . . . . . . . . . . 12 7.1. Enabling Multicast Damping . . . . . . . . . . . . . . . 13
7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 12 7.2. Troubleshooting and Monitoring . . . . . . . . . . . . . 13
7.3. Default and maximum values . . . . . . . . . . . . . . . 13 7.3. Default and Maximum Values . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15
9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 16
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.2. Informative References . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 15 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
11.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
In a multicast VPN [RFC6513] deployed with BGP-based procedures In a multicast VPN [RFC6513] deployed with BGP-based procedures
[RFC6514], when receivers in VPN sites join and leave a given [RFC6514], when receivers in VPN sites join and leave a given
multicast group or channel through multicast membership control multicast group or channel through multicast membership control
protocols (IGMP [RFC3376], MLD[RFC3810]), multicast routing protocols protocols (Internet Group Management Protocol (IGMP) [RFC3376] and
accordingly adjust multicast routing states and P-multicast tree Multicast Listener Discovery (MLD) [RFC3810]), multicast routing
states, to forward or prune multicast traffic to these receivers. protocols accordingly adjust multicast routing states and P-multicast
Similar challenges arise in the context of multicast specification tree states to forward or prune multicast traffic to these receivers.
for VPLS [RFC7117]. Similar challenges arise in the context of the multicast
specification for Virtual Private LAN Service (VPLS) [RFC7117].
In VPN contexts, providing isolation between customers of a shared In VPN contexts, providing isolation between customers of a shared
infrastructure is a core requirement resulting in stringent infrastructure is a core requirement resulting in stringent
expectations with regards to risks of denial of service attacks. expectations with regard to risks of denial-of-service attacks.
By nature multicast memberships change based on the behavior of By nature, multicast memberships change based on the behavior of
multicast applications running on end hosts, hence the frequency of multicast applications running on end hosts. Hence, the frequency of
membership changes can legitimately be much higher than the typical membership changes can legitimately be much higher than the typical
churn of unicast routing states. churn of unicast routing states.
Hence, mechanisms need to be put in place to ensure that the load put Therefore, mechanisms need to be put in place to ensure that the load
on the BGP control plane, and on the P-tunnel setup control plane, put on the BGP control plane, and on the P-tunnel setup control
remains under control regardless of the frequency at which multicast plane, remains under control regardless of the frequency at which
memberships changes are made by end hosts. multicast membership changes are made by end hosts.
This document describes procedures, inspired from existing BGP route This document describes procedures inspired by existing BGP route
damping [RFC2439], aimed at offering means to set an upper bound to damping [RFC2439] that are aimed at offering means to set an upper
the amount of processing for the mVPN control plane protocols, more bound to the amount of processing for the MVPN control-plane
precisely the BGP control plane in [RFC6514], and the P-tunnel protocols: more precisely, the BGP control plane in [RFC6514], the
control plane protocol in the contexts of [RFC6514] and multicast P-tunnel control-plane protocol in the contexts of [RFC6514], and the
specification for VPLS [RFC7117]. This aims to be achieved while at multicast specification for VPLS [RFC7117]. The goal of setting this
the same time preserving the service provided (delivering the upper bound is pursued simultaneous with the goal of preserving the
multicast stream as requested by Customer Edge devices), although at service provided (delivering the multicast stream as requested by
the expense of a minimal increase of average bandwidth use in the Customer Edge devices), although at the expense of a minimal increase
provider network. The upper bound to the control plane load due to of average bandwidth use in the provider network). The upper bound
the processing of a given multicast state, is controlled indirectly to the control-plane load due to the processing of a given multicast
via configurable parameters. state is controlled indirectly via configurable parameters.
Section 16 of [RFC6514] specifically spells out the need for damping Section 16 of [RFC6514] specifically spells out the need for damping
the activity of C-multicast and Leaf Auto-discovery routes, and the activity of C-multicast and Leaf Auto-discovery routes and
outlines how to do it by "delaying the advertisement of withdrawals outlines how to do it by "delaying the advertisement of withdrawals
of C-multicast routes". This specification provides appropriate of C-multicast routes". This specification provides appropriate
detail on how to implement this approach and how to provide control detail on how to implement this approach and how to provide control
to the operator, and for this reason, is an update to [RFC6514]. to the operator; for this reason, it is an update to [RFC6514].
The base principle of this specification is described in Section 3. The base principle of this specification is described in Section 3.
Existing mechanisms that could be relied upon are discussed in Existing mechanisms that could be relied upon are discussed in
Section 4. Section 5 details the procedures introduced by this Section 4. Section 5 details the procedures introduced by this
specification. specification.
Section 6 provides specific details related to the damping of Section 6 provides specific details related to the damping of
multicast VPNs P-tunnel state. multicast VPNs P-tunnel state.
Finally, Section 7 discusses operational considerations related to Finally, Section 7 discusses operational considerations related to
the proposed mechanism. the proposed mechanism.
2. Terminology 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].
This document reuses terminology from [RFC7761] and [RFC6514]. This document reuses terminology from [RFC7761] and [RFC6514].
In this specification, damping of a multicast state will be said to In this specification, damping of a multicast state will be said to
be "active" or "inactive". Note that in [RFC2439], the term used for be "active" or "inactive". Note that in [RFC2439], the term used for
a unicast route which is dampened is "suppressed", but we will avoid a unicast route that is dampened is "suppressed", but we will avoid
this term in this specification given that the proposed solution this term in this specification given that the proposed solution
consist in holding active a damped multicast state. consists in holding active a damped multicast state.
3. Overview 3. Overview
The procedures described in this document allow the network operator The procedures described in this document allow the network operator
to configure multicast VPN PEs (Provider Edge routers) so that they to configure multicast VPN PEs (Provider Edge routers) so that they
can delay the propagation of multicast state prune messages between can delay the propagation of multicast state prune messages between
PEs, when faced with a rate of multicast state dynamicity exceeding a PEs when faced with a rate of multicast state dynamicity exceeding a
certain configurable threshold. Assuming that the number of certain configurable threshold. Assuming that the number of
multicast states that can be created by a receiver is bounded, multicast states that can be created by a receiver is bounded,
delaying the propagation of multicast state pruning results in delaying the propagation of multicast state pruning results in
setting up an upper bound to the average frequency at which the setting up an upper bound to the average frequency at which the
router will send state updates to an upstream router. router will send state updates to an upstream router.
From the point of view of a downstream router, such as a CE (Customer From the point of view of a downstream router, such as a CE (Customer
Edge router), this approach has no impact: the multicast routing Edge router), this approach has no impact: the multicast routing
states changes that it solicits to its PE will be honored without any state changes that it solicits to its PE will be honored without any
additional delay. Indeed the propagation of joins is not impacted by additional delay. Indeed, the propagation of Joins is not impacted
the procedures specified here, and having the upstream router delay by the procedures specified here, and having the upstream router
state prune propagation to its own upstream router does not affect delay state prune propagation to its own upstream router does not
what traffic is sent to the downstream router. In particular, the affect what traffic is sent to the downstream router. In particular,
amount of bandwidth used on the PE-CE link downstream to a PE the amount of bandwidth used on the PE-CE link downstream to a PE
applying this damping technique is not increased. applying this damping technique is not increased.
This approach increases the average bandwidth utilization on a link This approach increases the average bandwidth utilization on a link
upstream to a PE applying this technique, such as a PE-PE link: upstream to a PE applying this technique, such as a PE-PE link:
indeed, a given multicast flow will be forwarded for a longer time indeed, a given multicast flow will be forwarded for a longer time
than if no damping was applied. That said, it is expected that this than if no damping was applied. That said, it is expected that this
technique will meet the goals of protecting the multicast routing technique will meet the goals of protecting the multicast routing
infrastructure control plane without a significant average increase infrastructure control plane without a significant average increase
of bandwidth; for instance, damping events happening at a frequency of bandwidth; for instance, damping events happening at a frequency
higher than one event per X second, can be done without increasing by higher than one event per X seconds can be done without increasing by
more than X second the time during which a multicast flow is present more than X seconds the time during which a multicast flow is present
on a link. on a link.
That said, simulation of the exponential decay algorithm show that That said, simulation of the exponential decay algorithm shows that
the multicast state churn can be drastically reduced without the multicast state churn can be drastically reduced without
significantly increasing the duration for which multicast traffic is significantly increasing the duration for which multicast traffic is
forwarded. Hence, using this technique will efficiently protect the forwarded. Hence, using this technique will efficiently protect the
multicast routing infrastructure control plane against the issues multicast routing infrastructure control plane against the issues
described here, without a significant average increase of bandwidth. described here without a significant average increase of bandwidth.
The exception will be a scenario with strict constraints on multicast The exception will be a scenario with strict constraints on multicast
bandwidth, where extending the time a multicast flow is forwarded bandwidth, where extending the time a multicast flow is forwarded
would result in congestion. would result in congestion.
To be practical, such a mechanism requires configurability. In To be practical, such a mechanism requires configurability. In
particular, means are required to control when damping is triggered, particular, means are required to control when damping is triggered
and to allow delaying the pruning of a multicast state for a time and to allow delaying the pruning of a multicast state for a time
increasing with the churn of this multicast state. This will let the increasing with the churn of this multicast state. This will let the
operator control the tradeoff made between minimizing the dynamicity operator control the trade-off made between minimizing the dynamicity
and reducing bandwidth consumption. and reducing bandwidth consumption.
4. Existing mechanisms 4. Existing Mechanisms
This section describes mechanisms that could be considered to address This section describes mechanisms that could be considered to address
the issue, but that end up appearing as not suitable or not efficient the issue but that end up appearing as not suitable or not efficient
enough. enough.
4.1. Rate-limiting of multicast control traffic 4.1. Rate-Limiting Multicast Control Traffic
PIM-SM specification [RFC7761] examine multicast security threats and The Protocol Independent Multicast - Sparse Mode (PIM-SM)
among other things the risk of denial of service attacks described in specification [RFC7761] examines multicast security threats and,
Section 1. A mechanism relying on rate-limiting PIM messages is among other things, the risk of denial-of-service attacks described
proposed in section 5.3.3 of [RFC4609], but has the identified in Section 1. A mechanism relying on rate-limiting PIM messages is
proposed in Section 5.3.3 of [RFC4609] but has the identified
drawbacks of impacting the service delivered and having side-effects drawbacks of impacting the service delivered and having side-effects
on legitimate users. on legitimate users.
4.2. Existing PIM, IGMP and MLD timers 4.2. Existing PIM, IGMP, and MLD Timers
In the context of PIM multicast routing protocols [RFC7761], a In the context of PIM multicast routing protocols [RFC7761], a
mechanism exists that may offer a form of de-facto damping of mechanism exists that may offer a form of de facto damping of
multicast states, under some conditions. Indeed, when active, the multicast states, under some conditions. Indeed, when active, the
prune override mechanism consists in having a PIM upstream router prune override mechanism consists in having a PIM upstream router
introduce a delay ("prune override interval") before taking into introduce a delay ("prune override interval") before taking into
account a PIM Prune message sent by a downstream neighbor. account a PIM Prune message sent by a downstream neighbor.
This mechanism has not been designed specifically for the purpose of This mechanism has not been designed specifically for the purpose of
damping multicast state, but as a means to allow PIM to operate on damping multicast state, but as a means to allow PIM to operate on
multi-access networks. See [RFC7761] section 4.3.3. However, when multi-access networks. See Section 4.3.3 of [RFC7761]. However,
active, this mechanism will prevent a downstream router to produce when active, this mechanism will prevent a downstream router from
multicast routing protocol messages that would cause, for a given producing multicast routing protocol messages that would cause, for a
multicast state, the upstream router to send to its own upstream given multicast state, the upstream router to send to its own
router, multicast routing protocol messages at a rate higher than upstream router multicast routing protocol messages at a rate higher
1/[JP_Override_Interval]. This provides de-facto a form of damping. than 1/[JP_Override_Interval]. This provides a form of de facto
damping.
Similarly, the IGMP and MLD multicast membership control protocols Similarly, the IGMP and MLD multicast membership control protocols
can provide a similar behavior, under the right conditions. can provide a similar behavior under the right conditions.
These mechanisms are not considered suitable to meet the goals These mechanisms are not considered suitable to meet the goals
spelled out in Section 1, the main reasons being that: spelled out in Section 1, the main reasons being that:
o when enabled, these mechanisms require additional bandwidth on the o when enabled, these mechanisms require additional bandwidth on the
local link on which the effect of a prune is delayed (in our case local link on which the effect of a prune is delayed (in our case,
the PE-CE link) the PE-CE link);
o when enabled, these mechanisms require disabling explicit tracking o when enabled, these mechanisms require disabling explicit tracking
(see Section 4.3.3 of [RFC7761]), even though enabling this (see Section 4.3.3 of [RFC7761]), even though enabling this
feature may otherwise be desired feature may otherwise be desired;
o on certain implementations, these mechanisms are incompatible with o on certain implementations, these mechanisms are incompatible with
behaviors that cannot be turned off (e.g. implementation applying behaviors that cannot be turned off (e.g., implementation applying
a fast-leave behavior on interfaces with only two neighbors) a fast-leave behavior on interfaces with only two neighbors);
o they do not provide a suitable level of configurability o they do not provide a suitable level of configurability; and
o they do not provide a way to discriminate between multicast flows o they do not provide a way to discriminate between multicast flows
based on estimation of their dynamicity based on estimation of their dynamicity.
4.3. BGP Route Damping 4.3. BGP Route Damping
The procedures defined in [RFC2439] and [RFC7196] for BGP route flap The procedures defined in [RFC2439] and [RFC7196] for BGP route flap
damping are useful for operators who want to control the impact of damping are useful for operators who want to control the impact of
unicast route churn on the routing infrastructure, and offer a unicast route churn on the routing infrastructure and offer a
standardized set of parameters to control damping. standardized set of parameters to control damping.
These procedures are not directly relevant in a multicast context, These procedures are not directly relevant in a multicast context for
for the following reasons: the following reasons:
o they are not specified for multicast routing protocol in general o they are not specified for multicast routing protocol in general,
and
o even in contexts where BGP routes are used to carry multicast o even in contexts where BGP routes are used to carry multicast
routing states (e.g. [RFC6514]), these procedures do not allow to routing states (e.g., [RFC6514]), these procedures do not allow
implement the principle described in this document, the main the implementation of the principle described in this document;
reason being that a damped route becomes suppressed, while the the main reason being that a damped route becomes suppressed while
target behavior would be to keep advertising when damping is the target behavior would be to keep advertising when damping is
triggered on a multicast route triggered on a multicast route.
However, the set of parameters standardized to control the thresholds However, the set of parameters standardized to control the thresholds
of the exponential decay mechanism can be relevantly reused. This is of the exponential decay mechanism can be relevantly reused. This is
the approach proposed for the procedures described in this document the approach proposed for the procedures described in this document
(Section 5). Motivations for doing so is to help the network (Section 5). Motivations for doing so are to help the network
operator deploy this feature based on consistent configuration operator deploy this feature based on consistent configuration
parameter, and obtain predictable results, without the drawbacks of parameters and to obtain predictable results without the drawbacks of
relying on rate-limiting of multicast control protocol exchanges (as relying on rate-limiting multicast control protocol exchanges (as is
exposed in Section 4.1) or on the use of existing PIM/IGMP timers (as exposed in Section 4.1) or on the use of existing PIM/IGMP timers (as
exposed in Section 4.2). is exposed in Section 4.2).
5. Procedures for multicast state damping 5. Procedures for Multicast State Damping
5.1. PIM procedures 5.1. PIM Procedures
This section describes procedures for multicast state damping This section describes procedures for multicast state damping
satisfying the goals spelled out in Section 1. This section spells satisfying the goals spelled out in Section 1. This section
out procedures for (S,G) states in the PIM-SM protocol [RFC7761]; describes procedures for (S,G) states in the PIM-SM protocol
they apply unchanged for such states created based on multicast group [RFC7761]; they apply unchanged for such states created based on
management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream multicast group management protocols (IGMP [RFC3376], MLD [RFC3810])
interfaces. The same procedures are applied to (*,G) states in the on downstream interfaces. The same procedures are applied to (*,G)
context of PIM-SM ASM groups (damping is not applied to (S,G,Rpt) states in the context of PIM-SM Any-Source Multicast (ASM) groups
Prune state). (damping is not applied to (S,G,Rpt) Prune state).
The following notions of [RFC2439] are reused in these procedures: The following notions of [RFC2439] are reused in these procedures:
figure-of-merit: a number reflecting the current estimation of figure-of-merit: A number reflecting the current estimation of
recent past activity of an (S,G) multicast routing state, which recent past activity of an (S,G) multicast routing state, which
increases based on routing events related to this state, and increases based on routing events related to this state and
between these events decreases following an exponential decay decreases between these events following an exponential decay
function (see below); the activation or inactivation of damping on function (see below); the activation or inactivation of damping on
the state is based on this number; this number is associated to the state is based on this number. This number is associated with
the upstream state machine for (S,G) and is initialized to a value the upstream state machine for (S,G) and is initialized to a value
of zero on state creation of zero on state creation.
exponential decay function: a mathematical function as defined exponential decay function: A mathematical function as defined in
inSection 2.3 of [RFC2439] (ignoring the first paragraph of that Section 2.3 of [RFC2439] (ignoring the first paragraph of the
section that does not apply here) section, as it does not apply here).
decay-half-life: duration used to control how fast is the decay-half-life: The duration used to control how fast the
exponential decay of the *figure-of-merit* ; this parameter of the exponential decay of the *figure-of-merit* is; this parameter of
exponential decay function is the time duration during which the the exponential decay function is the time duration during which
*figure-of-merit* will be reduced by half, in the absence of a the *figure-of-merit* will be reduced by half when in the absence
routing event (configurable parameter) of a routing event (configurable parameter).
cutoff-threshold: value of the *figure-of-merit* over which damping cutoff-threshold: The value of the *figure-of-merit* over which
is applied (configurable parameter) damping is applied (configurable parameter).
reuse-threshold: value of the *figure-of-merit* under which damping reuse-threshold: The value of the *figure-of-merit* under which
stops being applied (configurable parameter) damping stops being applied (configurable parameter).
Additionally to these values, a configurable *increment-factor* In addition to these values, a configurable *increment-factor*
parameter is introduced, that controls by how much the *figure-of- parameter is introduced that controls by how much the *figure-of-
merit* is incremented on multicast state update events. merit* is incremented on multicast state update events.
Section 7.3 proposes default and maximum values for the configurable Section 7.3 proposes default and maximum values for the configurable
parameters. parameters.
On reception of updated multicast membership or routing information On reception of updated multicast membership or routing information
on a downstream interface I for a given (S,G) state, that results in on a downstream interface I for a given (S,G) state, which results in
a change of the state of the PIM downstream state machine (see a change of the state of the PIM downstream state machine (see
section 4.5.3 of [RFC7761]), a router implementing these procedures Section 4.5.3 of [RFC7761]), a router implementing these procedures
MUST: MUST:
o apply procedures of [RFC7761] unchanged, for everything relating o apply procedures of [RFC7761] unchanged, for everything relating
to what multicast traffic ends up being sent on downstream to what multicast traffic ends up being sent on downstream
interfaces, including interface I interfaces, including interface I
o update the *figure-of-merit* following the exponential decay o update the *figure-of-merit* following the exponential decay
algorithm algorithm
o increase the *figure-of-merit* for the (S,G) by the *increment- o increase the *figure-of-merit* for the (S,G) by the *increment-
factor* factor*
o update the damping state for the (S,G) state: damping becomes o update the damping state for the (S,G) state: damping becomes
active on the state if the recomputed *figure-of-merit* is active on the state if the recomputed *figure-of-merit* is
strictly above the configured *cutoff-threshold* strictly above the configured *cutoff-threshold*:
* if damping remains inactive on (S,G) state, update the upstream * if damping remains inactive on (S,G) state, update the upstream
state machine as usual (as per section 4.5.7 of [RFC7761]) state machine as usual (as per Section 4.5.7 of [RFC7761]).
* if damping becomes active for the (S,G) state: * if damping becomes active for the (S,G) state:
+ if the received message has caused the upstream state + if the received message has caused the upstream state
machine to transition to Joined state, update the upstream machine to transition to Joined state, update the upstream
state machine for (S,G) (applying usual PIM procedures in state machine for (S,G) applying usual PIM procedures in
section 4.5.7 of [RFC7761], including sending a PIM Join to Section 4.5.7 of [RFC7761] and including sending a PIM Join
the upstream neighbor) to the upstream neighbor
+ if the received message has caused the upstream state + if the received message has caused the upstream state
machine to transition to NotJoined state, do not update the machine to transition to NotJoined state, do not update the
upstream state machine for (S,G) upstream state machine for (S,G)
+ hold the upstream state machine in Joined state until the + hold the upstream state machine in Joined state until the
reuse threshold is reached : for the purpose of updating reuse threshold is reached: for the purpose of updating this
this state machine, events that may result in updating the state machine, events that may result in updating the state
state based on [RFC7761] SHOULD be ignored until the *reuse- based on [RFC7761] SHOULD be ignored until the *reuse-
threshold* is reached. The effect is that in the meantime, threshold* is reached. The effect is that in the meantime,
while PIM Join messages may be sent as refreshes to the while PIM Join messages may be sent as refreshes to the
upstream neighbor, no PIM Prune message will be sent. upstream neighbor, no PIM Prune message will be sent.
* if damping was already active: do not update the upstream state * if damping was already active, do not update the upstream state
machine for (S,G) (the upstream state machine was frozen after machine for (S,G); the upstream state machine was frozen after
processing the previous message) processing the previous message.
Once the *figure-of-merit* for (S,G) damping state decays to a value Once the *figure-of-merit* for (S,G) damping state decays to a value
strictly below the configured *reuse-threshold*, the upstream state strictly below the configured *reuse-threshold*, the upstream state
machine for (S,G) is recomputed based on states of downstream state machine for (S,G) is recomputed based on states of downstream state
machines, eventually leading to a PIM Join or Prune message to be machines, eventually leading to a PIM Join or Prune message to be
sent to the upstream neighbor. sent to the upstream neighbor.
Given the specificity of multicast applications, it is REQUIRED for Given the specificity of multicast applications, it is REQUIRED for
the implementation to let the operator configure the *decay-half- the implementation to let the operator configure the *decay-half-
life* in seconds, rather than in minutes. life* in seconds, rather than in minutes.
This specification does not impose the use of a particular technique This specification does not impose the use of a particular technique
to update the *figure-of-merit* following the exponential decay to update the *figure-of-merit* following the exponential decay
controlled by the configured *decay-half-life*. For instance, the controlled by the configured *decay-half-life*. For instance, the
same techniques as the ones described in [RFC2439] can be applied. same techniques as the ones described in [RFC2439] can be applied.
The only requirement is that the *figure-of-merit* has to be updated The only requirement is that the *figure-of-merit* has to be updated
prior to increasing it, and that its decay below the *reuse- prior to increasing it and that its decay below the *reuse-threshold*
threshold* has to be timely reacted upon: in particular, if the has to be reacted upon in a timely manner: in particular, if the
recomputation is done with a fixed time granularity, this granularity recomputation is done with a fixed time granularity, this granularity
should be low enough to not significantly delay the inactivation of should be low enough to not significantly delay the inactivation of
damping on a multicast state beyond what the operator wanted to damping on a multicast state beyond what the operator wanted to
configure (e.g. for a *decay-half-life* of 10s, recomputing the configure (e.g., for a *decay-half-life* of 10s, recomputing the
*figure-of-merit* each minute would result in a multicast state to *figure-of-merit* each minute would result in a multicast state
remained damped for a much longer time than specified). remaining damped for a much longer time than specified).
PIM implementations typically follow [RFC7761] suggestion that PIM implementations typically follow the suggestion from Section 4.1
"implementations will only maintain state when it is relevant to of [RFC7761] that:
forwarding operations - for example, the 'NoInfo' state might be
assumed from the lack of other state information, rather than being implementations will only maintain state when it is relevant to
held explicitly" (Section 4.1 of [RFC7761]). To properly implement forwarding operations - for example, the 'NoInfo' state might be
damping procedures, an implementation MUST keep an explicit (S,G) assumed from the lack of other state information, rather than
state as long as damping is active on an (S,G). Once an (S,G) state being held explicitly.
expires, and damping becomes inactive on this state, its associated
*figure-of-merit* and damping state are removed as well. To properly implement damping procedures, an implementation MUST keep
an explicit (S,G) state as long as damping is active on an (S,G).
Once an (S,G) state expires, and damping becomes inactive on this
state, its associated *figure-of-merit* and damping state are removed
as well.
Note that these procedures: Note that these procedures:
o do not impact PIM procedures related to refreshes or expiration of o do not impact PIM procedures related to refreshes or expiration of
multicast routing states: PIM Prune messages triggered by the multicast routing states: PIM Prune messages triggered by the
expiration of the (S,G) keep-alive timer, are not suppressed or expiration of the (S,G) keep-alive timer are not suppressed or
delayed, and the reception of Join messages not causing transition delayed, and the reception of Join messages not causing transition
of state on the downstream interface does not lead to incrementing of state on the downstream interface does not lead to incrementing
the *figure-of-merit*; the *figure-of-merit*;
o do not impact the PIM assert mechanism, in particular PIM Prune o do not impact the PIM Assert mechanism: in particular, PIM Prune
messages triggered by a change of the PIM assert winner on the messages triggered by a change of the PIM Assert winner on the
upstream interface, are not suppressed or delayed; upstream interface are not suppressed or delayed;
o do not impact PIM Prune messages that are sent when the RPF o do not impact PIM Prune messages that are sent when the RPF
neighbor is updated for a given multicast flow; neighbor is updated for a given multicast flow; and
o do not impact PIM Prune messages that are sent in the context of o do not impact PIM Prune messages that are sent in the context of
switching between a Rendez-vous Point Tree and a Shortest Path switching between a Rendezvous Point Tree and a Shortest Path
Tree. Tree.
Note also that no action is triggered based on the reception of PIM Note also that no action is triggered based on the reception of PIM
Prune messages (or corresponding IGMP/MLD messages) that relate to Prune messages (or corresponding IGMP/MLD messages) that relate to
non-existing (S,G) state, in particular, no *figure-of-merit* or non-existing (S,G) state: in particular, no *figure-of-merit* or
damping state is created in this case. damping state is created in this case.
5.2. Procedures for multicast VPN state damping 5.2. Procedures for Multicast VPN State Damping
The procedures described in Section 5.1 can be applied in the VRF The procedures described in Section 5.1 can be applied in the Virtual
PIM-SM implementation (in the "C-PIM instance"), with the Routing and Forwarding (VRF) PIM-SM implementation (in the "C-PIM
corresponding action to suppressing the emission of a Prune(S,G) instance"), with the corresponding action to suppressing the emission
message being to not withdraw the C-multicast Source Tree Join of a Prune(S,G) message being to not withdraw the C-multicast Source
(C-S,C-G) BGP route. An implementation of [RFC6513] relying on the Tree Join (C-S,C-G) BGP route. An implementation of [RFC6513]
use of PIM to carry C-multicast routing information MUST support this relying on the use of PIM to carry C-multicast routing information
technique, to be compliant with this specification. MUST support this technique to be compliant with this specification.
In the context of [RFC6514] where BGP is used to distribute In the context of [RFC6514], where BGP is used to distribute
C-multicast routing information, the following procedure is proposed C-multicast routing information, the following procedure is proposed
as an alternative to the procedures in Section 5.1 and consists in as an alternative to the procedures in Section 5.1 and consists in
applying damping in the BGP implementation, based on existing BGP applying damping in the BGP implementation based on existing BGP
damping mechanism, applied to C-multicast Source Tree Join routes and damping mechanisms applied to C-multicast Source Tree Join routes and
Shared Tree Join routes (and as well to Leaf A-D routes - see Shared Tree Join routes (and as well to Leaf A-D routes - see
Section 6), and modified to implement the behavior described in Section 6) and modified to implement the behavior described in
Section 3 along the following guidelines: Section 3 along the following guidelines:
o not withdrawing (instead of not advertising) damped routes o not withdrawing (instead of not advertising) damped routes;
o providing means to configure the *decay-half-life* in seconds if o providing means to configure the *decay-half-life* in seconds if
that option is not already available that option is not already available; and
o using parameters for the exponential decay that are specific to o using parameters for the exponential decay that are specific to
multicast, based on default values and multicast specific multicast based on default values and multicast-specific
configuration configuration.
While these procedures would typically be implemented on PE routers, While these procedures would typically be implemented on PE routers,
in a context where BGP Route Reflectors (RRs, [RFC4456]) are used it in a context where BGP Route Reflectors (RRs) [RFC4456] are used it
can be considered useful to also be able to apply damping on RRs as can be considered useful to also be able to apply damping on RRs as
well to provide additional protection against activity created behind well to provide additional protection against activity created behind
multiple PEs. Additionally, for mVPN Inter-AS deployments, it can be multiple PEs. Additionally, for MVPN Inter-AS deployments, it can be
needed to protect one AS from the dynamicity of multicast VPN routing needed to protect one Autonomous System (AS) from the dynamicity of
events from other ASes. multicast VPN routing events from other ASes.
The choice to implement damping based on BGP routes or the procedures The choice to implement damping based on BGP routes or the procedures
described in Section 5.1, is up to the implementor, but at least one described in Section 5.1 is up to the implementor, but at least one
of the two MUST be implemented. In the perspective of allowing of the two MUST be implemented. In the perspective of allowing
damping to be done on RRs and ASBRs, implementing the BGP approach is damping to be done on RRs and Autonomous System Border Routers
recommended. (ASBRs), implementing the BGP approach is recommended.
When not all routers in a deployment have the capability to drop When not all routers in a deployment have the capability to drop
traffic coming from the wrong PE (as spelled out in section 9.1.1 of traffic coming from the wrong PE (as spelled out in Section 9.1.1 of
[RFC6513]), then the withdrawal of a C-multicast route resulting from [RFC6513]), then the withdrawal of a C-multicast route resulting from
a change in the Upstream Multicast Hop or Upstream Multicast PE a change in the Upstream Multicast Hop or Upstream Multicast PE
SHOULD NOT be damped. An implementation of this specification MUST SHOULD NOT be damped. An implementation of this specification MUST
whether, not damp these withdrawals by default, or alternatively do at least one of the two following things:
provide a tuning knob to disable the damping of these withdrawals.
Additionally, in such a deployment context, it is RECOMMENDED to not o not damp these withdrawals by default, and/or
enable any multicast VPN route damping on RRs and ASBRs, since these
equipments cannot distinguish the event having caused a C-multicast o provide a tuning knob to disable the damping of these withdrawals.
to be withdrawn.
Additionally, in such a deployment context, it is RECOMMENDED not to
enable any multicast VPN route damping on RRs and ASBRs since these
types of equipment cannot distinguish the event having caused a
C-multicast to be withdrawn.
Note well that it is out of scope of this section to consider the Note well that it is out of scope of this section to consider the
application of these damping techniques on mVPN BGP routes other than application of these damping techniques on MVPN BGP routes other than
C-multicast routes. C-multicast routes.
6. Procedures for P-tunnel state damping 6. Procedures for P-Tunnel State Damping
6.1. Damping mVPN P-tunnel change events 6.1. Damping MVPN P-Tunnel Change Events
When selective P-tunnels are used (see section 7 of [RFC6513]), the When selective P-tunnels are used (see Section 7 of [RFC6513]), the
effect of updating the upstream state machine for a given (C-S,C-G) effect of updating the upstream state machine for a given (C-S,C-G)
state on a PE connected to multicast receivers, is not only to state on a PE connected to multicast receivers is not only to
generate activity to propagate C-multicast routing information to the generate activity to propagate C-multicast routing information to the
source connected PE, but also to possibly trigger changes related to source connected PE, but also to possibly trigger changes related to
the P-tunnels carrying (C-S,C-G) traffic. Protecting the provider 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 network from an excessive amount of change in the state of P-tunnels
is required, and this section details how this can be done. is required, and this section details how this can be done.
A PE implementing these procedures for mVPN MUST damp Leaf A-D A PE implementing these procedures for MVPN MUST damp Leaf A-D routes
routes, in the same manner as it would for C-multicast routes (see in the same manner as it would for C-multicast routes (see
Section 5.2). Section 5.2).
A PE implementing these procedures for mVPN MUST damp the activity A PE implementing these procedures for MVPN MUST damp the activity
related to removing itself from a P-tunnel. Possible ways to do so related to removing itself from a P-tunnel. Possible ways to do so
depend on the type of P-tunnel, and local implementation details are depend on the type of P-tunnel, and local implementation details are
left up to the implementor. left up to the implementor.
The following is proposed as example of how the above can be The following is proposed as an example of how the above can be
achieved: achieved:
o For P-tunnels implemented with the PIM protocol, this consists in o For P-tunnels implemented with the PIM protocol, this consists in
applying multicast state damping techniques described in applying multicast state damping techniques described in
Section 5.1 to the P-PIM instance, at least for (S,G) states Section 5.1 to the P-PIM instance, at least for (S,G) states
corresponding to P-tunnels. corresponding to P-tunnels.
o For P-tunnels implemented with the mLDP protocol, this consists in o For P-tunnels implemented with multipoint LDP (mLDP), this
applying damping techniques completely similar to the one consists in applying damping techniques completely similar to the
described in Section 5, but generalized to apply to mLDP states one described in Section 5 but generalized to apply to mLDP
states.
o For root-initiated P-tunnels (P-tunnels implemented with the P2MP o For root-initiated P-tunnels (P-tunnels implemented with the
RSVP-TE, or relying on ingress replication), no particular action Point-to-Multipoint (P2MP) RSVP-TE, or relying on ingress
needs to be implemented to damp P-tunnels membership, if the replication), no particular action needs to be implemented to damp
activity of Leaf A-D route themselves is damped P-tunnels membership, if the activity of Leaf A-D route themselves
is damped.
o Another possibility is to base the decision to join or not join o Another possibility is to base the decision to join or not join
the P-tunnel to which a given (C-S,C-G) is bound, and to advertise 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), based on or not advertise a Leaf A-D route related to (C-S,C-G) based on
whether or not a C-multicast Source Tree Join route is being whether or not a C-multicast Source Tree Join route is being
advertised for (C-S,C-G), rather than by relying on the state of advertised for (C-S,C-G) rather than by relying on the state of
the C-PIM Upstream state machine for (C-S,C-G) the C-PIM Upstream state machine for (C-S,C-G).
6.2. Procedures for Ethernet VPNs 6.2. Procedures for Ethernet VPNs
Specifications exist to support or optimize multicast and broadcast Specifications exist to support or optimize multicast and broadcast
in the context of Ethernet VPNs [RFC7117], relying on the use of in the context of Ethernet VPNs [RFC7117] relying on the use of
S-PMSI and P-tunnels. For the same reasons as for IP multicast VPNs, Selective P-Multicast Service Interface (S-PMSI) and P-tunnels. For
an implementation of [RFC7117] MUST follow the procedures described the same reasons as for IP multicast VPNs, an implementation of
in Section 6.1, to be compliant with this specification. [RFC7117] MUST follow the procedures described in Section 6.1 to be
compliant with this specification.
7. Operational considerations 7. Operational Considerations
7.1. Enabling multicast damping 7.1. Enabling Multicast Damping
In the context of multicast VPNs, these procedures would be enabled In the context of multicast VPNs, these procedures would be enabled
on PE routers. Additionally in the case of C-multicast routing based on PE routers. Additionally, in the case of C-multicast routing
on BGP extensions ([RFC6514]) these procedures can be enabled on based on BGP extensions ([RFC6514]), these procedures can be enabled
ASBRs and Route Reflectors. on ASBRs and RRs.
7.2. Troubleshooting and monitoring 7.2. Troubleshooting and Monitoring
Implementing the damping mechanisms described in this document should Implementing the damping mechanisms described in this document should
be complemented by appropriate tools to observe and troubleshoot be complemented by appropriate tools to observe and troubleshoot
damping activity. damping activity.
Complementing the existing interface providing information on Complementing the existing interface providing information on
multicast states with information on eventual damping of multicast states with information on eventual damping of
corresponding states (e.g. MRIB states) is RECOMMENDED: C-multicast corresponding states (e.g., Multicast Routing Information Base (MRIB)
routing states and P-tunnel states. states) is RECOMMENDED for C-multicast routing states and P-tunnel
states.
7.3. Default and maximum values 7.3. Default and Maximum Values
Considering that, by design multicast streams will be delivered Considering that, by design, multicast streams will be delivered
unchanged to the end user, independently of the value chosen for the unchanged to the end user independent of the value chosen for the
configurable parameters, and that the only trade-off being made is an configurable parameters, and that the only trade-off being made is an
increase of bandwidth use, the default and maximum values do not have increase of bandwidth use, the default and maximum values do not have
to be perfectly tuned. to be perfectly tuned.
This section proposes default and maximum values, conservative so as This section proposes default and maximum values that are
to not significantly impact network dimensioning but still prevent conservative, so as to not significantly impact network dimensioning
multicast state churn going beyond what can be considered a but still prevent multicast state churn going beyond what can be
reasonably low churn for a multicast state (see below for considered a reasonably low churn for a multicast state (see below
illustrations in order of magnitude of the effect of these values). for illustrations in order of magnitude of the effect of these
values).
The following values are RECOMMENDED to adopt as default values: The following values are RECOMMENDED to be adopted as default values:
o *increment-factor*: 1000 o *increment-factor*: 1000
o *cutoff-threshold*: 3000 o *cutoff-threshold*: 3000
o *decay-half-life*: 10s o *decay-half-life*: 10s
o *reuse-threshold*: 1500 o *reuse-threshold*: 1500
For unicast damping, it is common to set an upper bound to the time For unicast damping, it is common to set an upper bound to the time
during which a route is suppressed. In the case of multicast state during which a route is suppressed. In the case of multicast state
damping, which relies on not withdrawing a damped route, it may be damping, which relies on not withdrawing a damped route, it may be
desirable to avoid a situation where a multicast flow would keep desirable to avoid a situation where a multicast flow would keep
flowing in a portion of the network for a very large time in the flowing in a portion of the network for a very long time in the
absence of receivers. absence of receivers.
The proposed default maximum value for the *figure-of-merit* is The proposed default maximum value for the *figure-of-merit* is
20x*increment-factor*, i.e. 20000 with the proposed default 20x*increment-factor*, i.e., 20000 with the proposed default
*increment-factor* of 1000. *increment-factor* of 1000.
As illustrations, with these values: As illustrations, with these values:
o a multicast state updated less frequently than once every 6s will o a multicast state updated less frequently than once every 6 s will
not be damped at all not be damped at all;
o a multicast state changing once per second for 3s, and then not o a multicast state changing once per second for 3 s, and then not
changing, will not be damped changing, will not be damped;
o a multicast state changing once per second for 4s, and then not o a multicast state changing once per second for 4 s, and then not
changing, will be damped after the fourth change for approximately changing, will be damped after the fourth change for approximately
13s 13 s;
o a multicast state changing twice per second for 15s, and then not o a multicast state changing twice per second for 15 s, and then not
changing, will be damped after the fourth change for approximately changing, will be damped after the fourth change for approximately
50s 50 s; and
o a multicast state changing at a fast pace for a long time will o 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 reach the maximum of *figure-of-merit*; once the activity on this
state stops, corresponding traffic may still flow in the network state stops, corresponding traffic may still flow in the network
for approximately 37s before dampening stops being active for approximately 37 s before dampening stops being active.
The following values are proposed as maxima: The following values are proposed as maximums:
o *decay-half-life*: 60s o *decay-half-life*: 60 s
o *cutoff-threshold*: 50000 o *cutoff-threshold*: 50000
More aggressive protection against the risk of denial of service can More aggressive protection against the risk of denial of service can
be achieved by increasing the *increment-factor* or the *decay-half- be achieved by increasing the *increment-factor* or the
life*, or reducing the *cutoff-threshold* and/or *reuse-threshold*. *decay-half-life*, or by reducing the *cutoff-threshold* and/or
*reuse-threshold*.
8. IANA Considerations
This document makes no request to IANA.
Note to the RFC Editor: this section may be removed on publication as
an RFC.
9. Security Considerations 8. Security Considerations
The procedures defined in this document do not introduce additional The procedures defined in this document do not introduce additional
security issues not already present in the contexts addressed, and security issues not already present in the contexts addressed and
actually aim at addressing some of the identified risks without actually aim at addressing some of the identified risks without
introducing as much denial of service risk as some of the mechanisms introducing as much denial-of-service risk as some of the mechanisms
already defined. already defined.
The protection provided relates to the control plane of the multicast The protection provided relates to the control plane of the multicast
routing protocols, including the components implementing the routing routing protocols, including the components implementing the routing
protocols and the components responsible for updating the multicast protocols and the components responsible for updating the multicast
forwarding plane. forwarding plane.
The procedures describe are meant to provide some level of protection The procedures described are meant to provide some level of
for the router on which they are enabled by reducing the amount of protection for the router on which they are enabled by reducing the
routing state updates that it needs to send to its upstream neighbor amount of routing state updates that it needs to send to its upstream
or peers, but do not provide any reduction of the control plane load neighbor or peers but do not provide any reduction of the control-
related to processing routing information from downstream neighbors. plane load related to processing routing information from downstream
neighbors. Protecting routers from an increase in control-plane load
Protecting routers from an increase in control plane load due to due to activity on downstream interfaces toward core routers (or in
activity on downstream interfaces toward core routers (or in the the context of BGP-based MVPN C-multicast routing, BGP peers) relies
context of BGP-based mVPN C-multicast routing, BGP peers) relies on on the activation of damping on corresponding downstream neighbors
the activation of damping on corresponding downstream neighbors (or (or BGP peers) and/or at the edge of the network. Protecting routers
BGP peers) and/or at the edge of the network. Protecting routers from an increase in control-plane load due to activity on customer-
from an increase in control plane load due to activity on customer-
facing downstream interfaces or downstream interfaces to routers in facing downstream interfaces or downstream interfaces to routers in
another administrative domain, is out of the scope of this document another administrative domain is out of the scope of this document
and should use already defined mechanisms (see [RFC4609]). and should use already defined mechanisms (see [RFC4609]).
To be effective the procedures described here must be complemented by To be effective, the procedures described here must be complemented
configuration limiting the number of multicast states that can be by configuration limiting the number of multicast states that can be
created on a multicast router through protocol interactions with created on a multicast router through protocol interactions with
multicast receivers, neighbor routers in adjacent ASes, or in multicast receivers, neighbor routers in adjacent ASes, or in
multicast VPN contexts with multicast CEs. Note well that the two multicast VPN contexts with multicast CEs. Note well that the two
mechanism may interact: state for which Prune has been requested may mechanisms may interact: the state for which Prune has been requested
still remain taken into account for some time if damping has been may still remain taken into account for some time if damping has been
triggered and hence result in otherwise acceptable new state from triggered and hence result in an otherwise acceptable new state from
being successfully created. being successfully created.
Additionally, it is worth noting that these procedures are not meant Additionally, it is worth noting that these procedures are not meant
to protect against peaks of control plane load, but only address to protect against peaks of control-plane load but only address
averaged load. For instance, assuming a set of multicast states averaged load. For instance, assuming a set of multicast states are
submitted to the same Join/Prune events, damping can prevent more submitted to the same Join/Prune events, damping can prevent more
than a certain number of Join/Prune messages to be sent upstream in than a certain number of Join/Prune messages to be sent upstream in
the period of time that elapses between the reception of Join/Prune the period of time that elapses between the reception of Join/Prune
messages triggering the activation of damping on these states and messages triggering the activation of damping on these states and
when damping becomes inactive after decay. when damping becomes inactive after decay.
10. Acknowledgements 9. References
We would like to thank Bruno Decraene and Lenny Giuliano for
discussions that helped shape this proposal. We would also like to
thank Yakov Rekhter and Eric Rosen for their reviews and helpful
comments. Thanks to Wim Henderickx for his comments and support of
this proposal. Additionally, Martin Vigoureux, Gunter Van De Velde
and Alvaro Retana provided useful comments to finalize the document.
11. References
11.1. Normative References 9.1. Normative References
[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>.
[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, DOI 10.17487/RFC2439, November
1998, <http://www.rfc-editor.org/info/rfc2439>.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002. 3", RFC 3376, DOI 10.17487/RFC3376, October 2002,
<http://www.rfc-editor.org/info/rfc3376>.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Discovery Version 2 (MLDv2) for IPv6", RFC 3810,
DOI 10.17487/RFC3810, June 2004,
<http://www.rfc-editor.org/info/rfc3810>.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E., Ed. and R. Aggarwal, Ed., "Multicast in MPLS/
VPNs", RFC 6513, February 2012. 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 [RFC6514] Aggarwal, R., Rosen, E., Morin, T., and Y. Rekhter, "BGP
Encodings and Procedures for Multicast in MPLS/BGP IP Encodings and Procedures for Multicast in MPLS/BGP IP
VPNs", RFC 6514, February 2012. VPNs", RFC 6514, DOI 10.17487/RFC6514, February 2012,
<http://www.rfc-editor.org/info/rfc6514>.
[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. [RFC7117] Aggarwal, R., Ed., Kamite, Y., Fang, L., Rekhter, Y., and
Kodeboniya, "Multicast in Virtual Private LAN Service C. Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, February 2014. (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. [RFC7196] Pelsser, C., Bush, R., Patel, K., Mohapatra, P., and O.
Maennel, "Making Route Flap Damping Usable", RFC 7196, May Maennel, "Making Route Flap Damping Usable", RFC 7196,
2014. DOI 10.17487/RFC7196, May 2014,
<http://www.rfc-editor.org/info/rfc7196>.
[RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I.,
Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent
Multicast - Sparse Mode (PIM-SM): Protocol Specification Multicast - Sparse Mode (PIM-SM): Protocol Specification
(Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March
2016, <http://www.rfc-editor.org/info/rfc7761>. 2016, <http://www.rfc-editor.org/info/rfc7761>.
11.2. Informative References 9.2. Informative References
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<http://www.rfc-editor.org/info/rfc4456>. <http://www.rfc-editor.org/info/rfc4456>.
[RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol
Independent Multicast - Sparse Mode (PIM-SM) Multicast Independent Multicast - Sparse Mode (PIM-SM) Multicast
Routing Security Issues and Enhancements", RFC 4609, Routing Security Issues and Enhancements", RFC 4609,
October 2006. DOI 10.17487/RFC4609, October 2006,
<http://www.rfc-editor.org/info/rfc4609>.
Acknowledgements
We would like to thank Bruno Decraene and Lenny Giuliano for
discussions that helped shape this proposal. We would also like to
thank Yakov Rekhter and Eric Rosen for their reviews and helpful
comments. Thanks to Wim Henderickx for his comments and support of
this proposal. Additionally, Martin Vigoureux, Gunter Van De Velde,
and Alvaro Retana provided useful comments to finalize the document.
Authors' Addresses Authors' Addresses
Thomas Morin (editor) Thomas Morin (editor)
Orange Orange
2, avenue Pierre Marzin 2, avenue Pierre Marzin
Lannion 22307 Lannion 22307
France France
Email: thomas.morin@orange.com Email: thomas.morin@orange.com
Stephane Litkowski Stephane Litkowski
Orange Orange
France France
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.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
skipping to change at page 17, line 22 skipping to change at page 18, line 14
Stephane Litkowski Stephane Litkowski
Orange Orange
France France
Email: stephane.litkowski@orange.com Email: stephane.litkowski@orange.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
USA United States of America
Email: keyupate@cisco.com Email: keyupate@cisco.com
Zhaohui Zhang Zhaohui Zhang
Juniper Networks Inc. Juniper Networks Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA United States of America
Email: zzhang@juniper.net Email: zzhang@juniper.net
Robert Kebler Robert Kebler
Juniper Networks Inc. Juniper Networks Inc.
10 Technology Park Drive 10 Technology Park Drive
Westford, MA 01886 Westford, MA 01886
USA United States of America
Email: rkebler@juniper.net Email: rkebler@juniper.net
Jeff Haas Jeffrey Haas
Juniper Networks Juniper Networks
Email: jhaas@juniper.net Email: jhaas@juniper.net
 End of changes. 150 change blocks. 
339 lines changed or deleted 353 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/