draft-ietf-bess-multicast-damping-03.txt   draft-ietf-bess-multicast-damping-04.txt 
Network Working Group T. Morin, Ed. Network Working Group T. Morin, Ed.
Internet-Draft S. Litkowski Internet-Draft S. Litkowski
Intended status: Standards Track Orange Updates: 6514 (if approved) Orange
Expires: July 8, 2016 K. Patel Intended status: Standards Track K. Patel
Cisco Systems Expires: September 17, 2016 Cisco Systems
Z. Zhang Z. Zhang
R. Kebler R. Kebler
J. Haas J. Haas
Juniper Networks Juniper Networks
January 05, 2016 March 16, 2016
Multicast VPN state damping Multicast VPN state damping
draft-ietf-bess-multicast-damping-03 draft-ietf-bess-multicast-damping-04
Abstract Abstract
This document describes procedures to damp multicast VPN routing This document describes procedures to damp multicast VPN routing
state changes and control the effect of the churn due to the state changes and control the effect of the churn due to the
multicast dynamicity in customer site. 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. New procedures are proposed inspired from BGP
unicast route damping principles, but adapted to multicast. unicast route damping principles, but adapted to multicast.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 8, 2016. This Internet-Draft will expire on September 17, 2016.
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Existing mechanisms . . . . . . . . . . . . . . . . . . . . . 4 4. Existing mechanisms . . . . . . . . . . . . . . . . . . . . . 5
4.1. Rate-limiting of multicast control traffic . . . . . . . 4 4.1. Rate-limiting of multicast control traffic . . . . . . . 5
4.2. Existing PIM, IGMP and MLD timers . . . . . . . . . . . . 4 4.2. Existing PIM, IGMP and MLD timers . . . . . . . . . . . . 5
4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 5 4.3. BGP Route Damping . . . . . . . . . . . . . . . . . . . . 6
5. Procedures for multicast state damping . . . . . . . . . . . 6 5. Procedures for multicast state damping . . . . . . . . . . . 7
5.1. PIM procedures . . . . . . . . . . . . . . . . . . . . . 6 5.1. PIM procedures . . . . . . . . . . . . . . . . . . . . . 7
5.2. Procedures for multicast VPN state damping . . . . . . . 9 5.2. Procedures for multicast VPN state damping . . . . . . . 10
6. Procedures for P-tunnel state damping . . . . . . . . . . . . 10 6. Procedures for P-tunnel state damping . . . . . . . . . . . . 11
6.1. Damping mVPN P-tunnel change events . . . . . . . . . . . 10 6.1. Damping mVPN P-tunnel change events . . . . . . . . . . . 11
6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 11 6.2. Procedures for Ethernet VPNs . . . . . . . . . . . . . . 12
7. Operational considerations . . . . . . . . . . . . . . . . . 11 7. Operational considerations . . . . . . . . . . . . . . . . . 12
7.1. Enabling multicast damping . . . . . . . . . . . . . . . 11 7.1. Enabling multicast damping . . . . . . . . . . . . . . . 12
7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 11 7.2. Troubleshooting and monitoring . . . . . . . . . . . . . 12
7.3. Default and maximum values . . . . . . . . . . . . . . . 12 7.3. Default and maximum values . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9. Security Considerations . . . . . . . . . . . . . . . . . . . 12 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
11.1. Normative References . . . . . . . . . . . . . . . . . . 14 11.1. Normative References . . . . . . . . . . . . . . . . . . 15
11.2. Informative References . . . . . . . . . . . . . . . . . 14 11.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 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, MLD), multicast routing protocols accordingly adjust protocols (IGMP [RFC3376], MLD[RFC3810]), multicast routing protocols
multicast routing states and P-multicast tree states, to forward or accordingly adjust multicast routing states and P-multicast tree
prune multicast traffic to these receivers. states, to forward or prune multicast traffic to these receivers.
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 regards to risks of denial of service attacks.
By nature multicast memberships change based on the behavior of
multicast applications running on end hosts, hence the frequency of
membership changes can legitimately be much higher than the typical
churn of unicast routing states.
Hence, mechanisms need to be put in place to ensure that the load put Hence, mechanisms need to be put in place to ensure that the load put
on the BGP control plane, and on the P-tunnel setup control plane, on the BGP control plane, and on the P-tunnel setup control plane,
remains under control regardless of the frequency at which multicast remains under control regardless of the frequency at which multicast
memberships changes are made by end hosts. By nature multicast memberships changes are made by end hosts.
memberships change based on the behavior of multicast applications
running on end hosts, hence the frequency of membership changes can
legitimately be much higher than the typical churn of unicast routing
states. Section 16 of [RFC6514] specifically spells out the need for
damping the activity of C-multicast and Leaf Auto-discovery routes.
This document describes procedures, remotely inspired from existing This document describes procedures, inspired from existing BGP route
BGP route damping, aimed at protecting these control planes while at damping [RFC2439], aimed at offering means to set an upper bound to
the same time avoiding negative effects on the service provided, the amount of processing for the mVPN control plane protocols
although at the expense of a minimal increase in average of bandwidth ([RFC6514], and the P-tunnel control plane protocol in certain cases
use in the network. as well), while at the same time preserving the service provided
(delivering the multicast stream as requested by Customer Edge
devices), although at the expense of a minimal increase of average
bandwidth use in the provider network. The upper bound to the
control plane load due to the processing of a given multicast state,
is controlled indirectly via configurable parameters.
The base principle is described in Section 3. Existing mechanisms Section 16 of [RFC6514] specifically spells out the need for damping
that could be relied upon are discussed in Section 4. Section 5 the activity of C-multicast and Leaf Auto-discovery routes, and
details the procedures introduced by these specifications. outlines how to do it by "delaying the advertisement of withdrawals
of C-multicast routes". This specification provides appropriate
detail on how to implement this approach and how to provide control
to the operator, and for this reason, in an update to [RFC6514].
The base principle of this specification is described in Section 3.
Existing mechanisms that could be relied upon are discussed in
Section 4. Section 5 details the procedures introduced by this
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
This document reuses terminology from [RFC4601] and [RFC6514]. This document reuses terminology from [RFC7761] and [RFC6514].
In this specification, damping of a multicast state will be said to
be "active" or "inactive". Note that in [RFC2439], the term used for
a unicast route which is dampened is "suppressed", but we will avoid
this term in this specification given that the proposed solution
consist 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
skipping to change at page 4, line 26 skipping to change at page 4, line 48
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 allow to meet the goals of protecting the multicast technique will allow to meet the goals of protecting the multicast
routing infrastructure control plane without a significant average routing infrastructure control plane without a significant average
increase of bandwidth; for instance, damping events happening at a increase of bandwidth; for instance, damping events happening at a
frequency higher than one event per X second, can be done without frequency higher than one event per X second, can be done without
increasing by more than X second the time during which a multicast increasing by more than X second the time during which a multicast
flow is present on a link. flow is present on a link.
That said, simulation of the exponential decay algorithm show that
the multicast state churn can be drastically reduced without
significantly increasing the duration for which multicast traffic is
forwarded. Hence, using this technique will efficiently protect the
multicast routing infrastructure control plane against the issues
described here, without a significant average increase of bandwidth.
The exception will be a scenario with strict constraints on multicast
bandwidth, where extending the time a multicast flow is forwarded
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 tradeoff 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 of multicast control traffic
PIM-SM specifications [RFC4609] examine multicast security threats PIM-SM specification [RFC7761] examine multicast security threats and
and among other things the risk described in Section 1. A mechanism among other things the risk of denial of service attacks described in
relying on rate-limiting PIM messages is proposed in section 5.3.3 of Section 1. A mechanism relying on rate-limiting PIM messages is
[RFC4609], but has the identified drawbacks of impacting the service proposed in section 5.3.3 of [RFC4609], but has the identified
delivered and having side-effects on legitimate users. drawbacks of impacting the service delivered and having side-effects
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 [RFC4601], 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 [RFC4601] section 4.3.3. However, when multi-access networks. See [RFC7761] section 4.3.3. However, when
active, this mechanism will prevent a downstream router to produce active, this mechanism will prevent a downstream router to produce
multicast routing protocol messages that would cause, for a given multicast routing protocol messages that would cause, for a given
multicast state, the upstream router to send to its own upstream multicast state, the upstream router to send to its own upstream
router, multicast routing protocol messages at a rate higher than router, multicast routing protocol messages at a rate higher than
1/[prune override interval]. This provides de-facto a form of 1/[JP_Override_Interval]. This provides de-facto a form of damping.
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
even though enabling this feature may otherwise be desired (see Section 4.3.3 of [RFC7761]), even though enabling this
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
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
skipping to change at page 6, line 27 skipping to change at page 7, line 11
relying on rate-limiting of multicast control protocol exchanges (as relying on rate-limiting of multicast control protocol exchanges (as
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). 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 spells
out procedures for (S,G) states in the PIM-SM protocol [RFC4601] ; out procedures for (S,G) states in the PIM-SM protocol [RFC7761];
they apply unchanged for such states created based on multicast group they apply unchanged for such states created based on multicast group
management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream management protocols (IGMP [RFC3376], MLD [RFC3810]) on downstream
interfaces. The same procedures are applied to (*,G) states in the interfaces. The same procedures are applied to (*,G) states in the
context of PIM-SM ASM groups (damping is not applied to (S,G,Rpt) context of PIM-SM ASM groups (damping is not applied to (S,G,Rpt)
Prune state). Prune state).
The following notions introduced in [RFC2439] are reused in these The following notions of [RFC2439] are reused in these procedures:
procedures:
figure-of-merit: a number reflecting the current estimation of past figure-of-merit: a number reflecting the current estimation of
recent activity of an (S,G) multicast routing state, which evolves recent past activity of an (S,G) multicast routing state, which
based on routing events related to this state and based an increases based on routing events related to this state, and
exponential decay algorithm ; the activation or inactivation of between these events decreases following an exponential decay
damping on the state is based on this number ; this number is function (see below); the activation or inactivation of damping on
associated to the upstream state machine for (S,G) and is the state is based on this number; this number is associated to
initialized to a value of zero on state creation the upstream state machine for (S,G) and is initialized to a value
of zero on state creation
exponential decay function: a mathematical function as defined
inSection 2.3 of [RFC2439] (ignoring the first paragraph of that
section that does not apply here)
decay-half-life: duration used to control how fast is the
exponential decay of the *figure-of-merit* ; this parameter of the
exponential decay function is the time duration during which the
*figure-of-merit* will be reduced by half, in the absence of a
routing event (configurable parameter)
cutoff-threshold: value of the *figure-of-merit* over which damping cutoff-threshold: value of the *figure-of-merit* over which damping
is applied (configurable parameter) is applied (configurable parameter)
reuse-threshold: value of the *figure-of-merit* under which damping reuse-threshold: value of the *figure-of-merit* under which damping
stops being applied (configurable parameter) stops being applied (configurable parameter)
decay-half-life: period of time used to control how fast is the
exponential decay of the *figure-of-merit* (configurable
parameter)
Additionally to these values, a configurable *increment-factor* Additionally 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, that 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 [RFC4601]), a router implementing these procedures section 4.5.3 of [RFC7761]), a router implementing these procedures
MUST: MUST:
o apply unchanged procedures for everything relating to what o apply procedures of [RFC7761] unchanged, for everything relating
multicast traffic ends up being sent on downstream interfaces, to what multicast traffic ends up being sent on downstream
including interface I interfaces, including interface I
o increasing the *figure-of-merit* for the (S,G) by the *increment- o update the *figure-of-merit* following the exponential decay
factor* (updating the *figure-of-merit* based on the decay algorithm
algorithm must be done prior to this increment)
o increase the *figure-of-merit* for the (S,G) by the *increment-
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 [RFC4601]) 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 [RFC4601], including sending a PIM Join to section 4.5.7 of [RFC7761], including sending a PIM Join to
the upstream neighbor) 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)
+ then freeze the upstream state machine in Joined state, and + hold the upstream state machine in Joined state until the
setup a trigger to update it once damping later becomes reuse threshold is reached : for the purpose of updating
inactive again. The effect is that in the meantime, PIM this state machine, events that may result in updating the
Join messages will be sent as refreshes to the upstream state based on [RFC7761] SHOULD be ignored until the *reuse-
neighbor, but no PIM Prune message will be sent. threshold* is reached. The effect is that in the meantime,
while PIM Join messages may be sent as refreshes to the
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.
Same techniques as the ones described in [RFC2439] can be applied to
determine when the *figure-of-merit* value is recomputed based on the
exponential decay algorithm and the configured *decay-half-life*.
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. When the recomputation is life* in seconds, rather than in minutes.
done periodically, the period should be low enough to not
significantly delay the inactivation of damping on a multicast state
beyond what the operator wanted to configure (i.e. for a *decay-half-
life* of 10s, recomputing the *figure-of-merit* each minute would
result in a multicast state to remained damped for a much longer time
than what the parameters are supposed to command).
PIM implementations typically follow [RFC4601] suggestion that This specification does not impose the use of a particular technique
to update the *figure-of-merit* following the exponential decay
controlled by the configured *decay-half-life*. For instance, the
same techniques as the ones described in [RFC2439] can be applied.
The only requirement is that the *figure-of-merit* has to be updated
prior to increasing it, and that its decay below the *reuse-
threshold* has to be timely reacted upon: in particular, if the
recomputation is done with a fixed time granularity, this granularity
should be low enough to not significantly delay the inactivation of
damping on a multicast state beyond what the operator wanted to
configure (e.g. for a *decay-half-life* of 10s, recomputing the
*figure-of-merit* each minute would result in a multicast state to
remained damped for a much longer time than specified).
PIM implementations typically follow [RFC7761] suggestion that
"implementations will only maintain state when it is relevant to "implementations will only maintain state when it is relevant to
forwarding operations - for example, the 'NoInfo' state might be forwarding operations - for example, the 'NoInfo' state might be
assumed from the lack of other state information, rather than being assumed from the lack of other state information, rather than being
held explicitly" (Section 4.1 of [RFC4601]). To properly implement held explicitly" (Section 4.1 of [RFC7761]). To properly implement
damping procedures, an implementation MUST keep an explicit (S,G) 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 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 expires, and damping becomes inactive on this state, its associated
*figure-of-merit* and damping state are removed as well. *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
skipping to change at page 9, line 27 skipping to change at page 10, line 23
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 VRF
PIM-SM implementation (in the "C-PIM instance"), with the PIM-SM implementation (in the "C-PIM instance"), with the
corresponding action to suppressing the emission of a Prune(S,G) corresponding action to suppressing the emission of a Prune(S,G)
message being to not withdraw the C-multicast Source Tree Join message being to not withdraw the C-multicast Source Tree Join
(C-S,C-G) BGP route. Implementation of [RFC6513] relying on the use (C-S,C-G) BGP route. An implementation of [RFC6513] relying on the
of PIM to carry C-multicast routing information MUST support this use of PIM to carry C-multicast routing information MUST support this
technique. 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 mechanism, 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
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) are used it can be in a context where BGP Route Reflectors (RRs, [RFC4456]) are used it
considered useful to also be able to apply damping on RRs as well. can be considered useful to also be able to apply damping on RRs as
Additionally, for mVPN Inter-AS deployments, it can be needed to well to provide additional protection against activity created behind
protect one AS from the dynamicity of multicast VPN routing events multiple PEs. Additionally, for mVPN Inter-AS deployments, it can be
from other ASes. needed to protect one AS from the dynamicity of 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, is up to the implementor, but at least one of described in Section 5.1, is up to the implementor, but at least one
the two MUST be implemented. In the perspective of allowing damping of the two MUST be implemented. In the perspective of allowing
to be done on RRs and ASBRs, implementing the BGP approach is damping to be done on RRs and ASBRs, implementing the BGP approach is
RECOMMENDED. 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 the specification in this SHOULD NOT be damped. An implementation of this specification MUST
document MUST whether, not damp these withdrawals by default, or whether, not damp these withdrawals by default, or alternatively
alternatively provide a tuning knob to disable the damping of these provide a tuning knob to disable the damping of these withdrawals.
withdrawals. Additionally, in such a context, it is RECOMMENDED to Additionally, in such a deployment context, it is RECOMMENDED to not
not enable any multicast VPN route damping on RRs and ASBRs, since enable any multicast VPN route damping on RRs and ASBRs, since these
these equipments cannot distinguish these events. equipments cannot distinguish the event having caused a C-multicast
to be withdrawn.
Note well that damping SHOULD NOT be applied to BGP routes of the Note well that it is out of scope of this section to consider the
following sub-types: "Intra-AS I-PMSI A-D Route", "Inter-AS I-PMSI application of these damping techniques on mVPN BGP routes other than
A-D Route", "S-PMSI A-D Route", and "Source Active A-D Route". 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
skipping to change at page 10, line 51 skipping to change at page 11, line 50
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, in the same manner as it would for C-multicast routes (see routes, 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 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 the mLDP protocol, this consists in
applying damping techniques completely similar to the one applying damping techniques completely similar to the one
described in Section 5, but generalized to apply to mLDP states described in Section 5, but generalized to apply to mLDP states
skipping to change at page 11, line 31 skipping to change at page 12, line 31
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, S-PMSI and P-tunnels. For the same reasons as for IP multicast VPNs,
an implementation of these procedures MUST follow the procedures an implementation of [RFC7117] MUST follow the procedures described
described in Section 6.1. 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 based
on BGP extensions ([RFC6514]) these procedures can be enabled on on BGP extensions ([RFC6514]) these procedures can be enabled on
ASBRs and Route Reflectors. ASBRs and Route Reflectors.
skipping to change at page 12, line 7 skipping to change at page 13, line 7
be complemented by appropriate tools to observe and troubleshoot be complemented by appropriate tools to observe and troubleshoot
damping activity. damping activity.
More specifically it is RECOMMENDED to complement the existing More specifically it is RECOMMENDED to complement the existing
interface providing information on multicast states with information interface providing information on multicast states with information
on eventual damping of corresponding states (e.g. MRIB states): on eventual damping of corresponding states (e.g. MRIB states):
C-multicast routing states and P-tunnel states. C-multicast routing states and P-tunnel states.
7.3. Default and maximum values 7.3. Default and maximum values
The following values are RECOMMENDED to adopt as default conservative Considering that, by design multicast streams will be delivered
values: unchanged to the end user, independently of the value chosen for the
configurable parameters, and that the only trade-off being made is an
increase of bandwidth use, the default and maximum values do not have
to be perfectly tuned.
This section proposes default and maximum values, conservative so as
to not significantly impact network dimentioning but still prevent
multicast state churn to go beyond what can be considered a
reasonably low churn for a multicast state (see below for
illustrations in order of magnitude of the effect of these values).
The following values are RECOMMENDED to adopt 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 large 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:
o a multicast state updated less frequently than once every 6s will
not be damped at all
o a multicast state changing once per second for 3s, and then not
changing, will not be damped
o a multicast state changing once per second for 4s, and then not
changing, will be damped after the fourth change for approximately
13s
o a multicast state changing twice per second for 15s, and then not
changing, will be damped after the fourth change for approximately
50s
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
state stops, corresponding traffic may still flow in the network
for approximately 37s before dampening stops being active
The following values are proposed as maxima: The following values are proposed as maxima:
o *decay-half-life*: 60s o *decay-half-life*: 60s
o *cutoff-threshold*: 50000 o *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 reducing the *cutoff-threshold* and/or *reuse-threshold*.
8. IANA Considerations 8. IANA Considerations
This document makes no request of IANA. This document makes no request to IANA.
Note to RFC Editor: this section may be removed on publication as an Note to the RFC Editor: this section may be removed on publication as
RFC. an RFC.
9. Security Considerations 9. 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
skipping to change at page 13, line 47 skipping to change at page 15, line 35
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 10. Acknowledgements
We would like to thank Bruno Decraene and Lenny Giuliano for We would like to thank Bruno Decraene and Lenny Giuliano for
discussions that helped shape this proposal. We would also like to discussions that helped shape this proposal. We would also like to
thank Yakov Rekhter and Eric Rosen for their reviews and helpful thank Yakov Rekhter and Eric Rosen for their reviews and helpful
comments. Thanks to Wim Henderickx for his comments and support of comments. Thanks to Wim Henderickx for his comments and support of
this proposal, and Martin Vigoureux and Gunter Van De Velde for their this proposal. Additionally, Martin Vigoureux, Gunter Van De Velde
reviews. and Alvaro Retana provided useful comments to finalize the document.
11. References 11. References
11.1. Normative References 11.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, March 1997.
[RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route [RFC2439] Villamizar, C., Chandra, R., and R. Govindan, "BGP Route
Flap Damping", RFC 2439, November 1998. Flap Damping", RFC 2439, November 1998.
[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, October 2002.
[RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", RFC 4601, August 2006.
[RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP [RFC6513] Rosen, E. and R. Aggarwal, "Multicast in MPLS/BGP IP
VPNs", RFC 6513, February 2012. VPNs", RFC 6513, February 2012.
[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, February 2012.
[RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C. [RFC7117] Aggarwal, R., Kamite, Y., Fang, L., Rekhter, Y., and C.
Kodeboniya, "Multicast in Virtual Private LAN Service Kodeboniya, "Multicast in Virtual Private LAN Service
(VPLS)", RFC 7117, February 2014. (VPLS)", RFC 7117, February 2014.
[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, May
2014. 2014.
[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>.
11.2. Informative References 11.2. Informative References
[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 [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. October 2006.
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
 End of changes. 51 change blocks. 
137 lines changed or deleted 227 lines changed or added

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